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.

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.

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

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.

"Do you know where you are wrong ?" will definitely trigger people's defense

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

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

I think this is only half of it.

Years ago, I worked at a company where my time was split between working on a bespoke platform for an older client and a generic platform that would be used for all clients going forward. The bespoke platform was essentially being used to fund the development of the generic platform.

The contrast between the two was stark: the bespoke platform was legacy in all its weird glory, and the generic platform was considerably higher quality. Seeing that contrast up close, and flipping between working on each one, was immensely useful to me. It made it clearer why I favour certain approaches over others, and it made concepts easier to explain to others.

Since then, I'm of the opinion you should aim to work with both the good and the bad to clarify the "why" of things.

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.

It works better if you “split the axis”; (imo) good code is easy to modify, bad code is hard to understand. Everything else is, as you say, trade offs, and so only evaluatable within a specific context.

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.

I don't think code is inherently bad or good without defining the exact context and purpose of the code.

It all depends on what field you are in, the business requirements, the team and so many other factors.

What is the most important aspect: Easy to extend, easy to read or most optimal performance?

Is your team more comfortable with the functional style of programming or OO?

Do you follow existing conventions your team has established or current best practices?

Do you implement everything yourself or do you use external libraries?

Do you write code that makes you look smart using tech that looks good on your resume or do you use the simplest method to solve the program?

The is no one right way to program.

> Do you write code that makes you look smart using tech that looks good on your resume

> The is no one right way to program.

Those two statements taken together makes me suspect you think there is.

I do. I am not free of an ego. I just try to not confuse my taste for objective good or wrong though I sometimes fail.

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.

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.

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

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

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

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

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

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.

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

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

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.

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.