5 ms·

> 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 "qualit

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

brunooliv 4mo ago
Thanks for saying this! I completely agree with everything you said! There’s far, far too many people who confuse code quality for speed of development and start treating code quality as the product for customer base in the hundreds and active customers in the dozens and for most features to be basically unused. The reality is that tech debt as a concept these days is hardly real: to be in debt means previous decisions or a previous implementation makes current work extremely hard or impossible, but, the truth is that the human factors such as knowing what to build, team collaboration and even speaking to customers matter far more and can get you “in debt” so so much faster than code alone. At least in your typical SaaS company. If you ship code in a way that you let tech debt pile up to the point that customers notice it, you have an organisational problem, not code issues per se. The fact that a lot of people don’t get this is really baffling to me.
- nandomrumber 4mo ago
  [dead]
- 21asdffdsa12 4mo ago
  Im talking about the speed of mental model building, understanding concepts, relations and organizational concepts. Good codebases sort of read themselves. You can guess where things are, how they are sorted and how they work, by understanding and relying on the authors ideas.
  - hnlmorg 4mo ago
    “Good” code makes trade offs. While readability is an important constraint, it’s far from being the only constraint. And there are plenty of occasions where objectively better code is subjectively harder to read because other constraints trump human parserability, such as using CPU-friendly memory layouts, SIMD-instructions in tight mathematical loops, and so on and so forth. Not to mention that readability is entirely dependent on the readers familiarity with particular coding styles. Eg someone unfamiliar with SQL would find ORMs easier to read, whereas I find SQL easier than ORMs. Same is true for any other paradigm, eg for functional vs imperative. And this is why I hate when people generalise about human readability being the definition of “good code”. For one thing, there will never be a consensus on what is more readable. And external constraints might require subjectively less readable code.
ryandrake 4mo ago
This is one of the reasons I got away from writing commercial software and now only write code as a hobby. To me, the code itself is the product. I want the code to look like a beautiful painting—the fact that it does something is secondary. I’ll sit there for hours working on things like const correctness, and making sure each class has the bare minimum amount of state/instance variables, making sure function arguments are named and ordered consistently, even though it has no effect on user-visible bugs or runtime performance. I’m the kind of person that paints the back of the cabinet. Even though no user will see it, I will know it is there. Obviously this mentality is at odds with commercial software’s imperative to shit out barely working spaghetti code as fast and cheaply as possible, so I opted out.
- fdsfsdsd 4mo ago
  Although in this case it's more like using the paint in the tin to paint the tin itself. It's useless and completely missing the point of why the paint exists in the first place. You do you, I'm sorry if I come across rude and stupid, but I am both things. But "code is the product" is what IMO caused the downfall of this entire profession. No wonder everyone is trying to get rid of us. I wouldn't want a plumber that's obsessed with the tubes itself and not whether my house has working plumbing in a reasonable time frame and within budget.
  - qdotme 4mo ago
    I’ve been in this profession for two decades as well. As both things. My take on this is that we need both, because the market is cyclical. It’s just that it’s hard to perceive any of those cycles if you (a) live them (b) are not experienced enough to introspect. I absolutely would love an obsessed plumber (and got one!) when it comes to deciding that we’re going to do PTFE tubing in our new house. An obsessed electrician in charge to overinvest into our grid, rather than a 3-month timeframe executive. Otherwise our critical infrastructure gets myopically degraded. I also want the “working within timeframe” outcome. And we, as an industry, swing wildly in both direction. The Cambrian explosion of shareware was the the former. We course-corrected into cathedrals of good software (I still love Windows 2000’s stability, the pinnacle of NT line), followed by the “reasonable timeframe” 4GB Electron apps, etc. It will swing. Every complex system from logistic equation upwards will oscillate .
dkarl 4mo ago
> 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. You may have worked with people whose meaning of "code quality" encompassed things that you found inconsequential and a waste of effort. They may have even told you that if you didn't care about those things, then you didn't care about code quality. But that's not true. It only meant you disagreed with them about what code quality is and how to recognize it. You draw a distinction between aspects of code that tend to lead to better outcomes and aspects of code that don't matter. You say you know what tech debt looks like. When you look at a codebase, you have opinions on where time should be spent to improve it. "Code quality" is shorthand for the heuristics underlying those opinions. Instead of accepting that other, possibly dumber people get to define what code quality is, own your own definition of it and use it when you communicate with other people.
- hnlmorg 4mo ago
  I don't think you're being very charitable in your reading of my comments. For example: > You may have worked with people whose meaning of "code quality" encompassed things that you found inconsequential and a waste of effort. They may have even told you that if you didn't care about those things, then you didn't care about code quality. But that's not true. It only meant you disagreed with them about what code quality is and how to recognize it. Who's these "people" you're referring to? This is an imaginary conversation you've added. What I actually said was that there's a balance between design and output. I did generalize that often product people will push too far towards output and often developers will push too far between design, but like all generalizations, I know there are exceptions (eg me). But the crux of my point is that there are tradeoffs between the two, and thus times when it makes more sense to lean towards output and times when it makes more sense to focus on design. What you've replied with isn't even remotely the same sentiment as the comment I made. > You draw a distinction between aspects of code that tend to lead to better outcomes and aspects of code that don't matter. You say you know what tech debt looks like. When you look at a codebase, you have opinions on where time should be spent to improve it. "Code quality" is shorthand for the heuristics underlying those opinions. No. Code quality is just a subjective term that means nothing in reality because everyone will have different goals in mind when they think about the purpose of the code. So the underlying heuristics require far insight into project goals, deadlines, and resources than just "code quality". > Instead of accepting that other, possibly dumber people get to define what code quality is, The original reason I replied (albeit I did digress quite a bit) was to demonstrate that you cannot extrapolate how smart or dumb an engineer is from their "code quality" alone. So please refrain from calling people dumb in your rebuttals. > own your own definition of it and use it when you communicate with other people. That's literally what I've done. --- This comment better summarizes my point: https://news.ycombinator.com/item?id=48555191 https://news.ycombinator.com/item?id=48555191

by hnlmorg 4mo ago

brunooliv 4mo ago

Thanks for saying this! I completely agree with everything you said! There’s far, far too many people who confuse code quality for speed of development and start treating code quality as the product for customer base in the hundreds and active customers in the dozens and for most features to be basically unused. The reality is that tech debt as a concept these days is hardly real: to be in debt means previous decisions or a previous implementation makes current work extremely hard or impossible, but, the truth is that the human factors such as knowing what to build, team collaboration and even speaking to customers matter far more and can get you “in debt” so so much faster than code alone. At least in your typical SaaS company. If you ship code in a way that you let tech debt pile up to the point that customers notice it, you have an organisational problem, not code issues per se. The fact that a lot of people don’t get this is really baffling to me.

nandomrumber 4mo ago
[dead]
21asdffdsa12 4mo ago
Im talking about the speed of mental model building, understanding concepts, relations and organizational concepts. Good codebases sort of read themselves. You can guess where things are, how they are sorted and how they work, by understanding and relying on the authors ideas.
- hnlmorg 4mo ago
  “Good” code makes trade offs. While readability is an important constraint, it’s far from being the only constraint. And there are plenty of occasions where objectively better code is subjectively harder to read because other constraints trump human parserability, such as using CPU-friendly memory layouts, SIMD-instructions in tight mathematical loops, and so on and so forth. Not to mention that readability is entirely dependent on the readers familiarity with particular coding styles. Eg someone unfamiliar with SQL would find ORMs easier to read, whereas I find SQL easier than ORMs. Same is true for any other paradigm, eg for functional vs imperative. And this is why I hate when people generalise about human readability being the definition of “good code”. For one thing, there will never be a consensus on what is more readable. And external constraints might require subjectively less readable code.

ryandrake 4mo ago

This is one of the reasons I got away from writing commercial software and now only write code as a hobby. To me, the code itself is the product. I want the code to look like a beautiful painting—the fact that it does something is secondary. I’ll sit there for hours working on things like const correctness, and making sure each class has the bare minimum amount of state/instance variables, making sure function arguments are named and ordered consistently, even though it has no effect on user-visible bugs or runtime performance. I’m the kind of person that paints the back of the cabinet. Even though no user will see it, I will know it is there. Obviously this mentality is at odds with commercial software’s imperative to shit out barely working spaghetti code as fast and cheaply as possible, so I opted out.

fdsfsdsd 4mo ago
Although in this case it's more like using the paint in the tin to paint the tin itself. It's useless and completely missing the point of why the paint exists in the first place. You do you, I'm sorry if I come across rude and stupid, but I am both things. But "code is the product" is what IMO caused the downfall of this entire profession. No wonder everyone is trying to get rid of us. I wouldn't want a plumber that's obsessed with the tubes itself and not whether my house has working plumbing in a reasonable time frame and within budget.
- qdotme 4mo ago
  I’ve been in this profession for two decades as well. As both things. My take on this is that we need both, because the market is cyclical. It’s just that it’s hard to perceive any of those cycles if you (a) live them (b) are not experienced enough to introspect. I absolutely would love an obsessed plumber (and got one!) when it comes to deciding that we’re going to do PTFE tubing in our new house. An obsessed electrician in charge to overinvest into our grid, rather than a 3-month timeframe executive. Otherwise our critical infrastructure gets myopically degraded. I also want the “working within timeframe” outcome. And we, as an industry, swing wildly in both direction. The Cambrian explosion of shareware was the the former. We course-corrected into cathedrals of good software (I still love Windows 2000’s stability, the pinnacle of NT line), followed by the “reasonable timeframe” 4GB Electron apps, etc. It will swing. Every complex system from logistic equation upwards will oscillate .

dkarl 4mo ago

> 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. You may have worked with people whose meaning of "code quality" encompassed things that you found inconsequential and a waste of effort. They may have even told you that if you didn't care about those things, then you didn't care about code quality. But that's not true. It only meant you disagreed with them about what code quality is and how to recognize it. You draw a distinction between aspects of code that tend to lead to better outcomes and aspects of code that don't matter. You say you know what tech debt looks like. When you look at a codebase, you have opinions on where time should be spent to improve it. "Code quality" is shorthand for the heuristics underlying those opinions. Instead of accepting that other, possibly dumber people get to define what code quality is, own your own definition of it and use it when you communicate with other people.

hnlmorg 4mo ago
I don't think you're being very charitable in your reading of my comments. For example: > You may have worked with people whose meaning of "code quality" encompassed things that you found inconsequential and a waste of effort. They may have even told you that if you didn't care about those things, then you didn't care about code quality. But that's not true. It only meant you disagreed with them about what code quality is and how to recognize it. Who's these "people" you're referring to? This is an imaginary conversation you've added. What I actually said was that there's a balance between design and output. I did generalize that often product people will push too far towards output and often developers will push too far between design, but like all generalizations, I know there are exceptions (eg me). But the crux of my point is that there are tradeoffs between the two, and thus times when it makes more sense to lean towards output and times when it makes more sense to focus on design. What you've replied with isn't even remotely the same sentiment as the comment I made. > You draw a distinction between aspects of code that tend to lead to better outcomes and aspects of code that don't matter. You say you know what tech debt looks like. When you look at a codebase, you have opinions on where time should be spent to improve it. "Code quality" is shorthand for the heuristics underlying those opinions. No. Code quality is just a subjective term that means nothing in reality because everyone will have different goals in mind when they think about the purpose of the code. So the underlying heuristics require far insight into project goals, deadlines, and resources than just "code quality". > Instead of accepting that other, possibly dumber people get to define what code quality is, The original reason I replied (albeit I did digress quite a bit) was to demonstrate that you cannot extrapolate how smart or dumb an engineer is from their "code quality" alone. So please refrain from calling people dumb in your rebuttals. > own your own definition of it and use it when you communicate with other people. That's literally what I've done. --- This comment better summarizes my point: https://news.ycombinator.com/item?id=48555191 https://news.ycombinator.com/item?id=48555191