I hadn't seen that type of 'high' performer much for most of my career, but now I work at a place that appears to be plagued with them. I think some cultural practices foster that bad behavior, common in places that move fast.

One of them is to value support and firefighting very highly. The best firefighter is often one that is also the most familiar with the code, so it's common to see amazing firefighters that are also your arsonists! But when you don't track where the bugs come from well, and have little code ownership, whoever writes the most code writes the most bugs, does more firefighting later, learns more about the system, and distances themselves from the rest of your developers that actually want the system to work. This also increases the amount of tribal knowledge (as systems get quirky and badly documented), making it harder for anyone else to seem like a high performer, as to make any changes to anything that isn't new, you have to learn how the rest of the snakepit works. And as you learn how it works, it gets bigger, because the "high performers" are creating debt far faster than anyone else can learn it.

If bugs are treated seriously, tests are treated seriously, and how easy people join a team is considered an evaluation criteria for the existing team members, not the new ones, things are different.

> whoever writes the most code writes the most bugs

I'm experiencing this first-hand now. One colleague is writing lots of code very fast. Problem is, this code is far from perfect, and I spend a lot of time to understand it, and I find many bugs quite often. In the meantime while I'm reviewing, the guy writes even more code...

Hopefully you're not merging the feature branch until it passes code review. And if there are bugs, then you kick it back to him with all the comments you made.

In my experience, these types of employees are "too busy for that". And they typically have the political clout that they can continue to get away with it. I'm not saying it should be that way, and YMMV, but it's how I've typically seen it play out.

I definitely been at places that regard firefighters as heroes and people who want to build houses that don't burn down in the first place as trouble makers and pessimists. It is a terrible culture to have and sometimes it is difficult to get away from, because to admit that you've built a fragile system is to point the finger at someone for work they did months ago or to point the finger at yourself.

Very sharp summary. I definitely recognise this.

and then you end up with a company where one or two people are utterly indispensable.

Some organizations have that tendency no matter what is done. It's perceived as more efficient.

Nobody has any idea of how to place a value on any of those things, so you're just making it up so far as they are concerned.

Your development process is broken. How "high performer" can create technical debt in first place? I, personally, will not close ticket until it is well documented (i.e. code has comments, documentation is updated, ticket has resolution summary), and test cases are created (to be sure that nobody else will broke new code by incident), and code and test cases are properly peer reviewed by at least one member of the team (to allow information to spread across team), and all issues are addressed. Moreover, tickets are short, so they are easy to done and review.

I would disagree on this one as well, but it depends on the industry, and on the mindset: if you hire people that have only ever worked in go-go-ship-crap-but-ship environments you can't expect them to suddenly start thinking about unit tests, technical debt and good code hygiene, they need to be mentored to switch to that mindset (which is where the advice of mixing young/old talent comes in).

To give you an example I have been working for over 10 years at the same company and have to support today infrastructure code I wrote 6-7 years ago, and the previous company I worked at I worked for 5 years in a similar environment.

You can bet anything I write is VERY well unit tested and VERY easily understandable, and am extremely careful about technical debt and will push back quite strongly if asked to incur it "just for this ad-hoc fix/feature/deliverable", but that comes from a career spent with a certain mindset, when I was fresh out of university the words "unit tests" and "technical debt" were not part of my lexicon, I had a lot of algorithmic knowledge, but in a university environment you aren't drilled nearly as much as you should be on good code hygiene and practices.

If it was me in universities I would have a course in your 1st year where you have to develop some sort of application, and in your 5th year a follow-up course where you have to extend your original application and a classmate's in some significant way, that would drive the technical debt and writing code/docs/comment so you/others can understand later points very well.

And I would make it very clear over and over again that it's not the case that the less lines of code you write the faster it's executed, and that often the most compact solution ends up being the slower and less maintainable one.

That is a really good idea! Having people revisit old work is a powerful tool in learning. Definitely stealing this idea. :)

I've actually worked with that kind of "high performer". The guy was actually good, always on top of his game and aware of everything that was happening across product teams, but his haste to get things done quickly led to a lot of technical debt in our part of the product. He just checked things in continuously without waiting for a code review. Feature-wise he was adding a lot of value to the product, but always at the expense of code maintainability.

I was the one who couldn't sleep at night seeing all that debt and every now and then would clean things up. At least he would thank me for it :)

Developers come in many different forms, and I think this kind of "high performer" can be most valuable in an early-stage startup environment, where code quality hardly matters if product-market fit cannot be discovered before the runway ends.

I also suspect that many of these "high performers" are very aware of the technical debt they are adding, and simply prioritize shipping over anything else. To them, the mess is just a fact of software development, to be cleaned up only as can be justified by the needs of the business.

In general I don't actually agree with this view, but I also try not to dismiss it outright. (My counterargument usually involves the fact that technical debt will slow you down in the mid-to-long term, so if there is any expectation of keeping code around, it actually saves the business money to invest up front in code quality.)

Shit, that guy is me. I have brought back more or less dead projects with some good ideas and showcasing them.

OTOH, I am constantly worried I am too slow (the legend of the 10x developer does not help) and tend to omit test cases or leave code in that works but is not easy to read or understand.

At least I use every time I find to refactor code later, but we've had some bugs in UAT which shouldn't have been there.

If you refactor it later, I think it's fine. But this guy would keep cranking out code like mad and good luck keeping up with it. It was a bit insane at times.

Code reviews do not have to block checkins. See also "continuous integration". It's a way.

Part of our review process automatically compiles the new code, then runs unit and integration tests. The review is mostly for checking that new tests properly cover the change, the style and structure of the new code, and other problems that can't really be replaced by CI.

I'd think style and structure would be agreed on up front and possibly partially enforced by a formatting tool like Astyle. of course, prototyping might be something that can be varianced, so long as its agreed that the prototype will be discarded. But a given shop may not have the maturity for that. Shame, really.

Nobody ever wants to do it, but I've used a statement of work approach in the past.

I once used the wrong version of coding standards in a shop, and heard about it in a performance review. I'm in no way convinced this was inadvertent. My piece had negative defects - I found a dozen or so old crufty bugs in my testing. The rest of the team took months getting integration right.

We had a process: every code reviewed by at least one team member before checking in.

Perhaps, with the right kinds of expectations and code review processes, many of the "high performers" to which he refers end up becoming the "low performers" that you see as the cause of most technical debt. People who, in one environment, are able to ship buggy code quickly (and without much consideration) find themselves, in a different environment, spending abnormal amounts of time writing and reworking code in order to get it through a code review process.

He kind of mentions it, but in a very early-stage startup, the ability to deliver MVPs quickly (regardless of code quality) may be seen as a positive trait. Of course, even better is when you can ship quality code just as quickly, but such developers are probably the exception to the rule.

It's a question about the definition of a "high performer". From management's point of view, it's about implementing features - and it can happen that a person can implement a feature fast but mess up internal code quality. From a programmer's point of view, a "high perfomer" is someone who makes a change in software that is properly done on all levels - functional and non-functional.

When I read the article, this section annoyed me. You hit the nail on the head with this. I think the author should put this quote into the article to improve that section. Based on the rest of the article I think this is what he meant too.

Agreed, and it is not limited to web development. Effective developers seem to know what they are trying to do, have a plan for how to get there, and have a mental map of where they are, while poor developers are groping for a solution in a fog of confusion.

The author's claim is almost self-contradictory: if technical debt is bad, then anyone using it to create the illusion of being a high performer will end up hamstrung by his accumulated debt.

IME: The "effective" developer is never the one who has to clean up the accumulated debt though. They are pushed off to new projects before the warts start to show. It's everyone else that has to clean up after them.

Yep. They're moved on to the next project that needs their speed and expertise. Cleaning up the mess is usually left to those who don't pump out new lines of code quite as fast.

Good point - I have seen that myself.