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

121–130 of 134 posts

Re: Ship Something Every Day

#121

Post by Hasu »

storoj wrote: post #91
zeroq wrote: post #16

|> Your team (and manager) sees you're working That's one of the greatest corporate flaws and my biggest personal failure that I fail, and refuse, to adapt to. When I work in a team I often try to empower lacking teammates by taking a challanging task, do most of the hard work, and give it to somebody else to finish up the easy part and ship the solution. While working on it they have to understand how the solution a…

> do most of the hard work, and give it to somebody else to finish up the easy part and ship the solution once I realized that the hardest part is actually _finishing_

Maybe for you. I'm terrible at starting projects and the beginning of them, but I love getting all the pieces in place and getting the product/feature to a production-ready state. It's easy and natural for me.

I used to work closely with a "starter" who is great at getting the activation energy to start, and we made a great team. Find yourself a "finisher".

Re: Ship Something Every Day

#123

Post by nicbou »

This doesn't make sense to me. Sometimes I need to sit down with a problem for a few days before I can even get to writing code. There is nothing to ship because I'm still wrapping my head around the business logic.

On other days I get nothing done because the most productive thing I can do is rest, or tend to personal matters. That doesn't mesh well with hustle culture, but it contributes to my personal happiness and long term productivity.

Re: Ship Something Every Day

#124

Post by hollerith »

nicbou wrote: post #123

This doesn't make sense to me. Sometimes I need to sit down with a problem for a few days before I can even get to writing code. There is nothing to ship because I'm still wrapping my head around the business logic. On other days I get nothing done because the most productive thing I can do is rest, or tend to personal matters. That doesn't mesh well with hustle culture, but it contributes to my personal happiness an…

I think some developers cannot create and refine a mental model of the finished product well enough for it to be worth it for them to spend days doing it.

Also, many managers perceive only writing code as worthwhile.

Re: Ship Something Every Day

#125

Post by lee »

I've experienced being on teams where PRs and commits happen infrequently, resulting in massive PRs and merges/rebases that constantly have conflicts.

The spirit of pushing small incremental changes on a team really helps address that.

This can be sustainable if everyone on the team realizes that every PR is expected to be small and incremental. It shouldn't be a large push every time.

Re: Ship Something Every Day

#126

Post by zarathustreal »

mythhabit wrote: post #47
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…

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…

> 1. Develop a system where you can turn codepaths on and off with a toggle.

> All are good practices…

I beg to differ on this point actually. It’s very difficult to get right and leads to subtle bugs (or even potential security vulnerabilities). It also pollutes the codebase with conditional statements that aren’t related to the business logic and makes it harder to read. Avoid feature flags.

Re: Ship Something Every Day

#127

Post by MaxLeiter »

PheonixPharts wrote: post #120
chipdart wrote: post #57

Earlier quoted context omitted.

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

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

Re: Ship Something Every Day

#128

Post by simiones »

morgante wrote: post #100
simiones wrote: post #95

Earlier quoted context omitted.

A day is barely enough time to have even a first go at a more serious problem. Why would you push failed starts into the main branch? And why do you think it's somehow better to have code behind a runtime branch (if) rather than a git branch?

You might not finish a serious problem, but there isn't any problem where you can't check something in. > And why do you think it's somehow better to have code behind a runtime branch (if) rather than a git branch? 1. It's a communication mechanism. Other people on your team should know what approaches you're exploring. 2. It is much easier to review small, incremental PRs than a massive PR dumped at the end of a pro…

> 1. It's a communication mechanism. Other people on your team should know what approaches you're exploring.

If they have the time to do that, they can look at a branch as well.

> 2. It is much easier to review small, incremental PRs than a massive PR dumped at the end of a project.

It's also much easier to entirely lose track of what the purpose of a feature was if you only review it in small, incremental chunks. The chunks often make sense individually, but are a convoluted mess when you look at the full picture. Also, a feature branch should still have many small commits on it, and you can easily review those individually as well, but you also get to look at the whole picture before putting everything in. Not to mention, if it needs to be reverted, much much much easier if there's a single PR with 50 commits instead of 50 disparate commits over 3 weeks.

> 3. The lift from merge conflicts / integration work is less.

If you pull everyday from the main branch, there's rarely a problem with merge conflicts and integration work, unless someone else is doing a major refactor. And if they are, there is going to be a problem regardless of whether you commit early or late, you'll still have to keep adjusting to their ongoing refactor (and the possibility of ever reverting will be slim to none).

Re: Ship Something Every Day

#129

Post by erik_seaberg »

Tao3300 wrote: post #115

> I'm sure people like recruiters look at GitHub profiles, and an empty page isn't a great look. What recruiter is going to see my company's private GitHub repos?

This. Since 2008 I've worked at one company using a Perforce derivative and three others using Gitolite or GitLab privately, but never GitHub. Maybe commit history matters to recruiters, but I've been on a lot of interview debriefs (discussing whom to hire) and it never came up.

Re: Ship Something Every Day

#130

Post by erik_seaberg »

mewpmewp2 wrote: post #89
safety1st wrote: post #54

Earlier quoted context omitted.

I was about to say; if we replace 'ship' with 'commit' I'm in full agreement. If you're a full time developer I don't know why you wouldn't. Commits are communication. If we're making them often and correctly, there's that much less fluffing around with reports and status updates and meetings that we need to do. The merits of CI/CD notwithstanding I definitely do NOT want my reports feeling like they need to deploy e…

Managers watch commit histories? Haven't ever heard of something like that.

I don't know about routine skimming of history, but promo committees in big tech look at both commits and code reviews (the comments you left on others' commits).
Post reply on HN