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

41–50 of 116 posts

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

#41

Post by ilrwbwrkhv »

pphysch wrote: post #39
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.

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 extraneous code and you should think very carefully if you are adding any line beyond that.

The worst in the typescript world is elaborate types which do not work all of the time. Better to have implicit types doing most of the heavy work and remember you are building software, not doing type system research.

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

#42

Post by marginalia_nu »

fidotron wrote: post #35
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.

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

Yeah, this is a very astute observation.

It's also worth noting that the cost of technical debt is higher for larger organizations. Refactoring is very cheap when you're just one or a few people, but prohibitively expensive to the point of impossible when working in a much larger organization.

I think it's generally a bad idea to write code to large-organization standards when you're working alone. It makes your process much more rigid than it needs to be. The great benefit of flying solo or with a small team is exactly how nimble you can be, the small cost of re-writes and even throwing stuff away.

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

#43

Post by iveqy »

I strongly disagree. You should always keep the code as simple as possible and only add abstractions once you really need them.

Too many times I've found huge applications that it turns out be most scaffolding and fancy abstractions without any business logic.

My biggest achievement is to delete code.

1. I've successfully removed 97% of all code while adding new features. 2. I replaced 500 lines with 17 lines (suddently you could fit it on a screen and understand what it did)

Also: https://www.youtube.com/watch?v=o9pEzgHorH0

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

#44

Post by rqtwteye »

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.

"Rapid iteration on user control surfaces is good; rapid iteration on public APIs is bad."

I think rapid UI iteration is bad once a product has reached a certain maturity. I absolutely hate it when a tool I use often, suddenly changes its interface without any discernible benefit. I am fine with yearly changes but the constant churn is really annoying. MS Teams is a big offender here. They constantly change stuff but nothing gets better, just different. And a lot of UX guys seem to feel it's best to take away features that only a few percent of users are using.

Compared to the progress we made in 1990s and 2000s, it feels like most companies are just moving buttons around and making UI elements more difficult to distinguish but otherwise they are out of ideas for actually useful stuff.

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

#45

Post by bschmidt1 »

haswell wrote: post #34
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 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. If money is your #1 you wouldn't call it "crappy code" at all. Even code that is not as performant as it could be is only "crappy" if it's affecting the bottom line (which it often does). But so-called bad code that is yielding higher profits, hard to call crappy.

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

#46

Post by mihaaly »

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…

This way, I like to work in the shower or during commute of a crowded bus staring outside. But the best ideas come in the can, office or home bathroom, does not matter. : )

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

#47

Post by halfcat »

iveqy wrote: post #43

I strongly disagree. You should always keep the code as simple as possible and only add abstractions once you really need them. Too many times I've found huge applications that it turns out be most scaffolding and fancy abstractions without any business logic. My biggest achievement is to delete code. 1. I've successfully removed 97% of all code while adding new features. 2. I replaced 500 lines with 17 lines (sudden…

Yes. Battle future unknowns by remaining simple and flexible, not by trying to predict the future.

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

#49

Post by OrigamiPastrami »

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…

> If it's business - we had a solution deployed for the customer in less than an hour.

Boeing was good at finding cheaper solutions to business problems as well. In the end it's society that suffers for our tolerance of late stage capitalism.

There is no "right" answer to this. But tolerating crappy engineering because it's cost effective seems like an admission of defeat to people that actually want to make things better. It's not so much letting perfect be the enemy of good enough; it's more about the steady decline in quality because that's what we incentivize.

Post reply on HN