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

11–20 of 123 posts

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

#11

Post by JamesBarney »

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.

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

#13

Post by clumsysmurf »

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

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

#15

Post by duncan-donuts »

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.

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.

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

#16

Post by ericmcer »

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…

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.

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

#17

Post by sroussey »

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

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

#18

Post by wwweston »

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.

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.

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

#19

Post by duncan-donuts »

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

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

#20

Post by fzeindl »

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 agree. I have written a blog article about this: https://fabianzeindl.com/posts/the-codequality-pyramid#testa...
Post reply on HN