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

What 10k Hours of Coding Taught Me: Don't Ship Fast

sotergreco.com

Post reply on HN
Print view View original

71–80 of 116 posts

Re: What 10k Hours of Coding Taught Me: Don't Ship Fast

#71

Post by klodolph »

npalli wrote: post #64
klodolph wrote: post #62

I don’t know how many k hours of coding I have. 10k is long in the rear-view mirror. My advice? Ship fast. The way you get good is by being fast. Think of two junior engineers, we’ll call them Uno and Dos. Uno is working hard on a feature and wants to get it working, and working right. Uno spends two full weeks working on it and then sends out a PR. Dos starts by thinking “fast”, and figures out how to send a PR with…

This whole thesis rests on the team not knowing what to build and shipping fast to get more learning cycles. Works if you don't know anything (said juniors) or new fields (like internet or social or mobile etc.). Lot of places (including formerly new fields) that is not true anymore. Not everything is move fast and break things - which was Facebook's motto until 2014.

I say this is wrong, and the true reason to ship slower is when shipping something wrong is catastrophic.

Let’s say you are making something well-understood like a PCB. To me, the “ship fast” option is to make a prototype PCB fast, even if it doesn’t meet the design constraints (say, size, power consumption, cost),

That’s because very few things we build are so well-understood that you can design and then ship. Development is, in its most ideal form, highly iterative and incorporates data from the field as soon as feasible. In the PCB design scenario, we want the prototype sooner because we can learn things like “this design is too sensitive to EMI”, which may necessitate a redesign or at the very minimum re-spinning the PCBs.

PCBs are very similar to ICs. ICs get fewer prototypes and a more careful shipping process because it can cost millions to do a new stepping. Not because IC design is poorly understood or mysterious, but because mistakes are costly. That is the real reason you would slow down. Maybe you spend more time and money doing simulations for your ICs, maybe you have them go through more design reviews.

Likewise, shipping a bad medical device or bad space probe is usually catastrophic.

Re: What 10k Hours of Coding Taught Me: Don't Ship Fast

#72

Post by bigstrat2003 »

dahdum wrote: post #20

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

Re: What 10k Hours of Coding Taught Me: Don't Ship Fast

#73

Post by bigstrat2003 »

rkuodys wrote: post #40
mitthrowaway2 wrote: post #36

Earlier quoted context omitted.

Yes, please leave it alone. Nothing prompts me to leave a service I've been with for a long time than a UX "refresh" after I had years of experience and setting everything the way I liked it.

I think this is such an interesting issue. On one hand as a system developer, you want to keep existing customers happy with what they are used to. On the other- you want to grow and acquire new ones which requires upgrades to existing processes till you reach a limit - you need a new ui/ux. And what do you do? Maintain N versions?

The problem, as usual, stems from businesses prioritizing growth above all things (including the existing customers). There's absolutely nothing wrong with having a stable business that turns a respectable profit, but modern day American business culture is allergic to the idea.

Re: What 10k Hours of Coding Taught Me: Don't Ship Fast

#74

Post by mewpmewp2 »

bigstrat2003 wrote: post #72
dahdum wrote: post #20

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

It is a potentially misleading to think of it as a goal in terms of raw calculations.

If we parallelize it to debt should it be your goal to have 0 debt and why?

Shouldn't you first consider what is the interest rate of that debt and what do you gain by having this debt as opposed to not having it?

If debt has 0% interest, and you don't have limit on debt, why not just keep taking debt? What if debt has negative interest?

The goal should be to determine what is the optimal approach after considering all those factors and then take those approaches.

Some people have principles that they don't want to owe anything to anyone, but this will make them take suboptimal decisions. They assign this emotional value to something that is actually an arbitrary concept.

Re: What 10k Hours of Coding Taught Me: Don't Ship Fast

#75

Post by mewpmewp2 »

lordnacho wrote: post #9

One of the great things about working from home is that I often don't do anything. As in, I'm not even by my computer. I'm still thinking about what to do, but I'm not implementing anything. I'm not typing stuff, I'm not waiting for a compile, I'm not outwardly moving the project forward. But the project is moving forward. Inside, I am considering the tradeoffs. I'm thinking about what the business needs, and what th…

> One of the great things about working from home is that I often don't do anything. As in, I'm not even by my computer.

Couldn't agree more. I think one major advantage of working from home is that you can go for a walk whenever you feel like it without having to feel guilt or feel like you have to justify it to anyone. Not only is it amazing against stress and for health reasons, but it's also amazing to get another perspective with your thoughts left free to run.

Not to mention all the other productivity and efficiency ruining obligations in the office like having to feel you have to stay until certain time even though at that point it would be more efficient to do something else etc.

Re: What 10k Hours of Coding Taught Me: Don't Ship Fast

#77

Post by bschmidt1 »

cjfd wrote: post #59
bschmidt1 wrote: post #45

Earlier quoted context omitted.

Is code more like poetry or more like a recipe? If the former, then yes we should be allowed the time and space to craft the highest syntactic art imaginable. But if it's the latter, it should just be quick, correct, readable, and extensible. If it's art - how dare you ruin my masterpiece? If it's business - we had a solution deployed for the customer in less than an hour. If syntax (poetry) is your #1 take your time…

It is you who starts to talk about 'art' en 'poetry' but these words do not come from what you are reacting to. One thing you seem to assume is that the 'crappy code' works and therefore the concerns about its crappiness must be about irrelevant things like 'art' or 'poetry'. However, the working of what I would consider crappy code is generally highly tenuous. There has not been found a bug, YET...., but one differe…

> must be about irrelevant things like 'art' or 'poetry'

If by "bad code" you mean something related to syntax, convention, or code that "might have bugs" (wtf), there is still a case it's actually "good code" if it's more readable, was a quicker solution that yields higher profits, is a less error prone approach to the larger management of the codebase albeit less performant etc.

> one difference between crappy code and good code is that in crappy code one is quite sure there are lurking many bugs

Sounds too superficial/judgmental and not evidence-based. If there is a bug there is a bug. Even perfectly written code to the best possible standard can still be code that does the wrong thing.

Re: What 10k Hours of Coding Taught Me: Don't Ship Fast

#78

Post by mewpmewp2 »

IshKebab wrote: post #13
l5870uoo9y wrote: post #6

When I program something new and challenging, whether I want to or not, I follow Kent Beck's pattern[0]: “Make it work, make it right, make it fast.”. It seems unavoidable. [0]: https://en.wikipedia.org/wiki/Kent_Beck

I dunno if you can always do them in order. I've seen so many projects fail because they left "make it fast" until the very end ("but premature optimisation!") and then found they'd written tens of thousands of lines of code using a language or architecture that was fundamentally slow, and making it fast would require a full rewrite. I think it's fine advice in some circumstances but like so much coding advice the re…

Out of curiosity which projects were those?

It must be a very specific use-case, because usually I would see languages usually considered worst for performance being able to scale really, really far.

In 95% cases it's usually database being the bottleneck rather than whichever coding language you chose.

Re: What 10k Hours of Coding Taught Me: Don't Ship Fast

#79

Post by bschmidt1 »

andrepd wrote: post #63
bschmidt1 wrote: post #45

Earlier quoted context omitted.

Is code more like poetry or more like a recipe? If the former, then yes we should be allowed the time and space to craft the highest syntactic art imaginable. But if it's the latter, it should just be quick, correct, readable, and extensible. If it's art - how dare you ruin my masterpiece? If it's business - we had a solution deployed for the customer in less than an hour. If syntax (poetry) is your #1 take your time…

> so-called bad code that is yielding higher profits, hard to call crappy Missing the point of the person you're replying to entirely ... Yes you can get higher profits with shittier code, just as you can by building shittier airplanes, cars, bridges, etc. The consequences being exploits, hacks, 737MAX, Ford Pinto, etc

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.

Re: What 10k Hours of Coding Taught Me: Don't Ship Fast

#80

Post by hinkley »

stouset wrote: post #5

So much of our “ship fast” culture is based around end-user application development, where it’s a reasonable and defensible approach. But the further away you go from end users toward libraries, then internal services, then even further toward infrastructure, the slower and more thoughtfully you should move. These things often have far less rapidly changing requirements, and getting it right pays dividends. Or more r…

TDD is trying to accomplish the same thing. Here’s the shape of the thing, now make it work. But maybe we should just be writing the manual first. Though I would say we need something akin to “code coverage” in that doc, even if it’s just QA changing the font color of every line that is now true from red to black, so you know where the gaps still are.
Post reply on HN