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

111–120 of 123 posts

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

#111

Post by disgruntledphd2 »

JohnFen wrote: post #86
this_steve_j wrote: post #73

Earlier quoted context omitted.

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.

It depends on what you're building, tbh. If you run a large b2c site and want to outpace your competition then you default to shipping. If the costs of failures are much higher, you are better off defaulting to a slow and steady pace.

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

#112

Post by BerislavLopac »

One danger in the "what about the rest of the infantry?" mindset is that it's too easy to start generalising the problem - and, consequently, design solutions - to a bigger and bigger extent.

What about other stones inside the encampment that the soldiers can slip on? What about the stones outside of the encampment? Wait, isn't the wall around the encampment MADE OF stones?

And pretty soon you have soldiers cleaning up stones all over the landscape, replacing the wall with solid concrete and designating a stone-cleaning platoon that will go ahead and clean the stones preemptively.

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

#113

Post by [deleted] »

throwaway327649 wrote: post #94
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…

Has anyone been stuck in a position where you seemingly cannot land a promotion because you've had to keep taking on more responsibilities, to the point where you're beyond qualified for the next level, but you're not yet able to excel past it to the next level beyond that? - Must achieve the highest performance rating for current responsibilities to qualify for promotion. - But current responsibilities are actually…

[deleted]

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

#114

Post by agumonkey »

GoodDreams wrote: post #60
agumonkey wrote: post #57

Earlier quoted context omitted.

This is why I need a different job. This pattern sucks energy out of me. I need military minded coders.

I’m interested in understanding what it means to be a military minded coder.

On the field there's no time for false drama or fluff, you have resources (time, energy, devices) and you keep doing the best you can at every step. And if you don't think enough about how you plan your operations, you die.

I don't want my teammates to feel on the verge of death, but I really, really work better if I'm operating at high pace and density and if the team also does that, like swarm of people attacking all problems at all levels on the job.

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

#115

Post by JohnFen »

disgruntledphd2 wrote: post #111
JohnFen wrote: post #86

Earlier quoted context omitted.

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.

It depends on what you're building, tbh. If you run a large b2c site and want to outpace your competition then you default to shipping. If the costs of failures are much higher, you are better off defaulting to a slow and steady pace.

True, from a certain business point of view. As a customer, though, I want nothing to do with such software and I don't want to work on software that I wouldn't personally use. That's why I say it's obvious which side I fall on.

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

#116

Post by JohnFen »

l33t233372 wrote: post #89
JohnFen wrote: post #77

Earlier quoted context omitted.

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

I have no single source. I only meant that this is a topic that is widely covered, and collectively with greater depth than is appropriate in this thread. Read widely on this topic, and don't focus just on one perspective. That way, needed nuance can be retained.

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

#117

Post by hbrn »

BerislavLopac wrote: post #112

One danger in the "what about the rest of the infantry?" mindset is that it's too easy to start generalising the problem - and, consequently, design solutions - to a bigger and bigger extent. What about other stones inside the encampment that the soldiers can slip on? What about the stones outside of the encampment? Wait, isn't the wall around the encampment MADE OF stones? And pretty soon you have soldiers cleaning…

Even bigger danger is convincing yourself that you are the hero that eliminated a "class" of problems without a concrete evidence that the class exists or worth eliminating. After all, everyone is biased to build a story in their mind in which they are the hero.

I've seen too many teams happily investing in stone-cleaning activities while forgetting there's a war out there.

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

#118

Post by hbrn »

nonethewiser wrote: post #58
mike_hock wrote: post #45

I'll take forced parables that don't make any sense in the metaphorical context in which they're framed for $500.

Here is an easy example. You have a project that has both typescript and javascript. Someone makes a change in a JS file. They try to access a property of an object but there is a typo. You could fix the typo and be done. Or you could fix the typo, and convert the file to TS and make sure its typed.

And then you get another typo in another JS file. So you convert it too. Rinse and repeat. In the end, all your application is now written in typescript, hooray.

Only the number of defects stays the same. Puzzled, you start investigating, and eventually you realize that all of those bugs were shipped by the same person. Turns out your whole TS crusade was a distraction. Even worse: you were optimizing for poor performers at the cost of your best performers.

But when all you have is a hammer, everything looks like a nail.

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

#119

Post by lcall »

fzeindl wrote: post #20
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...

Excellent article; thank you. I have written similarly in my notes, focused on the code maintainability (or component quality) part, but not in a shareable format yet. It is a sort of maturity model (I hope eventually to turn it into a grid with practices on the left side and levels across the top, so the RH column is near-ideal behaviors personally and organizationally). But the concept begins with a self-code review for each commit or PR, followed a code review from someone else (who ideally was not part of the design discussion) who asks questions like: is this code easily understood for a new maintainer? would I want to maintain this? How was it tested? Is any coordination in order with other stakeholders, or does documenation need to be updated? Is it clear why the code exists and the tests do what they do?

And then improving over time. This came up for me after repeatedly encountering code that no one could understand but the original author ("bus count of one", or if one person gets hit by a bus we would be in trouble), or that was needlessly complex for the enjoyment of complexity (really), or that had tests where no one knew why they tested for certain behavior (until fortunately someone else came back from vacation after I was about to commit a change to the test). Etc, all for comprehensibility and maintainability, and reliability.

Ps: overall, this is one of the most enjoyable HN discussions I have seen.

pps: I also one started encouraging our team and others to maintain a set of wiki pages, listing all projects for which we were responsible, then for each one at least one simple page of documenation listing things like who are the stakeholders, where is the source code, any odd build or deployment steps, the key (one sentence) inputs and outputs, where it runs, who does backups of what, etc. Before that it was haphazard. This is short of a real ops manual and could be done better of course, and would change as other org. practices change, but it was far better than nothing, and could be created in 10 minutes from a template. Great for bringing new teammates on board. I think an organization should have something like that for the whole org, listing teams and each team having such a page, as well as listing everything essential that a new person should know rather than relying on haphazard cultural transmission. We had rules like "no new debt" that were well-adopted and began to slip out of the culture as new people joined.

Post reply on HN