This is where erlang/elixir really shines! Using actor processes (aka genservers) to model business workflows and logic helps to align the programmer's and stakeholder's shared understanding and language of a feature, which leads to the implementation and expectations about it to be much more "correct".
Too many of us jump straight to modeling the domain objects as database tables without formalizing the the data model of the actual business need. Explicit state changes and considering "time" are way more important than database layout at that point.
And please either use operation explicit types and/or finite state machines when modeling the main domain objects.
My last three jobs started with untangling a bunch of "status" fields into explicit and hierarchical structures so that the whole company could agree and define what each of them actually meant. Common language, yo! It's the secret sauce!
Until it's 7 years later, the original developers are gone, the ticketing system has changed twice, and you have no clue why something is the way it is.
When you're committing is exactly when you already have the context of "why" loaded and even a short explanation should be quick to write. The thought cycles argument feels lazy unless you're doing a bunch of quick exploratory commits and clean up/squash your git history later and add context once a solution solidifies.
In that case, why should the commit history be the place to go? Commit histories are extremely exclusive – everybody not a part of the programming process will be locked out of that information. That is not fair.
Regardless, what you describe is more an organisational failure than an issue with commit messages.
> In that case, why should the commit history be the place to go?
In my experience with open source projects, the history is very much where I go. Say I read some code and don't understand a line (say it is weird, but it does not feel like complete garbage because the rest of the code is actually good), then I will definitely `git blame` or even start digging in the history to see where that line comes from.
Good commit messages have saved me more than once in that situation. It doesn't have to be a whole essay, but something meaningful. Something like "apparently Travis CI wants two white spaces here" is already useful: it says that back then, they used a CI called "Travis" and it required that weird extra space. Now I feel safe removing it because the project does not rely on Travis anymore. (For example).
Note: it could be in a comment. But comments rot, move, get out of sync, disappear. It's much harder to check all the revisions of a file in the last 7 years to look for a potential comment on another line than it is to find the commits that actually edited the line of code.
Same here! What a magical and empowering feeling to just see how a website works, edit it, and see the changes immediately. A year later I was paid to make my first website and 28 years later I'm still working as a full stack web developer. That one discovery in a toolbar led to a career and changed the course of my life. It's sad that that type of discoverability is largely gone.
Yeah, I used it quite successfully for a local nonprofit that kept most of their data in Salesforce. The eventually consistent syncing sidestepped a ton of headache for us and we could read straight from PostgreSQL. We just used API calls then writes to PostgreSQL for important changes (registrations, etc) originating from the website.
I keep having this argument about multitasking not being a real thing but I'd love some concrete research to back it up. I get the sense that people just feel more productive when "multitasking" Rather than recognizing the true cost of constant context switching.
reply