What 10k Hours of Coding Taught Me: Don't Ship Fast • Hacker News Board

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

#51

Post by mihaaly » Sat, Sep 21, 2024, 7:42 PM UTC

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…

Those shipping fast and lot write software not to use but to sell. Not for the user but for sales and marketing departments. And this is why software and programmers are not respected, rightfully so. Judged by their products. And software are crap (and then reasoned with vigour why crap is good by those having incentives in it). Much more time than not, the not is the exception nowadays.

Those having too little resources (money) for their monumental ambition also ship fast.

Also it is so f annoying. All those river of notifications about 'hey, brend new version, now!, stop everything and download right away or else!' is a great nuisance. Like if this was the center of the life of the user, to have the newest and prettiest and greatest new feature (or mostly fixup of f*ups) of the software used. Secret for developers: no one cares. They need a tool to do the thing, and that's it. Do it well, do it smooth, that's all that counts. Not the new versions. Please write it well in the first place instead of this endless tinkering and bugging the customer.

Sipping too fast is some sort of premature ejaculation of the programmers' mind.

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

#52

Post by henning » Sat, Sep 21, 2024, 7:44 PM UTC

> I’ve been an engineer for over 7 years now. I have worked on countless projects

If you've worked on countless projects in 7 years, that means no single project was that big or long.

> Refactoring a relatively big software, for example, with over 70,000 lines of code, can take 30-40 hours

I admire the author's ability to casually introduce completely arbitrary definitions of "relatively big" and that "refactoring" 70,000 SLOC only takes "30-40 hours" without giving any information about what the nature of the refactoring is.

> Now imagine if we didn’t implement a good architecture from the beginning

This post does nothing to define what "good architecture is" or prove that adding additional indirection helps anything. Code re-use is about more than just not putting query and service call logic in a controller method. The contrived examples about adding logging to a codebase that has no logging (why does the app have no logging? why does it need to be added now when it didn't before?) only makes sense if every part of the application conforms to the same interface you've introduced. Considering that a large application may have many different features and do lots of different tasks, this may not happen in which case you need one interface for each situation or create some stupid abstract thing that can handle everything.

The stupid pre-commit setup makes it impossible to share a branch you're working on if you can't figure out why a test won't pass and want to get help from someone on your team. Or you have a WIP codebase where tests are broken and want to pass it off or show it to someone else.

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

#53

Post by ChrisMarshallNY » Sat, Sep 21, 2024, 7:47 PM UTC

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…

I have found that "it depends" is an almost universal solvent for all technical quandaries.

I have found in my experience (and I have a lot of that), that the search for "One Solution To Rule Them All" is a snipe hunt. You can't get there from here.

It always (in my experience) comes down to context[s].

That "[s]" is important. There's the current context, and then, there is the future context.

You survived your baptism in fire to live to keep delivering software.

That's great. It's crap software that got you here.

Time to rewrite it, so we now have software with a future

Right?

OK?

That's what we'll do...right?

Oh, for Cthulhu's sake, what do you mean we need to keep building on our foundation of sand?

Congratulations. You now not only have technical debt; you have technical bankruptcy, coming down the road.

Better sell the company fast, before the bomb goes off...

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

#54

Post by dyauspitr » Sat, Sep 21, 2024, 7:51 PM UTC

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…

Well most places putting out code for the first time don’t have the luxury of spending the time to put out perfect code. The funding only lasts so long, you’re trying to outpace competitors, you end up getting continuous scope creep etc. Star Citizen is a great example of what happens when you want to get everything perfect before you release it, by the time you’re done someone else has eaten your lunch.

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

#55

Post by Spivak » Sat, Sep 21, 2024, 7:51 PM UTC

freefaler wrote: post #32

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

I've always called this "good problems to have." If you're at the point where your slapped together solution doesn't cut it anymore then it means you're successful enough to actually need better.

Don't use the solutions to hard problems when you don't have hard problems yet. Because they're making trade-offs to meet constraints that you're not under. Ranch dressing at the grocery store has to be shelf stable and they make a bunch of compromises to get it to that point. The ranch dressing you make it home can be better easily by just ignoring those constraints.

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

#56

Post by muspimerol » Sat, Sep 21, 2024, 7:53 PM UTC

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.

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

#57

Post by fabian2k » Sat, Sep 21, 2024, 7:54 PM UTC

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…

One big problem is that you often don't know yet what you actually need, you only find that out when your software is in front of real users. So the later versions might be substantially different than your MVP. Building a very robust first version might be entirely useless if you have to throw away most of it after discovering it doesn't actually solve the user's needs.

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

#58

Post by f819934580bd48f » Sat, Sep 21, 2024, 7:54 PM UTC

freefaler wrote: post #32

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

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

#59

Post by cjfd » Sat, Sep 21, 2024, 7:55 PM UTC

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…

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 difference between crappy code and good code is that in crappy code one is quite sure there are lurking many bugs that are just waiting for the right circumstances to occur in practice. Also when bad code is changed, this is a much riskier affair because it is difficult to be sure that no unwanted side-effects were introduced.

There is a hypothesis that the crappy code was faster to write. At some point, this becomes false because one also has to spend time fixing the bugs. I would wager that this duration is measured in weeks, rather than months. From which it follows that the picking crappy code for speed is actually foolish and lowers profits for all but the most simple projects.

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

#60

Post by diffxx » Sat, Sep 21, 2024, 7:56 PM UTC

I agree with the author that slow can be good and that taste and diligence can trump raw smarts.

I think what is often missed though is the opportunity cost of shipping bad products. Our industry lionizes fast delivery to juice short term earnings but this is very often at tremendous long term cost. When your revenue depends on shoddy products, you must devote an excess of resources to patching the holes that are slowly sinking your ship. The best people will tire of this and jump aboard the next vessel that offers better working conditions and/or higher compensation. But of course one never escapes the fundamental problems by job hopping.

To build something great, reliable and high value takes time. If it were easy, the market would be awash with cheap high quality products. It clearly isn't.

For things to improve, I believe that a small group of workers will likely need to join together and sacrifice short term earnings to build viable long term companies on a different set of ethics and values. I have personally made this sacrifice and am working on something I think is great and valuable that I could not possibly do within a typical company.

I have optimism that soon alternative approaches to building companies will emerge outside of the current VC funding model, which I believe has run its course. There are many, many software developers who are wealthy enough to sacrifice short term compensation to build more equitable companies with longer term vision and with a much higher ownership percentage that will pay off in the long run.