Your Developers Aren’t Bricklayers, They’re Writers








Robert Glass, Facts and Fallacies of Software Engineering




Fred Brooks, The Mythical Man-Month

Let me give you an actual (yes, IRL) example

(Names have been changed to protect the innocent.)

This test/fix cycle is repeated two or three times.







Congrats! Rejoice! Champagne again!




Phil Haack, 10 Developers For The Price Of One

Now, what is the worst that could happen here?




So, why does this go unnoticed so often?





Related articles:
10 Developers For The Price Of One
What Makes Bad Programmers Different?
What Makes Great Programmers Different?

Who am I and why am I telling you this










  1. I really liked the read and have experienced the Rockstar vs Lousy in a startup. In that case it was accepting credit card payments – one guy did it in a week where the other spent months and it never shipped. In the first case, if static code analysis were in use, we would have seen his code was hopeless much faster. What are your thoughts on linting and code analysis to help send out some early warning signals to others?

    (bias disclaimer: working on a startup in this space)

  2. Yours is yet another reminder of some of the time-tested truths of software development. The best are not just slightly better than the worst. There is a wide gulf of productivity and quality depending on who is assigned to each project.

    As your story illustrates, this can lead to disgruntled employees who feel unappreciated and undervalued. This leads me to two questions. From an employer’s perspective, how do you attract and retain these top talents. From the point of view of an employee, how do you promote your own talents and get rewarded for your work?

  3. Great write. I’ve been using the same writer anology. I also think we piss away a lot of software dev productivity by making tasks collaborative that really are’nt. If you want to have a bestseller, is it a good idea to have 10 junior developers in india write it?

  4. Its not only correct that its hard to measure developer productivity but no one takes into account developer peak and trough cycles either. I can go full on for about two iterations and then I slump for an iteration.

    • Sir Code-a-lot

      March 31, 2015 at 9:56 am

      Sprints do not apply to rockstar developers, as they`re better at splitting tasks and prioritizing them. If they had to deal with unneeded management overhead, they would not be rockstar in the first place.

  5. I think that there’s a problem with the whole “Rockstar” mentality. By separating performance and manifesting them in 2 different types of people, you might be ignoring a totally different type of collaboration and work.

    Lets think about different environments depending on different circumstances.
    Exhibit A (which I don’t have much experience with.) A small team of collaborative programmers / designers / project leads / QA which works collaboratively, intelligently, and calmly. They get the work done and go home for a beer after work. They use “agile” technologies and have the methodologies in place for working quickly.

    Exhibit B. A true to life organization which has concerns dating way back when. They use legacy code that constantly needs to be re-factored, and they have strict organizational tendencies.

    Exhibit B is more likely to fertilize a situation where one can BE a Rockstar. Due to the separation of roles in the organization – business needs are met much quicker but development needs are not so much. Development is entirely driven by the immediate needs of the business which are often driven by profit. These situations are sink or swim and Mr. Lousy’s and Mr. Rockstars will pop up according to the situation.

    Although I don’t have much experience with an organization like Exhibit A – the egoless programming and happy community seems perfectly at home with being further away from life as ever.

    • I would actually argue that it’s easier to spot the Rockstars in exibit A. Most of my work has been in small teams similar to what you described. Everyone is given a small set of tasks and there’s a lot of code reviews and overlap all throughput the process. This makes it much harder to hide bad developers as each team member must be able to pull their own weight. It makes it blatantly obvious who takes WAY to long on tasks, and who needs design help.

  6. I agree. Right now I work on a team with 3 other developers; two of the developers are new and not really up to speed, so I won’t count them. The remaining dev is a front-end web dev, and I usually make the back end for him. I’ve noticed that it usually seems like he’s making all kinds of progress to higher upsbecause they can easily see what he’s done- go to this page, boom, all kinds of new things. When it comes to my work, even though I made the core that the front-end guy relies on, it looks like I’ve spent a lot of time dicking around and haven’t done much. But, I have in two weeks made new functionality that the previous programmer said wasn’t possible.

    • The answer here is to stop specialising on front end or back end and learn to code the full stack. Or stop complaining.

      If you stop building the backend features it forces your boss to assess your value… or maybe those backend features aren’t really that complex.

      As a former backed developer who now codes regularly on both sides I can honestly say that both worlds are hard – but the value gained by learning both parts is gold.

      • That’s not the point though. In Tyler’s case, because he has been casted into the “backend” development role, his work might not be as appreciated – even though its equally complex.

        The article though tries to cover this by recommending that the higher ups be better versed with the development process – so that they can retain good talent.

    • You can specialize on backend, you just need to sell you work better.

      You see when the front dev, tells your boss that changing the button from blue to yellow will increase sales conversion by 8% he is doing a napkin calculation or pulling numbers out of his ass(unless he has real A/B test reports to back that up).

      Now if you change all yous apis from xml to json you can run a crappy microbenchmark and report to you boss that the new json parser is 20% more efficient than the older xml one and that will save the company 8% in hardware costs yearly(or you can take time and run a real benchmark to see the impact).

      PS: Your work has value and it’s your fault others can’t see it. Shove it to their faces.

  7. This reminds me of another kind of programming – optimization. I worked for a large organization with 500 programmers, and a large base of code written in ‘c’. A module needed to be sped up and my office mate and I were well known to be effective at this sort of thing, but the boss wanted to showcase one of her engineers and help her to get promoted. When she was done, the code was slower than the original. So it was passed to me and my office mate. Like your story it was done right the first time and at about 1/2 of the staff hours.

  8. You dont mention what I call “janitor syndrome”. Mr Rockstar has now spent a month mopping up Mr Lousy’s code. Playing the janitor. But because Mr Rockstar has not been present in all the requirement meetings etc, he has to catch up on some required knowledge. The time he takes to rewrite Mr Lousy’s code is actually more than the time he would have taken to write the code if he had been on the project from day one.

    Meanwhile, Mr Lousy has had this problem taken off his plate. He is suddenly free to start with other work. It turns out that the boss has a backlog of things to be coded, and hands off the next item to Mr Lousy to implement. You know how well that’s going to turn out.

    In the mean time, Mr Rockstar has completed the rewrite, everyone is happy. The boss asks Mr Rockstar if he can quickly look at Mr Shoddy’s project, which is experiencing similar problems to those Mr Lousy’s experienced. Turns out its a similar situation. Because customer’s are screaming, Mr Rockstar has to rewrite that too, as in yesterday. Again, he doesn’t have all the information required, but he manages to find everything, and delivers a working result in a slightly longer time than would have been the case if he were to have coded the project from the beginning.

    Again, everyone is happy, but look! Mr Lousy has in the meantime been working on a new project. Its a mess, customers are screaming. The boss would really appreciate Mr Rockstar having a look at what is going on. Again, he is mopping up after someone else.

    Eventually, Mr Rockstar is a full time janitor. He spends all his time mopping up after others. Ultimately, having the other two around is wasting money, and time as Mr Rockstar would actually have completed the projects faster if he were involved from day one. Also, there would be a lot fewer annoyed customers.

    • Say, just wanted to say that I agree wholeheartedly with this post. I’ve seen that scenario a lot in my career, across multiple organizations.

      The janitor problem, in my experience, usually ends up with a situation where Mrs Lousy and Mr Shoddy are seldom held accountable, as they are usually pulled off of the project gone bad to work on the next great thing. They then leave Mr Rockstar to deal with their mess, and sometimes it’s Mr Rockstar who gets associated with the problem, even though he was just the guy brought in to save the day.

      I have found myself questioning whether this happens because management is ignorant of the situation, or whether it is intentional because they are trying to prop up and protect certain classifications of employees.

      Maybe it’s a bit of both.

      • @Soren I actually know what management would think. You’re the rockstar, you should do more job, because that’s the teamwork. Lousy etc would be the backup if you quit.
        ehhh… more money? You’re not a manager right?

    • @Jesse that’s really my daily tasks too, struggle for rewriting projects without ‘requirements’ but actually many hidden requirements.

  9. The 28:1 ratio is often cited and originates from a paper published by Grant & Sackman’s in 1967. Some argue, eg., that using Grant & Sackman’s data, that the real ratio is more like 14:1. Which is still an impressive number.

  10. You said Mr Rockstar and Mr Lousy performed the exact same task. They did not. Mr Rockstar benefited from significant hindsight: with the semi-working prototype from Mr Lousy he had the _final_ requirements, and a list of bugs to avoid.

    He may be more productive than Mr Lousy, but this experiment isn’t enough to measure how much. We need more details about the task at hand to asses the situation.

  11. Great article, and 100% agree. I started out as a salesman, then project manager, then designer, then front-end, then backend, and finally product manager and can completely emphasise with everything mentioned here 🙂

  12. At story about Mr. Lousy and Mr. Rockstar you miss the point that crafting software from scratch and rewriting (or porting) a software is two different task. Rewriting the software usually can make 10 times faster that crafting from scratch because when rewriting, the material is already there.
    I don’t really agree with the following statement:
    “The huge difference between these two developers only surfaced here because they performed the exact same task.”
    Maybe not the same task, but the same goal.

    • Even though Mr. Lousy’s code was terrible, the bulk job of development got done, which is to detail out the requirements of the end product. So I agree with your sentiment, the comparison is not fair as the tasks would be substantially different.

      In cases like this, when the stars align for a disastrous outcome, it is often a good idea to take a step back and do a post mortem analysis of the project. I am confident that Mr. Lousy was only partly to blame for the outcome, and the biggest problems are yet to be uncovered and dealt with.

      That’s not to say that Mr. Rockstar and Mr. Lousy aren’t different in levels of proficiency, just that there is a lot you can do to even out the differences and make lousy programmers shine. The challenges in this occupation exists on multiple levels, and you can usually isolate a number of root causes.

  13. I agree with everything except the assumption that such discrepancies don’t exist in “commodity” jobs like bricklayers and janitors. As someone who currently works in IT and has previously worked in the trades I can assure you that varying abilities in trades can have very significant impact on projects. Especially on big jobs, where there are a lot of different trades (carpenters, plumbers, electricians) who need to work in a coordinated fashion and be aware of how their work affect those who come after them. It cost a lot less to fix a plumbing leak or make an adjustment BEFORE the sheet rockers cover all the pipes. The best tradespeople are aware of these issues will attempt to work accordingly. The key difference between this scenario and a software development team is that on a dev team, everyone is ostensibly on the same team, whereas in the trades, the carpenters and electricians and plumbers usually all work for different companies. So from a job performance assessment perspective there is significantly less incentive for them to work together. And yet, the best, the ones who take pride in their work, usually do make the effort, often resulting a huge savings. And just as with “rockstar” developers, often unappreciated by management.

    Officially, coordination is the job of a general contractor, just as in software it is the job of the project manager. But we all know that in reality a project manager can only do so much in that regard – at some level it is the responsibility of every dev on the team to work as a team. Likewise in the trades.

  14. Speed of development is not a good benchmark. Nor is the volume of code
    generated. I worked on a project where the lead developer generated code
    at a furious pace, introducing a new feature at each monthly meeting. By
    any “metric” this would appear amazing. The code leveraged patterns and
    conformed to all the latest buzzwords.

    Unfortunately, reality bit the project hard. The first ship was delivered to
    the customer in a state that wouldn’t even compile. After the lead left we
    found out that nobody else understood the primary data structure. There
    were no explanations. There was “javadoc” of the API but it was useless.
    The final code could not process much beyond toy input.

    The lead “retired into management” at another company and is generally
    hailed as a first-rate programmer. Hit and run rockstars.

  15. Joshua A. Schaeffer

    April 1, 2015 at 1:23 am

    I always knew one good programmer could match more than one bad programmer, I just never allowed myself to admit that it could equal a whole team, because that is a hard thing to convince a non-programmer. But I have definitely seen and demonstrated it in practice.

  16. I’m currently in a position where i have to assume a rockstar role while being lead for the web part. At one point it is very interesting since I have vigouriously taken ownership of the codebase and ramped it up to a much more maintainable level in three months, i do have a coworker that could be described as a mister lousy. Though a great guy, he doesn’t evolve and barely manages to follow my lead, and has a hard time understanding his anti-patterns. My output is 3 times as high and 3 times less buggy and I’ve revamped one third of all the modules he developed since I joined.
    Management knows this but he is still usefull for the legacy clients so as long as he doesn’t work on the payment system and other critical processes. And i now know I have to ‘janitor’ from time to time, still hoping to get that one amazing devops intern i’m hoping to find

  17. It’s lovely to reason about Mr Rockstar, Mr Lousy and Mr Shoddy, but where does this leave slow, cautious coders like me? I don’t consider myself Mr Rockstar because I don’t think I’m fast enough. Certainly Business seems to wish I would hurry up.

    I think of myself as a solid coder. I read a lot. I try to understand the tech I’m working on. I implement design patters, and spend a LOT of time thinking about design and architecture before I start coding. My code is neat and manageable, fairly bug resistant and usually easy to maintain or extend. However, I need to build a complete mental model before I can start coding, of how thing fit together. Once the model is done, the code flows like water from my fingers, but until that point I’m staring blankly at the wall while the project manager does the Impatience Fandango around my chair.

    In your world of Ms Rockstar vs Mr Lousy/Shoddy, there seems to be no space for me. I’ve grown cynical of fast “rockstar” coders because they don’t seem to spend a moment on planning; features are all over the place and duplication abounds.

    So am I wrong? Am I just a stodgy old-timer? Should I be grasping the intricacies of the model faster or just not think about it anymore?

    I think there are more variations of coders than just the Rockstars and the Whatevers, but since these are the only two ever mentioned, if you’re not the one you must be the other, and I don’t agree with that.

    If code mattered more than how quickly it took to write it, I might have a little rockstar in me 🙁

    • Piet

      April 5, 2015 at 2:39 pm

      “My code is neat and manageable, fairly bug resistant and usually easy to maintain or extend.”

      Well, that seems like a Mr Rockstar to me.


      Yes, but you say your code is manageable and fairly bug resistant. So when you deliver, it’s pretty sure that you’re finished and won’t spend an unknown time squashing bugs and annoying colleagues and customers in the process.

      The image I’ve got of a Mr Rockstar isn’t someone who starts hammering the keyboard 2 minutes after he/she got a new task.

      And there are indeed more variations of coders, but this is just an example. I wanted to make the point that there can be a lot of difference between someone who knows what he’s doing and someone who really hasn’t got a clue.

      When programmers think about 10x coders (how it seems to be called), they often see themselves as average and can’t believe that there are others who possibly work 10 times ‘better’.
      But, they should rather think about the worst vs the best programmers they know. And then I guess most will agree there can be a 10x difference (and unfortunately that management is totally clueless about it).

  18. I’m bricklayer who is learning programming and I thought I would google bricklayer programmer to see what would come up. It was nice read and I can see your point but bricklaying would be a bad example for the point your trying to make not because you need to know a lot, even though you do need to know a lot if you want to be respected within the trade but because the skill levels are really varied which is why a lot of firms do it on pricework for example I layed 1000 bricks in one day and earned £330 for the day but the worst I’ve seen is a 30 yr old man put a piece of lego in between his cross joint to get exactly 5mm and he layed about 50 in one day, it was an absolute joke.

  19. Interesting writeup which I agree to except the writer analogy – pure BS. How would you explain Twilight and 50 Shades of Grey? Those have shoddy editing, errors everywhere, and still sell like hotcakes. So, not a good analogy.

    • Piet

      July 21, 2015 at 10:05 am

      At least they reached their goals: be interesting/entertaining and sell millions.
      And 99.9% of their readers won’t notice the errors or shoddy editing.

      I’m sure there are errorfree books out there with excellent editing that were recycled to toilet paper after X years. As well as bug ridden pieces of software with a crap interface that went on to become hugely successful.

      But OK, there might be better analogies (which?).

Leave a Reply to George Cancel reply
