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

31–40 of 116 posts

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

#31

Post by sobellian »

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 not understand how the software needs to evolve. Don't waste time making something extensible in a way that will never happen.

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

#32

Post by freefaler »

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…

Indeed, my own experience in my several companies confirms this.

Yes, code quality is important, but we write code to solve a problem for the paying customer. If we can't solve it on time and on budget it doesn't matter how well it has been written.

If you survive long enough you'll refactor the parts that are important.

Also some parts are more important than other, everything with money calculation and potential data loss should be written more carefully.

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

#33

Post by DangitBobby »

Commit hooks are not the place for test checks. You want developers to commit and push work so they don't lose it to catastrophic disk failure, theft, etc. Instead, test on push, or before merging. If you like to enforce "atomic commits", well, there's always interactive rebase.

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

#34

Post by haswell »

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…

> 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 the real world impact playing out as the next zero day, the next botnet, the next Boeing scandal, etc.

I’m not saying there’s never a place for bad-but-working code, but I’m increasingly convinced it never belongs in customer facing products, and that we have a major task ahead of us collectively to correct the mindset behind this and fix the incentive structure that enables this.

Software runs the world now, and a frighteningly large number of software companies do not take their position of power seriously.

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

#35

Post by fidotron »

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…

A former colleague of mine had a good way to describe it: technical debt is like financial debt, too much will kill you but if you don’t have any you will be outgunned by those that do.

The trick is how to manage tech debt properly, and the widespread scrum fake-agile in use provides no means for ever tackling tech debt once taken on. This is one reason for the explosion in SRE teams.

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

#36

Post by mitthrowaway2 »

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

This, exactly. Rapid iteration on user control surfaces is good; rapid iteration on public APIs is bad. Edit to say — rapid iteration of UX is good as long as it’s goal-aligned and has an endpoint. Set a goal, iterate and measure until you achieve it, then leave it alone.

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.

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

#37

Post by stackghost »

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

This, exactly. Rapid iteration on user control surfaces is good; rapid iteration on public APIs is bad. Edit to say — rapid iteration of UX is good as long as it’s goal-aligned and has an endpoint. Set a goal, iterate and measure until you achieve it, then leave it alone.

I can't think of a UI/UX iteration in the last 10+ years that felt like an upgrade.

Reddit, Gmail, Twitter, Windows, Android, touch screens replacing actual buttons, etc. they all used to be better but big companies seemingly can't help themselves from making their product worse.

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

#38

Post by [deleted] »

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.

[deleted]

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

#39

Post by pphysch »

jakelazaroff wrote: post #18

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

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

#40

Post by rkuodys »

mitthrowaway2 wrote: post #36
sonofhans wrote: post #7

Earlier quoted context omitted.

This, exactly. Rapid iteration on user control surfaces is good; rapid iteration on public APIs is bad. Edit to say — rapid iteration of UX is good as long as it’s goal-aligned and has an endpoint. Set a goal, iterate and measure until you achieve it, then leave it alone.

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