12 ms·

One common behavior seen in “mature” software engineers

228 points by luuio 4y ago

ChrisMarshallNY 4y ago
A few days ago, I wrote this comment[0], and followed it up with this one[1]. I am the most frequent consumer and refactorer [Ed. C'mon! That's gotta be a word!] of my code. Most of the breadcrumbs I leave, are for me. I write about my approach here[2]. [0] https://news.ycombinator.com/item?id=34602701 https://news.ycombinator.com/item?id=34602701 [1] https://news.ycombinator.com/item?id=34608516 https://news.ycombinator.com/item?id=34608516 [2] https://littlegreenviper.com/miscellany/leaving-a-legacy/ https://littlegreenviper.com/miscellany/leaving-a-legacy/
pigbearpig 4y ago
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.
vsareto 4y ago
Prevention is better, but you often don't get the same rewards.
- pigbearpig 4y ago
  Sad but true, I've grown to realize that it's important to highlight the applications that just work or were easy to extend because of a little foresight, otherwise it's too easy to forget. As I've done this more, I realize manager appreciate the reminder and reward the effort for these drama-free applications.
- lightbendover 4y ago
  Best path to promotion as a high-level engineer is intentionally creating institutional-level problems that only you can fix at scale.
  - duncan-donuts 4y ago
    I've worked with people that do this and nothing will put you on my never-work-with-again list faster. Hamstringing entire teams because you're doing something only for yourself is toxic.
  - mym1990 4y ago
    I wouldn't say this is the 'best' path, but certainly one that is rewarded a bit too often. Ultimately this leads to some really poor org structures and power imbalances, at which point I hope all the good people have left.
  - intelVISA 4y ago
    You just described cloud in a nutshell.
- twblalock 4y ago
  It's possible to learn to communicate these prevention efforts successfully.
PaulKeeble 4y ago
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. 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.
- l33t233372 4y ago
  > because we had no bugs in our software and there was no drama for the business to get what it wanted and needed I’m confused here. The business needed your software to have bugs for the drama? Surely this isn’t the whole story.
  - duncan-donuts 4y ago
    I think OP was trying to say something like, "Management replaced our team because we were quiet and didn't rally around problems like other teams". I do think it was poorly worded and a bit jaded.
  - wwweston 4y ago
    Management can be assured of worker productivity by evidence of activity or evidence of output. In some situations (probably a lot of software engineering situations) output is difficult to measure, and so the habit of tuning in to activity is adopted instead. Some may even forget the difference.
    - JohnFen 4y ago
      > output is difficult to measure But in software engineering, it isn't difficult to measure at all. We're developing a deliverable. You can measure if the deliverable happens on time and with acceptable quality.
bbush915 4y ago
[dead]
clumsysmurf 4y ago
> 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. 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.
- bgribble 4y ago
  I'm conflicted about this. Definitely am a fan of "leave it better than you found it", refactor as you go, etc. But when it comes to bug fixes, the "absolute minimum" is often the best approach -- it can be explained to demonstrate that we know precisely the root cause of the problem, it can be reviewed for correctness readily, and we can feel good that we are not adding a lot of new behavior that can have downstream effects. The "defensive programming" approach. A refactoring that makes the problem go away forever is an awesome tech debt project, but when you have a hot problem and someone puts up a 1k LOC PR to refactor the problem away it often introduces so much uncertainty that the improvements aren't worth the risk. You have to start asking questions like how long has this person been around, do they understand what they are doing here, have they really tested this fix or does it just have good "coverage", do they really understand the root cause of the problem or is this just a "refactor and pray it goes away" fix... A small-as-possible fix relies much less on the credibility of the code author and much more on the fix being self-evidently correct.
  - JohnFen 4y ago
    It's a judgement call. If you're maintaining software, it's true that every time you touch the code -- even to fix a bug -- you're taking a risk that you're introducing a new bug. Refactoring software is an even greater risk. So, in general, the instinct is (and should be) to touch the code as little as possible. However, that's not always the right answer. The right answer is to do a risk/benefit calculation and choose the approach that is most likely to lead to an overall improvement. Sometimes, that means change as little as possible to fix a bug. Sometimes, that means refactoring a major piece. It all depends.
  - 4y ago
twblalock 4y ago
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 same problem being reported by different people or teams.
NikolaNovak 4y ago
"promotion is more about consistent level N+1 behavior, while one could get a high performance rating by solving many level N problems." Not all companies are like this, and I find it common that new employees are not sufficiently taught what their company is like : A) you have been performing well as N,promotion means "we feel / hope you're ready to work as N+1 in the future " B) you've done great as N and have repeatedly performed N+1 tasks successfully. Promotion means "we recognize what you've already been doing " First one is "proactive" and represents faith 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. 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
- JamesBarney 4y ago
  I've seen B cause issues for great devs. It seems like if you're an ok or good dev with management qualities you're much more likely to get promoted than if you're a fantastic dev with management qualities. You're too important to delegate management tasks to, so you never get the required experience to move up.
  - dirtybirdnj 4y ago
    a victim of your own success. the idea that there's no path for ICs beyond management is insulting and degrading to the hard working creatives and engineers out there. Don't give up there's a place for you, you just need to look a LOT harder and in places you wouldn't expect. Play the numbers its a statistics game.
    - JamesBarney 4y ago
      Oh this hasn't happened to me, I've been pretty proactive about interacting with both my direct manager and several levels above them, but I have seen it happen to other devs. Especially ones from east Asia who seem to culturally focus a lot more on doing a great job on N level tasks instead of focusing on N+1 level tasks.
taeric 4y ago
I've grown wary of folks in senior spots that are completely oblivious to the problems they cause in the name of going beyond. 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. 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. 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.
- Falkon1313 4y ago
  >I've grown wary of folks in senior spots that are completely oblivious to the problems they cause in the name of going beyond. Like over-abstraction, adding layers of indirection, changing things to use generic code that has no clear relation to the problem domain (and complicates domain-related changes to business requirements), then making other parts of the system (or other systems) re-use those same generic abstractions, so that they're all coupled and/or have increased dependencies? A good abstraction can be useful, and can even simplify things, but sometimes adding abstractions can be injecting second-system effect into an existing system. Whenever I think of doing something that could turn out like that, I try to get at least a couple of my teammates opinions on it before I even start.
jpswade 4y ago
This is the classic Boy Scout principle - leave it better than you found it.
jongjong 4y ago
> 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... > the general asked "aren't you afraid that you'll slip on the same stone on the way back?" 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...
- smilespray 4y ago
  Young soldier, aren't you taking the story a bit too literally?
  - jongjong 4y ago
    I guess. But as a millennial who's been in the place of that young soldier a bit too many times, it's difficult to see it from the general's point of view. The message of subordination stands out more to me.
    - vdqtp3 4y ago
      There's no message of subordination. The message is fix the problem, don't just plan to avoid it.
      - euroderf 4y ago
        I see cultural differences here. An American will get grumpy and just fix the damned thing. Someone from another culture might sigh that someone else didn't do their job and shrug shoulders and amble away.
908B64B197 4y ago
That's the difference between programmers and engineers. 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?". 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.
- eggsmediumrare 4y ago
  I'm a bootcamper and I only nest if statements 4 levels deep.
mike_hock 4y ago
I'll take forced parables that don't make any sense in the metaphorical context in which they're framed for $500.
- nonethewiser 4y ago
  Here is an easy example. You have a project that has both typescript and javascript. Someone makes a change in a JS file. They try to access a property of an object but there is a typo. You could fix the typo and be done. Or you could fix the typo, and convert the file to TS and make sure its typed.
  - mike_hock 4y ago
    Yes. It's the metaphor that doesn't make sense.
  - canucker2016 4y ago
    Here's a real world example. On a product's multi-year death march, I look at the next bug assigned to me for the project-within-the-product I was on. Over an hour of diligent debugging revealed the problem - the C++ code meant to do X = Y; but someone had typed and committed: X == Y; The destructive value assignment became an innocuous comparison, whose result is immediately ignored. I decided to search the rest of the tens-of-KLOCs project for similar assignment-turned-comparison statements. That's mindless and tedious work perfectly designed for a computer. Several minutes later, after weeding through the false positives, I created bug entries for any offenders. Did I stop there? No. I connected to the source server for the entire product and kicked off the same search. When the search finished, I separated the buggy wheat from the chaff and created bug entries accordingly. This happened on the weekend. When the product triage team met the following weekday morning, they saw all the bugs entered across the several projects in the product due to the same root cause - double equals instead of a single equals sign. Management decided to take the next step. They bought a site license for a static source code analyzer. We integrated the analyzer into our project build process and ran the analyzer on each build and triaging accordingly. Highest compliment I got for creating all this "extra work": "F*ck you!" said with a smile. Did I stop there? No. I kept my eyes and ears on the lookout for more possible typos. I would read commit emails and resolutions to bugs to see if the cause/fix would fit the model of "easily-found-via-grep". I expanded my batch file to cover new cases and created new bugs when the batch file found them. Did I stop there? No. Eventually I hit the wall of diminishing returns for source code analysis via regular-expression searching. I looked for a tool that could go to the next level. At that time, the one scripting language available in our project's build tools was perl. Off to the bookstore and I bought O'Reilly's Pink Camel Perl book. A few hours later, I had a rudimentary source code analyzer that looked at lines of source code for typos. I added more cases as appropriate. But C/C++ source code isn't rigidly formatted and programmers wouldn't play nice and limit their code to one code statement per source code line. Preprocessor macros also confused the line-at-a-time script analysis. So I bit the bullet and expanded the perl script to "parse" C/C++ code. I added checks to make sure memory allocations were checked for failure (no exception-handling for memory failure in our codebase). Did I stop there? No. I publicized the script within the company, answered questions, listened to suggestions, and offered help to other product groups in the company. A couple of other product groups integrated the script into their build process. Obviously it'd be better if each programmer would run the script before they committed modified code. Did I stop there? No. I had worked on the company's new signature product before the current project's death march had started. I still had access to that signature product's source code. So I would run my perl script against the product's source code. That product is huge. A source code scan over the network (my work machine didn't have enough disk space to enlist in every project in the product) would take all night. I had access to the bug database but I didn't know which source code directory mapped to which project in that product. So I did the next, most annoying thing - I sent a cleansed list of defects to all the developers in the product. Did I stop there? No. The company had bought a static source code analyzer product and proceeded to integrate it into most of the company's products' development process. They created a stripped down version of the source code analyzer suitable for developer use before committing code. My perl script was obsolete now. But that didn't mean others couldn't benefit from it even though the company didn't need it anymore. I noticed a "call for papers" notice for an open source conference. I emailed the company's legal department and requested to open source my perl script. Their reply: "Permission granted." I wrote my proposal, sent it into the conference organizers, who accepted the proposal, wrote a talk, and presented at the open source conference. Did I stop there? No. Talk is nice. Code is better. I published/uploaded the script on CPAN (the Comprehensive Perl Archive Network - https://www.cpan.org https://www.cpan.org ). Did I stop there? No. Around the time Coverity started scanning open source projects, I had downloaded the source code to several prominent open source projects and scanned their code and sent emails with possible bugs where appropriate.
amelius 4y ago
> 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?" The infantry is bound to reinvent whatever you come up with badly, and slip on the same stone.
WirelessGigabit 4y ago
While true usually there is no time to properly educate the others. Bug fixed? Move along. Next. We'll document it later. No we won't, tomorrow there will be another fire.
agumonkey 4y ago
So the young soldier moved the stone, marked the area, and warned everybody about this to spare them. He was mocked and bullied by everybody. 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.
- BoorishBears 4y ago
  He was only mocked because he wasn't wearing his PT belt.
- commandlinefan 4y ago
  > He was mocked and bullied by everybody. He was also demoted for wasting time moving stones around when he was supposed to be peeling potatoes.
- euroderf 4y ago
  There's a mindset that sees this good deed being done and says, "Sucker!".
ranting-moth 4y ago
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.
- commandlinefan 4y ago
  > The article describes how it should be. Posts like this hit HN pretty regularly and are always popular, but they're essentially the equivalent of the perennial LinkedIn "I was already late for a job interview, but I stopped to help a stranded motorist change a flat tire, and then when I showed up for the interview, it turned out I was interviewing with the stranded motorist". For whatever reason, a lot of people seem to believe that if you post something often enough on the internet, you'll make it come true.
19f191ty 4y ago
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.
fuzzieozzie 4y ago
The article speaks about a generic behaviour for good managers wherever they are managing.
jheriko 4y ago
One common sign our industry is a sea of wasters...
roflyear 4y ago
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.
- mberger 4y ago
  I feel personally attacked
BurningFrog 4y ago
A related thing is people who write code for the computer vs those who write for the people who'll work with it later.
faangiq 4y ago
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.”
- zuj 4y ago
  I like how Sarah Mei says, "Inline everything". You don't get to go on a refactoring crusade. You do it on a daily basis when you are working on the actual production issues. Easy to say but based on my experience, it is the only way to move things in the right direction and keep them that way.
deleted 4y ago
[deleted]
Tao3300 4y ago
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. It was an interesting idea, but egos in the room weren't ready for the possibility that the "official" answers weren't actually correct. 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. It was obviously for the best, but still pretty funny that there are some places where this sort of "maturity" is frowned upon.
zuj 4y ago
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. 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.
Seb-C 4y ago
I call that "working around the symptom rather than fixing the actual problem".
BerislavLopac 4y ago
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. What about other stones inside the encampment that the soldiers can slip on? What about the stones outside of the encampment? Wait, isn't the wall around the encampment MADE OF stones? 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.
- hbrn 4y ago
  Even bigger danger is convincing yourself that you are the hero that eliminated a "class" of problems without a concrete evidence that the class exists or worth eliminating. After all, everyone is biased to build a story in their mind in which they are the hero. I've seen too many teams happily investing in stone-cleaning activities while forgetting there's a war out there.
blain_the_train 4y ago
It's the general's purpose to tell solider to fix it for the rest of the army.

228 points by luuio 4y ago

A few days ago, I wrote this comment[0], and followed it up with this one[1]. I am the most frequent consumer and refactorer [Ed. C'mon! That's gotta be a word!] of my code. Most of the breadcrumbs I leave, are for me. I write about my approach here[2]. [0] https://news.ycombinator.com/item?id=34602701 https://news.ycombinator.com/item?id=34602701 [1] https://news.ycombinator.com/item?id=34608516 https://news.ycombinator.com/item?id=34608516 [2] https://littlegreenviper.com/miscellany/leaving-a-legacy/ https://littlegreenviper.com/miscellany/leaving-a-legacy/

pigbearpig 4y ago

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.

vsareto 4y ago

Prevention is better, but you often don't get the same rewards.

pigbearpig 4y ago
Sad but true, I've grown to realize that it's important to highlight the applications that just work or were easy to extend because of a little foresight, otherwise it's too easy to forget. As I've done this more, I realize manager appreciate the reminder and reward the effort for these drama-free applications.
lightbendover 4y ago
Best path to promotion as a high-level engineer is intentionally creating institutional-level problems that only you can fix at scale.
- duncan-donuts 4y ago
  I've worked with people that do this and nothing will put you on my never-work-with-again list faster. Hamstringing entire teams because you're doing something only for yourself is toxic.
- mym1990 4y ago
  I wouldn't say this is the 'best' path, but certainly one that is rewarded a bit too often. Ultimately this leads to some really poor org structures and power imbalances, at which point I hope all the good people have left.
- intelVISA 4y ago
  You just described cloud in a nutshell.
twblalock 4y ago
It's possible to learn to communicate these prevention efforts successfully.

PaulKeeble 4y ago

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. 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.

l33t233372 4y ago
> because we had no bugs in our software and there was no drama for the business to get what it wanted and needed I’m confused here. The business needed your software to have bugs for the drama? Surely this isn’t the whole story.
- duncan-donuts 4y ago
  I think OP was trying to say something like, "Management replaced our team because we were quiet and didn't rally around problems like other teams". I do think it was poorly worded and a bit jaded.
- wwweston 4y ago
  Management can be assured of worker productivity by evidence of activity or evidence of output. In some situations (probably a lot of software engineering situations) output is difficult to measure, and so the habit of tuning in to activity is adopted instead. Some may even forget the difference.
  - JohnFen 4y ago
    > output is difficult to measure But in software engineering, it isn't difficult to measure at all. We're developing a deliverable. You can measure if the deliverable happens on time and with acceptable quality.

bbush915 4y ago

[dead]

clumsysmurf 4y ago

> 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. 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.

bgribble 4y ago
I'm conflicted about this. Definitely am a fan of "leave it better than you found it", refactor as you go, etc. But when it comes to bug fixes, the "absolute minimum" is often the best approach -- it can be explained to demonstrate that we know precisely the root cause of the problem, it can be reviewed for correctness readily, and we can feel good that we are not adding a lot of new behavior that can have downstream effects. The "defensive programming" approach. A refactoring that makes the problem go away forever is an awesome tech debt project, but when you have a hot problem and someone puts up a 1k LOC PR to refactor the problem away it often introduces so much uncertainty that the improvements aren't worth the risk. You have to start asking questions like how long has this person been around, do they understand what they are doing here, have they really tested this fix or does it just have good "coverage", do they really understand the root cause of the problem or is this just a "refactor and pray it goes away" fix... A small-as-possible fix relies much less on the credibility of the code author and much more on the fix being self-evidently correct.
- JohnFen 4y ago
  It's a judgement call. If you're maintaining software, it's true that every time you touch the code -- even to fix a bug -- you're taking a risk that you're introducing a new bug. Refactoring software is an even greater risk. So, in general, the instinct is (and should be) to touch the code as little as possible. However, that's not always the right answer. The right answer is to do a risk/benefit calculation and choose the approach that is most likely to lead to an overall improvement. Sometimes, that means change as little as possible to fix a bug. Sometimes, that means refactoring a major piece. It all depends.
- 4y ago

twblalock 4y ago

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 same problem being reported by different people or teams.

NikolaNovak 4y ago

"promotion is more about consistent level N+1 behavior, while one could get a high performance rating by solving many level N problems." Not all companies are like this, and I find it common that new employees are not sufficiently taught what their company is like : A) you have been performing well as N,promotion means "we feel / hope you're ready to work as N+1 in the future " B) you've done great as N and have repeatedly performed N+1 tasks successfully. Promotion means "we recognize what you've already been doing " First one is "proactive" and represents faith 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. 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

JamesBarney 4y ago
I've seen B cause issues for great devs. It seems like if you're an ok or good dev with management qualities you're much more likely to get promoted than if you're a fantastic dev with management qualities. You're too important to delegate management tasks to, so you never get the required experience to move up.
- dirtybirdnj 4y ago
  a victim of your own success. the idea that there's no path for ICs beyond management is insulting and degrading to the hard working creatives and engineers out there. Don't give up there's a place for you, you just need to look a LOT harder and in places you wouldn't expect. Play the numbers its a statistics game.
  - JamesBarney 4y ago
    Oh this hasn't happened to me, I've been pretty proactive about interacting with both my direct manager and several levels above them, but I have seen it happen to other devs. Especially ones from east Asia who seem to culturally focus a lot more on doing a great job on N level tasks instead of focusing on N+1 level tasks.

taeric 4y ago

I've grown wary of folks in senior spots that are completely oblivious to the problems they cause in the name of going beyond. 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. 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. 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.

Falkon1313 4y ago
>I've grown wary of folks in senior spots that are completely oblivious to the problems they cause in the name of going beyond. Like over-abstraction, adding layers of indirection, changing things to use generic code that has no clear relation to the problem domain (and complicates domain-related changes to business requirements), then making other parts of the system (or other systems) re-use those same generic abstractions, so that they're all coupled and/or have increased dependencies? A good abstraction can be useful, and can even simplify things, but sometimes adding abstractions can be injecting second-system effect into an existing system. Whenever I think of doing something that could turn out like that, I try to get at least a couple of my teammates opinions on it before I even start.

jpswade 4y ago

This is the classic Boy Scout principle - leave it better than you found it.

jongjong 4y ago

> 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... > the general asked "aren't you afraid that you'll slip on the same stone on the way back?" 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...

smilespray 4y ago
Young soldier, aren't you taking the story a bit too literally?
- jongjong 4y ago
  I guess. But as a millennial who's been in the place of that young soldier a bit too many times, it's difficult to see it from the general's point of view. The message of subordination stands out more to me.
  - vdqtp3 4y ago
    There's no message of subordination. The message is fix the problem, don't just plan to avoid it.
    - euroderf 4y ago
      I see cultural differences here. An American will get grumpy and just fix the damned thing. Someone from another culture might sigh that someone else didn't do their job and shrug shoulders and amble away.

908B64B197 4y ago

That's the difference between programmers and engineers. 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?". 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.

eggsmediumrare 4y ago
I'm a bootcamper and I only nest if statements 4 levels deep.

mike_hock 4y ago

I'll take forced parables that don't make any sense in the metaphorical context in which they're framed for $500.

nonethewiser 4y ago
Here is an easy example. You have a project that has both typescript and javascript. Someone makes a change in a JS file. They try to access a property of an object but there is a typo. You could fix the typo and be done. Or you could fix the typo, and convert the file to TS and make sure its typed.
- mike_hock 4y ago
  Yes. It's the metaphor that doesn't make sense.
- canucker2016 4y ago
  Here's a real world example. On a product's multi-year death march, I look at the next bug assigned to me for the project-within-the-product I was on. Over an hour of diligent debugging revealed the problem - the C++ code meant to do X = Y; but someone had typed and committed: X == Y; The destructive value assignment became an innocuous comparison, whose result is immediately ignored. I decided to search the rest of the tens-of-KLOCs project for similar assignment-turned-comparison statements. That's mindless and tedious work perfectly designed for a computer. Several minutes later, after weeding through the false positives, I created bug entries for any offenders. Did I stop there? No. I connected to the source server for the entire product and kicked off the same search. When the search finished, I separated the buggy wheat from the chaff and created bug entries accordingly. This happened on the weekend. When the product triage team met the following weekday morning, they saw all the bugs entered across the several projects in the product due to the same root cause - double equals instead of a single equals sign. Management decided to take the next step. They bought a site license for a static source code analyzer. We integrated the analyzer into our project build process and ran the analyzer on each build and triaging accordingly. Highest compliment I got for creating all this "extra work": "F*ck you!" said with a smile. Did I stop there? No. I kept my eyes and ears on the lookout for more possible typos. I would read commit emails and resolutions to bugs to see if the cause/fix would fit the model of "easily-found-via-grep". I expanded my batch file to cover new cases and created new bugs when the batch file found them. Did I stop there? No. Eventually I hit the wall of diminishing returns for source code analysis via regular-expression searching. I looked for a tool that could go to the next level. At that time, the one scripting language available in our project's build tools was perl. Off to the bookstore and I bought O'Reilly's Pink Camel Perl book. A few hours later, I had a rudimentary source code analyzer that looked at lines of source code for typos. I added more cases as appropriate. But C/C++ source code isn't rigidly formatted and programmers wouldn't play nice and limit their code to one code statement per source code line. Preprocessor macros also confused the line-at-a-time script analysis. So I bit the bullet and expanded the perl script to "parse" C/C++ code. I added checks to make sure memory allocations were checked for failure (no exception-handling for memory failure in our codebase). Did I stop there? No. I publicized the script within the company, answered questions, listened to suggestions, and offered help to other product groups in the company. A couple of other product groups integrated the script into their build process. Obviously it'd be better if each programmer would run the script before they committed modified code. Did I stop there? No. I had worked on the company's new signature product before the current project's death march had started. I still had access to that signature product's source code. So I would run my perl script against the product's source code. That product is huge. A source code scan over the network (my work machine didn't have enough disk space to enlist in every project in the product) would take all night. I had access to the bug database but I didn't know which source code directory mapped to which project in that product. So I did the next, most annoying thing - I sent a cleansed list of defects to all the developers in the product. Did I stop there? No. The company had bought a static source code analyzer product and proceeded to integrate it into most of the company's products' development process. They created a stripped down version of the source code analyzer suitable for developer use before committing code. My perl script was obsolete now. But that didn't mean others couldn't benefit from it even though the company didn't need it anymore. I noticed a "call for papers" notice for an open source conference. I emailed the company's legal department and requested to open source my perl script. Their reply: "Permission granted." I wrote my proposal, sent it into the conference organizers, who accepted the proposal, wrote a talk, and presented at the open source conference. Did I stop there? No. Talk is nice. Code is better. I published/uploaded the script on CPAN (the Comprehensive Perl Archive Network - https://www.cpan.org https://www.cpan.org ). Did I stop there? No. Around the time Coverity started scanning open source projects, I had downloaded the source code to several prominent open source projects and scanned their code and sent emails with possible bugs where appropriate.

amelius 4y ago

> 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?" The infantry is bound to reinvent whatever you come up with badly, and slip on the same stone.

WirelessGigabit 4y ago

While true usually there is no time to properly educate the others. Bug fixed? Move along. Next. We'll document it later. No we won't, tomorrow there will be another fire.

agumonkey 4y ago

So the young soldier moved the stone, marked the area, and warned everybody about this to spare them. He was mocked and bullied by everybody. 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.

BoorishBears 4y ago
He was only mocked because he wasn't wearing his PT belt.
commandlinefan 4y ago
> He was mocked and bullied by everybody. He was also demoted for wasting time moving stones around when he was supposed to be peeling potatoes.
euroderf 4y ago
There's a mindset that sees this good deed being done and says, "Sucker!".

ranting-moth 4y ago

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.

commandlinefan 4y ago
> The article describes how it should be. Posts like this hit HN pretty regularly and are always popular, but they're essentially the equivalent of the perennial LinkedIn "I was already late for a job interview, but I stopped to help a stranded motorist change a flat tire, and then when I showed up for the interview, it turned out I was interviewing with the stranded motorist". For whatever reason, a lot of people seem to believe that if you post something often enough on the internet, you'll make it come true.

19f191ty 4y ago

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.

fuzzieozzie 4y ago

The article speaks about a generic behaviour for good managers wherever they are managing.

jheriko 4y ago

One common sign our industry is a sea of wasters...

roflyear 4y ago

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.

mberger 4y ago
I feel personally attacked

BurningFrog 4y ago

A related thing is people who write code for the computer vs those who write for the people who'll work with it later.

faangiq 4y ago

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.”

zuj 4y ago
I like how Sarah Mei says, "Inline everything". You don't get to go on a refactoring crusade. You do it on a daily basis when you are working on the actual production issues. Easy to say but based on my experience, it is the only way to move things in the right direction and keep them that way.

deleted 4y ago

[deleted]

Tao3300 4y ago

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. It was an interesting idea, but egos in the room weren't ready for the possibility that the "official" answers weren't actually correct. 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. It was obviously for the best, but still pretty funny that there are some places where this sort of "maturity" is frowned upon.

zuj 4y ago

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. 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.

Seb-C 4y ago

I call that "working around the symptom rather than fixing the actual problem".

BerislavLopac 4y ago

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. What about other stones inside the encampment that the soldiers can slip on? What about the stones outside of the encampment? Wait, isn't the wall around the encampment MADE OF stones? 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.

hbrn 4y ago
Even bigger danger is convincing yourself that you are the hero that eliminated a "class" of problems without a concrete evidence that the class exists or worth eliminating. After all, everyone is biased to build a story in their mind in which they are the hero. I've seen too many teams happily investing in stone-cleaning activities while forgetting there's a war out there.

blain_the_train 4y ago

It's the general's purpose to tell solider to fix it for the rest of the army.