I said this in another comment recently about git, but I find it odd that even after a decade of using git as a mandatory part of my professional life, I'm still learning new things.
That's maybe not a good sign about the usability of git.
That `@{'3 days ago'}` thing? That's incredible. Why didn't I know about that 8 years ago? Why wasn't it obvious, intuitive to me that this was possible?
git is brilliant and I love it. But there are very few affordances that make it obvious what to do next, what is possible. There's few patterns in it where I can apply what I already know.
The thing that replaces git will have most of the power of git, but an intuitive interface that makes learning everything about it easy.
> I said this in another comment recently about git, but I find it odd that even after a decade of using git as a mandatory part of my professional life, I'm still learning new things.
If I can humbly offer a suggestion: read the man pages. A man page read once thoroughly is much more useful than the same man page skimmed 1000 times. The syntax in question is in the rev-parse man page (`git help rev-parse`).
These are tools we use every day. Look, I'm the first person to throw out those furniture assembly instructions and dive right in. But the truth is, we'd all be better off reading the documentation for our tools.
The git man pages are far from the best, but they contain tons of useful information.
And it's not just with git that developers seem allergic to reading documentation. I noticed a colleague the other day doing this from a shell script:
I think we'd all be better developers if we RTFM, at least for the tools/languages we use every day. You simply don't know what you don't know. This way you at least know a little more what you don't know. :-)
I think rather than asking everyone to read the manual, the designers of software systems ought to all read Don Norman's "The Design of Everyday Things".
Apple products became what they are because no manual was needed. They were designed with patterns that were intuitive, affordances, and a deep understanding of human psychology.
What I am arguing is that git lacks those very things that make reading a manual not needed.
I don't think the fact that you keep discovering features is a bad sign for a tool like git. It would be a bad sign if you kept discovering new footguns in the features you use (there is a fair bit of software like that).
I'm 25 and a couple weeks ago I discovered a new way to use a knife to prepare a fish, even though I've been doing that all my life. I don't think knives or fish have bad UX, even though I keep discovering new ways to use knives on fish. What's important is that I don't keep discovering new ways to hurt myself with knives.
Git is more like… the new car. It’s complicated and most people have no idea how it works, but they know how to steer very simply and can drive it with a bit of training. Experienced people however, who know how cars work, can do really cool things with them and have no problem repairing them on their own.
Still, cars are useful. A bike would be better of course.
I like it! I'll do you one further. Git is more like... someone ripped out all the controls from your car and installed a Boeing 787 dashboard. You'd probably figure out how to start it and make it go forward, left and right, but you'd miss out on a lot of functionality and likely destroy something while playing with unknown buttons.
I never copy them from stackoverflow because I'm worried it does some weird magic that I don't want. Instead I build them against one or more examples.
There’s a subtle reason that programmers always want to throw away the code and start over. The reason is that they think the old code is a mess. [...] The reason that they think the old code is a mess is because of a cardinal, fundamental law of programming: It’s harder to read code than to write it.
Joel is 100% spot on. This is exactly why I don’t think things like Copilot will catch on. Making programming involve less writing code and more reading code actually makes the job more difficult.
And the corollary: since code is harder to read than write, steer clear of writing clever code where simple code would suffice, as the clever code will be much harder to read.
I can highly recommend regexr.com for testing and developing regex patterns; paste a representative sample in the "Text" area and it'll show you how things match (and usually, crucially, don't match) as you change the regex pattern.
I'm not associated with them, and I understand you don't seem to have any real issues with regex, but thought this would be a good place to mention a useful tool.
Using such testing you can only prove a regex isn’t what you want for specific inputs, and make a number of plausibility checks, but you can’t prove it is what you want for all inputs. For that you need to do the reasoning on the expression as if you had built it yourself.
I've used that and regexbuddy and others over the years. Almost anything the gives you some visual rendering of what's going on is helpful. Personally, I've taken to using the regex stuff in the Jetbrains IDEs, mostly because I'm there already most of the time, and it's 'good enough'. But I'm not always at my own setup, and regexr and similar are always a good tool to have (and to share with others to show them how a regex is working).
If I did this all the time, I might not need tools like this. But complex regex are something I only dive in to a handful of times per year, and it's never the same problem twice.
Nice! I’ve been writing (and reading) regexes for over 20 years now. I can usually ‘read’ them on sight, but I’ve been wanting this tool for when it all goes wrong.
Which of course always happens at least once or twice in any new dataset/usage.
Totally agree! But oddly enough, I have this problem with all code/languages… I always write code much more easily than I read it. I can write fairly complex applications just by following the logic of what the application must do in my brain (but with ZERO cleverness). But give me the source code of even the simplest Unix command and I’ll struggle to understand the purpose of every #define, the variable naming scheme, etc., etc. I’m sure this is telling me something interesting about how my brain works but I’m not sure what!
Regex is much simpler than Git, but also the different regex implementations in use have a lot of subtle and less subtle differences, whereas there is roughly only one Git.
> even after a decade of using git as a mandatory part of my professional life, I'm still learning new things.
I still learn new things in Python every month. I still learn new things in Magento every _day_. I'll learn something new in VIM or PyCharm or PhpStorm at least once every few weeks. I'll learn something new in my native language every few weeks, and I'll learn something new in my other languages almost every day. I'll learn something new about Bash or Linux or CORS or Selenium or some useful Chrome or Firefox setting or extension at least every week.
Learning new things is not unusual in the software development industry.
It's vindicating to see the general response in this thread vs threads about git a decade ago, where everybody defended git and decreed all of us simpletons just don't understand it enough.
Oh we do, and we understand how most of it is a flaming trash pile.
git could also have just followed some standards. For instance, how am I supposed to know the syntax of "3 days ago" in general?
They could have used time spans from ISO 8601 standard, so for instance simply "P3D". Or "P3Y6M4DT12H30M17S".
git is powerful but it involves a higher amount of time investment than it could if it were not reinventing the wheel and taking shortcuts as much. It's easy to see that it is and was built for powerusers mainly.
That's maybe not a good sign about the usability of git.
That `@{'3 days ago'}` thing? That's incredible. Why didn't I know about that 8 years ago? Why wasn't it obvious, intuitive to me that this was possible?
git is brilliant and I love it. But there are very few affordances that make it obvious what to do next, what is possible. There's few patterns in it where I can apply what I already know.
The thing that replaces git will have most of the power of git, but an intuitive interface that makes learning everything about it easy.