Hacker News Reader

Comment by somethingsimple | Hacker News Reader

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 :)

View on HN

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.

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

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.

Reply on news.ycombinator.com