Taste vs. Skills
refactoring.fm
refactoring.fm
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.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.
It has a single switch to force unchanging non-formatted output, to use in scripts, not one different per subcommand.
It was carefully designed, not just adding random flags.
I don't know what will replace git. However I know they'll have a mountain to climb on to create something better.
Leaky abstraction is not git's problem. Git's problem is shit like "checkout -b". Why does git-checkout have a flag to do what git-branch is for? Convenience of course, but this kind of shortcut makes git harder to learn initially.
That's why the added `git-switch` lately.
For the rest, I would agree. Git is at its core technically "simple". But the CLI UX is quite, let's call it, involved.
I think there are two primary reasons for that: Git is a very interactive tool. That just doesn't go well with a UI which is fundamentally a line printer.
OTOH Git is very powerful. Most GUIs (or TUIs) can't "handle" this well, imho.
Git is "feature overkill". On the command line this doesn't matter much as you never see all features and options at once—besides of course that nobody can remember all those switches. ;-)
But when creating GUIs, which are better in the interactivity dimension, this becomes a real hurdle. Basically you have only the options to hide things and dumb-down your tool or end up with a overloaded and therefore quite complex GUI. Really hard to strike a balance.
The best I've seen so far regarding Git GUIs was Sublime Merge. It also hides much things at first sight but manages to not lock away Git's power by doing so. A lot of features are contextual. Also you have an "intelligent" command palette at your disposal. This matches nicely with the interactivity of Git! Also the GUI is strongly inspired by the look & feel of Git's command line output.
Sublime Merge feels for those reasons in large parts like if the command line tool would be "projected" into a GUI (which is convenient as the CLI output is already quite optimized to see everything relevant quickly), but given the GUI one does not need to remember the awkward command line flags.
Git on the command line should be more like that I guess. At least a kind of build-in REPL would be good as Git is interactive not "batchy".
I know there is a "git-repl", but it's not really what I imagine. It's not really context sensitive or interactive.
"Magit" looks good from far away, or at least heading in the right direction, but it only runs under EMACS.
If there would be something like Sublime Merge for the command line (and maybe even available OOTB) this could solve quite some of Git's usability problems I think.
.....with rm -rf /path/to/repository && git co https://repository, the same as you solve any other problems with git.
This ultimately sums up my thoughts: https://twitter.com/markrussinovich/status/15784512452490526...
At that point, it's just network effect. GitHub made using Git easy enough that people were willing to accept a clunky interface. It's not like people expected great interfaces from CLI programming tools in 2008, anyway. People are still using Mercurial, in any case.
As for Darcs, I used it. It's cool. I'm not convinced it's that much easier to understand than Git, and it has well-known performance issues.
(No disrespect to Junio intended)
The cli not so much, it's just serviceable, but the plumbing is a work of art.
Couple sources:
https://www.youtube.com/watch?v=PbC4gqZGPSY
https://www.themarginalian.org/2014/01/29/ira-glass-success-...
Thanks!
> 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.
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.
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 always wanted to be a music producer, I have a million ideas I love, but I found the study and act of music production tedious and frustrating.
However, after my studies, I was a wedding DJ. My taste in music rocked many a party (you haven't lived until you've seen grandma twerk) despite my inability to translate my cool ideas into cool music.
I have awesome taste, but poor ability to create. This reflects in other things I have a well developed taste for, but a poor ability to create, like photography.
Another interesting aspect is how skill can inform taste. As I studied music production and learned the nuances, I appreciated music on a far deeper level. Same with photography.
to know what to do... wisdom
to know how to do it... skill
to do the thing as it should be done is... service
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.
It's the same people that demand data before you can conclude that a quadriplegic is going to finish a 40 yard dash behind a non-quadraplegic.
SOURCE? :D
This is not bashing on the OP who may be innocent of this, but I swear there is a type of person who demands DATA! with the fervor of faith in academics that would make the apostles blush. The eternal hyper-fearful spiritual serf afraid of disobeying the masters of the age and instantly CYA's by running to his priest. For all the SCIENCE they screech, they have no concept of what the kind of research that would produce the DATA! they want might even look like; far from curiosity, it is the absolute form of incuriosity: they want to enter all life's questions into SSRN and have The Anointed tell them the right answer.
This has revealed the importance of being an authority who can spread truth, whereas I used to think seeking power was evil in of itself, now I see it as a powerful tool to spread goodness to those who only respond to power.
(I recently read the 48 laws of power and it was illuminating)
Imagine presenting the original version of King Lear to someone who doesn't know English. It's beautify poetry, I won't argue that, and our hypothetical listener might even be able to detect the rhythm of its iambic pentameter buried under the seemingly-gibberish words, but they won't appreciate it on the same level as someone who actually speaks the language. And while they'd be able to get the story if it was translated, it would lose the rhythm unless the translator recreated it, at which point you've got a new work of art.
Similarly, nobody's going to be able to appreciate the Git data model unless they've already got a solid sense of algorithmic thinking, and preferably the background knowledge of filesystems to know what problem it's actually trying to solve. Or the Quicksort algorithm to someone who doesn't even know what a recursion is.
(Some anal-retentive postmodernist would probably argue that there is, in fact, a language to physical architecture, and that if you don't speak it, you won't get it. The problem is that the only way I know of to test that would be to find someone with zero experience with human-made structures, which seems impossible. I see no real purpose in arguing this point, because when it comes to algorithmic beauty, there is definitely a skill floor below which you just won't get it.)
1) Yes, you definitely need to know Latin to appreciate the Aeneid, I agree with this.
2) It is a comparatively low bar though. Ability to write Hamlet is quite a step up from ability to read it. So a floor level of skill is absolutely necessary to even “unlock” the taste.
3) There are also returns to additional knowledge/skill for a while. The better your English is, or the more cultural references you know, the better your appreciation of Hamlet might be. You “unlock” less dramatic but still new taste buds.
4) I do think, however, that my OG point largely holds: your acquisition of baseline knowledge/skills doesn’t instill taste so much as unlock it. In other words, among people who speak English, all but the aforementioned seething subset will agree that Shakespeare is great and among people with some algo thinking, all will think elegant code is elegant.
5) Because the skill to unlock taste is so much less than the skill to produce, I agree with the article that they are basically orthogonal.
Taste can differentiate between different forms of beauty and form subjective preferences. Beauty is both relative and absolute. Your 16th century London building may cross the beauty threshold on some absolute scale, but consider a block that is filled with equally beautiful, but stylistically distinct buildings. It would be in poor taste to build a new building on that block in the 16th century style, even if the new building is objectively beautiful.
I actually mostly agree with you about intuition, but your claims are too extreme for my taste ;)
True, just like it would be in poor taste to stick a beautiful ornate green column in a building where it doesn’t belong. Beauty requires harmony on the collective level, a cacophony of individually beautiful things can be ugly as a whole. We don’t want eyesores like we don’t want a wrong note in a symphony, though the same note might fit well in a different symphony.
Not a matter of opinion and not in the eye of the beholder, beauty is almost entirely objective. “Good” taste / “bad” taste may be our way of saying how much one has jammed the frequency in his brain that disables himself from perceiving beauty.
A stronger way of saying this, which I believe to be true, is that no two people with good taste will have strongly divergent views when evaluating the same thing, whether that be a piece of elegant software or Shakespeare or Bach.
I disagree with this assertion (look at the heated arguments between different interpretations of quantum mechanics as a simple counter example that comes to mind). If I'm reading you right, you're claiming that taste is just appreciation for beauty, which is itself an undeniable objective truth. But I think this is too extreme in discounting any subjective role in the assessment of beauty. Any object that we deem beautiful just is. Whether or not we ascribe it as beautiful or not says as much about us as it does as the object. What does universal even mean here? Universal to humans? Can dolphins have an appreciation for beauty? If not, can it be said to be truly universal? If so, do we think that the dolphin's standard for beauty is identical to ours?
Again, I do agree with you that there are certain archetypes of beauty that most people will agree on. I also agree with your point that some people will dismiss beauty out of a sense of sour grapes. I just think you are taking things too far in the claim that beauty is a universal, objective truth outside of the realm of subjectivity. The concept of beauty itself cannot even exist outside of subjective experience so how could it completely transcend it?
> 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.
Both come with experience and a willingness to learn.
I'm not keen on the idea of taste as simply some innate quality, rather than something learned / taught. Thinking of it as some X factor makes it easier to write off people who just disagree or lack experience.
That said, I've totally seen code with poor taste and I've written it myself, so I believe in the underlying concept.
Most people are not highly skilled. And most people have poor taste.
It was in the context of I believe, creative work, people with good taste can produce good work by virtue of volume and discarding things that feel "off", regardless of initial skill
Skill comes from experience. It means knowing what will or won't work before you do it, not having to make random stabs in the dark until you find something that works.
That being said, as your skill improves, your taste is likely to improve because you are better able to differentiate between high and low skill work. But in many cases, you don't need any skill to tell the difference. It's not exactly difficult to tell the difference between a mediocre amateur singer and a well trained professional. Where it gets really tricky though is that you may find that you may not prefer the most technically skilled practitioner. There are many people who would rather listen to Bob Dylan sing than Luciano Pavarotti. Is that poor taste? I'm not so sure. It's certainly possible to acknowledge Pavarotti's technical vocal superiority while still preferring Dylan. Whichever singer you prefer, you don't need any vocal skill to immediately tell the vast technical difference between the two. Many things are like this.
Same for singers, a technically good singers are often bad at identifying what people want, while more popular singers have better test so better able to produce what the crowd wants. But same problem here, bands often lose taste as they become famous, they didn't lose skill they are probably more skilled than ever, they just lost their ability to tell whether what they are doing is great or not.
good stuff by the author
imma reach out
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.
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.
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
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.
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!
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.