Hacker News Reader

> 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.

Key terms in what I wrote:

- 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.

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.

What's the point of having such a goal? Seems like additional overhead if you need to remember and go out of your way to do such a trivial commit.

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?

That almost sounds reasonable!

Except it isn't. This is the reason why software is shitty, and most teams are shitty, too.

I write software because I have a vision in my mind, which I want to achieve. Coding up stuff and trying it out helps a lot, but so do phases of quiet introspection and reflection.

> I think that posting at least one commit per day is an incredible low goal. A commit can be anything, from a major refactoring to fixing a typo.

This is an easy goal in some companies / projects, while in others (usually bigger companies / projects) it's unreasonable and will even be counter productive.

You might need hours of execution time in a test cluster, then need code reviews from several peers (who are busy working on prioritized items), and if your commit is later integrated with commits from other organizations and tested as a whole which results in failures, you put extra load on those who are tasked with finding and sorting out the offending commits.

In principle I do absolutely agree with you that ideally it should be encouraged to spontaneously fix and commit, but in practice "it depends". I've found that larger companies / projects have a certain cadence, and trying to deviate from that cadence too much just results in grinding gears on all levels.

> I think that posting at least one commit per day

Notice that the article has been edited.

> Edit: A better title would've been "commit every day that you work". I don't mean you should work on weekends or not take time off, and whatever you work on doesn't need to "ship to prod".

I'm pretty sure parent comment was replying to the original version which, at quick skim, gives the impression that the article was about pushing to prod everyday.

I've worked at startups to do push to pod every day at it's an absolute frenetic nightmare.

Posting a commit everyday is so uncontroversial that I doubt the headline would have made it to the FP of HN. I've also never heard the term "shipping" in software refer to anything other than getting something into prod.

This confusion came from me not thinking too long before writing. My work makes use of feature flags so we incrementally merge features all the time, internally (and can do it quickly). But its still “shipped.”

You both are right but talking about slightly different aspects.

The morale of the story is don’t play speed chess but make move every day.

This right here is the truth. Yes, there's all the of the other stuff -- "requirements", etc -- but in reality, as an IC, we're here to push code and review code. All of the requirements stuff comes on top of that. (In my experience, the people who aren't pushing or reviewing code are _also_ not doing the other stuff either.)

Remember, commenting on PRs counts as activity. That's PR review -- that's doing something, and potentially a _lot_ of something. Big long stretches of empty space on Github is absolutely a red flag, until you get into the highest levels of IC seniority and are mostly in meetings all day.

It is extremely easy to do nothing at all as a software engineer, when there is so much stuff to do any given day. It's easy to get defensive when faced with such privilege.