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

81–90 of 123 posts

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

#81

Post by luuio »

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…

Thanks for the call out! There are definitely companies that go with (A), but in all the companies I've been at, (B) is the model.

As others have responded, there are definitely trade offs with different models. The way I've seen (B) worked well is:

* Given a project, separate out the "level" of different axes. A project could have level N technical scope, but level N+1 collaboration scope, etc.

* Let the level-N engineer handle one level N+1 axis at a time, with supervision on other axes.

* And if they ace one axis, then back off and give them more responsibilities on the other axes, for the same project or subsequent projects.

Of course there are also scenarios where someone is just thrown into the deep end. They will either sink or swim :)

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

#82

Post by fishtoaster »

rlpb wrote: post #79
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,…

> I found that there were two general classes of great engineers: fast and slow There is a third type: those who can adapt to what is appropriate under the circumstances.

Yeah, I gotta say, it seems like one of the key skills that differentiates a mid-level dev from a senior one is knowing whether the current task calls for being a slow engineer vs being a fast engineer.

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

#84

Post by faangiq »

Really mature engineers will spend 3 months running a psyop campaign with upper management about the value of removing the stone, 3 months devising a new stoneless architecture, 15 months letting a team of underlings implement it, and a lifetime of failing upwards because they “led large scale projects.”

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

#85

Post by chatmasta »

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.

There is some unfortunate tension between the two maxims of "cleanup as you go" and "keep PRs focused." An idealist will tell you, "why not submit the cleanup in a separate PR?" But in reality, there is always overhead to each new PR, and the code most amenable to "cleanup on the go" seems to be the code that sits just below the start of that overhead.

It's especially frustrating when "cleanup the code" means "change one line in a few dozen files," because this results in a PR with a high number of changed files. Even if each change is only one line, the high number in the "top line metric" (no pun intended) of "files changed" makes the PR look unfocused, and a lazy reviewer might waste everyone's time criticizing that. So the path of least resistance is to avoid even mentioning the cleanup. Repeat for every PR for the lifetime of the codebase, and your code quality will deteriorate from death by a thousand cuts.

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

#86

Post by JohnFen »

this_steve_j wrote: post #73
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,…

As a slow engineer I always liked the term “careful”. As in: Move carefully and fix things; vs Move fast and break things. I’d say that most experienced tradespeople are capable of operating in either mode or somewhere along the continuum. Personality traits, beliefs, perspective, motivations, attitudes, age, and experiences might predispose someone to favor one side or the other.

Since I consider "Move fast and break things" to be one of the worst and most destructive philosophies to find adoption in software engineering, I guess it's obvious which side I favor.

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

#87

Post by eggsmediumrare »

908B64B197 wrote: post #42

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

I'm a bootcamper and I only nest if statements 4 levels deep.

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

#88

Post by bobwaycott »

dcow wrote: post #47
JohnFen wrote: post #30

Earlier quoted context omitted.

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.

“Delayed satisfaction”—I love that.

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

#89

Post by l33t233372 »

JohnFen wrote: post #77
californical wrote: post #76

Earlier quoted context omitted.

Not exactly. Your approach works if everyone knows ahead-of-time the exact amount of effort that something will take. In software, it’s rarely the case that a project complexity is fully understood from the beginning; at best, you can make a ballpark estimate. If you have a rock solid approach and design a system with little drama, which is released on time and with high quality, then you look like it wasn’t a very a…

> Your approach works if everyone knows ahead-of-time the exact amount of effort that something will take. No, it really doesn't require that. But we're getting into the topic of project planning, which is a larger subject than we can tackle in the comments here. Fortunately, this is a topic discussed in great detail elsewhere. > But it’s also possible that the first engineer was just better, and the second had terri…

Where is project planning discussed well, in your opinion?

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

#90

Post by taocoyote »

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…

I once knew a soldier that had reconfigured his tent heater to be out of the way by placing it against the side of his tent. The tent caught fire. He received and award for putting out the fire.

I have seen this pattern repeated a few times throughout my career. People are rewarded for putting out fires they created (metaphorically), but people who are diligent and don't create problems to solve are overlooked or seen as less than capable.

Post reply on HN