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.
Sometimes a good abstraction should leak. I hated Subversion and Perforce because both seemed like mystery boxes; I could use them but I never felt like I understood them. With git I've never had that feeling, if anything it's the opposite. Git is easier to understand than it is to use; the data model is simple enough to figure out in a few minutes, but learning the nuances of the various commands and flags takes a lot longer.
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.
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.
I agree, git made more sense to me after 6 months than svn did in the 5 years prior. The whole conflation of directories, branches and tags made svn an irredeemable monstrosity.
I’m really happy with source control at Google (perforce on a huge monorepo?). My experience with GIT has always been trying to find dummy guides on how to do simple things.
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 answer for why Git beat Mercurial in overall usage more or less boils down to GitHub being very successful. That isn't to say that Git wasn't already in a good position prior to that, but GitHub made it very easy to get into Git in a way that hadn't really existed before. (Anyone who used CVS or SVN on SourceForge knows what I mean.)
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.
Git was already very hype before github arrived. Every LUG and CS club was having people evangelize git seemingly every week before there was even a whisper of github. I think it got this hype from the association with Linus and Linux.
I think so. Mercurial had a lot of people using it, lots of features .. yet something made git blossom way higher very rapidly. Maybe python perf made a difference ..
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.
> Taste is a manifestation of beauty and beauty in all forms is universal and hypnotic and skill-independent.
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 ;)
> 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.
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.
> no two people with good taste will have strongly divergent views when evaluating the same thing
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?
I think you might have a point, but it's not applicable to this situation. Software architecture isn't like architecture. It's more like mathematics, or maybe poetry. There's a language to it, and if you don't speak it, you're not going to get it.
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.)
Thank you, your comment helps me sharpen my thought.
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.
>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.
I feel like this is most of humanity. Perhaps a central trait of humanity, following authority, the crowd, the tribe, whatever.
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)
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.
I agree with you. Skill helps you appreciate what is good taste.
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.
They may not be _totally_ independent, but the correlation coefficient is generally nowhere near 1. If you have reached the point where taste and skill are identical, then either you have none of either or you have reached perfection.
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.
Taste often becomes worse as you gain skill though, since you now start seeing trees and stop seeing the forest. A beautiful forest is more than a set of beautiful trees, so I think an expert on trees might be even worse at identifying beautiful forests than an average person since he will focus on details that doesn't matter much.
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.
Agreed. I'd say taste doesn't always require skill, but skill is necessarily accompanied by some measure of taste. It's even somewhat tautological in the sense that skill is the ability to generate something good, and taste is what defines what is good.
Skill enhances taste, developing skill gives you the experience needed to perceive nuances in design that other people wouldn't notice. But if you don't have taste in the first place I don't think developing skill will fix that.
I can't remember where I read it, but I recall hearing one time, "You need not know how to do something, just know how it should be right, making it will be simple because you will know when it's wrong"
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
If you have good aesthetic sense but no skill, you can create good work. But not efficiently. You'll have a lot of false starts, trying things only to discover they don't work, retrying again and again until you find something that satisfies your sense of taste. Through this process you will develop 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.
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.
An example of good taste but poor skill in execution.
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.
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.
It doesn’t necessarily mean you have the skills, but it can inform the process. I can’t think of a case where knowing your materials would be detrimental to working with them.
That's fair, it certainly helps. If you don't understand how all the parsing bits work you might make something that sucks to parse which can lead to confusing syntax. But it doesn't guarantee you can do the design phase.
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.
