This is just another Waterfall By Another Name process and as a developer all I got out of this was don't work at Jam (whoever that is).<p>> When developers pick up tickets that don't have all the information they need, they need to spend more cycles investigating and waiting for follow up information from the broader team.<p>This could also be interpreted as adding layers of friction between the people experiencing problems and the people fixing those problems. This generally leads to worse outcomes.<p>> After product spec and kick-off, the next step is for engineering to spend a little bit of time writing a technical plan.<p>Oh good, a spec tossed over the fence in yet another meeting, and then <i>another</i> spec before any lines of code are written. No thanks.<p>> Having milestones put on the calendar also gives us the flexibility to move them when needed, but makes it so that we consciously need to decide to move them, rather than letting dates slip by.<p>The dates slip by because software estimation is akin to the Halting Problem. You aren't fixing that, just making your managers feel better.<p>> Having a daily check in on the project status helps us recognize when we are drifting off track and need to make decisions about whether to change the date or re-prioritize what's in scope.<p>Even more meetings, hooray!<p>> All of the tips above are things we started doing as a direct result of something one of us suggested in a retro. Retros are awesome, and are so important.<p>And more meetings about what went wrong in the prior meetings.<p>FAANG doesn't do this. Hire great people, trust them, communicate async frequently, coordinate planning infrequently. This reads like a manifesto for "we hired a bunch of subpar developers and don't give them any ownership or empowerment". Pass.
> hours of planning can save weeks of engineering.<p>This is so hard to get teams to do. I am almost always the slowest to implement a change simply because I don't conflate design and implementation.<p>At first glance it looks like I get less done, but when you account for the fact that nobody has to clean up after me or shoehorn a work around for an edge case in I become one of the most efficient.<p>Assigning cost to subsequent follow up tasks is difficult as well. Both technically in terms of aggregating/grouping as well as interpersonally because people get defensive or discouraged when you're consistently pointing out shoddy work.
Agree with everything in this blog except the premise<p><pre><code> Move fast and break things
</code></pre>
was never about breaking production by being cavalier with your code. It means to don't let inertia accrue, don't fail to challenge assumptions, don't let fear of pushback prevent you from exploring the best course of action.<p>Way easier to achieve in a small organization.<p>edit: Did a bit of digging and I may be wrong here. In an interview in 2014 [0], when Facebook was changing their motto to "move fast with stable infrastructure", Zuckerberg said<p><pre><code> "As developers, moving quickly was so important, we would even tolerate a few bugs to do it..."
</code></pre>
I've always interpreted like I originally wrote, but that's not in sync with being ok shipping bugs.<p>0: <a href="https://www.cnet.com/tech/mobile/zuckerberg-move-fast-and-break-things-isnt-how-we-operate-anymore/" rel="nofollow">https://www.cnet.com/tech/mobile/zuckerberg-move-fast-and-br...</a>
None of these tips are specific to remote. None are insightful either. Write comments, plan better, do things better. Seriously?<p>Just another google spam blog post to drive traffic.<p>Btw, if your team goal is "ship to production" (as per screenshot), you're probably not moving fast enough.
The whole point of "move fast and break things" was making an actual choice instead of trying to do everything badly. This puff piece misses the point.<p>It also doesn't tell us what "fast" is at Jam. We only know that it's calendar-driven development with quality gates.
> Tip #5 – more code comments.<p>I find this to rarely be true in practice. It's not that comments are intrinsically useless (though they do suffer from the intrinsic limitations that are not statically checked or tested), but that most developers tend to write comments for things that benefit from them. Or, when they do need them, they are poorly written or too terse to be useful to anyone else. I would venture to say I've seen maybe or two comments in my 15 years of software engineering that I saw and actually thought "wow, well this helps me understand this a lot better."
> Having a daily check in on the project status helps us recognize when we are drifting off track and need to make decisions about whether to change the date or re-prioritize what's in scope<p>Does daily project status seem excessive? Development can be non-linear, so I wonder what decisions are needed to made on a daily basis.
We move fast and have guardrails such that breaking things permanently is unlikely. All diffs require another engineer to sign-off. There is no directly pushing to production without A Very Very Good Reason(TM). CI/CD and canarying occurs automatically.
OK, i could expect there's tons of hidden tech debts to be discovered as the project goes big.<p>Expect 1 year to migrate to new services.<p>But that's another story, because "If it works in production, don't touch it".<p>Not breaking things is only half of story.
All great tips. I would add another bullet point along the lines of,<p>* Make your software observable. Your feature is not finished until you've verified it is being used as expected. Ideally you should have all of the data you need to know if things are going well without having to wait for customers to email you with complaints. Be careful not to develop a culture of developers throwing code "over the fence", either to QA staff or a release team - developers own their code from IDE to production.<p>If you don't develop this culture of ownership you end up with longer feedback loops between customer support, QA and dev.