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

11–20 of 116 posts

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

#11

Post by bluGill »

tetha wrote: post #8
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…

Mjeah. It is our goal at work to enable our teams to deploy changes to their systems in production within minutes. And this works and the teams utilizing it get commended for it. But I also need to plan and execute a major database upgrade with ~250 applications depending on it. I will be very happy if I can have a solid, generally accepted plan in a month or two. It will just take 1-2 person-days to eventually execu…

Great, butmy end users don't live in fast internet range. every few months they spend some time in 2g cell range. upgrades mean mailing a usb drive. we have to get quality right as fixes cannot be rolled out fast.

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

#12

Post by emidln »

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…

Rich Hickey calls this "hammock time".

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

#13

Post by IshKebab »

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 real skill is not knowing the advice, it's knowing when to apply it.

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

#14

Post by firefoxd »

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

If you are lucky, you'll work in a company that is profitable without a hyped up product. Here you have the bandwidth to refactor.

I've worked in several companies that are built to sell. Tech debt is ignored unless there is a major breach.

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

#15

Post by bluGill »

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

If edison had spent some more time thinking he would have perspired a lot less. Too often there is no path from one to the next other than starting over.

If you have the wrong algorithm your existing tests won't help much as the likely have wrong edge cases.

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

#16

Post by IshKebab »

ashu1461 wrote: post #2

The refactoring piece is a great advice. That is the only way to keep the codebase sane and relatively free from tech debt. And if it is not the part of the process, it would never get prioritised.

Yeah I definitely agree. Any time spent prototyping is easily worth it (and I mean real prototyping, not "prototype that you add features too until it's the product").

I once spent a few weeks protecting a project with different GUI toolkits. I think I spent a week each on Qt, AngularDart and Vue. I wanted to spend one more week trying React but my boss was just itching to "start" and couldn't wait one more week.

We went with Vue, which turned out to be a terrible decision (I'm not sure about Vue 3, but Vue 2 at least is shit compared to React). Guess what we spent 6 months doing later... all to save one week.

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

#17

Post by greenbit »

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…

It's kind of maddening, after having the space to Just Think during the WFH days, to be back in the office and any time you stop typing for more than 30 seconds risk being interrupted by co-workers who think you're Not Busy.

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

#18

Post by jakelazaroff »

Strongly 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 you haven’t wasted a bunch of time refactoring before you know how your code base will grow.

I prefer this approach from The Grug Brained Developer:[1]

> next strategy very harder: break code base up properly (fancy word: "factor your code properly") here is hard give general advice because each system so different. however, one thing grug come to believe: not factor your application too early!

> early on in project everything very abstract and like water: very little solid holds for grug's struggling brain to hang on to. take time to develop "shape" of system and learn what even doing. grug try not to factor in early part of project and then, at some point, good cut-points emerge from code base

> …

> grug try watch patiently as cut points emerge from code and slowly refactor, with code base taking shape over time along with experience. no hard/ fast rule for this: grug know cut point when grug see cut point, just take time to build skill in seeing, patience

> sometimes grug go too early and get abstractions wrong, so grug bias towards waiting

[1] https://grugbrain.dev/

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

#20

Post by dahdum »

> 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 enough to do so was a sign of success.

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. Virtually all of the code I’ve written over the years has been tossed by acquiring companies moving everything to “their stack”, acquihire, company shutting down, product pivots, or better 3rd party software becoming available/affordable. I’ve pushed some trash tier code over the years because it worked just well enough to drive growth/revenue and keep the lights on.

Post reply on HN