> This has nothing to do with streaks or dopamine rushes or pleasing managers. This is about getting stuff done. To me, a developer who can't figure out ways to be productive by contributing tiny commits spread over time is a developer who is wasting space in a team.
This totally discounts any work that does not result in commits, such as requirements analysis, legacy code analysis, or code that results in insights but won't be merged.
But then, anyone who knows how incredibly valuable such work is will likely not want to argue whether they are "wasting space in a team" either, and leave on their part when confronted with such claims.
If you're regularly unable to make even a single line change as an IC, your team will probably not be at a loss.
Some of my biggest breakthroughs have been far away from a computer, but I can easily understand where the OP is coming from: give yourself a chance to make tangible contribution each day, and maybe it snowballs into something more.
Maybe it doesn't and that's ok, but at least give yourself the chance for it to.
(It also says something to read the OP and not be able to imagine any interpretation other than "they just don't understand how work is done")
Equalling "tangible contributions" to "git commits" is insanely reductionist. It works maybe if everything your org does - tickets, documentation, manuals, analyses, meeting transcripts, research notes, everything - lives in git, but otherwise, you're just asking to lower the quality of your org's organization and work culture for the sake of hitting made up KPIs.
- regularly unable: When you're an IC, there's plenty of non-code contributions needed but if it's so fantastically wild that you should regularly contribute code, something might be off.
- not be able to imagine any interpretation: the article literally says it now, but any half charitable reading already covers a productive day of non-code work. There's just still something to be said for making "butt in chair in front of editor" time.
If there's so much "other" taking your time in an organization that this seems onerous, it might be all the more reason to push for that time or question why that is.
> This totally discounts any work that does not result in commits, such as requirements analysis, legacy code analysis, or code that results in insights but won't be merged.
I don't think it does. My point was not "do this OR that". My point is that posting a commit a day is a goal that's easily achieved if you do professional work. The work it takes you to fix a typo or add a commit is not something you need to plan around, or have to choose in place of doing requirements analysis.
Only if your job is to write new code/features. I've been involved with critical bugs that took 6 months to figure out the root cause. What are you supposed to commit for those 6 months while staring at core dumps, trying to guess what might be going on?
This goes back to the "ADHD-ish attitude". I've had entire weeks where I didn't commit anything, because I was doing discovery or documentation or some other useful task with an outcome that wasn't code. Should I have deliberately broken my flow state to go put up a commit for a random unrelated typo?
The article does in fact note that documentation is acceptable.
This totally discounts any work that does not result in commits, such as requirements analysis, legacy code analysis, or code that results in insights but won't be merged.
But then, anyone who knows how incredibly valuable such work is will likely not want to argue whether they are "wasting space in a team" either, and leave on their part when confronted with such claims.