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

41–50 of 123 posts

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

#41

Post by commandlinefan »

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

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

#42

Post by 908B64B197 »

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.

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

#43

Post by jongjong »

smilespray wrote: post #40
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?

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.

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

#44

Post by JamesBarney »

dirtybirdnj wrote: post #21
JamesBarney wrote: post #11

Earlier quoted context omitted.

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.

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.

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

#46

Post by amelius »

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

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

#47

Post by dcow »

JohnFen wrote: post #30
sroussey wrote: post #17

Earlier quoted context omitted.

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

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

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

#48

Post by JohnFen »

ericmcer wrote: post #16
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 ticke…

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.

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

#49

Post by JohnFen »

wwweston wrote: post #18
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.

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.

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

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

#50

Post by amethyst »

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

May I propose terminology that has less negative connotations associated with them? How about "quick" vs "deliberate"?
Post reply on HN