3 ms·

> IMHO "every day" is far too frequent, and this ADHD-ish attitude is one of the reasons why the quality of average software has gone down the drain. I think y

> IMHO "every day" is far too frequent, and this ADHD-ish attitude is one of the reasons why the quality of average software has gone down the drain. I think you are too quick to try to claim someone is incompetent or unsuited for a job just because you can't or won't understand a point they make over how many commits they make. I disagree with you: 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. Any developer worth its title is well aware of stuff that needs to be done in a project in spite of not being a high priority. From renaming a function to refactoring a class, from adding a unit test to tweak how a test is setup, there is always, and I mean always, things that need to be done in a project. Even updating a document or adding a comment counts as a commit. And in the very least, if you feel that touching something in a project is a risky ordeal, your project needs tests. 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.

moring 2y ago
> 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.
- BoorishBears 2y ago
  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")
  - creshal 2y ago
    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.
    - BoorishBears 2y ago
      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.
- chipdart 2y ago
  > 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.
  - strken 2y ago
    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.
  - kalaksi 2y ago
    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.
  - bluGill 2y ago
    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?
sibeliuss 2y ago
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.
auggierose 2y ago
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.
mirekrusin 2y ago
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.
ZaoLahma 2y ago
> 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.
PheonixPharts 2y ago
> 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.
- MaxLeiter 2y ago
  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.”

moring 2y ago

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

BoorishBears 2y ago
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")
- creshal 2y ago
  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.
  - BoorishBears 2y ago
    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.
chipdart 2y ago
> 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.
- strken 2y ago
  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.
- kalaksi 2y ago
  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.
- bluGill 2y ago
  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?

sibeliuss 2y ago

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.

auggierose 2y ago

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.

mirekrusin 2y ago

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.

ZaoLahma 2y ago

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

PheonixPharts 2y ago

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

MaxLeiter 2y ago
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.”