I feel like the last point "development speed" is dependent on all previous points.
When I do a new project I always try to focus on a tech stack where - if i need to replace a part - i could easily do so. All these components are part of the decision
> One interesting consequence of this is that engineers with bad taste are like broken compasses. If you’re in the right spot, a broken compass will still point north. It’s only when you start moving around that the broken compass will steer you wrong. Likewise, many engineers with bad taste can be quite effective in the particular niche where their preferences line up with what the project needs.
This paragraph really gets to the idea of why I think discussing someone’s taste is basically useless in an engineering context. This “predictably broken compass” person stands out like a sore thumb, and you can just hold a 20min behavioural interview to filter them out.
A far more dangerous engineer is the “partially broken compass”, which appears at first sight to be working because it spins around like you’d expect, but is actually 127degrees off at all times.
Lecturing on "good taste" is a huge red flag for narcissism. "Taste" implies subjectivity. Pairing it with "good" is presupposing something along the lines of "my subjective evaluation of things is superior to yours", or "my subjective choices are superior to yours".
> In my view, your engineering taste is composed of the set of engineering values you find most important. For instance:
Strange how absent the customer or underlying business always is in this discussion.
I've seen a LOT of software that could have literally just been a spreadsheet on a file share or a simple SQL ETL job. When reviewing the actual business requirements, we will often find that we don't even need a goddamn web interface. It's just assumed we're gonna build some full stack slop so we never bother to stop and ask why.
I'm watching a client (despite my advice) self destruct on yet another rewrite of a piece of software that doesn't need to exist in the first place. Looking forward to having this exact same conversation IRL in a few months.
I think the heart of bad taste comes from obsessing over tools and techniques and not ever getting meaningful things built and shipped to real customers. Being exposed to unfiltered criticism of the people who actually use your software is the fastest way to drive the noob behavior out of a developer. It's amazing how quickly you drop weird principled takes when your monkey brain senses it is disappointing others.
Good code is invisible - either there's no code at all (because the requirements and architecture are well adapted so that code isn't necessary for a particular feature), or the code is so simple and boring that you skip over it without pausing.
Not all code can be like that, sometimes you need to write clever code, but it is an ideal to strive for.
BTW this is why egoless programming is so hard. Not only you have to accept criticism and let go of the idea of ownership of "your" code - you also have to write the code in a way that strokes ego the least.
I would say limiting the braggadocio is important to "good taste" as well. I interviewed once for a dev role on the email team for a very large free software company you've heard of. The team's egos were so large I could hardly fit in the room. "Oh! I see you wrote the control system for a nuclear power plant. That's cute, I once inverted a tree data structure!" or "I see you wrote the modular exponentiator that was in half the ATM machines deployed in the US in the mid-90s. Whatever. I wrote code that changes the background color of our web page."
> Is the software easy to take in at a glance and to onboard new engineers to?
This is not as easy as it sounds. Who are those "new engineers", juniors? 10 years of experience? 30 years? What's your requirement?
"Readability" is such a wildcard, with a whole range of acceptable levels from zero to infinity. Readability is a non-concept really. Maxwell's famous equations are readable to some and absolutely impenetrable to the rest of us.
So when someone says "code should be readable", to whom exactly?
When used in the domain of fashion "good taste" describes someone who has a unique way of selecting clothes that just mesh well together - clothes that by themselves independently are meaningless, no matter their make or quality, but when combined together create a powerful effect - much greater than the sum of their parts.
I was hoping the article would go in that direction - what subjective combination is a software engineer deciding on that you can argue is truly a matter of taste and not just a technical decision about a trade-off.
I would say this this article itself may be an example of bad taste. It meanders across a couple of disparate topics in software engineering, independently each section is competently written but as a whole they really don't sell the "look" the article was aiming for.
(I don't mean to discourage future writing by the author - I think it's a potentially excellent choice of topic. I'm just giving my two cents here on the execution.)
The portable definition of good taste in software development is likely something like fitness to purpose, i.e. how well does the taste lend itself to producing good software, where good software in turn is software that does what it is indented to do.
If you want to go more concrete than that, you need additional parameters, otherwise you risk ending up with a broken compass that only points north in organizations similar in size and other properties to the ones you've worked in before.
I'm not entirely sure what op means by good taste in this context.
If we can seperate good taste from best practice, it's that good taste is commonly associated with restraint and economy. Hence, no one can say that Liberace or Elvis had good taste. On the other hand best practice is primarily governed by efficiency and is driven by commonly practiced principles.
I was hoping we moved beyond this "clean code"-ish nonsense of functions having to be short.
Quality of a software design, maintainability, etc, have virtually no relation to length of functions and the most respectable software out there contain functions hundreds if not thousands of lines of code long without being impacted by its own weight.
I like the article. Most engineering decisions are indeed a tradeoff that should be carefully considered.
That said...
> I will always distrust engineers who justify decisions by saying “it’s best practice”. No engineering decision is “best practice” in all contexts! You have to make the right decision for the specific problem you’re facing.
There are indeed general best practices that are applicable to most, if not all, situations. E.g. version control and testing (arguably even the testing approach) are practices that every competent developer would agree are pretty much requirements.
Context does matter, but within specific contexts there are practices that can be generally considered "best", because applying them delivers more value than not, and their drawbacks are manageable.
For example, after a certain team size, implementing a CI pipeline is a best practice. Yes, it takes time and effort to implement and maintain, but the benefits far outweigh the drawbacks. After a certain scale, implementing a robust and efficient infrastructure management and deployment solution is pretty much a requirement. Relying on ClickOps to provision infrastructure, and deploying with shell scripts over SSH, while technically "simple", can only get you so far. And so on.
These practices become more evident with experience, and deciding when to vouch for them, even strongly, becomes more evident with wisdom. So I wouldn't necessarilly always distrust engineers who want to promote best practices. I would listen to them, discuss it with them, and make a decision along with the rest of the team. If they do push back after a decision has been made, that would be a bigger issue. Not necessarilly with that specific engineer―it could also be a sign of communication problems, egos, politics, etc. Unfortunately, there are many dysfunctional teams and companies with toxic environments, but I suppose that's just human nature.
72 comments
[ 3.4 ms ] story [ 60.6 ms ] threadThe point about varying levels of skill vs taste is accurate in my experience.
I think I fall into the more taste than skill camp, although neither are particularly large in an absolute sense.
I switched to product management quite early in my career and pivoted to learning design and product “taste” more than software engineering.
When I do a new project I always try to focus on a tech stack where - if i need to replace a part - i could easily do so. All these components are part of the decision
This paragraph really gets to the idea of why I think discussing someone’s taste is basically useless in an engineering context. This “predictably broken compass” person stands out like a sore thumb, and you can just hold a 20min behavioural interview to filter them out.
A far more dangerous engineer is the “partially broken compass”, which appears at first sight to be working because it spins around like you’d expect, but is actually 127degrees off at all times.
Strange how absent the customer or underlying business always is in this discussion.
I've seen a LOT of software that could have literally just been a spreadsheet on a file share or a simple SQL ETL job. When reviewing the actual business requirements, we will often find that we don't even need a goddamn web interface. It's just assumed we're gonna build some full stack slop so we never bother to stop and ask why.
I'm watching a client (despite my advice) self destruct on yet another rewrite of a piece of software that doesn't need to exist in the first place. Looking forward to having this exact same conversation IRL in a few months.
I think the heart of bad taste comes from obsessing over tools and techniques and not ever getting meaningful things built and shipped to real customers. Being exposed to unfiltered criticism of the people who actually use your software is the fastest way to drive the noob behavior out of a developer. It's amazing how quickly you drop weird principled takes when your monkey brain senses it is disappointing others.
Not all code can be like that, sometimes you need to write clever code, but it is an ideal to strive for.
BTW this is why egoless programming is so hard. Not only you have to accept criticism and let go of the idea of ownership of "your" code - you also have to write the code in a way that strokes ego the least.
I did not take the job.
This is not as easy as it sounds. Who are those "new engineers", juniors? 10 years of experience? 30 years? What's your requirement?
"Readability" is such a wildcard, with a whole range of acceptable levels from zero to infinity. Readability is a non-concept really. Maxwell's famous equations are readable to some and absolutely impenetrable to the rest of us.
So when someone says "code should be readable", to whom exactly?
I was hoping the article would go in that direction - what subjective combination is a software engineer deciding on that you can argue is truly a matter of taste and not just a technical decision about a trade-off.
I would say this this article itself may be an example of bad taste. It meanders across a couple of disparate topics in software engineering, independently each section is competently written but as a whole they really don't sell the "look" the article was aiming for.
(I don't mean to discourage future writing by the author - I think it's a potentially excellent choice of topic. I'm just giving my two cents here on the execution.)
If you want to go more concrete than that, you need additional parameters, otherwise you risk ending up with a broken compass that only points north in organizations similar in size and other properties to the ones you've worked in before.
If we can seperate good taste from best practice, it's that good taste is commonly associated with restraint and economy. Hence, no one can say that Liberace or Elvis had good taste. On the other hand best practice is primarily governed by efficiency and is driven by commonly practiced principles.
I was hoping we moved beyond this "clean code"-ish nonsense of functions having to be short.
Quality of a software design, maintainability, etc, have virtually no relation to length of functions and the most respectable software out there contain functions hundreds if not thousands of lines of code long without being impacted by its own weight.
That said...
> I will always distrust engineers who justify decisions by saying “it’s best practice”. No engineering decision is “best practice” in all contexts! You have to make the right decision for the specific problem you’re facing.
There are indeed general best practices that are applicable to most, if not all, situations. E.g. version control and testing (arguably even the testing approach) are practices that every competent developer would agree are pretty much requirements.
Context does matter, but within specific contexts there are practices that can be generally considered "best", because applying them delivers more value than not, and their drawbacks are manageable.
For example, after a certain team size, implementing a CI pipeline is a best practice. Yes, it takes time and effort to implement and maintain, but the benefits far outweigh the drawbacks. After a certain scale, implementing a robust and efficient infrastructure management and deployment solution is pretty much a requirement. Relying on ClickOps to provision infrastructure, and deploying with shell scripts over SSH, while technically "simple", can only get you so far. And so on.
These practices become more evident with experience, and deciding when to vouch for them, even strongly, becomes more evident with wisdom. So I wouldn't necessarilly always distrust engineers who want to promote best practices. I would listen to them, discuss it with them, and make a decision along with the rest of the team. If they do push back after a decision has been made, that would be a bigger issue. Not necessarilly with that specific engineer―it could also be a sign of communication problems, egos, politics, etc. Unfortunately, there are many dysfunctional teams and companies with toxic environments, but I suppose that's just human nature.
Compare:
* I apply the dependency inversion principle to keep my code testable
* I minimise the scope and mutability of all my variables
With:
* These methods do what they say they do
* This code is good because it's declarative
* These functions have the right number of lines