5 ms·

> In other words, immature engineers are too inflexible about their taste. They know what they like, but they mistake that liking for a principled engineering p

by t43562 1y ago

> In other words, immature engineers are too inflexible about their taste. They know what they like, but they mistake that liking for a principled engineering position. I have come across this although I think quite experienced engineers can suffer from this kind of immaturity. Aeons ago I used to help friends with their Computer Science assignments. I remember the temptation to rewrite their code because I didn't like the way it worked. I would start to do so and then, eventually, think that it was going to take ages and be unrecognisable to them. How could I help them by rejecting everything they thought? I'd think about it again and realise that they weren't idiots - their approach probably could work with a couple of adjustments. I helped them make those adjustments and they were happy because they could understand the result. After that I would find that my own way of thinking about the problem had changed and my own code would get much better from having seen the problem from a different angle. I should really have been the one thanking them. I am still like this - still prejudiced - but in the back of my mind I know it and when I'm being sensible I remember to try to give the other viewpoint a proper chance and be happy when it really turns out to have more merit. Principles are a bit subjective and if you lean on them all the time without thought it's a sort of laziness - you're not really examining the situation and what it merits.

Propelloni 1y ago
This principle (sorry ;)) is applicable to all domains. I'd wish I would remember this more often. Thank you for the gentle reminder!
- andruby 1y ago
  It's close to the mantra "strong opinions, loosely held", which I appreciate a lot.
CaptainOfCoit 1y ago
This is why I like experimenting with lots of different programming languages, and why I try to make the next language to understand as different as the ones I know, as I'm having these "epiphanies" all the time, challenging my existing views, which I can apply across languages when suitable. You just need to accept that things feel "wrong" and "weird" initially, before you've grokked the whys and hows.
grvdrm 1y ago
What a great comment. Your way of thinking is how I like to handle my direct hires. And people on a project that may not be my direct hires. Recognize that there are different ways to get things done. Not everything needs to please my specifics, process, etc. if the end result or goal is met
JKCalhoun 1y ago
"Good taste" I have found comes from experiencing "good" API's and other "good" code. You know good code (and API) when you see it — and in time you should be able to write it as well. In short though, it's hard to have good coding taste when you are new to the field. (But, as you point out, it's not true that experience guarantees you will acquire taste — you have to both be looking out for it, recognize it, and be able to to mirror it.)
- CaptainOfCoit 1y ago
  I'd argue the opposite, and go further and say there is no "good" code, only "not bad" code. I feel like most of what I think is good is because it's the only remaining option left after removing the "bad" ones. It's also way easier to find out why something is "bad" vs why something is "good" for some reason, not sure why. In the end, all code comes with tradeoffs, so I'm guessing we're really talking about good/bad tradeoffs, rather than the actual code itself.
  - hellisothers 1y ago
    I describe this as the Artist vs Scientist software engineer. I’m also an “artist” and approach the problem as a ball of clay, hacking away at it (and sometimes starting with a new ball) until the solution appears beneath my hands. The Scientist approach is to know the solution ahead of time , write tests to ensure it comes out the expected way, and then execute.
    - matthewkayin 1y ago
      In writing they call this the "gardener" (artist) vs "architect" (scientist). Some writers plot more at the beginning, and others just dive straight into writing, knowing that they'll have plenty of revising ahead of them. I'm definitely more of a gardener myself, and I've always considered the architect software engineers of the world to be silly and unfun and prone to locking themselves into an over-engineered architecture before they even understood the problem properly, but they really are just different approaches to software development and each of them has their strengths. In indie game development, the requirements are often unclear, and I am still exploring what the game idea might be, still trying to "find the fun" of a game, and so the gardening approach works quite well. In other fields, where you have clear requirements figured out from day one and the consequences for not meeting those requirements is much higher, the architect's approach has its wisdom.
enraged_camel 1y ago
>> I have come across this although I think quite experienced engineers can suffer from this kind of immaturity. Experience does not always result in maturity. It is actually pretty common for engineers to become more set in their ways as they gain experience, especially if they've seen some success, because that success has convinced them that the way they do things is the right way.
Retr0id 1y ago
I had exactly the same experience with giving CS assignment help. Although at the time, I didn't quite have the wisdom to work within their existing approach and tended towards more radical rewrites. Not that I thought they were idiots, I just didn't like their approaches - and didn't take the time to try to understand them.
stronglikedan 1y ago
I don't ever tall a junior that they are doing something in a less-than-optimal way. I always ask them why they're doing it that way. At the end of each conversation, one of us has learned something. Sometimes I learn an alternate approach, and sometimes they learn why their alternate approach won't work in the long run. Either way, it's never a confrontational conversation.
- idontwantthis 1y ago
  Asking questions is always the best way to correct someone (Hey Socrates). You avoid triggering defense, and if it turns out you were wrong, you don’t sound like a jackass.
  - cindyllm 1y ago
    [dead]
  - lukan 1y ago
    You still have to be sensible in the way how you ask questions. Very possible to intentionally or unintentionally insult and trigger lots of other things just by "asking a question" (my speciality).
    - sevensor 1y ago
      I try to channel Terry Gross. “You say it’s very important to frob the encabulator before and after you linearize the splines? Interesting, tell me more about that.” I don’t just want to correct bad code, I want to understand the misunderstandings that produced it and fix those. Otherwise you just wind up with more bad code.
  - mrheosuper 1y ago
    "Do you know where you are wrong ?" will definitely trigger people's defense
  - 71bw 1y ago
    This is why I never went into CS educationally. I was never treated in a respectful way by the Polish system. Always treated like ass
hosh 1y ago
Maturity is not exactly correlated to time in experience, just as emotional and social maturity doesn’t exactly correlate with biological age. I was 12 years into my career before the ideas in this article started filtering into my mind.
BinaryIgor 1y ago
I think that with experience, great programmers learn to recognize and differentiate subjective parts of software engineering form the objective ones; and then to have more lax and open approach to the former and stricter to the latter
estimator7292 1y ago
The solution for prejudice, bias, and rigid thinking in general is education and experience outside of your personal worldview. Actively trying to understand the world through someone else's perspective is how you grow as a person/professional and expand your own perspective. As an engineer and a strong generalist, I find that simply knowing that another angle or solution exists is enough to change my view of a problem and come up with solutions that are better than my first instinct.
heavyset_go 1y ago
It helps to remember that all code is bad, including your own code, and that includes your best code. You can make it a bit better, but it's still bad, and one should feel bad if they judge someone else based on their code.
hobs 1y ago
I think a big part of it is also moving your value system from the code to people and you'll make this migration naturally. Any code can be made perfect, but what could you help the person across the table with to make it good enough and also improve their understanding given their priors. Making the code perfect will simply be a bridge too far for them (and generally just means coding it up to your level of incompetence anyway.)
sevensor 1y ago
> Principles are a bit subjective and if you lean on them all the time without thought it's a sort of laziness - you're not really examining the situation and what it merits. I think there’s a very important developmental stage for programmers where they buy in to a set of principles past the point of all reason. It can be maddening to work with them at this stage. They’re all in on type systems or OOP or hexagonal architecture or what have you, and everything looks like a nail for that hammer. But eventually, some of them see the shortcomings of the one true way and come out better programmers for it.

by t43562 1y ago

Propelloni 1y ago

This principle (sorry ;)) is applicable to all domains. I'd wish I would remember this more often. Thank you for the gentle reminder!

andruby 1y ago
It's close to the mantra "strong opinions, loosely held", which I appreciate a lot.

CaptainOfCoit 1y ago

This is why I like experimenting with lots of different programming languages, and why I try to make the next language to understand as different as the ones I know, as I'm having these "epiphanies" all the time, challenging my existing views, which I can apply across languages when suitable. You just need to accept that things feel "wrong" and "weird" initially, before you've grokked the whys and hows.

grvdrm 1y ago

What a great comment. Your way of thinking is how I like to handle my direct hires. And people on a project that may not be my direct hires. Recognize that there are different ways to get things done. Not everything needs to please my specifics, process, etc. if the end result or goal is met

JKCalhoun 1y ago

"Good taste" I have found comes from experiencing "good" API's and other "good" code. You know good code (and API) when you see it — and in time you should be able to write it as well. In short though, it's hard to have good coding taste when you are new to the field. (But, as you point out, it's not true that experience guarantees you will acquire taste — you have to both be looking out for it, recognize it, and be able to to mirror it.)

CaptainOfCoit 1y ago
I'd argue the opposite, and go further and say there is no "good" code, only "not bad" code. I feel like most of what I think is good is because it's the only remaining option left after removing the "bad" ones. It's also way easier to find out why something is "bad" vs why something is "good" for some reason, not sure why. In the end, all code comes with tradeoffs, so I'm guessing we're really talking about good/bad tradeoffs, rather than the actual code itself.
- hellisothers 1y ago
  I describe this as the Artist vs Scientist software engineer. I’m also an “artist” and approach the problem as a ball of clay, hacking away at it (and sometimes starting with a new ball) until the solution appears beneath my hands. The Scientist approach is to know the solution ahead of time , write tests to ensure it comes out the expected way, and then execute.
  - matthewkayin 1y ago
    In writing they call this the "gardener" (artist) vs "architect" (scientist). Some writers plot more at the beginning, and others just dive straight into writing, knowing that they'll have plenty of revising ahead of them. I'm definitely more of a gardener myself, and I've always considered the architect software engineers of the world to be silly and unfun and prone to locking themselves into an over-engineered architecture before they even understood the problem properly, but they really are just different approaches to software development and each of them has their strengths. In indie game development, the requirements are often unclear, and I am still exploring what the game idea might be, still trying to "find the fun" of a game, and so the gardening approach works quite well. In other fields, where you have clear requirements figured out from day one and the consequences for not meeting those requirements is much higher, the architect's approach has its wisdom.

enraged_camel 1y ago

>> I have come across this although I think quite experienced engineers can suffer from this kind of immaturity. Experience does not always result in maturity. It is actually pretty common for engineers to become more set in their ways as they gain experience, especially if they've seen some success, because that success has convinced them that the way they do things is the right way.

Retr0id 1y ago

I had exactly the same experience with giving CS assignment help. Although at the time, I didn't quite have the wisdom to work within their existing approach and tended towards more radical rewrites. Not that I thought they were idiots, I just didn't like their approaches - and didn't take the time to try to understand them.

stronglikedan 1y ago

I don't ever tall a junior that they are doing something in a less-than-optimal way. I always ask them why they're doing it that way. At the end of each conversation, one of us has learned something. Sometimes I learn an alternate approach, and sometimes they learn why their alternate approach won't work in the long run. Either way, it's never a confrontational conversation.

idontwantthis 1y ago
Asking questions is always the best way to correct someone (Hey Socrates). You avoid triggering defense, and if it turns out you were wrong, you don’t sound like a jackass.
- cindyllm 1y ago
  [dead]
- lukan 1y ago
  You still have to be sensible in the way how you ask questions. Very possible to intentionally or unintentionally insult and trigger lots of other things just by "asking a question" (my speciality).
  - sevensor 1y ago
    I try to channel Terry Gross. “You say it’s very important to frob the encabulator before and after you linearize the splines? Interesting, tell me more about that.” I don’t just want to correct bad code, I want to understand the misunderstandings that produced it and fix those. Otherwise you just wind up with more bad code.
- mrheosuper 1y ago
  "Do you know where you are wrong ?" will definitely trigger people's defense
- 71bw 1y ago
  This is why I never went into CS educationally. I was never treated in a respectful way by the Polish system. Always treated like ass

hosh 1y ago

Maturity is not exactly correlated to time in experience, just as emotional and social maturity doesn’t exactly correlate with biological age. I was 12 years into my career before the ideas in this article started filtering into my mind.

BinaryIgor 1y ago

I think that with experience, great programmers learn to recognize and differentiate subjective parts of software engineering form the objective ones; and then to have more lax and open approach to the former and stricter to the latter

estimator7292 1y ago

The solution for prejudice, bias, and rigid thinking in general is education and experience outside of your personal worldview. Actively trying to understand the world through someone else's perspective is how you grow as a person/professional and expand your own perspective. As an engineer and a strong generalist, I find that simply knowing that another angle or solution exists is enough to change my view of a problem and come up with solutions that are better than my first instinct.

heavyset_go 1y ago

It helps to remember that all code is bad, including your own code, and that includes your best code. You can make it a bit better, but it's still bad, and one should feel bad if they judge someone else based on their code.

hobs 1y ago

I think a big part of it is also moving your value system from the code to people and you'll make this migration naturally. Any code can be made perfect, but what could you help the person across the table with to make it good enough and also improve their understanding given their priors. Making the code perfect will simply be a bridge too far for them (and generally just means coding it up to your level of incompetence anyway.)

sevensor 1y ago

> Principles are a bit subjective and if you lean on them all the time without thought it's a sort of laziness - you're not really examining the situation and what it merits. I think there’s a very important developmental stage for programmers where they buy in to a set of principles past the point of all reason. It can be maddening to work with them at this stage. They’re all in on type systems or OOP or hexagonal architecture or what have you, and everything looks like a nail for that hammer. But eventually, some of them see the shortcomings of the one true way and come out better programmers for it.