Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

One common behavior seen in “mature” software engineers

luu.io

Post reply on HN
Print view View original

21–30 of 123 posts

Re: One common behavior seen in “mature” software engineers

#21

Post by dirtybirdnj »

JamesBarney wrote: post #11
NikolaNovak wrote: post #6

"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 repe…

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.

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.

Re: One common behavior seen in “mature” software engineers

#22

Post by harveywi »

NikolaNovak wrote: post #6

"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 repe…

To go from level N to N + 1, one must learn to embrace the succ.

Re: One common behavior seen in “mature” software engineers

#23

Post by fishtoaster »

NikolaNovak wrote: post #6

"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 repe…

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?"

Re: One common behavior seen in “mature” software engineers

#24

Post by taeric »

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.

Re: One common behavior seen in “mature” software engineers

#25

Post by HeyLaughingBoy »

l33t233372 wrote: post #9
PaulKeeble wrote: post #5

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 ha…

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

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.

Re: One common behavior seen in “mature” software engineers

#26

Post by Hermitian909 »

sroussey wrote: post #17
PaulKeeble wrote: post #5

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 ha…

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,…

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

Re: One common behavior seen in “mature” software engineers

#27

Post by mym1990 »

lightbendover wrote: post #10
vsareto wrote: post #4

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

Best path to promotion as a high-level engineer is intentionally creating institutional-level problems that only you can fix at scale.

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.

Re: One common behavior seen in “mature” software engineers

#29

Post by bgribble »

clumsysmurf wrote: post #13

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

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.

Re: One common behavior seen in “mature” software engineers

#30

Post by JohnFen »

sroussey wrote: post #17
PaulKeeble wrote: post #5

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 ha…

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,…

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.

Post reply on HN