I did maintain Git for a few months, and the thing that made me ask Junio if he wanted to be the maintainer is that very-hard-to-describe notion of "good taste". I don't really have a better description for it: programming is about solving technical problems, but how you solve them, and how you think about them is important too, and it's one of those things you start to recognize over time: certain people have that "good taste" thing and pick the "right" solution.
I don't want to claim that programming is an art, because it really is mostly just about "good engineering". I'm a big believer in Thomas Edison's "one percent inspiration and ninety-nine percent perspiration" mantra: it's almost all about the little details and the everyday grunt-work. But there is that occasional "inspiration" part, that "good taste" thing that is about more than just solving some problem - solving it cleanly and nicely and yes, even beautifully.
And Junio had that "good taste".
And every time Git comes up, I try to remember to really make it very very clear: I may have started and designed the core ideas in Git, but I often get too much credit for that part. It's been 15+ years, and I was really only involved with Git in that first year. Junio has been an exemplary maintainer, and he's the one who has made Git what it is today.
Btw, this whole "good taste" thing and finding people who have it, and trusting them - that's very much not just about Git. It's very much the history of Linux too. Unlike Git, Linux is obviously a project that I still do actively maintain, but very much like Git, it's also a project with lots of other people involved, and I think one of the big successes of Linux is having literally hundreds of maintainers around, all with that hard-to-define "good taste", and all people who maintain parts of the kernel.
This also reminds me there are different dimensions to taste.
A developer can have both excellent taste and skill in code and lack one or both in its user interface. For instance, I'd personally say git seems to be amazingly successful and robust but that the UX could be much more consistent without sacrificing any power.
I fully expect there are other dimensions to this too for other overlapping domains in software engineering. Something like E.g:
- testing - does the test code work? (skill), is it making the most of opportunities for coverage and self-documentation (taste? Or a different kind of skill?)
- API design - can it do what's required? (skill), is it a sensible ABI too? (skill), can others understand it? (taste), is boilerplate minimal? (taste)
- documentation - is it correct and complete (skill) and understandable? (taste)
- code review - can you spot bugs and inconsistencies? (skill), are you giving feedback that allows incremental improvements without overwhelming? (taste)
I fully believe both skill and taste can be learned in all these areas but different thought processes will help in each.
I have a lot of respect for both Linus Torvalds and Junio Hamano. I think git has been very important, Linux even moreso. But why didn’t darcs or hg win instead? I will never know.
The interesting thing to keep in mind is that there is a subjective aspect to taste. Personally, I do not care for Linus's taste in programming or system design, but I absolutely respect his immense skill within his domain.
There is no "data" that would satisfy you if your intuition is so completely erased that you need some sociologist to tell you this.
Taste is a manifestation of beauty and beauty in all forms is universal and hypnotic and skill-independent. Babies, animals, 80 year old grandmas, all incapable of executing, all still respond to beauty. Beauty instantiates itself in different "tastes" of the day, maybe, but there is no act of beauty that becomes ugly over time. There are buildings from across the world 500 AD we consider beautiful and even try to emulate today. Execution has very little to do with this; you don't need to be a bricklayer to appreciate the pretty brick building from 16th century London.
The people who are most incapable of having good taste are generally not the unskilled people - those actually instinctively orient themselves to beauty when they encounter it - far from it, it is the seething subset of lesser skilled people who resent their inability to produce something of beauty and respond crabs-in-a-bucket style by taking true beauty down a notch. It is pompous art gallery types that will try to persuade you that the signed toilet bowl is "akshually art", worthy of being preserved in museums next to Caravaggio.
As my facility with code has grown, so has my sense of taste. I see beauty in code much more clearly than early in my journey. This is true of other things in my life as well.
You bring up a good point. I really don't know anyone in my personal/work life who I think has great taste but poor ability to execute. This includes not only tech but music, interior design, cooking, conversation, anything. I definitely know the reverse; people who can execute quickly but produce something smelly.
I'm reminded of the oft-quoted experiment where people judged on the number of ceramics they could create in a given time period ended up making higher quality output than people who were judged on their single best piece. The ability to make good judgements often is acquired by people who continuously have to make many judgements. And the ability to make many judgements is limited by your ability to execute.
I'll give a simple example. Do you think knowing how to write a lexer and parser means you know how to write the syntax of a language that will be pleasant to use? Because knowing the algorithms to do one does not mean you have the skills to do the other, which is a form of taste.
I'd argue that taste is a kind of skill (or more generally, knowledge). It can be developed. Doing things requires a multitude of skills. Depending on the task, some skills may be more impactful. There is also some co-development depending on the skill.
Basically, to get better at something, usually you have to branch out and develop periphery skills and knowledge. For example, don't just focus on writing bug-free code fast, but also on software design, and design in general. And team management. And people skills. And read research papers and algorithms. And learn from past failures and case studies, etc.
Thanks for the summary as I didn't read the article and I don't like arguing about "taste"... but I was piqued by "do what's needed to do the work" as "skill". I was reminded of the entrance plaque to the Schoellkopf Power Station:
to know what to do... wisdom
to know how to do it... skill
to do the thing as it should be done is... service
As someone who often thinks about these kinds of things, I like the OP's "skills as floor, taste as ceiling" take. Nothing earth-shattering here, but a cool little post.
This is not true for things that matter. It's no coincidence that the example he chooses is movies, of all things.
Skill is the independent variable. When your skill increases, your taste will increase.
It's not more complicated than that.
But a lot of people make it more complicated than that because they have an incentive to.
Because convincing others that you have "taste" is a very useful skill (ha) in our world. It's how you can position yourself as a leader, manager, critic, etc. without taking the time to develop skill yourself. It's a shortcut.
The trick is having to decoupling the two, which this article tries at.
I'd take 1 engineer with skill over 100 with "taste" (whatever that means) any day.
Taste is a thing, but having taste without skill is a myth.
> Taste is a thing, but having taste without skill is a myth.
I couldn't disagree more. Having taste but no skill renders the person unable to create tasteful things, but they are still able to recognize beauty when they see it. They may not have the language required to explain why the thing is beautiful, but being unable to explain beauty doesn't mean they lack the perception of beauty.
I am very uncomfortable working with people who sell their skill of taste. They have big plans and ambitions, but when the real talk comes they fall flat. It's hard to reconcile with them.
I see this behaviour in folks who made the shift to management from engineering without improving their skill enough.
Highly recommend Ira Glass's peptalk on this topic as related to storytelling, about embracing the process of failing forward. https://vimeo.com/24715531
I enjoyed the article, but I found the description of taste a bit nebulous.
I think part of it is the knowledge and experience you base your expectations/perspective on.
I would argue that there is a subjective aspect to taste that is determined by your personal/technical values. Having different values doesn't mean you have bad taste, it means you're optimising for different things.
If you find yourself in an environment where you're unhappy because things don't match your taste, you might value different things. This doesn't necessarily mean anything is wrong or objectively bad.
I think it's useful to frame things in this way because it can prevent you from dismissing the opinions of people that value different things.
Diversity of opinion and perspective is a good thing to a certain degree. Lack of a common set of shared values is probably a breeding ground for conflict though!
Taste is the soft skills side of exercising an idea. Skills are the actual technical skills. Both of those are measurable and quantifiable. Most people will argue this, often for self centered reasons because they don’t know how to measure things. Even then the people that do measure things frequently measure the wrong things in defense of themselves.
Here is how to solve for that: when it comes to measurements always put the product first and the people second.
For example:
* Is the product fast? If so how fast and compared to what baseline? All that matters is the performance difference in numbers.
* Is the product correct? Most of the time shops will measure for correctness of a developers contributions. That is putting people before the product. Instead measure the defects (both quantity and severity) coming out of the product.
* Do you have test automation? The only things that matter with test automation are the quantity of business requirements covered and the speed of execution. If your test automation takes hours to fire up or if it covers almost nothing nobody is going to use it. If the test automation covers more than 80% of the business requirements and executes in less than 2 minutes everybody will use it all the time because failing that costs less than involving other people.
* How long does it take to complete a new feature or solve a defect? If it takes a week you can deliver 5x less than if it takes a day. Simplicity and predictability in the code are major factors here.
* Do design decisions prioritize familiar conventions over evidence? Does your team do something just because it’s the framework way or because it’s a popular way of doing things or do your compare viable options and the one that scores highest?
Taste is how you convey these kinds of things. Most of those things listed above scare the shit out of developers. It takes a special kind of person to impose product measures contrary to the status quo and make the developers empowered for it.
taste is a tarpit. If your project has enough degrees of freedom to require taste, you're probably going to fail. Geniuses please ignore me. Everyone else, find your audience first.
robocat|3 years ago
mark_undoio|3 years ago
A developer can have both excellent taste and skill in code and lack one or both in its user interface. For instance, I'd personally say git seems to be amazingly successful and robust but that the UX could be much more consistent without sacrificing any power.
I fully expect there are other dimensions to this too for other overlapping domains in software engineering. Something like E.g:
- testing - does the test code work? (skill), is it making the most of opportunities for coverage and self-documentation (taste? Or a different kind of skill?) - API design - can it do what's required? (skill), is it a sensible ABI too? (skill), can others understand it? (taste), is boilerplate minimal? (taste) - documentation - is it correct and complete (skill) and understandable? (taste) - code review - can you spot bugs and inconsistencies? (skill), are you giving feedback that allows incremental improvements without overwhelming? (taste)
I fully believe both skill and taste can be learned in all these areas but different thought processes will help in each.
avg_dev|3 years ago
This ultimately sums up my thoughts: https://twitter.com/markrussinovich/status/15784512452490526...
thefaux|3 years ago
tiffanyh|3 years ago
(No disrespect to Junio intended)
k__|3 years ago
leetrout|3 years ago
Couple sources:
https://www.youtube.com/watch?v=PbC4gqZGPSY
https://www.themarginalian.org/2014/01/29/ira-glass-success-...
zharknado|3 years ago
pcurve|3 years ago
ChrisMarshallNY|3 years ago
Thanks!
angarg12|3 years ago
> Skill is the ability to build — to do what’s needed to do the work.
> Taste and skill are totally independent.
This is the crux of the article, and I'm not sure what to make of it. Some people have argued the opposite as well.
When the whole argument rests on a big assumption, I'd expect some data to back it up. If I don't agree with the premise, the argument falls apart.
club_tropical|3 years ago
Taste is a manifestation of beauty and beauty in all forms is universal and hypnotic and skill-independent. Babies, animals, 80 year old grandmas, all incapable of executing, all still respond to beauty. Beauty instantiates itself in different "tastes" of the day, maybe, but there is no act of beauty that becomes ugly over time. There are buildings from across the world 500 AD we consider beautiful and even try to emulate today. Execution has very little to do with this; you don't need to be a bricklayer to appreciate the pretty brick building from 16th century London.
The people who are most incapable of having good taste are generally not the unskilled people - those actually instinctively orient themselves to beauty when they encounter it - far from it, it is the seething subset of lesser skilled people who resent their inability to produce something of beauty and respond crabs-in-a-bucket style by taking true beauty down a notch. It is pompous art gallery types that will try to persuade you that the signed toilet bowl is "akshually art", worthy of being preserved in museums next to Caravaggio.
avg_dev|3 years ago
> Taste and skill are totally independent.
As my facility with code has grown, so has my sense of taste. I see beauty in code much more clearly than early in my journey. This is true of other things in my life as well.
zwkrt|3 years ago
I'm reminded of the oft-quoted experiment where people judged on the number of ceramics they could create in a given time period ended up making higher quality output than people who were judged on their single best piece. The ability to make good judgements often is acquired by people who continuously have to make many judgements. And the ability to make many judgements is limited by your ability to execute.
runevault|3 years ago
Ferret7446|3 years ago
Basically, to get better at something, usually you have to branch out and develop periphery skills and knowledge. For example, don't just focus on writing bug-free code fast, but also on software design, and design in general. And team management. And people skills. And read research papers and algorithms. And learn from past failures and case studies, etc.
throw7|3 years ago
to know what to do... wisdom
to know how to do it... skill
to do the thing as it should be done is... service
swayvil|3 years ago
cestith|3 years ago
Jensson|3 years ago
chrisweekly|3 years ago
EZ-Cheeze|3 years ago
good stuff by the author
booleandilemma|3 years ago
This is not true for things that matter. It's no coincidence that the example he chooses is movies, of all things.
Skill is the independent variable. When your skill increases, your taste will increase.
It's not more complicated than that.
But a lot of people make it more complicated than that because they have an incentive to.
Because convincing others that you have "taste" is a very useful skill (ha) in our world. It's how you can position yourself as a leader, manager, critic, etc. without taking the time to develop skill yourself. It's a shortcut.
The trick is having to decoupling the two, which this article tries at.
I'd take 1 engineer with skill over 100 with "taste" (whatever that means) any day.
Taste is a thing, but having taste without skill is a myth.
MichaelCollins|3 years ago
I couldn't disagree more. Having taste but no skill renders the person unable to create tasteful things, but they are still able to recognize beauty when they see it. They may not have the language required to explain why the thing is beautiful, but being unable to explain beauty doesn't mean they lack the perception of beauty.
club_tropical|3 years ago
joseda-hg|3 years ago
It's the understanding that generates the taste, and while it can come from experience, it can also come from observation.
The example of movie I believe is apt, and also aplies ti art in general and creative work as a whole
unknown|3 years ago
[deleted]
sawyna|3 years ago
I am very uncomfortable working with people who sell their skill of taste. They have big plans and ambitions, but when the real talk comes they fall flat. It's hard to reconcile with them.
I see this behaviour in folks who made the shift to management from engineering without improving their skill enough.
taylorbuley|3 years ago
n0w|3 years ago
I think part of it is the knowledge and experience you base your expectations/perspective on.
I would argue that there is a subjective aspect to taste that is determined by your personal/technical values. Having different values doesn't mean you have bad taste, it means you're optimising for different things.
If you find yourself in an environment where you're unhappy because things don't match your taste, you might value different things. This doesn't necessarily mean anything is wrong or objectively bad.
I think it's useful to frame things in this way because it can prevent you from dismissing the opinions of people that value different things.
Diversity of opinion and perspective is a good thing to a certain degree. Lack of a common set of shared values is probably a breeding ground for conflict though!
throwaway0asd|3 years ago
Here is how to solve for that: when it comes to measurements always put the product first and the people second.
For example:
* Is the product fast? If so how fast and compared to what baseline? All that matters is the performance difference in numbers.
* Is the product correct? Most of the time shops will measure for correctness of a developers contributions. That is putting people before the product. Instead measure the defects (both quantity and severity) coming out of the product.
* Do you have test automation? The only things that matter with test automation are the quantity of business requirements covered and the speed of execution. If your test automation takes hours to fire up or if it covers almost nothing nobody is going to use it. If the test automation covers more than 80% of the business requirements and executes in less than 2 minutes everybody will use it all the time because failing that costs less than involving other people.
* How long does it take to complete a new feature or solve a defect? If it takes a week you can deliver 5x less than if it takes a day. Simplicity and predictability in the code are major factors here.
* Do design decisions prioritize familiar conventions over evidence? Does your team do something just because it’s the framework way or because it’s a popular way of doing things or do your compare viable options and the one that scores highest?
Taste is how you convey these kinds of things. Most of those things listed above scare the shit out of developers. It takes a special kind of person to impose product measures contrary to the status quo and make the developers empowered for it.
Timwi|3 years ago
throwawayoaky|3 years ago
Zabihullah888|3 years ago
[deleted]
haskell_melody|3 years ago