Hacker News Reader

Comment by gumby | Hacker News Reader

One really good developer I worked with wrote excellent code and also terrible code that had to be replaced immediately — and both made him great to work with.

The value of writing good code is self explanatory. You probably use some of his code today.

But he was also great in a firefight: customer is dead in the water and it might be our fault. He’d show up cold and “jam his fingers in the holes in the dam”: quickly figure out what was wrong and then rapidly write and install the most hideous spaghetti code that cot the customer up and running. Code that could not be checked in, or be refactored. Eye-bleeding stuff. Someone would have to take the time to engineer a proper fix, but the immediate crisis was averted.

I was actually much more impressed by the latter skill — among other reasons it’s simply rare. Also he was just a nice guy and everybody loved him.

(Won’t name him since I described some of his code as hideous)

View on HN

I'm one of these firefighter type, and it's causing some frictions with others developpers, because my code is not great and not future proof. But I get the job done quickly, and lots of my quirky code have saved the day, either by solving an emergency or winning a tender. It's difficult to communicate with "perfect minded" developpers, because for them if code is not thought-out, then it's not worth anything, even if they understand the need for speed. Of course they think the reverse about me^^

We're set up a weekly meeting to alleviate the issue and it's working OK. The hardest is finding out which "type" is the right one, when it's not an emergency but there's a tight schedule/unclear specifications... At least we make a common decision

>I was actually much more impressed by the latter skill — among other reasons it’s simply rare

Not exactly something to encourage, but it sounds like he has experience in competitive competitions, where generating code to a problem on the fly is necessary. It's not something you can't learn yourself, but rote memorization of common problems and solutions (to the point where you can mechanically type down some algorithm from memory) is the bane of my existence

Don't competitions usually have completely different kinds of problems than what you typically run into in production fires? When I think of competitive programming I think of algorithms and puzzles, not network errors and data corruption.

In my experience production fires are rarely put out by rote algorithmic knowledge, the skill is more having a detailed knowledge of the inner workings of every layer of the system so that you can come to the right conclusion based on the very limited information available in the average production monitoring system.

This is my understanding as well. Rare is the day I’ve solved a production firefight by editing some algorithm - it’s almost always arcane configuration, restarting services in the right order, some network thing flapping/dos-ing the rest of the system, some service aggressively restarting and dos-ing others, actual malevolent dos, noisy neighbors, resource starvation, etc.

Yes, it's not the full equation. But that type of environment gives you a mindset that isn't present in most other types of coding. The ability to think under pressire, identity the fastest solution, and store a number of approaches in your head should you encounter dire edge cases.

>the skill is more having a detailed knowledge of the inner workings of every layer of the system so that you can come to the right conclusion

Yup, and that's transferable skills from competition coding. You're not juggling algorithms in your head per se, but you juggle whatever tribal knowledge needed as options to cycle through. That combined with the above mindset can lead to such skills.

It still seems a bit of a stretch to jump to the conclusion that someone who's good at fighting production fires probably has experience with competitive coding. You could maybe conclude that they would be good at competitive coding were they to try it, but competitive coding is way less popular than just... having a career in software.

> Not exactly something to encourage

Yes it is. Putting out fires, quickly, is very important.

The problem comes later when the breathing sapce arrives to regularise the fix and replace the band-aid with good quality code.

At this point no fire is burning, the problems are not immediately visible, and it takes very good management, right up the stack, to fix that sort of problrm.

> Not exactly something to encourage

Yes. Exactly right. Because the band-aid with all its ugliness becomes the permanent fix because there is no revenue box to place the work in takes to fix it into

>Because the band-aid with all its ugliness becomes the permanent fix because there is no revenue box to place the work in takes to fix it into

Yeah, that's what I was getting at. Especially in my industry, we don't get too many chances to convince the product managers to "go back and actually fit the code". From a business sense, it's a great skill, but business realities equate it to the ability to plug up a dam with a cork.

I just do the boring thing and get it in writing somewhere.

"This will fix the problem for now, BUT it will make _everything_ harder in the long run unless we spend time to do it properly".

Then when they complain about stuff taking longer than it should I can just refer to the ticket/email/meeting memo and remind them that I did say so.

Reply on news.ycombinator.com