Live data from Hacker News

Ship Something Every Day

maxleiter.com

131–134 of 134 posts

Re: Ship Something Every Day

#131

Earlier quoted context omitted.

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

I work at a FAANG like company, and here it's just annual performance reviews, that include bunch of achievements and then politics. No way anyone is going to check anyone's commit history. There are huge calibration meetings where managers have to stand up for their engineers on who gets what kind of performance rating and who gets promoted, and it's just verbal debates. There's just no way anyone can bring up someone's commit history and have enough time to explain what is going on overall.

And managers have little clue about the actual work that is going on. Definitely not enough clue to understand what commits are about, even if they have had a technical background overall.

Re: Ship Something Every Day

#133

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

In my view there's almost no excuse for going an entire 8 hour work day without something to show for it.

Re: Ship Something Every Day

#134

Earlier quoted context omitted.

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

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

I think you got things in reverse.

Deployments happen at each pipeline run. At each pipeline run, you run tests.

Continuous deployment.

Post reply on HN