Fog Creek Software
Discussion Board

Regarding Joel's latest article

I have read (more like made a quick pass) Joel's most recent article titled "Lord Palmerston on Programming" and I feel that Joel might need to include a second summary section for "those that just don't get it" on all his articles. 

Recently, I was visiting another forum where this article was referenced as proof that companies should only hire developers based on prior tool usage and platform familiarity.  This logic makes sense to me if the person you plan on hiring will be using those specific tools and technologies at your company for several years.  However, outside of small shops like Joel's this advice typically doesn't make a whole lot of sense.  Unless of course, the person who gets hired will be required to maintain legacy software systems.

Now, I could care less how other developers interpret what they read here, however, I do care that team leads and hiring managers might be reading his articles and using them to justify their own hiring beliefs.

Here is how I interpreted Joel's most recent article. 

Those who claim to have exposure/experience with just about every technology under the sun might not be lying, however, most of them are far from reaching master level status in each and every one of those technologies, languages, etc.

When starting a non-trivial software project, you should make sure you have a strong technical lead working on the project.  If high-productivity is your main concern then choose your technologies wisely.  If possible, select the ones that that give you the highest return on your investment.  That is, the ones the majority of your team members are most familiar with.

one programmer's opinion
Thursday, December 12, 2002

I am not sure you have any disagreement with Joel’s article.

However, hiring a person who has several years experience on a key technology is going to mean a lot. In fact, even more important is that YOUR DESINGS must take into account the technology being used.

Also, since the design part is the hardest, then you better get a design that works well with your existing tools.

The skill level of the developer will make or break the project.

Hence the #1 consideration is at what level the developer is at. There are certainly more levels then just "trained" or "not trained". Generally there are a "lot" of skill levels, but the following breakdown is sufficient. This following list is from Edward Yourdon’s book. **

Stage 1 Innocent (never heard of the product)

Stage 2 Aware (Has read an article about X)

Stage 3 Apprentice (has attended a three-day seminar)

Stage 4 Practitioner (ready to use X on a real project)

Stage 5 Journeyman (uses X naturally and automatically in his job)

Stage 6 Master (has internalized X, knows when to break the rules)

Stage 7 Expert (writes books, gives lectures, looks for ways to extend x)

One should NEVER attempt a project with a team consisting with Stage 3 or lower people. This is a sure fire formula for failure. The team can consist of stage 4's, but they should have at least access to Stage 5, or 6.

Thus, we are going to assume that the developer is real good. However, good familiarly with the tool can make a huge difference.

For example, lets take a program written on Old FoxPro/dbase. In those systems, the order of data entered into the system is preserved. That means your designs for entry of data, and then perhaps having another user check, or use that data can assume that the data will be in the same order. In other words, the next part of the code/program can assume that the data is in the correct order. On most modern database systems, order of records (data) entered into the system can NOT be assumed. In fact, new systems (or some old ones like Pick) do NOT EVEN expose record numbers. JET for that matter also does not preserve data order.

In other words, the whole workflow design for how the application is going to deal with data, and how users interact with the application is going to be effected. Punched cards kept order. So did dBase/FoxPro systems. People with years of experience made the jump from punched cards to systems like xBase.

However, on the systems that came after that, the order of records must always be enforced. A lot of people had great difficult with this seemly simple concept. It also means that the designs that a experienced developer chooses cannot be based on what * used * to work. In other words, even years of experience can cause very poor designs to be chosen when using NEW tools.

In fact, most systems like Pick, (old), or new like SQL-server) do not, and cannot use record numbers anymore.

In database systems like Pick, there is in fact NO AutoNumber generation of ID’s, and also no built-in ability for the system to assign a record id (key). You have to use, and make up your own system. Again, designs in pick thus OFTEN use compound keys. (ie: date*roomnumber). You become a master of making up keys for records when you use Pick. If you never used the system, after a few mind will enable you to come up with schemes for record id’s (and some are bizzare!!).

My whole point here is that these subtle of differences can cause HUGE problems if you try and use a design that works well in one system, and now start using a new tool. In other words, the tried and true and standard approaches that you learned over the years will no longer apply to the new system. This is despite the fact that you dream in tables, and are a first rate database developer.

Also not mentioned is that only after a few years does one really learn what designs perform well. In other words, the speed/performance of the product will suffer LARGE if the team does not know the product well.

Hence, that * extra * knowledge Joel talks about will make, or break your next project in several areas. (performance, designs etc).

Albert D. Kallal
Edmonton, Alberta Canada

Albert D. Kallal
Thursday, December 12, 2002

I disagree.  I think that once you reach a certain level, you can lead pretty much any sort of development project.  Take a Ken Thompson, or a Dave Cutler, or a Linus Torvalds, etc.

You could let these guys lead pretty much any sort of SW development project in any environment and you are going to have a great chance of success.  Sure they are going to take a little extra time to pick up the intricacies of a particular toolset, but they will so it very quickly.


Peter McKenzie
Thursday, December 12, 2002

>>Sure they are going to take a little extra time to pick up the intricacies of a particular toolset, but they will so it very quickly.

First rate developers will pick new tools quite fast. However, a good 8 months is still required to lean most systems to become * really * productive.

It also is a question how many technologies one has to deal with. A program written in old xBase was real simple. Today, you will use SQL, and a bunch of ADO recordsets. Just learning sql, t-sql, and using connection objects and the recordsets is already FAR MORE to learn then all of the whole dbase system was back then. In fact, just dealing with how to setup security today can take more effort then a whole project did back in the old days.

Hence, a good developer can transfer their good table and normalizing skills, but the mastering the environment is a long process.

I used to work in Pascal.  I have been considering making a jump to start using Delphi since it is cross platform. I would guess it would take me AT LEAST one year to start becoming productive in Delphi. At university (computing science), we would learn a new language for each lab assignment (that was every two weeks), so I am no stranger to learning new platforms.  There is huge difference between writing hello world program, and learning that the nesting of functions and subs is COMPLETELY different when using Pascal vs a language like C+.  Writing a program to simulate a gas station Que using pointers and a linked list for an home work assignment is nothing compared to what one has to write in the real world (darn good start, but 2 weeks is not a project).

I will say at the 6 months mark a developer is now starting to absorb what will work, and what will NOT work.  I have no idea how the classic parent to child data designs are handled in Delpi. Perhaps they use the lousily way that VB does? Of course VB does have a declarative statement that you can use to get VB to handle the parent->child relation, but VERY few developers even know about it’s existence! As a result, the developer starts writing tons of code, when little, or even none is needed!. (if you use the statement, then when you add child records, the relational id is set for you with NO code).  I know for sure that my many years of experience using systems like Pick, or VB or SQL are not going to apply to how the classic invoice and invoice details is going to be handled in Delphi/Kylix. The same designs will not work.

In addition, with Kylix, we are now no doubt using a different data engine, and again major design decisions have to made. You can’t possibly tell me that the above answers are easy. To get up to speed writing a business application in Kylix is going to take a LONG time. Heck, it can take a year to just to master Postgress, and that certainly would be my data base engine of choice. In fact, just learning the data engine is going to take at least as long as learning Kylix (in fact, probably longer).  Of course, during this time, one’s designs are going be very crappy indeed…since one does not really know what works..and what does not.

Gee, a simple change to Kylix? Wow, new secuirty model, new database engine, new IDE, new sql syntax (gee what kind of sql statements does PostGress NOT support?). What do the triggers look like in PostGress?

The above is the short condensed list...

Albert D. Kallal
Edmonton, Alberta Canada

Albert D. Kallal
Thursday, December 12, 2002

Hi Albert,

Generally speaking, you are correct.  I don't have any problem with Joel's article.  However, I do have a problem with the way some people are interpreting his thoughts, which in this case, might be me.  :)

Here is the problem that I have with this issue.  In the computer contracting world, it is common knowledge that if you don't have technical skills (that someone PAID you to use) that closely match a particular job order most brokers won't bother contacting you.  This practice now seems to have been adopted by all types of employers.  In effect, the industry has established a system where technical people are not only temporary but disposable.

Does the fact that someone has primarily mainframe development experience (or AS/400, Unix, etc.) on their resume mean that they should never be allowed to work on a Windows PC application or software project?

one programmer's opinion
Thursday, December 12, 2002

Ah, ok..I do understand you now.

It is far too often that some people don't even get a chance at some jobs since they lack one stupid skill. 

Worse, is your example!

It really comes down to what walks trough the door. If I need a pick programmer, then I going to head over to a company that specializes in hiring pick people .

For example:

If you have multi-value DB experience, then that company above can help you find a job. If you don’t have mv-experience, then you have nothing to offer the above job board. It is a waste of your time and their time.

Companies that need a mv developer just cannot afford to train one. Perhaps 5, or 6 years ago, the situation was different, and many companies were willing to take any developer. Today, with the current market, special skills count.

Joel has often mentioned several times that this business is all about turning code into dollars. Well, from a Companies point of view, it is in fact the other way around:

  Taking dollars and turning it into software!

Companies must, and will do whatever it takes to get a project done. You cannot ignore the cost of a project. I wish we all could work for the government, or the Military.

There is simply no choice to hire the talent with the right skills. Last month I integrated a Excel spreadsheet (VBA) with a pick system. A developer with strong VB and Excel skills would have NOT fit the bill, unless the company was willing to fork out a month or more. To complete the project a person needed good VB skills (VBA is really the same as VB these days). As it was, it was only a 2 day project for me since I know mv systems. I also know VB. In theroy, the project could probably have been split between two developers (if the project was larger).

However, your point is fair. If the project involved a team of 5 or 6 people, then certainly one of the people on the team can be a newbe to the current system despite being a experienced developer. That is the best type of opportunity to learn under. However, as mentioned, it is a issue of cost.

The dot com bust did something very good to this industry:

    Companies now pay for results…..

Albert D. Kallal
Edmonton, Alberta Canada

Albert D. Kallal
Thursday, December 12, 2002

Albert, everything you write is understandably very much from your own perspective.  You write about the sort of things you might find difficult or challenging, about the sort of details that you can't imagine anyone could come to grips with without months of hard graft.

Thats all well and good, I know where you are coming from.

But like it or not, there ARE people who are just much much better than average or even good developers.  These people take weeks not months to become proficient in new environments.

Peter McKenzie
Thursday, December 12, 2002


I understand what you are saying, however, the problem is that this industry is NOT willing to hire talent who not have the right skills.  Employers only want to steal talent from other employers.  That is, they want people with the right skills and they want people who have been PAID to use those skills. 

As your last post pointed out you were able to use your existing skillset to complete a task that probably would have taken someone without your unique knowledge/skillset a lot longer to complete.

However, what if you didn't have prior paid VBA experience on your resume, but you had previously created several MS Office applications on your time?  In many situations, the fact that you have learned VBA programming on your own time (by taking a class, doing projects at home, etc.) doesn't seem to count for squat even though you can demonstrate that you have knowledge/skills to get the job done.  This is a point that I probably failed to get across earlier. 

I understand why specific programming skills are important to many employers, however, in my opinion obsessing over this one issue (not you but the industry in general) seems to me to cause more problems than it solves in the long-term.

one programmer's opinion
Thursday, December 12, 2002

>>>But like it or not, there ARE people who are just much much better than average or even good developers.  These people take weeks not months to become proficient in new environments.

Well, those are not the norm, so what you say is really a moot point. The best top dog developers I have ever met did not even come close to learning the windows environment or the windows API in a few weeks. In fact the very best I know still will state that they only know small part of the windows OS. Learning these new systems takes years…not months…

So, maybe there is that one in a billion that learn and internalize the windows Os in a few weeks, but for the rest of the folks like me who finished at the top of their class…it takes us longer…..

Why do you think a company even bothers looking at experience?

So, I rephrase this:

A top fight developer who is the top of the class will take a good year  to really learn most of the new environments, especially when you consider how many areas must be mastered.

The above may not apply to that .000000001 %, but for the rest of the worlds top flight best in class developers…it does apply.

In fact, for a single system/language , Peopleware quoted about 6 months. Of course today, you have to learn 3, or 4 or even 5 different systems. You can do the math, and start adding up the time for each system…

Albert D. Kallal
Edmonton, Alberta Canada

Albert D. Kallal
Friday, December 13, 2002

Experience does not relate to skill.  I have worked with a lot of developers that have many years experience, but they did not learn from that experience.

One of the best programmers I ever worked with on a Windows C++ COM project had never touched any of those technologies before.  He was hired because he was bright.  He could program extremely well in assembly.  The people who hired him saw transferable skills such as problem solving, initiative, determination, research skills , debugging skills, etc.  These skills are very hard to learn.  Learning how to draw text on a windows GDI is not very hard.

Friday, December 13, 2002

>> First rate developers will pick new tools quite fast. However, a good 8 months is still required to lean most systems to become * really * productive.

Yes, but here we were talking about system architects.
Architects don't have to be * really * productive. No, they have just to have a good idea about how the tools work and what to expect from them. Then, the * programmers * are the ones who have to be productive.
So, back to architects don't code. Which is normal and practical, no matter what the programmers might think.
Somebody with good experience in system design and project management cannot be expected to also know how to take com objects out of the memory, even if that is a good thing to know for a programmer.
Golf, on the other hand...

Friday, December 13, 2002


Transferability of skills.

The first contract I had working for myself was to port a device driver for the Tandon Data Pac to the Qnx operating system. 

The device driver I was going to port was written in C and macroed to the eye teeth to try and get some portability into it.

I had considerable knowledge about the hardware and about how the Pac interfaced with DOS.  I had zero knowledge about the driver because it had just been released  as I was leaving Tandon and it was relatively huge for a device driver.

I knew virtually nothing about QNX, I hadn't even seen it.  I'd been told by the company that wanted the driver that it was Unix like. 

I had a working driver within about 10 days, it wouldn't boot the device, but you could mount it, unmount it, eject and load drives.  Most of that time was spent staring at macros working out what was going on.  The QNX side was relatively simple.

Getting it to boot took work with QNX and it turned out to be the size of the driver, an updated kernel and it worked fine.

Now, this little story isn't intended to show what a genius I am, just that I applied skills I already had in a situation that was relatively novel.  I'd say that a good 40% of whatever I've done over the past twenty odd years I did for the first time.

Simon Lucy
Friday, December 13, 2002

If your only metric is learning the windows API then your view of the world is quite skewed.  The windows APIs are by far some of the most convoluted and inane APIs that are out there.  Does experience in developing to the windows APIs translate to other systems?  No it does not, but oddly enough the converse IS true.  A well seasoned OO developer from another environment can produce a good windows app in time.

If you learn to think in 'windows' your ability to translate your experience to other platforms will be greatly hampered.

I've seen the results of both scenerios enough to be confident with that statement.

I also agree with another poster that there are master developers out there that can be up and productive on a new platform/system in a few weeks.  I've seen it happen.

Wednesday, December 18, 2002

*  Recent Topics

*  Fog Creek Home