10 ms·

The more code I've written, the less I care about code quality. I think the things I could point to in my coding practice which would make the code I write now

by skohan 5y ago

The more code I've written, the less I care about code quality. I think the things I could point to in my coding practice which would make the code I write now better than the code I wrote 10 years ago would be: - I minimize interdependencies (changing a line of code should not affect something un-related) - I go for abstractions later, only when I need them, rather than trying to think of the perfect abstraction/design pattern which will solve the problem in the most elegant or clever way Besides that, I'm a huge fan of disposable code. In my experience 99% of the time, the best approach is to just dive into the problem and try to solve the problem in the most pragmatic way. Maybe that's hard-coding a lot of things. Maybe that's having a small amount of repetition here and there. Maybe it's writing one long function with 1000 lines. After that it's all about continuous improvement. You spend your time solving the problem, and when your code becomes hard to work on, you spend time improving your code to make it easier to work on by cleaning things up, and adding sensible abstractions which solve the problems you actually have. In my experience, over time this approach leaves you with a very ergonomic and easy to understand codebase.

bncy 5y ago
I always felt bad for doing things "the pragmatic way", but your comment made me realize that maybe I'm just not experienced enough to embrace the fact that no code is pretty from the start. Thanks!
- skohan 5y ago
  Yeah sure! One realization which helped me with this: how many people will be affected by how your code is written, vs what your code does? Given that, where should you put most of your effort?
jcbrand 5y ago
Back in university I had an experience that was really instructive. For a project we had to write a program that differentiates mathematical equations. I dove in and just started writing code. Eventually, I realized that I had made a design error and that my code was much more complicated and cumbersome than it needed to be and I was getting stuck due to the complexity of the monstrosity I created. Unfortunately I figured this fundamental design flaw the night before we had to hand the assignment in and there was no way I could rewrite everything from scratch. I had to push through and put lipstick on this pig as best I could. In the end, I had spent way more time working on this project than my friends who had spent time upfront designing their programs instead of just jumping in. This has taught me the lesson to always first try and think things through and come up with some kind of initial design, instead of just jumping in and writing code blindly. Yes you can always refactor, but some early design mistakes can cost you a lot of time, and perhaps make refactoring unfeasible compared to a complete rewrite. As they say "measure twice, cut once".
- skohan 5y ago
  Yeah this just hasn't been my experience. If you're working on a house you measure twice and cut once because the cost of reworking physical materials is a lot more expensive than the cost of doing a second measurement. If you could delete half your house and re-build it at zero cost, it might be more valuable to just go for the first attempt and learn from it rather than trying to do everything in theory up front. If you find yourself working on a "monstrosity" maybe you haven't seen the signs soon enough that you need to take a step back and refactor. But in my experience, at least starting on the problem with a POC gives you so much more high quality information that even if you have to scrap and re-write part way in, you're going to reach such a better result than if you try to map the whole thing out first without actually having tried to solve the problem.
  - gefhfffh 5y ago
    When can you rebuild at zero cost? I have made similar avoidable mistakes of not thinking it through enough, could have saved me a lot of rewriting, which was pretty expensive
    - runald 5y ago
      Probably not literally without cost, but if the code was written with disposability in mind combined with just a little bit of pre-planning, then rewriting or refactoring should be indeed trivial.
      - gefhfffh 5y ago
        When start off with "wrong" higher level design concepts, neither of those is trivial. If you're writing a function implementation without thinking about design, well you might be right.
        sseagull 5y ago
        I sometimes wonder if there is a miscommunication. I’m scratching my head sometimes like “how can rewriting/refactoring an entire 10-20k project take negligible time?” Maybe some people have very small projects compared to what I work on? Or maybe they are talking about the design of a single small component? I inherited a codebase that needed some refactoring because it was written “to just get it shipped”. If completely fell apart with more users and has taken me a year to get it where it needs to be.
rawoke083600 5y ago
>The more code I've written, the less I care about code quality. Yea I understand 100% where you coming from ! I also these days try to focus more on "just getting it done/shipped". Lol I even went so far as to have my own little PHP-MicroFramework called "JGID" which means "Just-Get-It-Done" to remind me at EVERY LEVEL even code that is PERFECT but not shipped is not as good as medicore-core that is shipped ! YMMV >I think the things I could point to in my coding practice which would make the code I write now better than the code I wrote 10 years ago would be: I like this approach - instead of asking what is "Good Code" You asking, "How has my code improve in 10 years" a subtle change but I there is a lot of value in there. This type of introspection-question reminds me of the very very common life-purpose question: a) What will you do if you have a million dollars ? Sure good question... But I always found the better version of this is: b)What will you do if you KNOW you won't fail ? To be honest I think it might have originated from Tim Ferris. You like or dislike him, but what I love about him is his great ability to ask interesting questions. >- I go for abstractions later, only when I need them, rather than trying to think of the perfect abstraction/design pattern which will solve the problem in the most elegant or clever way Yup I've noticed this as well. I remember my very first paid coding job. Writing a roulette-wheel-number-reader. And I was so proud to have like a OOP-Hierachy of 3 levels and implementing AbstractFactories for multiple reader-types etc :D Only the "other cases/readers" never happen :) >..After that it's all about continuous improvement.. Yes - I think I've also seen a similar effect, which is "better code" is a function of repeated-iteration of some process. It's like how woman like men that have a plan. Doesn't even have to be a good plan, just have a damn plan :D
marginalia_nu 5y ago
> The more code I've written, the less I care about code quality. I sort of agree with this, but not quite. I care about code quality, but not code aesthetics. Aesthetics was really important to me when I was younger and more inexperienced. I wanted my code to be pretty, and wouldn't be happy until I found an algorithm or abstraction that met my definitions of pretty code. I would polish it until it was shiny. I would even align my variable names to be pleasing to the eye. 20 years later, I know there are things that will just never quite look neat. FizzBuzz is a pretty accessible example of this phenomenon, but most non-trivial algorithms have that to some extent. > Besides that, I'm a huge fan of disposable code. In my experience 99% of the time, the best approach is to just dive into the problem and try to solve the problem in the most pragmatic way. Maybe that's hard-coding a lot of things. Maybe that's having a small amount of repetition here and there. Maybe it's writing one long function with 1000 lines. > After that it's all about continuous improvement. You spend your time solving the problem, and when your code becomes hard to work on, you spend time improving your code to make it easier to work on by cleaning things up, and adding sensible abstractions which solve the problems you actually have. I too am firmly in the camp of write code first, refactor into a maintainable solution when it works. Maybe it's tacit experience refactoring messy code, sort of knowing in the back of your head how it will shape up when refactored.
sseagull 5y ago
People who have been coding for a while learn not to repeat their mistakes. Their code contains good-ish abstractions and other “clean code” features because they intuitively know what they are doing. The code they just wrote to get something done & shipped is probably somewhat “clean” by most standards. But communicating those ideas to less experienced developers is where the problem comes in and all the prescriptive dogma arises. But this happens in all fields. How many times do experts give some advice they don’t always follow themselves? Experts understand when and how to break the rules, and that comes with experience.
- skohan 5y ago
  > communicating those ideas to less experienced developers is where the problem comes in and all the prescriptive dogma arises. I think a lot of it is just lack of context. A lot of "best practice" advice is valuable in certain cases but it gets over-applied, and people end up wasting a lot of time on things which don't matter.
- Mawr 5y ago
  Almost right ;) Novices need simple rules to follow. The world of a novice is filled with uncertainty, they have nearly zero intuition as to what's good or bad, so simple rules that get them 80% there are essential. Otherwise they'd get lost in the complexity. However, with time, as they gather experience, learn, and mature, they should be able to figure out the reasoning behind the rules they were once given. That then will allow them to make decisions on whether the rule is appropriate for the given context or not. Of course, getting to that point requires continuous improvement, which is why many, if not most, programmers don't get there. Example: "Never use `goto` in C." - great advice for a beginner, they'd just make their code into spaghetti. However, a seasoned coder knows that `goto` is only a problem when used to jump to arbitrary points in the code, so using it to reduce duplicated error handling is perfectly fine.
  - hinkley 5y ago
    Same with “premature optimization”. Many things can be fixed later. Some can’t or won’t, and those typically get ignored or relabeled as “good design” when it is still ultimately minmaxing cpu time versus developer brain cells.
misja111 5y ago
> The more code I've written, the less I care about code quality. .. - I minimize interdependencies (changing a line of code should not affect something un-related) - I go for abstractions later, only when I need them, rather than trying to think of the perfect abstraction/design pattern which will solve the problem in the most elegant or clever way It's funny, but those points you are describing are measures of code quality to me. The less interdependencies the higher I value the code, same for abstractions, most of the time it is the simpler the better. Except in those cases where they are explicitly required.
agumonkey 5y ago
very important lesson, more than that actually there's a lot of artistry, poetry, idealism in programming, but as a daily money making activity it just doesn't cut it. You have to reach goals as easily as possible (dry,yagni) fast without painting yourself in corners as much as you can (low coupling, min interdependencies). Finding the right variability points. it's something school don't do well (saying this humbly) yet crucial ps: I disagree with the article title. k&r, mccarthy's lisp, prolog, and many other have very clean general and beautiful code.
- skohan 5y ago
  Yeah I think that there's a bias for programmers to think about artistry, poetry, and idealism in the form of code since that's what we're dealing with all day. But in reality it matters a lot less than we would like to think.
  - agumonkey 5y ago
    IMO whenever survival (and money, contractual relationships) occur, we will or must go to a different kind of idealism which maximizing the value/effort ratio. I only "lead" one project (a minuscule thing by all means) and it was the first time I was responsible, and instead of burning out in rabbitholes, I discovered the bliss of being sharp cause I had near no time to allocate to anything. Suddenly only the minimum amount of change was important and you stop caring for so many parameters. It leads to a saner sense of skills and progress. You also start to understand systemic ideas better, every patch or change will have your brain think "is this gonna rot fast ? or will it be nicely decoupled from the rest and more pros than cons in the future?". No effort is wasted, every step improves the system. It feels very good, and makes you want to do more of that. Unlike 99% of side projects where you spend days on DESIGN.md or TODO or watching conferences about <trick>
ozim 5y ago
I love "ergonomic code" expression and after years of coding I see it as much better term to strive for than "clean code".
hinkley 5y ago
I still care, but the things I fret about have shifted substantially. There are many categories of code problem that you don’t have to get right the first time. Some things can grow organically. But there are combinations that can be extremely resistant to change. In particular, shared state is both state and coupling. Global shared state is a fucking nightmare, and almost made me quit my current job a couple months in. I thought I could fix it, but I underestimated the number of hands in the code, and the longevity of the alliances I could make to get it done. The thing with a hideous mess is that the people who don’t mind it stick around, and they probably made it in the first place. Mostly what’s kept me here is the pandemic, and he fact that a lot of my energy is now in a hobby, not invested in my job. The tiebreaker was that some self-aware wolves have found slightly better code patterns and I have been exploiting that all I can. Write more like that, delete code like this ASAP. We have spent much of the last 18 months working on things I identified in my first six weeks. Not always in the most healthy way, but at least some people are looking at it.
62951413 5y ago
I hope in real life you have enough discipline to practice things which people like me would call "code quality". Because taken literally it would lead to all those code bases I have had to maintain - barely a useful test in sight, an empty README.md, no javadocs, classes mixing multiple responsibilities, hundreds of LoCs in one class. Somehow all those things correlate and people who show a modicum of care in one area have others in a reasonable shape too. It worries me that with the leetcode fad in vogue people will pay even less attention to the things which actually matter in real software development.
- skohan 5y ago
  I think you might have missed the part of my post about eventually arriving at a well factored codebase
stjohnswarts 5y ago
This is why I'm like "it works, and has worked for months(years) leave it alone and do better next time" to all the young engineers who like to sling around terms like bit rot (bits do not rot) and "technical debt". Technical debt is when the code becomes hard to comprehend or update, not just because of age or you know a new fancy dancy language or DSL of their own design we should be using. Also get off my lawn lol
anamax 5y ago
> Besides that, I'm a huge fan of disposable code. In my experience 99% of the time, the best approach is to just dive into the problem and try to solve the problem My approach is slightly different. I think for a while and then start on the path that gets me to what I think is a common case. If the whole seems more complicated than reasonable, I back out the part that seems to be troublesome. Eventually, I get one case "working". That case might not be complete, but it does something. I then work on an adjacent case, using the same "back out the troublesome" process, going into a bit more detail (or perhaps deciding that some detail on the first case was wrong). I repeat "work on adjacent cases" until most/all cases are handled. As I do more cases, I use opportunities to reduce the cognitive footprint.

by skohan 5y ago

bncy 5y ago

I always felt bad for doing things "the pragmatic way", but your comment made me realize that maybe I'm just not experienced enough to embrace the fact that no code is pretty from the start. Thanks!

skohan 5y ago
Yeah sure! One realization which helped me with this: how many people will be affected by how your code is written, vs what your code does? Given that, where should you put most of your effort?

jcbrand 5y ago

Back in university I had an experience that was really instructive. For a project we had to write a program that differentiates mathematical equations. I dove in and just started writing code. Eventually, I realized that I had made a design error and that my code was much more complicated and cumbersome than it needed to be and I was getting stuck due to the complexity of the monstrosity I created. Unfortunately I figured this fundamental design flaw the night before we had to hand the assignment in and there was no way I could rewrite everything from scratch. I had to push through and put lipstick on this pig as best I could. In the end, I had spent way more time working on this project than my friends who had spent time upfront designing their programs instead of just jumping in. This has taught me the lesson to always first try and think things through and come up with some kind of initial design, instead of just jumping in and writing code blindly. Yes you can always refactor, but some early design mistakes can cost you a lot of time, and perhaps make refactoring unfeasible compared to a complete rewrite. As they say "measure twice, cut once".

skohan 5y ago
Yeah this just hasn't been my experience. If you're working on a house you measure twice and cut once because the cost of reworking physical materials is a lot more expensive than the cost of doing a second measurement. If you could delete half your house and re-build it at zero cost, it might be more valuable to just go for the first attempt and learn from it rather than trying to do everything in theory up front. If you find yourself working on a "monstrosity" maybe you haven't seen the signs soon enough that you need to take a step back and refactor. But in my experience, at least starting on the problem with a POC gives you so much more high quality information that even if you have to scrap and re-write part way in, you're going to reach such a better result than if you try to map the whole thing out first without actually having tried to solve the problem.
- gefhfffh 5y ago
  When can you rebuild at zero cost? I have made similar avoidable mistakes of not thinking it through enough, could have saved me a lot of rewriting, which was pretty expensive
  - runald 5y ago
    Probably not literally without cost, but if the code was written with disposability in mind combined with just a little bit of pre-planning, then rewriting or refactoring should be indeed trivial.
    - gefhfffh 5y ago
      When start off with "wrong" higher level design concepts, neither of those is trivial. If you're writing a function implementation without thinking about design, well you might be right.
      - sseagull 5y ago
        I sometimes wonder if there is a miscommunication. I’m scratching my head sometimes like “how can rewriting/refactoring an entire 10-20k project take negligible time?” Maybe some people have very small projects compared to what I work on? Or maybe they are talking about the design of a single small component? I inherited a codebase that needed some refactoring because it was written “to just get it shipped”. If completely fell apart with more users and has taken me a year to get it where it needs to be.

rawoke083600 5y ago

>The more code I've written, the less I care about code quality. Yea I understand 100% where you coming from ! I also these days try to focus more on "just getting it done/shipped". Lol I even went so far as to have my own little PHP-MicroFramework called "JGID" which means "Just-Get-It-Done" to remind me at EVERY LEVEL even code that is PERFECT but not shipped is not as good as medicore-core that is shipped ! YMMV >I think the things I could point to in my coding practice which would make the code I write now better than the code I wrote 10 years ago would be: I like this approach - instead of asking what is "Good Code" You asking, "How has my code improve in 10 years" a subtle change but I there is a lot of value in there. This type of introspection-question reminds me of the very very common life-purpose question: a) What will you do if you have a million dollars ? Sure good question... But I always found the better version of this is: b)What will you do if you KNOW you won't fail ? To be honest I think it might have originated from Tim Ferris. You like or dislike him, but what I love about him is his great ability to ask interesting questions. >- I go for abstractions later, only when I need them, rather than trying to think of the perfect abstraction/design pattern which will solve the problem in the most elegant or clever way Yup I've noticed this as well. I remember my very first paid coding job. Writing a roulette-wheel-number-reader. And I was so proud to have like a OOP-Hierachy of 3 levels and implementing AbstractFactories for multiple reader-types etc :D Only the "other cases/readers" never happen :) >..After that it's all about continuous improvement.. Yes - I think I've also seen a similar effect, which is "better code" is a function of repeated-iteration of some process. It's like how woman like men that have a plan. Doesn't even have to be a good plan, just have a damn plan :D

marginalia_nu 5y ago

> The more code I've written, the less I care about code quality. I sort of agree with this, but not quite. I care about code quality, but not code aesthetics. Aesthetics was really important to me when I was younger and more inexperienced. I wanted my code to be pretty, and wouldn't be happy until I found an algorithm or abstraction that met my definitions of pretty code. I would polish it until it was shiny. I would even align my variable names to be pleasing to the eye. 20 years later, I know there are things that will just never quite look neat. FizzBuzz is a pretty accessible example of this phenomenon, but most non-trivial algorithms have that to some extent. > Besides that, I'm a huge fan of disposable code. In my experience 99% of the time, the best approach is to just dive into the problem and try to solve the problem in the most pragmatic way. Maybe that's hard-coding a lot of things. Maybe that's having a small amount of repetition here and there. Maybe it's writing one long function with 1000 lines. > After that it's all about continuous improvement. You spend your time solving the problem, and when your code becomes hard to work on, you spend time improving your code to make it easier to work on by cleaning things up, and adding sensible abstractions which solve the problems you actually have. I too am firmly in the camp of write code first, refactor into a maintainable solution when it works. Maybe it's tacit experience refactoring messy code, sort of knowing in the back of your head how it will shape up when refactored.

sseagull 5y ago

People who have been coding for a while learn not to repeat their mistakes. Their code contains good-ish abstractions and other “clean code” features because they intuitively know what they are doing. The code they just wrote to get something done & shipped is probably somewhat “clean” by most standards. But communicating those ideas to less experienced developers is where the problem comes in and all the prescriptive dogma arises. But this happens in all fields. How many times do experts give some advice they don’t always follow themselves? Experts understand when and how to break the rules, and that comes with experience.

skohan 5y ago
> communicating those ideas to less experienced developers is where the problem comes in and all the prescriptive dogma arises. I think a lot of it is just lack of context. A lot of "best practice" advice is valuable in certain cases but it gets over-applied, and people end up wasting a lot of time on things which don't matter.
Mawr 5y ago
Almost right ;) Novices need simple rules to follow. The world of a novice is filled with uncertainty, they have nearly zero intuition as to what's good or bad, so simple rules that get them 80% there are essential. Otherwise they'd get lost in the complexity. However, with time, as they gather experience, learn, and mature, they should be able to figure out the reasoning behind the rules they were once given. That then will allow them to make decisions on whether the rule is appropriate for the given context or not. Of course, getting to that point requires continuous improvement, which is why many, if not most, programmers don't get there. Example: "Never use `goto` in C." - great advice for a beginner, they'd just make their code into spaghetti. However, a seasoned coder knows that `goto` is only a problem when used to jump to arbitrary points in the code, so using it to reduce duplicated error handling is perfectly fine.
- hinkley 5y ago
  Same with “premature optimization”. Many things can be fixed later. Some can’t or won’t, and those typically get ignored or relabeled as “good design” when it is still ultimately minmaxing cpu time versus developer brain cells.

misja111 5y ago

> The more code I've written, the less I care about code quality. .. - I minimize interdependencies (changing a line of code should not affect something un-related) - I go for abstractions later, only when I need them, rather than trying to think of the perfect abstraction/design pattern which will solve the problem in the most elegant or clever way It's funny, but those points you are describing are measures of code quality to me. The less interdependencies the higher I value the code, same for abstractions, most of the time it is the simpler the better. Except in those cases where they are explicitly required.

agumonkey 5y ago

very important lesson, more than that actually there's a lot of artistry, poetry, idealism in programming, but as a daily money making activity it just doesn't cut it. You have to reach goals as easily as possible (dry,yagni) fast without painting yourself in corners as much as you can (low coupling, min interdependencies). Finding the right variability points. it's something school don't do well (saying this humbly) yet crucial ps: I disagree with the article title. k&r, mccarthy's lisp, prolog, and many other have very clean general and beautiful code.

skohan 5y ago
Yeah I think that there's a bias for programmers to think about artistry, poetry, and idealism in the form of code since that's what we're dealing with all day. But in reality it matters a lot less than we would like to think.
- agumonkey 5y ago
  IMO whenever survival (and money, contractual relationships) occur, we will or must go to a different kind of idealism which maximizing the value/effort ratio. I only "lead" one project (a minuscule thing by all means) and it was the first time I was responsible, and instead of burning out in rabbitholes, I discovered the bliss of being sharp cause I had near no time to allocate to anything. Suddenly only the minimum amount of change was important and you stop caring for so many parameters. It leads to a saner sense of skills and progress. You also start to understand systemic ideas better, every patch or change will have your brain think "is this gonna rot fast ? or will it be nicely decoupled from the rest and more pros than cons in the future?". No effort is wasted, every step improves the system. It feels very good, and makes you want to do more of that. Unlike 99% of side projects where you spend days on DESIGN.md or TODO or watching conferences about <trick>

ozim 5y ago

I love "ergonomic code" expression and after years of coding I see it as much better term to strive for than "clean code".

hinkley 5y ago

I still care, but the things I fret about have shifted substantially. There are many categories of code problem that you don’t have to get right the first time. Some things can grow organically. But there are combinations that can be extremely resistant to change. In particular, shared state is both state and coupling. Global shared state is a fucking nightmare, and almost made me quit my current job a couple months in. I thought I could fix it, but I underestimated the number of hands in the code, and the longevity of the alliances I could make to get it done. The thing with a hideous mess is that the people who don’t mind it stick around, and they probably made it in the first place. Mostly what’s kept me here is the pandemic, and he fact that a lot of my energy is now in a hobby, not invested in my job. The tiebreaker was that some self-aware wolves have found slightly better code patterns and I have been exploiting that all I can. Write more like that, delete code like this ASAP. We have spent much of the last 18 months working on things I identified in my first six weeks. Not always in the most healthy way, but at least some people are looking at it.

62951413 5y ago

I hope in real life you have enough discipline to practice things which people like me would call "code quality". Because taken literally it would lead to all those code bases I have had to maintain - barely a useful test in sight, an empty README.md, no javadocs, classes mixing multiple responsibilities, hundreds of LoCs in one class. Somehow all those things correlate and people who show a modicum of care in one area have others in a reasonable shape too. It worries me that with the leetcode fad in vogue people will pay even less attention to the things which actually matter in real software development.

skohan 5y ago
I think you might have missed the part of my post about eventually arriving at a well factored codebase

stjohnswarts 5y ago

This is why I'm like "it works, and has worked for months(years) leave it alone and do better next time" to all the young engineers who like to sling around terms like bit rot (bits do not rot) and "technical debt". Technical debt is when the code becomes hard to comprehend or update, not just because of age or you know a new fancy dancy language or DSL of their own design we should be using. Also get off my lawn lol

anamax 5y ago

> Besides that, I'm a huge fan of disposable code. In my experience 99% of the time, the best approach is to just dive into the problem and try to solve the problem My approach is slightly different. I think for a while and then start on the path that gets me to what I think is a common case. If the whole seems more complicated than reasonable, I back out the part that seems to be troublesome. Eventually, I get one case "working". That case might not be complete, but it does something. I then work on an adjacent case, using the same "back out the troublesome" process, going into a bit more detail (or perhaps deciding that some detail on the first case was wrong). I repeat "work on adjacent cases" until most/all cases are handled. As I do more cases, I use opportunities to reduce the cognitive footprint.