3 ms·

I think developers sometimes get too obsessed with code quality thinking that smarter code makes them a better developer. In fact I’ve seen developers fall into

by hnlmorg 4mo ago

I think developers sometimes get too obsessed with code quality thinking that smarter code makes them a better developer. In fact I’ve seen developers fall into the trap of mistaking their code as the product and thus spend so much time beautifying it that that fail to ever release anything. Then you have the other end of the spectrum where people are too focused on hacking stuff together that the end result is unmaintainable. The reality is there needs to be a bit of both to be a good developer. For example, if you’re building a proof of concept (POC), then it’s more important to prove the idea than it is to define the architecture. And the reason for that is because you don’t always understand how the final product (whether it’s commercial software or a FOSS library) is best architected until you’ve gone through a few drafts of the idea. So spaghetti code isn’t necessarily a bad thing. But then when you know your idea works and you need to flesh it out into something more durable, you start to refactor the spaghetti into something more maintainable. Fabrice mainly releases POCs while Carmack mainly releases finished products. So it’s unsurprising you’ll see a difference in the style of architecting in their code. I used to be someone who focused on beautiful code for my POCs too. And used to fail to release any personal projects. Then one day I learned to embrace the chaos of POCs and realised that you can getting something built and tarting it up afterwards was better than failing to build anything at all.

21asdffdsa12 4mo ago
But the code quality is speed. And reach. You can not advance, unless you can read the code, you can understand the model, you can not scale beyond a certain point. The beauty of the architecture is the ability to build a spaceship compared to a train of kerosene tankers. Physically similar, but in capability radical different. I find this very scary. Somebody unable to perceive capabilities and tech-debt. If you can not perceive that- you should not be let near executive decisions or code-base evaluation. This is literally the difference between rocket-science and exploding failed projects. Everyone can pile up explosives, not everyone can go to space today. Its a great interview topic to filter this kind of candidate out of companies.
- MomsAVoxell 4mo ago
  “You can read the code” .. is very, very important in the context of milliseconds, hours, days, weeks, months and years. And decades. Today, you might say that John/Fabrice’ code is readable/unreadable, but will that also be true in 5 years time, in a different cultural/technological era? Obviously yes in the case of these individuals - because the ecosystem their products have created is self-sustaining at a mass (consumer/social) level. I’ve built software which has shipped and effected the lives of millions, too. Many of us have. But I have not built a massive ecosystem by working on the right software which was adopted by millions of developers who read my code, was inspired by it, and used it for something in their own products - thus creating sub-ecosystems upon sub-ecosystems, a big sprawling tree of economy which spreads out into the mass of humanity who use technology. In this story we have two cases of individuals who have accomplished an extraordinary reach of software, in their own uniquely flavored ways - and this demonstrates that there are no absolute requirements to strip personality from the code - as long as its damn good code in the first place. >filter candidates out of companies It’s a great way to decide not to work at a company which managers do not understand the importance of architecture at various scales, milliseconds, seconds, hours, days, weeks ..
- hnlmorg 4mo ago
  > But the code quality is speed No it’s not. Code quality is just code quality. It's a subjective measure. eg how do you define one thing is of greater "quality" than another? Is it CPU ops? Memory footprint? Code readability? And how do you measure readability? By who? What I find readable someone else might not, and visa versa. If you’re making choices to improve development throughput then that’s fine. But so often I see developers architecting code for what they mistakenly think will improve their throughput but ultimately they spend longer on writing those abstractions than any time they have saved when using them. XKCD parodies this problem with their pass the salt sketch: https://xkcd.com/974/ https://xkcd.com/974/ Sometimes this comes down to developer vanity, sometimes it comes down to poor alignment of goals and/or communication between the product teams and development teams. And sometimes it’s just because solving problems is fun so naturally we’ll look for problems to solve. But whatever the reasons, I’ve personally seen this happen (as well as being a victim of it myself) enough times to know it is an underestimated problem. > I find this very scary. Somebody unable to perceive capabilities and tech-debt. If you can not perceive that- you should not be let near executive decisions or code-base evaluation. This is a rather insulting assumption. I've been a tech lead for around 2 decades now and have worked on plenty of brownfield projects in that time. I know what tech debt looks like. The problem with "tech debt" is it can mean anything from "this is ugly code that takes 5 minutes longer to read but it works well" to "this in a insecure/unstable pile of horse manure and customers will start to notice". The latter is where time should be spent. The former is a vanity project that doesn't bring the business any value. That's not to say that developers shouldn't ever spend time on the former examples of tech debt, just that it's of a lower priority than getting the project working.
nixon_why69 4mo ago
It's the opposite, better-factored code makes me, a mediocre developer, capable of making progress instead of hitting a complexity wall. It's separate from striving for "beautiful" code, beauty within well-factored boundaries yields dimishing returns compared to just having the boundaries.
- hnlmorg 4mo ago
  You’re ostensibly arguing the same thing I am though. Focusing on building the thing rather than designing the code to look pretty.
  - nixon_why69 4mo ago
    I haven't read the codebases in question but people were talking about spaghetti code, which would not be well-factored and would impede someone less talented from comprehending it or being able to change it effectively. I guess I'm saying there are code quality concerns which do affect velocity/maintainability and then there are superficial and stylistic issues. The former aren't just about some kind of beauty standard, they're part of executing.
    - hnlmorg 4mo ago
      The comments about Ballard's code is very subjective. But if we take their comments at face value: > which would not be well-factored and would impede someone less talented from comprehending it or being able to change it effectively. Except the community did comprehend it and changed it effectively. Ballard hasn't maintained ffmpeg nor qemu for 20+ years. > I guess I'm saying there are code quality concerns which do affect velocity/maintainability and then there are superficial and stylistic issues. The former aren't just about some kind of beauty standard, they're part of executing. Which is why I'm saying we're basically arguing the same things. For a POC you get more velocity when focusing on proving that idea. I'm not saying zero effort should be spent on architecting the code. Just that you don't always know how best to organize it until you've had several revisions so developers shouldn't get too caught up trying to intellectualize the best internal layout. That can grow once the problem is better understood. And I made this point because I felt the comparisons of one engineers POC to another engineers commercial release was unfair. They're completely different ends of the factory.
psychoslave 4mo ago
> I think developers sometimes get too obsessed with code quality thinking that smarter code makes them a better developer. Not much about "smartness", but code can by far outlast many "product" sold on top of it, so it can make sense to polish them more than the ready to throw gift paper. People will certainly buy nice gift paper wrapping cheap crap music toy of the day. But they will also value differently access to a beautiful handcrafted musical instrument. On the other hands, people who don’t even play any music won’t be able to assess any musical appliance.
TremendousJudge 4mo ago
>For example, if you’re building a proof of concept (POC), then it’s more important to prove the idea than it is to define the architecture. I have tried to do this for POCs (just hacking everything together), and I always get stuck very quickly. Then until I figure out some sort of architecture for what I'm supposed to be doing I can't proceed. It's like, once I have the first step (of several) of the a POC working, I literally cannot think of how to implement the second one until the first one is somewhat well organized
bitwize 4mo ago
If your code is a low-stakes one-and-done and it works in the end, messy code is forgivable. Undertale looks like Yandere Simulator inside; nobody cares. But if your code is something that needs to be maintained over time and/or has constraints in terms of security, availability, etc., like virtually all code is, then yes: clearer, better factored, more readable code is a big part of the product because it's a massive favor both to yourself and your successors when changes have to be made and results in quicker changes, lowered costs for changes, and higher quality on metrics like security. Even if I'm writing a game—I'm auDHD, so if the initial code is garbage (and I've written a lot of garbage code) I'd be loath to touch it later. Better factored code is easier for me to revisit and improve upon with time. So I make it a point to continuously improve how I structure code from the jump to stave off it turning into an unpleasant quagmire later. This is especially important when you consider that oftentimes in business, the first draft that could possibly work goes right into production. Rewrite? What do you mean, rewrite? Fabrice is still fucking brill though. He'll slap something together that's a holy shit idea as easily as I take a dump.

by hnlmorg 4mo ago

21asdffdsa12 4mo ago

But the code quality is speed. And reach. You can not advance, unless you can read the code, you can understand the model, you can not scale beyond a certain point. The beauty of the architecture is the ability to build a spaceship compared to a train of kerosene tankers. Physically similar, but in capability radical different. I find this very scary. Somebody unable to perceive capabilities and tech-debt. If you can not perceive that- you should not be let near executive decisions or code-base evaluation. This is literally the difference between rocket-science and exploding failed projects. Everyone can pile up explosives, not everyone can go to space today. Its a great interview topic to filter this kind of candidate out of companies.

MomsAVoxell 4mo ago
“You can read the code” .. is very, very important in the context of milliseconds, hours, days, weeks, months and years. And decades. Today, you might say that John/Fabrice’ code is readable/unreadable, but will that also be true in 5 years time, in a different cultural/technological era? Obviously yes in the case of these individuals - because the ecosystem their products have created is self-sustaining at a mass (consumer/social) level. I’ve built software which has shipped and effected the lives of millions, too. Many of us have. But I have not built a massive ecosystem by working on the right software which was adopted by millions of developers who read my code, was inspired by it, and used it for something in their own products - thus creating sub-ecosystems upon sub-ecosystems, a big sprawling tree of economy which spreads out into the mass of humanity who use technology. In this story we have two cases of individuals who have accomplished an extraordinary reach of software, in their own uniquely flavored ways - and this demonstrates that there are no absolute requirements to strip personality from the code - as long as its damn good code in the first place. >filter candidates out of companies It’s a great way to decide not to work at a company which managers do not understand the importance of architecture at various scales, milliseconds, seconds, hours, days, weeks ..
hnlmorg 4mo ago
> But the code quality is speed No it’s not. Code quality is just code quality. It's a subjective measure. eg how do you define one thing is of greater "quality" than another? Is it CPU ops? Memory footprint? Code readability? And how do you measure readability? By who? What I find readable someone else might not, and visa versa. If you’re making choices to improve development throughput then that’s fine. But so often I see developers architecting code for what they mistakenly think will improve their throughput but ultimately they spend longer on writing those abstractions than any time they have saved when using them. XKCD parodies this problem with their pass the salt sketch: https://xkcd.com/974/ https://xkcd.com/974/ Sometimes this comes down to developer vanity, sometimes it comes down to poor alignment of goals and/or communication between the product teams and development teams. And sometimes it’s just because solving problems is fun so naturally we’ll look for problems to solve. But whatever the reasons, I’ve personally seen this happen (as well as being a victim of it myself) enough times to know it is an underestimated problem. > I find this very scary. Somebody unable to perceive capabilities and tech-debt. If you can not perceive that- you should not be let near executive decisions or code-base evaluation. This is a rather insulting assumption. I've been a tech lead for around 2 decades now and have worked on plenty of brownfield projects in that time. I know what tech debt looks like. The problem with "tech debt" is it can mean anything from "this is ugly code that takes 5 minutes longer to read but it works well" to "this in a insecure/unstable pile of horse manure and customers will start to notice". The latter is where time should be spent. The former is a vanity project that doesn't bring the business any value. That's not to say that developers shouldn't ever spend time on the former examples of tech debt, just that it's of a lower priority than getting the project working.

nixon_why69 4mo ago

It's the opposite, better-factored code makes me, a mediocre developer, capable of making progress instead of hitting a complexity wall. It's separate from striving for "beautiful" code, beauty within well-factored boundaries yields dimishing returns compared to just having the boundaries.

hnlmorg 4mo ago
You’re ostensibly arguing the same thing I am though. Focusing on building the thing rather than designing the code to look pretty.
- nixon_why69 4mo ago
  I haven't read the codebases in question but people were talking about spaghetti code, which would not be well-factored and would impede someone less talented from comprehending it or being able to change it effectively. I guess I'm saying there are code quality concerns which do affect velocity/maintainability and then there are superficial and stylistic issues. The former aren't just about some kind of beauty standard, they're part of executing.
  - hnlmorg 4mo ago
    The comments about Ballard's code is very subjective. But if we take their comments at face value: > which would not be well-factored and would impede someone less talented from comprehending it or being able to change it effectively. Except the community did comprehend it and changed it effectively. Ballard hasn't maintained ffmpeg nor qemu for 20+ years. > I guess I'm saying there are code quality concerns which do affect velocity/maintainability and then there are superficial and stylistic issues. The former aren't just about some kind of beauty standard, they're part of executing. Which is why I'm saying we're basically arguing the same things. For a POC you get more velocity when focusing on proving that idea. I'm not saying zero effort should be spent on architecting the code. Just that you don't always know how best to organize it until you've had several revisions so developers shouldn't get too caught up trying to intellectualize the best internal layout. That can grow once the problem is better understood. And I made this point because I felt the comparisons of one engineers POC to another engineers commercial release was unfair. They're completely different ends of the factory.

psychoslave 4mo ago

> I think developers sometimes get too obsessed with code quality thinking that smarter code makes them a better developer. Not much about "smartness", but code can by far outlast many "product" sold on top of it, so it can make sense to polish them more than the ready to throw gift paper. People will certainly buy nice gift paper wrapping cheap crap music toy of the day. But they will also value differently access to a beautiful handcrafted musical instrument. On the other hands, people who don’t even play any music won’t be able to assess any musical appliance.

TremendousJudge 4mo ago

>For example, if you’re building a proof of concept (POC), then it’s more important to prove the idea than it is to define the architecture. I have tried to do this for POCs (just hacking everything together), and I always get stuck very quickly. Then until I figure out some sort of architecture for what I'm supposed to be doing I can't proceed. It's like, once I have the first step (of several) of the a POC working, I literally cannot think of how to implement the second one until the first one is somewhat well organized

bitwize 4mo ago

If your code is a low-stakes one-and-done and it works in the end, messy code is forgivable. Undertale looks like Yandere Simulator inside; nobody cares. But if your code is something that needs to be maintained over time and/or has constraints in terms of security, availability, etc., like virtually all code is, then yes: clearer, better factored, more readable code is a big part of the product because it's a massive favor both to yourself and your successors when changes have to be made and results in quicker changes, lowered costs for changes, and higher quality on metrics like security. Even if I'm writing a game—I'm auDHD, so if the initial code is garbage (and I've written a lot of garbage code) I'd be loath to touch it later. Better factored code is easier for me to revisit and improve upon with time. So I make it a point to continuously improve how I structure code from the jump to stave off it turning into an unpleasant quagmire later. This is especially important when you consider that oftentimes in business, the first draft that could possibly work goes right into production. Rewrite? What do you mean, rewrite? Fabrice is still fucking brill though. He'll slap something together that's a holy shit idea as easily as I take a dump.