Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ship Something Every Day

maxleiter.com

Post reply on HN
Print view View original

71–80 of 134 posts

Re: Ship Something Every Day

#71

Post by strken »

chipdart wrote: post #70
moring wrote: 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…

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.

Re: Ship Something Every Day

#72

Post by vram22 »

anbotero wrote: post #59
userbinator wrote: post #5

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. Developers need to step back, think more deeply, and not worry about being pressured into "shipping code" that barely works. I agree with you partially because I’ve seen this Rush-Driven Development you describe, but with proper gates in place (hooks, Pull Request check…

>seen this Rush-Driven Development

Y. Also:

s/ush/esume

Re: Ship Something Every Day

#73

Post by vram22 »

Tommy430 wrote: post #51
userbinator wrote: post #5

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…

userbinator speaking out again, loving your posts on "modern" stuff. Unfortunately, that's how it's like sadly. People just want the "constant CONSTANT CONSTANT UPDATES!!!" without thinking properly, even if they don't need the new features but it's just because the company said so. Heck, physical books don't even need to get any updates and I can still enjoy picking them up and reading them, just like I can still en…

I just threw a pitchfork at you. It had only one tine, though. It was to the left of your username above, and pointing upward. Heck, it just disappeared into the screen or something.

Re: Ship Something Every Day

#74

Post by Arainach »

chipdart wrote: post #58
mythhabit wrote: post #47

Earlier quoted context omitted.

Some of the main benefits of shipping every day, is: 1. Develop a system where you can turn codepaths on and off with a toggle. 2. Become better at architecture. Learning to split a task into smaller chunks that are easier to reason about, both overall and individually. 3. Learn to do multi phase increment. 4. Develop an automatic deploy/rollback system. All are good practices, and essential if you need HA. It also g…

> Can you do all of that and ship on a weekly basis? Absolutely, I just haven't met anyone that do that. I'd go as far as to claim that you cannot, at least at a level close to a highly available system updated with full CD without any gating or manual intervention. Weekly deployments implicitly lead to merge trains and large PRs and team members sitting on their ass to approve changes. Each deployment is huge and in…

If your tests only run as part of deploy, you've already lost.

So long as you have a good set of integration tests and the right staging environments to run those tests against, when you ship doesn't matter. I've worked on multiple teams with test suites that give very high confidence what changes are good and are not; most tests were fast and could run before code was merged and block submission. The expensive integration tests ran against a staging environment, and when they started failing it was very quick to identify the range of CLs there and understand what to rollback/fix.

For most of my time there those services only pushed to prod twice a week - sometimes less if the integration tests were failing on the day of one of the deploys. Not every day, not every commit. And yet we had all of those benefits that you claim are impossible. No list of idle people waiting to approve changes, no "huge" deployments, infrastructure for automated tests and more. There are no meetings - those two weekly rollouts are entirely automated infrastructure, and unless an abnormal error rate is detected during the canary proceed entirely without human involvement.

The world didn't fall down. Customers didn't ask us where things were. Oncall appreciated that there weren't constant builds at risk of breaking and falling over - they only had to monitor rollouts twice a week and otherwise could focus on failing tests, logs, and alerts.

Re: Ship Something Every Day

#76

Post by fefe23 »

I find the reasons why he's advocating that interesting.

It's got for his mental health, it looks good to recruiters, it makes the work more incremental (wat?), and it gives him a dopamine hit.

Notably absent are reasons that would benefit the project or product.

To me checking something in every day does not look impressive. It looks like someone had nothing to do worth talking about and went around the neighborhood cutting off leaves from the hedges.

Causing a lot of transactions is a great way to stop people assigning you actual work. I suspect OP forgot to mention that reason. You already look busy without actually being busy. It's like managers scheduling useless meetings. They want to look busy so nobody gives them actual work to make them actually busy.

Re: Ship Something Every Day

#77

Post by liampulles »

No, focus on pushing the right solution. If you hold off pushing code that works but does not solve the correct (actual) problem, that's good.

Tracking commit frequency is one step away from tracking lines of code. If this is really the metric of performance, then you are a cog.

My take would be: plan upfront consistently. What do you need to do now to unblock the work later? Does the solution make sense? Is there something more useful? Think lots, talk lots, commit sometimes.

Re: Ship Something Every Day

#78

Post by pjd7 »

Laughs at a PostgreSQL schema change backfill jobs that need a few days to complete on i4i.16xlarge.

Or that time I spent $120k USD on testing some upgrade paths on a dataset in elasticsearch from version 2.4 -> 5 -> 6 -> 7 that took about 5-6 days runtime on imports per upgrade step.

Re: Ship Something Every Day

#80

Post by mirekrusin »

chipdart wrote: post #57
userbinator wrote: post #5

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…

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.

Post reply on HN