[HN Gopher] One common behavior seen in "mature" software engineers
___________________________________________________________________
One common behavior seen in "mature" software engineers
Author : luuio
Score : 114 points
Date : 2023-02-06 20:17 UTC (2 hours ago)
(HTM) web link (www.luu.io)
(TXT) w3m dump (www.luu.io)
| 908B64B197 wrote:
| 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.
| ChrisMarshallNY wrote:
| 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
|
| [1] https://news.ycombinator.com/item?id=34608516
|
| [2] https://littlegreenviper.com/miscellany/leaving-a-legacy/
| 19f191ty wrote:
| 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.
| pigbearpig wrote:
| 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 wrote:
| Prevention is better, but you often don't get the same rewards.
| pigbearpig wrote:
| 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 wrote:
| Best path to promotion as a high-level engineer is
| intentionally creating institutional-level problems that only
| you can fix at scale.
| intelVISA wrote:
| You just described cloud in a nutshell.
| mym1990 wrote:
| 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.
| duncan-donuts wrote:
| 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.
| twblalock wrote:
| It's possible to learn to communicate these prevention efforts
| successfully.
| taeric wrote:
| 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.
| PaulKeeble wrote:
| 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.
| testfrequency wrote:
| I saw this often.
|
| The heroes who are up late, solving a page or mitigating an
| outage are often the ones remembered and rewarded.
|
| Meanwhile, a dependable, resourceful, and independent IC who
| "picks up trash on the floor", promotes good work habits, and
| is dead reliable - no praise, they are just "doing their job"
|
| Managers and leaders like drama, most staff and senior
| engineers gravitate to drama and love talking about it. Their
| day to to day work, often subpar and often not team players
| hammock wrote:
| Everyone is selling something, and stories are how you do it.
| Can't have a story without some drama
| agumonkey wrote:
| This is why I need a different job. This pattern sucks
| energy out of me. I need military minded coders.
| GoodDreams wrote:
| I'm interested in understanding what it means to be a
| military minded coder.
| Ma8ee wrote:
| Yes, this is my problem. I'm seen as slow, because I take my
| time to deliver my stuff. And I'm rarely the hero of fixing
| some outage or some critical bug. Because my stuff works,
| quietly. The heros are always busy; fixing that bug and
| extinguishing that fire and delivers the new feature in a day
| (as soon as they clean up the latest incident). What people
| see is that I take three days to deliver the same feature.
| What they don't see is that I don't have to spend in total
| two weeks (spread over some time), fixing bugs and cleaning
| up corrupt data for the same feature.
| l33t233372 wrote:
| > 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.
| HeyLaughingBoy wrote:
| When the org that I was working for was doing TSP
| (https://segoldmine.ppi-int.com/node/67631), our coach told
| me a story about another team and an engineer I knew very
| well. He got high praise for all the late nights and weekends
| he worked to get a product out the door. But on analysis of
| what he was working on and the bugs he had to deal with, if
| he had taken the TSP approach that my team was using, most of
| those bugs would never have been created in the first place
| and the product would have been finished much sooner.
|
| Drama gets noticed, just quietly ticking along, producing
| high-quality output really doesn't.
| ryandrake wrote:
| Exactly. I've worked at software companies where the
| executives wouldn't believe any work was being done unless
| they could visibly see activity, and hear the "buzz" of
| "people doing things" and feel the drama of production
| emergencies and heroics. It felt like they were listening
| for intense movie-like typing on keyboards, watching for
| theatrics in front of whiteboards, project leads calling
| for standups, and so on. Those were the teams truly
| DoingThings(tm) and those teams were rewarded for their
| performance art. The team silently plugging away at their
| desks in chat, while they calmly deployed another build
| that passed all test automation--I'm not sure if leadership
| even knew who they were.
|
| EDIT: These folks almost certainly overlap with the ones
| pining for Return To Office instead of remote work: They
| miss the "hum" and "buzz" of SeriousBusiness(tm) happening
| all around them in the physical office.
| PaulKeeble wrote:
| Its exactly this. Their approach produced lots of weekends
| and late nights and broken releases and they could be seen
| to be fixing things and responding like lightening to every
| issue. My team on the other hand was 9 to 5, everything
| just worked when we released it with few bugs and we and
| the business worked like normal human beings. The problem
| is that its invisible and there are no heroics, its just
| good solid engineering. Which considering it was a back end
| system for a bank is the right way for things to be.
|
| Management likes people who make heroic effort even if they
| are the cause of needing it they are visibly working hard
| even if they are making less progress.
| duncan-donuts wrote:
| 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 wrote:
| 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 wrote:
| > 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.
| ericmcer wrote:
| Yeah the only way to get rewarded for working on resiliency
| like this is if you do it very loudly. If you spend an extra
| day or two refactoring a feature so that it is more robust you
| will be looked at poorly versus the engineer who slaps a few
| more conditionals onto it to keep it working.
|
| Raise the issue with higher ups, maybe create some fancy charts
| about lost engineering time in the future, spin up specific
| tickets for refactoring, turn it into a two week project and
| you will get recognition. Management loves a chart about
| improving X by N% almost more than a shiny feature.
| JohnFen wrote:
| Most of the places I've worked weren't like this, but a
| couple were. I quit those positions on the grounds that I was
| clearly a poor cultural fit.
| nonethewiser wrote:
| If they dont like that you took more time to refactor instead
| of bandaid, they arent going to respond well to you boasting
| about it for weeks.
| sroussey wrote:
| I like to rate engineers across various categories, but really
| I found that there were two general classes of great engineers:
| fast and slow. For marketing tests, etc., the whole team would
| be fast engineers. For payments, the whole team would be slow.
| Everything else I would try to have tension -- a mix of the two
| so they learn and appreciate each other.
|
| This is condensing a multidimensional vector into just a line,
| but effective enough to explain to non-engineers.
|
| If you are a precision (slow) engineer, then you are more
| likely on the backend, more likely to write tests, more likely
| to avoid costly errors. This will be wasted on some kinds of
| tasks (trying out new things, for example, but as a class these
| tasks can generate a lot of management interest). The only kind
| of management interest in the precision stuff is failure, and
| it is usually doomsday failure.
|
| That said, security is always present, and I am noodling ideas
| right now on how to eliminate whole classes of security and
| privacy issues while making it even easier faster for all
| engineer types.
| JohnFen wrote:
| Interesting. I never thought about dividing engineers this
| way. I do know that the two best engineers I've ever met were
| slow. Not just slow in working, but slow in everything.
| Speaking, moving, etc. This frustrated some people, but these
| engineers saved everyone else much time and frustration
| because their work was rock solid, well thought-out, and
| complete.
|
| And, once you accounted for time spent bug-fixing and
| validating things, they weren't actually slow.
| dcow wrote:
| > And, once you accounted for time spent bug-fixing and
| validating things, they weren't actually slow.
|
| The constant battle between instant gratification and
| delayed satisfaction.
| Hermitian909 wrote:
| > two general classes of great engineers: fast and slow ...
| Everything else I would try to have tension -- a mix of the
| two
|
| To add to this, if you are one of these engineers a great
| career hack is to find an engineer you respect on the other
| end of the spectrum and partner with them.
|
| As a "slow" engineer I make sure our key interfaces are
| abstractions are correct and my "fast" partner ensures that
| everything gets shipped and that I don't sweat the small
| stuff. This has lead to a lot more successful and impactful
| projects than I could manage on my own or with another "slow"
| engineer.
| amethyst wrote:
| May I propose terminology that has less negative connotations
| associated with them? How about "quick" vs "deliberate"?
| Retric wrote:
| Some of that is deeply ingrained, but it's useful to be able
| to swap between different kinds of problem solving.
|
| Ultimately, there isn't a single best approach to software
| development just different tradeoffs. Being able to whip up a
| bug ridden happy path that only works for some set of data is
| useful when trying to build an understanding of some new
| system. At the other end even if most of what you do is short
| lived demos creating a few rock solid building blocks can
| save you a great deal of pain.
| makushenko wrote:
| :D
| fzeindl wrote:
| I agree. I have written a blog article about this:
| https://fabianzeindl.com/posts/the-codequality-pyramid#testa...
| fuzzieozzie wrote:
| The article speaks about a generic behaviour for good managers
| wherever they are managing.
| NikolaNovak wrote:
| "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
| harveywi wrote:
| To go from level N to N + 1, one must learn to embrace the
| succ.
| fishtoaster wrote:
| I've seen B cause issues too.
|
| The duties of level N and N+1 are often a little different. If
| they're different enough, then it can be difficult to
| demonstrate N+1 while also doing N work. You're option is to
| work two jobs at once or, as I more commonly see, do the bare
| minimum of N work and focusing on N+1 work. This can look like
| the teammate who's focusing on division-wide initiatives at the
| expense of implementing the things their team is actually
| assigned - leaving their teammates to pick up the slack.
|
| This is certainly not inevitable, and I'm definitely not saying
| B is a _bad_ way to do things - just that this is a failure
| case I 've seen of that model. The other, of course, is "why
| spend a year doing N+1 work here at an N salary when it's
| easier to just get hired as an N+1 at a new company today?"
| jacobr1 wrote:
| One successful way I've seen this down is to proactively give
| people ownership of sub-projects with collaboration, or
| leadership scope N+1. It is explicitly acknowledged (so no
| shadow work that your team is covering to support) and acts
| as a way to gauge maturity, while limiting risk.
| JamesBarney wrote:
| 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 wrote:
| 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 wrote:
| 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.
| bbush915 wrote:
| [dead]
| jongjong wrote:
| > 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 wrote:
| Young soldier, aren't you taking the story a bit too literally?
| jongjong wrote:
| 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.
| ranting-moth wrote:
| 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.
| WirelessGigabit wrote:
| 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.
| clumsysmurf wrote:
| > 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 wrote:
| 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 wrote:
| 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.
| JohnFen wrote:
| > I find it frustrating when engineers do the absolute minimum,
| avoid refactors, and put the next person at a disadvantage
|
| If such engineers don't care about other or future engineers
| who will have to touch their work, they should at least care
| about themselves. Perhaps they've never heard the maxim: work
| to make the life of the next engineer to touch the code easier,
| because the "next engineer" will probably be you.
| commandlinefan wrote:
| > I find it frustrating when ... recognized by management as
| good.
|
| ... but you're not the one writing the checks, remember?
| Management is. They don't care about quality. They can't even
| define it, much less recognize it. They care about delivery
| dates. Delivery dates are easy to measure. So that's what
| matters.
|
| > put the next person at a disadvantage
|
| The first guy was at the same disadvantage - which was that he
| was under an unreasonable deadline that didn't leave enough
| time for quality improvements. So you expect him to sacrifice
| his reputation so that you don't have to sacrifice yours?
| JohnFen wrote:
| You're describing dysfunctional or bad management. Not all
| companies are like that.
| twblalock wrote:
| 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.
| jpswade wrote:
| This is the classic Boy Scout principle - leave it better than
| you found it.
| mike_hock wrote:
| I'll take forced parables that don't make any sense in the
| metaphorical context in which they're framed for $500.
| nonethewiser wrote:
| 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.
| amelius wrote:
| > 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.
| agumonkey wrote:
| 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 wrote:
| He was only mocked because he wasn't wearing his PT belt.
___________________________________________________________________
(page generated 2023-02-06 23:01 UTC)