The idea of fixing a whole class of problems is common in safety critical software. When you find the cause of a bug its not just about fixing the bug but looking for this pattern of failure everywhere and fixing that and then understanding the aspects that led to this class of bugs to begin with and eliminating those. Its just good engineering to solve the class of problems not just the bug in front of you.<p>But I have also been part of a team that was replaced by another because we weren't heroic enough, because we had no bugs in our software and there was no drama for the business to get what it wanted and needed. Management rarely values this type of engineering.
"promotion is more about consistent level N+1 behavior, while one could get a high performance rating by solving many level N problems."<p>Not all companies are like this, and I find it common that new employees are not sufficiently taught what their company is like :<p>A) you have been performing well as N,promotion means "we feel / hope you're ready to work as N+1 in the future "<p>B) you've done great as N <i>and</i> have repeatedly performed N+1 tasks successfully. Promotion means "we recognize what you've already been doing "<p>First one is "proactive" and represents <i>faith</i> you'll do well at next band. In principle all you have to do is do your job well. There is risk though that you man not succeed after promotion if next band has radically different role or skillset.<p>Second one ensures you're prepared for your new band, but you cannot there just by doing your job well, and many people are unaware or don't have opportunity to do tasks of next band in their current role
> They take the extra step to make sure the next person won't have to spend the same level of energy fixing the same issue, or eliminate the problem class altogether for their team.<p>Conversely, I find it frustrating when engineers do the absolute minimum, avoid refactors, and put the next person at a disadvantage ... all while their velocity is recognized by management as good.
I've grown wary of folks in senior spots that are completely oblivious to the problems they cause in the name of going beyond.<p>All too often, today's problems stem from yesterday's solutions. This does not mean that yesterday someone made a mistake. It just means progress moves answers. If you did make a choice that feels evergreen, it is just as likely that you are oblivious to work other people are doing.<p>To that end, maximal choices on how to fix things so that they don't come back are tough. And just as often, large and reaching refactor jobs cause work for the sake of the work. Which is not at all a positive. If you think you can predict what will work, good luck. But don't require good luck from people below you for survival. Celebrate good fortune without belittling the others.<p>Of course you don't want the next person to slip on the same stone, as it were. But realize that forcing people to walk next to you is a large portion of the reason they may be slipping. And leaving holes in the ground as an alternative is clearly off. As is not waiting for the work of a larger fix.
That's the difference between programmers and engineers.<p>Programmers fix the code, engineers fix the underlying issue. Engineering is being able to spot patterns and know enough about a subject to be able to research it properly and efficiently. "Is this a state machine?", "can I represent this as a tree?", "is this a regular language or do I need a more sophisticated parser?".<p>I recall someone from a bootcamp writing a cascade of nested if-else statement, 6 level deep in some places. Then someone with a real engineering background told him that he was basically building a finite state machine, to which the other dev responded that "he didn't need anything fancy, just for the function to work". Eye opening.
Something I am thinking of similar to this. Firefighter vs Gardener.
The firefighter focuses on the high stakes issue at hand and make sure it is solved in time and without much damage. The Gartner ensues the fire doesn't happen in the first place by making sure he is cleaning up the dried leaves in the first place.<p>But in a company environment, the firefighters are more valued are praised because that's something you can see and quantify. where as the regular cleanup/refactoring and fine-tuning the api is invisible and boring. Just a thought.
Another way to put this is that more senior engineers recognize that the issues impacting an org are not a discrete set of problems, but are sometimes the <i>same problem</i> being reported by different people or teams.
A few days ago, I wrote this comment[0], and followed it up with this one[1].<p>I am the most frequent consumer and refactorer <i>[Ed. C'mon! That's gotta be a word!]</i> of my code. Most of the breadcrumbs I leave, are for me.<p>I write about my approach here[2].<p>[0] <a href="https://news.ycombinator.com/item?id=34602701" rel="nofollow">https://news.ycombinator.com/item?id=34602701</a><p>[1] <a href="https://news.ycombinator.com/item?id=34608516" rel="nofollow">https://news.ycombinator.com/item?id=34608516</a><p>[2] <a href="https://littlegreenviper.com/miscellany/leaving-a-legacy/" rel="nofollow">https://littlegreenviper.com/miscellany/leaving-a-legacy/</a>
> Once they reached the other side, the general asked "aren't you afraid that you'll slip on the same stone on the way back?" "That's okay. I'll know which stone to watch out for," said the young soldier. To which the general replied "what about the rest of the infantry?"<p>The infantry is bound to reinvent whatever you come up with badly, and slip on the same stone.
Promotions are a function of the person(s) awarding the promotion and the person receiving them. Article is about the ideal behavior of the person receiving them. Unfortunately, often the people awarding promotions are looking for some other quality or are completely incapable of distinguishing level N+1 behaviours from the rest.
I was fired from a small ERP company that will remain nameless for fixing the broken math that caused an entire class of bugs instead of just the one bug as reported. It was a snapshot of an older version of the code base, so by giving known issues with known "correct" solutions to newer hires they could get them familiar with the code base quicker.<p>It was an interesting idea, but egos in the room weren't ready for the possibility that the "official" answers weren't actually correct.<p>I was very new there and my manager didn't understand the algebra when I showed them, and they were very uncomfortable when I showed how the general case manifested in production. I was sacked a day or two later.<p>It was obviously for the best, but still pretty funny that there are some places where this sort of "maturity" is frowned upon.
Really mature engineers will spend 3 months running a psyop campaign with upper management about the value of removing the stone, 3 months devising a new stoneless architecture, 15 months letting a team of underlings implement it, and a lifetime of failing upwards because they “led large scale projects.”
Couldn't agree more, and one of the more frustrating aspects of the job. I especially for situations where I find out that someone fixed a problem for x, even though they knew at the time the problem existed for y and z, but "no one reported it." So much time and productivity is wasted.
So the young soldier moved the stone, marked the area, and warned everybody about this to spare them.<p>He was mocked and bullied by everybody.<p>ps: don't forget about herd psychology and politics, not all peers want to see your good deeds, no matter how generous or useful they are.
One danger in the "what about the rest of the infantry?" mindset is that it's too easy to start generalising the problem - and, consequently, design solutions - to a bigger and bigger extent.<p>What about other stones inside the encampment that the soldiers can slip on? What about the stones <i>outside</i> of the encampment? Wait, isn't the wall around the encampment <i>MADE OF</i> stones?<p>And pretty soon you have soldiers cleaning up stones all over the landscape, replacing the wall with solid concrete and designating a stone-cleaning platoon that will go ahead and clean the stones preemptively.
This is great. I have a person at my company who doesn't even "learn the stone" for his own stuff. This person isn't even a baseline engineer - he's a negative for the whole team. And the management who doesn't recognize this is dragging us down as well.
The article describes how it should be. But in experience, it's sadly the one who churns out most features that wins. It doesn't' matter if the leaves the codebase in ruins. That someone's else's problem.
While true usually there is no time to properly educate the others. Bug fixed? Move along. Next.<p>We'll document it later. No we won't, tomorrow there will be another fire.
> the young soldier slipped on a stone. Feeling flustered in front of the general, the young soldier quickly put the stone back in place to catch up...<p>> the general asked "aren't you afraid that you'll slip on the same stone on the way back?"<p>That makes no sense. The general is an idiot if he thinks that the stone is the problem here. There are millions of stones in a river and they shift over time. Also, it's more likely a problem with the way he was walking; not feeling around with his foot to check that the stone is stable before shifting his weight. The message I get from this story is that bosses are often looking to invent ways to criticize their subordinates in order to bring down their self-esteem. Employees with low self-esteem will be more obedient, accept lower salaries, etc...