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

61–70 of 116 posts

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

#61

Post by stouset »

angarg12 wrote: post #25
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…

> even further toward infrastructure, the slower and more thoughtfully you should move. These things often have far less rapidly changing requirements I used to think that, until I worked on my first large scale system, infra heavy. It turns out it works both ways. If changing infra is hard, slow, painful and risky, people will be less inclined to do so. If changing infra is fast, easy, and with low risk, people will…

I don’t disagree at all, but I want to be clear that my point is more about upfront thoughtfulness and less about continual ability to iterate.

Being careful upfront often increases your ability to iterate rapidly because you aren’t constantly dealing with the consequences of poor early decisionmaking that causes calcification.

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

#62

Post by klodolph »

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 within only two days. This PR is, of course, horribly incomplete. Uno’s PR is bogged down in review because there are major problems. Dos, on the other hand, gets some really quick feedback from the team lead saying “you can extract this function and write a test for it, please do that.”

The same applies not only to junior engineers working on a small scale within a team, but to large scale projects being shipped by the whole team. Ship it fast, get feedback fast, and let it blow up in your face if you think you can survive the consequences.

The same applies to me. The best stuff I have ever shipped has been shipped fast and fixed afterwards.

If you want to raise the quality of your code, the way you do it is by meeting the requirements fast. If you beat the clock when it comes to baseline requirements, you get extra time to refactor and redesign components.

There are also a million things you can only learn by shipping code. Learn those things sooner; ship fast.

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

#63

Post by andrepd »

bschmidt1 wrote: post #45
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…

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

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

#64

Post by npalli »

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.

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

#66

Post by [deleted] »

firefoxd wrote: post #14

What 2 decades of coding taught me is, it all depends on the company. We all aspire to write clean code that scale. But most often then not, you inherit the code. If you work for a company that is built to sell, you will code fast and break things. Each feature is a show case to future buyers. If you work with "experts", you will write clean, scalable code that no one will buy. The priority is the code, not the produ…

[deleted]

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

#67

Post by angarg12 »

auggierose wrote: post #30
angarg12 wrote: post #25

Earlier quoted context omitted.

> even further toward infrastructure, the slower and more thoughtfully you should move. These things often have far less rapidly changing requirements I used to think that, until I worked on my first large scale system, infra heavy. It turns out it works both ways. If changing infra is hard, slow, painful and risky, people will be less inclined to do so. If changing infra is fast, easy, and with low risk, people will…

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.

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

#69

Post by sobellian »

muspimerol wrote: post #56
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…

It's important to note that this is only really relevant advice for a specific type of startup that is still trying to rapidly iterate to find product market fit. Personally I find it incredibly annoying to work on and with with products that were developed like this. There are so many half baked features that technically "work" but are slow, buggy or difficult to integrate with.

It's relevant if you need to rapidly iterate, period. The test is not whether you work at a start-up, but how well you understand your problem. I am currently doing a lot of automated design work with optimization over highly non-convex constraints. Good luck writing that without rapid iteration.

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

#70

Post by jakelazaroff »

ilrwbwrkhv wrote: post #41
pphysch wrote: post #39

Earlier quoted context omitted.

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.

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