Shipping fast might be confused for shipping smaller complete updates.
The more flexibility that's maintained in the start, the more things the code can try to solve.
This is also easier with less code written in general.
What 10k Hours of Coding Taught Me: Don't Ship Fast
91–100 of 116 posts
Re: What 10k Hours of Coding Taught Me: Don't Ship Fast
#92Earlier quoted context omitted.
I think you missed the point that it wouldn't actually be shittier code in that case. Some ugly 4 space indented, wrong kind of loops, old Node version, mongo as the main db, no linter, callback hell SaaS platform in 1 file called "server.js" could still be more reliable and yield higher profits and sooner than your masterpiece in Rust.
Yes, and then your user's personal details go on a darkweb leak. But who cares! You made bank and no law or liability will actually punish you for it, so what the hell.
No need for a dark web, Twitter and GitHub have both leaked user passwords stored in plain text on their own platforms right here on the corporate web.
Twitter who struggled to turn a profit (but not to pay its investors who became wildly rich off it) hired artists who chose technology like Ruby on Rails. They should have hired capitalists who breathed jQuery and ate pieces of sh*t like Active Record for breakfast
Re: What 10k Hours of Coding Taught Me: Don't Ship Fast
#93Think instead of abstract arguments it's better to think about concrete examples. I can think of lots of software that's survived, prospered with a "get it out of the door, fix it later" approach. Lol at risk of being attacked, Microsoft is classic case.
Love to hear of specific (not company secret of course) cases where projects, products or even companies died doing such shortcuts.
Re: What 10k Hours of Coding Taught Me: Don't Ship Fast
#94> They end-up making there managers happy, yet in the long-run everybody is panicking and they are considering refactoring or even building the application from scratch after 4-5 years. As mostly a startup dev I’ve never worked in a company with a runway long enough to afford worrying about a potential rewrite 5 years in the future. I’ve had to rewrite some of the most spaghetti founder code ever, but surviving long…
> Author isn’t wrong per se, but code purity isn’t always a worthwhile goal, and needs to be balanced by the needs of the business. I would phrase this slightly differently: code purity is always a worthy goal, but it's not always an attainable goal. As you said, sometimes the needs of the business have to get in the way even though it is a worthy goal.
[deleted]
Re: What 10k Hours of Coding Taught Me: Don't Ship Fast
#95Earlier quoted context omitted.
For me, the most important thing in this situation is coupling. The code implementing a feature may be an ungodly mess, but by minimizing its coupling to the rest of the system I make it easy to improve (or remove) later. I would much rather have messy and confusing code that is self-contained than an elegant abstraction with a large blast radius.
And you do that decoupling by… Refactoring. So I’m a little confused about why it sounds in this whole thread like we are vilifying refactoring without actually saying we are doing so. It’s weird.
No, I’m talking about the first time I write something. At that point in the game, my highest priority is to minimize the coupling between that code and the rest of the system (rather than, say, performance).
Re: What 10k Hours of Coding Taught Me: Don't Ship Fast
#96> They end-up making there managers happy, yet in the long-run everybody is panicking and they are considering refactoring or even building the application from scratch after 4-5 years. As mostly a startup dev I’ve never worked in a company with a runway long enough to afford worrying about a potential rewrite 5 years in the future. I’ve had to rewrite some of the most spaghetti founder code ever, but surviving long…
Another way to put it is that those colleagues are 4 teams away and 2 promos ahead before anyone has worked out exactly what went wrong and whose fault it was.
Re: What 10k Hours of Coding Taught Me: Don't Ship Fast
#97Earlier quoted context omitted.
And you do that decoupling by… Refactoring. So I’m a little confused about why it sounds in this whole thread like we are vilifying refactoring without actually saying we are doing so. It’s weird.
Refactoring "up front" is what people are taking issue with. It's extremely rare to have a project where you know every requirement and they never change "up front" before writing any code.
Either Fowler’s 2nd edition made some pretty big changes I’m unaware of, or we are all using very different definitions of Refactor. Do you guys mean “redesign”? Because that’s a very different word from “refactor”.
Re: What 10k Hours of Coding Taught Me: Don't Ship Fast
#98Strongly disagree with “Do the Refactoring First”. It is inevitable that your project will grow in ways you can’t anticipate. If you spend too much time up front on architecture, one of two things will happen: 1. You build abstractions that are not useful in the future, or 2. Worse, you build abstractions that constrain you from making future changes. Of course, either of these can happen anyway, but at least then yo…
Yes the author strikes me as a early/mid career SWE rather than a seasoned professional (10K hours is often used as an allusion to "mastery"). 1. Junior: hack a solution from A to B by any means necessary 2. Mid-level: wait, design matters. Abstract everything up front! 3. Expert/mastery: wait, complexity also matters. Consider many paths and finds sweet spot that is simple, robust, extensible, maintainable.
The article reads a bit like those blog posts from junior developers in third world countries who are trying their hardest to prove that they’re capable developers who know what they’re doing, in order to make it out of their current situation.
Re: What 10k Hours of Coding Taught Me: Don't Ship Fast
#99Earlier quoted context omitted.
Because you cannot build a substantial system such that it is easy and safe to change. Especially for changes you didn't foresee.
Hard disagree. The system I'm talking about is the largest scale system I've worked with (millions of QPS, thousands of servers). We built it in such a way that we were able to rewrite entire parts of our stack easily and relatively safely. The techniques and tools to do it are widely available today.
Good for you. Modular programming goes a long way, of course, but I'd say that your changes were then those that could be foreseen, for example by drawing the right modular boundaries from the start.
Re: What 10k Hours of Coding Taught Me: Don't Ship Fast
#100Aren’t we usually coding for another goal though?
Does shipping slow help us achieve those other goals?
If we look at coding purely for the goal of coding and having maintainable code, then of course we should ship slowly. But that’s not the only goal of most coding projects.