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

31–40 of 123 posts

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

#31

Post by Retric »

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

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.

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

#32

Post by PaulKeeble »

HeyLaughingBoy wrote: post #25
l33t233372 wrote: post #9

Earlier quoted context omitted.

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

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.

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

#33

Post by makushenko »

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

:D

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

#34

Post by ryandrake »

HeyLaughingBoy wrote: post #25
l33t233372 wrote: post #9

Earlier quoted context omitted.

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

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™ 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™ happening all around them in the physical office.

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

#35

Post by testfrequency »

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

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

#36

Post by hammock »

testfrequency wrote: post #35
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 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…

Everyone is selling something, and stories are how you do it. Can’t have a story without some drama

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

#37

Post by jongjong »

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

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

#38

Post by intelVISA »

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.

You just described cloud in a nutshell.

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

#39

Post by jacobr1 »

fishtoaster wrote: post #23
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…

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.

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

#40

Post by smilespray »

jongjong wrote: post #37

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

Young soldier, aren't you taking the story a bit too literally?
Post reply on HN