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

101–110 of 116 posts

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

#101

Post by fsckboy »

marginalia_nu wrote: post #42
fidotron wrote: post #35

Earlier quoted context omitted.

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 p…

>Yeah, this is a very astute observation.

isn't it just repeating the definition/use of debt which is why "technical debt" was called that in the first place?

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

#102

Post by IshKebab »

mewpmewp2 wrote: post #78
IshKebab wrote: post #13

Earlier quoted context omitted.

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 re…

Out of curiosity which projects were those? It must be a very specific use-case, because usually I would see languages usually considered worst for performance being able to scale really, really far. In 95% cases it's usually database being the bottleneck rather than whichever coding language you chose.

The main one I'm thinking of was a silicon verification system written in Python. Not the only reason the project failed but the fact that it was so janky and slow definitely helped slow progress to a crawl. It didn't have a database.

Speaking of Python, I also recently wrote a tool in Python that was getting a little slow and bloated - I rewrote it in Rust and managed to reduce the runtime by 40x and memory use by 3x. This one wasn't mission critical but you can see the scale of the issue. And no there wasn't any realistic way I could have found a hot spot and just written that part in another language. That rarely helps in my experience.

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

#103

Post by marginalia_nu »

fsckboy wrote: post #101
marginalia_nu wrote: post #42

Earlier quoted context omitted.

> 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 p…

> Yeah, this is a very astute observation. isn't it just repeating the definition/use of debt which is why "technical debt" was called that in the first place?

In many cases, points of view obvious to the point of childlike can be easily overlooked and very helpful.

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

#104

Post by muspimerol »

sobellian wrote: post #69
muspimerol wrote: post #56

Earlier quoted context omitted.

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.

Fair point, but I have seen a lot of shitty software developed with this mantra. Usually because the "iterate" part is forgotten in favor of the next "rapid" development. I agree that the quickest way to learn whether your solution is valid is to ship & experiment. But once you know the solution (which is sometimes not even that complicated) then you should really take the time to produce a solid piece of software before moving on.

But I agree, my original comment is probably a little too critical. There are valid times to rapidly iterate and ship. When it turns into the _only_ way you ship software, I think it becomes a problem.

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

#105

Post by orwin »

bschmidt1 wrote: post #77
cjfd wrote: post #59

Earlier quoted context omitted.

It is you who starts to talk about 'art' en 'poetry' but these words do not come from what you are reacting to. One thing you seem to assume is that the 'crappy code' works and therefore the concerns about its crappiness must be about irrelevant things like 'art' or 'poetry'. However, the working of what I would consider crappy code is generally highly tenuous. There has not been found a bug, YET...., but one differe…

> must be about irrelevant things like 'art' or 'poetry' If by "bad code" you mean something related to syntax, convention, or code that "might have bugs" (wtf), there is still a case it's actually "good code" if it's more readable, was a quicker solution that yields higher profits, is a less error prone approach to the larger management of the codebase albeit less performant etc. > one difference between crappy code…

Poor architecture/design make code unmaintanable, or at least very expensive to maintain.

I would rather have my junior spend 3 more days to understand the FSM we use to handle our front before changing anything than him adding 2 random useState an a random useEffect because it just works.

How you handle your data is also very telling of the code quality. I'm not against the "write shit fast, fix later", it is in fact how i do my stuff, but once i have a functioning prototype and basic mocks, i then spend a long time in my models.xxx file because modeling data is like 30% of the job.

I have an example of bad data modelling: your object (that is a data representation) have fields that in certain case will be empty and you know it. Some people will ignore them. In 90% of the cases, this is a mistake that will lead to mistake down the lane. If you can use discriminated unions and don't because "it's faster" (it takes literally 2 minutes to do), you are probably writing bad code. It's not about idiomatic or not following conventions (those help) or not typing your data, it's about bad modeling choices.

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

#106

Post by Degorath »

renlo wrote: post #10

Agree that the repository/service pattern is a good way to adhere to separation of concerns and make refactoring and readability easier. That said, I really disagree with any precommit checks. Committing code should be thought of as just saving the code, checks should be run before merging code not saving code. It'd be like Clippy preventing you from saving a Word document because you have a spelling error. It's a fr…

While I like abstracting storage into a repository class of sorts, this crap of "userService" needs to die already. I've seen too many bad codebases that stick everything user related into that one service that ends up having 8+ completely noncohesive functions.

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

#107

Post by freefaler »

f819934580bd48f wrote: post #58
freefaler wrote: post #32

Earlier quoted context omitted.

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 da…

> potential data loss should be written more carefully. Doesn't this apply to any code that touches data intended to eventually be persisted? If so, IMO this applies to a huge portion of all software, I would guess more than half, because writes tend to be much more complex than reads IME.

Data loss usually occurs when you "migrate", "backup/restore", "upgrade" data. A stupid internal tool can wreak havoc because it's something non-customer facing with less stringent testing.

The bugs on CRUD operations are usually ironed out early and can be limited to a small subset of data being lost. However a mingled migration script from one table to another is a really dangerous stuff but frequently it's treated as "internal tool".

Floating point calculation and storage is also tricky and should be written/tested with greater care.

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

#108

Post by Degorath »

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…

Refactor first and overarchitecting up front are completely different things, though.

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

#109

Post by bschmidt1 »

orwin wrote: post #105
bschmidt1 wrote: post #77

Earlier quoted context omitted.

> must be about irrelevant things like 'art' or 'poetry' If by "bad code" you mean something related to syntax, convention, or code that "might have bugs" (wtf), there is still a case it's actually "good code" if it's more readable, was a quicker solution that yields higher profits, is a less error prone approach to the larger management of the codebase albeit less performant etc. > one difference between crappy code…

Poor architecture/design make code unmaintanable, or at least very expensive to maintain. I would rather have my junior spend 3 more days to understand the FSM we use to handle our front before changing anything than him adding 2 random useState an a random useEffect because it just works. How you handle your data is also very telling of the code quality. I'm not against the "write shit fast, fix later", it is in fac…

> I would rather have my junior spend 3 more days to understand the FSM we use to handle our front before changing anything than him adding 2 random useState an a random useEffect because it just works.

React hooks obsoleted most use of state management tools years ago (there is even a native useReducer now so you don't have to install Redux just for that), especially if they're using SSR (Next.js) where state management has been moved to the server. There are still some cases for installing a global state management library in the FE, but usually useState / useEffect and custom hooks is enough for most React projects.

The problem is you came up with a heuristic in your mind that "global state management is pro, useState is amateur" but that isn't true.

Lets use a real example: If I worked on your team and pushed a component that captured email/pass with useState, you would tell me to move the username and password to a global state management library? Why? Dogma? It would be the wrong call.

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

#110

Post by cholantesh »

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…

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

Tried to hammer this into an intermediate level colleague recently while pairing and they just wouldn't accept it; eventually I said, ok let's do it, and as expected it ended up just creating a couple more days of toil for us. Hoping this turned out to be a learning experience for them.

Post reply on HN