Live data from Hacker News

Ship Something Every Day

maxleiter.com

111–120 of 134 posts

Re: Ship Something Every Day

#111
post #45

Or don't. The older I get, the more I find the obsession with work and hyper productivity to be pointless. This might be good advice for young people starting their careers, but even then I would advise prioritizing real life goals over work. Don't buy into the entrepreneur ideals you see on social media. People can be successful without working all day, everyday. Take rests, prioritize your health, and enjoy life fi…

I don't blog, but blogging is something I carry on my todo list for years. Knowing how important is the cadance to keeping the public engaged I always planned to post at most one post per month, and keeping a steady backlog of articles for at least 6 months in case I won't be able to come up with something new or simply not having time to add something new.

Re: Ship Something Every Day

#112
post #97

Earlier quoted context omitted.

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…

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.

Re: Ship Something Every Day

#113

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. Developers need to step back, think more deeply, and not worry about being pressured into "shipping code" that barely works. The dopamine rush of your code being shipped This frequent overstimulation leads to less ability for long-term attention. When I taught programming…

My attention span is not nearly enough to push releases everyday, but you also need to basically own the QA team. I've worked in enough places that if I don't have a QA team handy, I assume the worst possible environment. Devs get tunnel vision, we make really dumb UI choices, or account for x, y and z scenarios as issues, and forget a, b and c, which happen when the user uses your software while holding a toaster or whatever.

This is probably why 2 weeks prints are very common, its enough time to get some things out, enough time for QA to test it, and "short enough" that nobody is hounding as to why some feature is taking months. They can at least get it in incremental pieces with 2 week sprints (or whatever you prefer, 1 week, 3 weeks, 4, doesnt matter to me, just be consistent).

Re: Ship Something Every Day

#116
post #64

Earlier quoted context omitted.

> 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 b…

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

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?

Re: Ship Something Every Day

#117
There are a lot of people here that seem to be taking the view of "Oh no, it's a toxic to do this. You shouldn't work on the weekend. Why are you doing this just to get attention for your GitHub profile, or what your managers see?"

However, one concept that comes up in research like the book Atomic Habits, is that there's a much better reason to commit code frequently - quantity leads to quality. There's a famous story from the book Art & Fear about a university pottery class. The lecturer decided to grade half the class on the number of pots they produced, and the other half on the quality of a single pot. It turned out that the half of the class focused on quantity ended up producing higher quality pots over time. This is because the group that only had to produce one pot spent the whole time overthinking it rather than actually practicing and mastering their craft.

I think this is a much better reason to be committing code frequently and working on your skills every day. We're in an environment where it's a challenging hiring market, so it's important to set yourself apart from others within the industry. Some people have turned their nose up against "colouring in" their GitHub profile, but there are a number of psychological effects like "don't break the chain" that can be helpful in consistently putting in the effort.

Some commenters have mentioned tasks that simply take a long time, but I don't think the author of the original blog post was arguing against that. Rather, he's advocating that you should be continuously working on and improving your abilities.

Re: Ship Something Every Day

#119
> contribute something: docs, triage, whatever

> whatever you work on doesn't need to "ship to prod"

The author walked that back pretty quickly. My understanding is "ship to prod" is redundant, "shipping" means "ship to end-users (in prod)".

I guess "do your job on the days you're expected to" isn't great clickbait.

Re: Ship Something Every Day

#120

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. Developers need to step back, think more deeply, and not worry about being pressured into "shipping code" that barely works. The dopamine rush of your code being shipped This frequent overstimulation leads to less ability for long-term attention. When I taught programming…

> 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 lo…

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

Post reply on HN