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

81–90 of 116 posts

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

#81

Post by stouset »

hinkley wrote: post #80
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.

Sort of, but sometimes I feel like TDD approaches the forest by making each tree first one by one.

I really like writing a usage README first, since I don’t have to make anything work along any axis yet but I can play freely with the shape of things, figure out how to make the whole thing consistent, and experiment on what boundaries it makes sense to break components apart so they can be mixed and matched.

This does require a decent amount of engineering experience to both figure out what your consumers really need and also to design something that is actually implementable.

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

#82

Post by hinkley »

jakelazaroff wrote: post #70
ilrwbwrkhv wrote: post #41

Earlier quoted context omitted.

I think the intermediate level, do the refactoring first, clean code mentality is a big one to grow out of. The ultimate mastery is to think about "what does the computer need to do?" If there is a button click and some data has to be aggregated, those are two operations that should result in two blocks of code changing, the event handler and the db select group by (or other data source). Everything else beyond it is…

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.

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

#83

Post by hinkley »

neeleshs wrote: post #24

In my 25+ years of experience, any code you write today, however beautiful you think you wrote it, will get stale in a few years and has to be changed/enhanced to adapt to the new reality. With experience, you learn to find balance between pragmatism and purity more often than not. You will still not always be right. It is all still a mix of skill, experience, team and external factors.

When I’m working in lower-case c clean code, the amount of friction due to regrettable decisions made before everything became clear is unfortunate but manageable. When we have decisions that aren’t just regrettable but daunting (how on earth am I going to unravel this warren of pain and stupidity enough to get this thing to do what it’s supposed to do and only what it’s supposed to do??) then the full weight of the sins of the past hits, and we start making proclamations and resolutions about Never Again.

You don’t have to run away from the falling axe or ban axes. You need to not be there when it falls. And in the context of software what that looks like is very difficult to explain without ascribing unnecessary or even misguided qualities to the differences. We keep describing analogs, symptoms or harbingers of the real problem, and those fall down or distract.

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

#84

Post by hinkley »

sobellian wrote: post #31

You should usually wait to refactor until after you write the code and preferably ship it to someone. You may not understand what makes a correct implementation. Don't waste time refactoring incorrect code. You may not understand what makes a performant implementation. Don't waste time refactoring code that's too slow. You may not understand what the user wants. Don't waste time making something no one wants. You may…

One of the very frequent challenges I have with optimizing code, is that unless the problem is very highly contained, first I have to look at this code that’s all over the place, both physically and emotionally, and just try to figure out wtf it’s actually trying to do. I can’t replace it unless I know the requirements. The intent.

Give me a piece of code that’s wrong but clear about it, and we’re good. I can get in and out and move on to the next most tricky:value ratio’s problem.

Refactoring it to that point will always pay dividends. Even if it’s just for the next person trying to add more functionality in this area.

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

#85

Post by hinkley »

stouset wrote: post #81
hinkley wrote: post #80

Earlier quoted context omitted.

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.

Sort of, but sometimes I feel like TDD approaches the forest by making each tree first one by one. I really like writing a usage README first, since I don’t have to make anything work along any axis yet but I can play freely with the shape of things, figure out how to make the whole thing consistent, and experiment on what boundaries it makes sense to break components apart so they can be mixed and matched. This does…

We are doing this weird zigzag of a gradient descent because we know that things are bad, but we don’t know exactly how they are bad. We don’t know exactly which direction is “downhill” and which is “uphill”, so we turn around and head somewhere in a 120° code of where we think is the opposite direction. But it’s not the right thing, it just has some of the opposite qualities of the wrong thing.

It’s better than post-disaster politics, where “something must be done, this is something, so we shall do it” but it has an aftertaste of that same sentiment, if that makes sense.

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

#87

Post by sobellian »

hinkley wrote: post #84
sobellian wrote: post #31

You should usually wait to refactor until after you write the code and preferably ship it to someone. You may not understand what makes a correct implementation. Don't waste time refactoring incorrect code. You may not understand what makes a performant implementation. Don't waste time refactoring code that's too slow. You may not understand what the user wants. Don't waste time making something no one wants. You may…

One of the very frequent challenges I have with optimizing code, is that unless the problem is very highly contained, first I have to look at this code that’s all over the place, both physically and emotionally, and just try to figure out wtf it’s actually trying to do. I can’t replace it unless I know the requirements. The intent. Give me a piece of code that’s wrong but clear about it, and we’re good. I can get in…

I don't think you necessarily need to optimize before you make the code "clean" but you should at least understand what it will take to make it performant. This is a stronger requirement than it might sound like since most programmers are quite bad at predicting what will perform well without profiling first.

So knock together a prototype and profile that to understand what the bottlenecks are in your program, then you have an informed baseline of how the program needs to fit together to function well.

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

#88

Post by andrepd »

bschmidt1 wrote: post #79
andrepd wrote: post #63

Earlier quoted context omitted.

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

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.

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

#89

Post by haswell »

fabian2k wrote: post #57
haswell wrote: post #34

Earlier quoted context omitted.

> I’ve pushed some trash tier code over the years because it worked just well enough to drive growth/revenue With all respect, this summarizes everything I’ve come to hate about our industry over the years. I understand why this happens, and I’ve also been the person churning out crappy code at points in my career. But I think it also highlights how backwards the incentives have become, and we’re constantly seeing th…

One big problem is that you often don't know yet what you actually need, you only find that out when your software is in front of real users. So the later versions might be substantially different than your MVP. Building a very robust first version might be entirely useless if you have to throw away most of it after discovering it doesn't actually solve the user's needs.

The issue is that what often happens next is the thing that got cobbled together as a customer POC ends up in production.

Most hardware goes through extensive validation and revision before tooling to manufacture and ship at scale. The software space hasn’t always (often has not) found the correct balance between low cost early iterations and a properly hardened customer-ready product. The temptation is strong to just call it ready because it’s always possible to patch it later.

While I agree that finding this balance is a challenge, I don’t think that lowers the criticality of productionizing the code or the risk of using these early stage products that haven’t “grown up”.

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

#90

Post by pphysch »

hinkley wrote: post #82
jakelazaroff wrote: post #70

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

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.
Post reply on HN