Comment by johnnyanmac
2 years ago
>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
> 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.
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.