When a developer admits that a single wrong character cost them one hour, it probably took 3 hours.
My favourite Git commit (2019)
121–130 of 406 posts
Re: My favourite Git commit (2019)
#122For better or worse, my experience as a GitHub cofounder and author of several Git books (Pro Git, etc) is that the Git commit message is a unique vector for code documentation that is highly sub-optimal. The main issue is that most of the tooling (in Git or GitHub or whatever) generally only shows the first line. So in the case of this commit example would be the very simple message of a generic "US-ASCII error" pro…
I know the OP didn't mean it this way, but after reading HackerNews for the last decade or whatnot, it never ceases to surprise me how often developer complaints stem from developers just not doing their damn job. "Almost nobody ever sees it.... nobody reads anything other than the first 50 chars of the headline." On the one hand, I get it. If a tool makes something difficult, people are less likely to do it, and as…
Any system where the proposed solution is "be better" without an outline of "and here is how" and some method of enforcement is doomed to fail.
Checklists, build checks, linters, tests, SLOs, post incident responses, follow up tickets, etc all serve to unload "be a better software developer" into actual systems and processes that can continuously enable the better behavior.
Simply stating "do a better job" wont work as organizations scale. Related, you can expect what you inspect.
Re: My favourite Git commit (2019)
#123Earlier quoted context omitted.
> Essentially zero people read complex commit messages I don't think that's true. I worked in support doing break/fix and outage response work at a large organization. That means constantly dipping into codebases I'm utterly unfamiliar with. Often there is complexity, un-obvious elements, previous incorrect attempts at a bugfix and so on, where understanding what the author intended can save literal hours of examinat…
> [..] where understanding what the author intended can save literal hours of examination, experimentation etc. The problem with that it that you are relying on an inherently unreliable source of information - a human to enter details which may or may not lead you to the correct path. The code doesn't "lie". Just read it and the current issue and work from there.
The code might not lie, but is also does not tell you why the DNS record in your IaC was changed from 1.2.3.4 to 4.3.2.1...
Well written commit messages are useful. Some people use issue tracking system instead, but commit message should have the information in more concentrated form instead of spread over 50+ messages of discussion.
Re: My favourite Git commit (2019)
#124Earlier quoted context omitted.
I know the OP didn't mean it this way, but after reading HackerNews for the last decade or whatnot, it never ceases to surprise me how often developer complaints stem from developers just not doing their damn job. "Almost nobody ever sees it.... nobody reads anything other than the first 50 chars of the headline." On the one hand, I get it. If a tool makes something difficult, people are less likely to do it, and as…
I feel like it's not a question of "doing your damn job". It's a question of what value can you expect to get from a particular investment. If blame is your tool and every line happens to be changed from a different blame invocation (is it "-w", "-w -C", "-C -C -C", etc), how do you learn the story of this block of code best? Maybe you then need to read a story _per line_ of code. But that's not actually worst case.…
Coding is a really interesting field in how quickly it's developed, and I think there's a lot of people who assume their environment is the only environment and it should be that way for everyone.
Spending time digging through commit messages when tooling and design makes it harder, not easier, is a risky proposition if it turns out it was all fucking useless and you didn't find anything worth reading and are now even farther behind. Either due to the quality of the messages or a lack of your ability on your end to find what you need.
I'd love to work in the sort of environments these people seem to but it's just not been the case. I'm at a smaller company where I get to wear many hats, and coding/development is just one of them, but I know plenty of people at very large companies who also don't really do things like that because "putting in the effort" isn't rewarded as much as whatever arbitrary metric they're graded on.
Re: My favourite Git commit (2019)
#125Earlier quoted context omitted.
> Essentially zero people read complex commit messages I don't think that's true. I worked in support doing break/fix and outage response work at a large organization. That means constantly dipping into codebases I'm utterly unfamiliar with. Often there is complexity, un-obvious elements, previous incorrect attempts at a bugfix and so on, where understanding what the author intended can save literal hours of examinat…
> [..] where understanding what the author intended can save literal hours of examination, experimentation etc. The problem with that it that you are relying on an inherently unreliable source of information - a human to enter details which may or may not lead you to the correct path. The code doesn't "lie". Just read it and the current issue and work from there.
The code may tell you what it does, but that doesn’t necessarily tell you why it’s there.
Especially for non-obvious pieces of code I have to deal with, I certainly prefer to understand the original reasoning and context within 5 minutes by looking at the original commit / PR, than having to spend multiple hours rediscovering that one quirky edge-case scenario that someone else already dealt with 3 years ago.
Re: My favourite Git commit (2019)
#126great commits are great. This is fantastic As an aside, I'm tired of documenting: - in code - in commits - in jira - in confluence - in daily standups - in release notes
- in Sharepoint - in some random Google Doc owned by one person that has to give permission to each individual who needs to read it, even though it's something the entire Engineering department should have access to. - in a GitHub Wiki that nobody even realizes exists - in a separate git repo that exists for just documentation, but nobody has checked anything into for 2 years
sometimes I wonder: If I didn't need to update 6 things, get approval from two colleagues, and justify the time to a scrum master watching how many tasks I complete every 2 weeks... would I write more meaningful documentation?
Re: My favourite Git commit (2019)
#127It's true that giving a little potted history like this is "good" (other than he should have made a nice informative first line for summaries) BUT it's not super useful to say this is good, the hard part is knowing WHEN to put this much effort in and when you can skip it. I have many instances where I could do a longer story like this but it would be exhausting to do it every time. I try to do it when the commit migh…
> BUT it's not super useful to say this is good, the hard part is knowing WHEN to put this much effort in and when you can skip it.
I learned git in the context of Linux kernel development (its original use case). In that context, the commit message is where you explain, to whoever is reading, what your change does and why it should be accepted. The more subtle the change is, the longer and more detailed the explanation must be to convince a reviewer.
So basically, the rule of thumb would be: pretend you're going to email your commit to another developer, who has the power to accept or reject your change, and who is not going to consider anything outside that email in their decision. The more subtle your change is, the more detailed and convincing its explanation has to be.
Re: My favourite Git commit (2019)
#128For better or worse, my experience as a GitHub cofounder and author of several Git books (Pro Git, etc) is that the Git commit message is a unique vector for code documentation that is highly sub-optimal. The main issue is that most of the tooling (in Git or GitHub or whatever) generally only shows the first line. So in the case of this commit example would be the very simple message of a generic "US-ASCII error" pro…
I know the OP didn't mean it this way, but after reading HackerNews for the last decade or whatnot, it never ceases to surprise me how often developer complaints stem from developers just not doing their damn job. "Almost nobody ever sees it.... nobody reads anything other than the first 50 chars of the headline." On the one hand, I get it. If a tool makes something difficult, people are less likely to do it, and as…
I'd hate to say that laziness makes a person an incompetent developer. Often my problems stem from an excess of sincere hard work and rather than from laziness.
Re: My favourite Git commit (2019)
#129great commits are great. This is fantastic As an aside, I'm tired of documenting: - in code - in commits - in jira - in confluence - in daily standups - in release notes
The code and commit documentation are about different things. One is about what this thing is, the other is about what is changing. But then, jira is about what is changing, confluence is about what is changing, standups are about what is changing (oh, but this is doing them wrong), and release notes are about what is changing. So your complaint is completely reasonable, just the first item shouldn't be there.
You also get what is changing by doing "git diff", and often, it is self explanatory, especially if you have already commented in code why you did what you did.
For example:
- code: MAX_SIZE=1024 // maximum size the backend supports
- commit: limit the size to 1024, as it is the maximum the backend supports
- jira: fixed the problem by limiting the size to 1024, as it is the maximum the backend supports
- confluence: do not exceed 1024, as it is the maximum size the backend supports
- standup: I set the maximum size to 1024, as it is the maximum the backend supports
- release note: Maximum size set to 1024, as it is the maximum the backend supports
Re: My favourite Git commit (2019)
#130[dead]