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,…
May I propose terminology that has less negative connotations associated with them? How about "quick" vs "deliberate"?
One common behavior seen in “mature” software engineers
71–80 of 123 posts
Re: One common behavior seen in “mature” software engineers
#72Re: One common behavior seen in “mature” software engineers
#73The 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,…
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.
Re: One common behavior seen in “mature” software engineers
#74Re: One common behavior seen in “mature” software engineers
#75I'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.
It's the metaphor that doesn't make sense.
Re: One common behavior seen in “mature” software engineers
#76Earlier quoted context omitted.
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.
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 ambitious project. Or easier than expected. Maybe your team padded the estimates a lot and didn’t need to work that hard.
If you are putting in late nights and weekends and constantly fighting to get features working, maybe management thinks that the project was way harder than expected. They’re so lucky to have someone as hardworking as you or this project never would’ve been done!
Obviously there is a flaw in the logic — it’s possible that those assumptions are correct, and person 1 really was under-ambitious and person 2 is an incredible and dedicated engineer working on crazy hard problems. But it’s also possible that the first engineer was just better, and the second had terrible system design skills and constant spaghetti code that made a simple project seem complex.
It can be really hard to tell the difference. Even if both end up delivering on time, the second looks more ambitious, like they’re taking on harder problems.
Re: One common behavior seen in “mature” software engineers
#77Earlier quoted context omitted.
> 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.
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…
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 terrible system design skills and constant spaghetti code that made a simple project seem complex.
Right, I was intending to cover that with my "acceptable quality" conditional.
Re: One common behavior seen in “mature” software engineers
#78The 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.
The person to makes a lot of noise, good or bad, is noticed
Everyone say they want well engineered solutions, but in practice it's not what makes an impact.
Re: One common behavior seen in “mature” software engineers
#79The 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,…
There is a third type: those who can adapt to what is appropriate under the circumstances.
Re: One common behavior seen in “mature” software engineers
#80The 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 have been in the situation where over a period of time I inherited a lot of code that was written by my boss and absolutely critical to our business. Over time I began to see that they had made a number of poor design choices that made it very difficult to work with some of these internal frameworks. For example, there was a lot of global state passed around that kind of worked in production, but made it impossible to run tests in parallel (as well as making some of them flaky even when run serially). I introduced an internal dependency injection framework that leveraged some unusual host language features to remove the global state without painfully having to add a bunch of parameters to every function/class that would have to be passed around. This allowed the tests to run in parallel and completely removed the flaky failures. At the time I introduced the changes, they reduced the time to run all the tests from about 3 minutes to 20 seconds with no flaky failures. This was a major quality of life improvement not only for me, but for everyone else working on this part of the system.
Was this work rewarded? No. What I didn't consider when undertaking the refactoring was that I was implicitly making my boss look bad by fixing the systemic problems that they'd introduced. Even worse, I used techniques that were unfamiliar to them which was a further blow to their ego, though they wouldn't have admitted this at the time. Instead, they complained that they didn't understand some of my techniques rather than seriously try to learn what I'd done and appreciate the benefits that it brought. Ultimately, it became soul crushing to realize that they were more invested in doing things the way they'd always done them then to learn how to do things better (or at least offer constructive feedback beyond "I don't superficially understand this so it must be bad"). When you are in this situation, advancement becomes almost impossible because you have now become a threat to your boss, who will never make the mistake of allowing you to be promoted to their level or beyond.
I still think we should all strive to do the best work that we can because ultimately you should feel proud of the work that you've done. But this often comes with a major cost (which may ultimately be that you are forced to leave the organization).