5 ms·

IMO good programmer writes code that: 1. Solves task. 2. Does that within a necessary performance constraints. 3. Uses commonly accepted approaches, librarie

IMO good programmer writes code that: 1. Solves task. 2. Does that within a necessary performance constraints. 3. Uses commonly accepted approaches, libraries, style, does not reinvent things which are not necessary to reinvent. 4. Readable by programmers who'll work with that code in the future. That could be juniors or seniors, that depends on a particular company and project. 5. Extendable for changes which are likely to happen in the future. 6. Not extendable for changes which are not likely to happen in the future. Every item is necessary and going down this list requires more skill and more humility. It's easy to write complicated code. It's hard to write simple code which is as good as complicated where it matters. That's what my opinion is and that's what I strive to. That said, I might be completely wrong about it, as I see great churn with modern software, things are being rewritten over and over again. Code maintainability seems not to matter as much as it mattered in the past. May be that's my bubble. Sometimes I think that the good programmer is one who can spew JavaScript nonsense faster than his peers can review it, because who cares, that stuff is going to be rewritten tomorrow with revolutionary new age framework.

AnimalMuppet 4y ago
"Rewrite all the things in X" is how you get 1 year of experience 10 times, instead of 10 years of experience. It's also how your company burns through tons of money for little substantial result.
Sohcahtoa82 4y ago
> Uses commonly accepted approaches, libraries, style I would argue NOT to do this if you're writing Java. Java paradigms are awful, lead to way too many layers of abstraction, and code that is impossible to debug because your stack traces are just 30 calls of ".invoke()". > Readable by programmers who'll work with that code in the future. And yet Perl became popular.
- ben_w 4y ago
  Java was the language of choice when I was at university. The way they described it to us, was that everything about it was designed with teamwork (and large teams) in mind. I don't know how well it really did that even by the standards of the era of its introduction, but it has the air of plausibility. Certainly, I expect anyone who is used to that style to prefer to encounter and work with Java written in that style over Java written in the style of C. > And yet Perl became popular. As I recall, the joke being that it was a "write only" language.
  - Sohcahtoa82 4y ago
    > As I recall, the joke being that it was a "write only" language. Yeah, which is why I question how it go so popular.
    - ben_w 4y ago
      "Write only" means nobody works with it once it's been written ;)
mgkimsal 4y ago
> which are not likely to happen in the future. Making that determination is something you really only get good at with the experience of making the wrong determination too many times.
jacquesm 4y ago
5 and 6 are super hard decisions. You never really know what your code will be used for in the future, especially not if you make libraries. I try really hard to do this and over the years I've found myself more than once caught out by something that I wished I had foreseen but did not and, conversely, I have spent a lot of time preparing code for changes which seemed to be likely to happen but that never did.
- hbrn 4y ago
  This is a really good point. Engineers are constantly trying to predict the future, but ability to do so often does not depend on engineering skills at all. Often it is completely out of your control. Instead of trying to make code "extendable" I found that it is much better to make code "disposable". Do not hope you'll make the right prediction. Expect to be wrong and be able to recover fast.
- tabtab 4y ago
  Knowledge of the domain and general experience with similar domains helps. My horse sense about what's likely to change has improved with time. As far as #6, you don't want to outright limit change because the future surprises, but use a YAGNI-ish view of unlikely changes to keep the system simpler. In other words, you don't make it hard to change, you just don't spend complexity on things unlikely to change. You only spend abstraction-related complexity on things likely to change.
tboyd47 4y ago
Very nice summary here and I agree 100%.
nine_zeros 4y ago
> 4. Readable by programmers who'll work with that code in the future. That could be juniors or seniors, that depends on a particular company and project. Underrated. Layers of unnecessary abstractions or clever solutions (e.g. complex types in python when simple would do) is a mark of a junior engineer.
contravariant 4y ago
While those are all good guidelines (though I'm not too sure about 6) a 'master' programmer should probably know when to break each of those rules. In the end programming is about telling a computer what it ought to do. Making this process as easy as possible is the sign of a good programmer, but there's no reason the process has to be limited to writing code, so talking about what code makes a good programmer seems reductive. Also in this view 6 is usually a mistake as it makes it harder to communicate, not easier. That said some things don't make sense, and therefore probably shouldn't look like they make sense either.
- jrumbut 4y ago
  One of the aspects of mastery (that I've observed in others) is being able to say yes to 99% of requests but knowing how to steer projects away from that one feature that will cause complexity to explode without delivering commensurate value.
ChrisMarshallNY 4y ago
> does not reinvent things which are not necessary to reinvent. This is one of those "eye of the beholder" things. If I had a quarter for every time I've heard "That's a solved problem," with a reference to a dependency, somewhere, I'd be a rich man. I tend to really avoid external (not written by me) dependencies, because I have had many problems with other people's code. Fixing someone else's badly written open-source code usually takes longer than just writing the small part of their library that I need, and it doesn't involve having to argue with them, or have my PR rejected, because I have "too many comments." I know that's not a popular stance, around here, but it works for me. I use a ton of dependencies, in my work, but I wrote most of them.
- mellosouls 4y ago
  That's fine if nobody else has to maintain your code. If they do it's difficult to see how your solutions to solved problems aren't going to be significantly more problematic and risky than established libraries.
  - ChrisMarshallNY 4y ago
    Not really. I'm pretty good at what I do. Feel free to see for yourself: https://github.com/ChrisMarshallNY#browse-away https://github.com/ChrisMarshallNY#browse-away Most of those repos are dogfood.
    - dragonsky67 4y ago
      And that is all good if the developer is qualified and has time to review your work. Far easier to use something that 1000's of others are using as well. Far more likely for edge case bugs to surface. That said, I have to agree that it can be painful trying to get one of those edge case bugs resolved if you are the only one being impacted. In this case I may be worth just implementing your own functionality and swallowing the future support. But I think it's got to be a backup plan, not your first response. The real problem is that most developers don't have the experience or knowledge to go beyond accepting the "use xyz library" suggestion on Stack Overflow on face value, not having the ability to review xyz library for suitability. We end up with lots of code that is just collections of dependencies where only a very small % of functionality is used and no resources are put into ensuring that using the dependency is not introducing more problems than they solve.
glouwbug 4y ago
Are we talking about industry programming? A good programmer knows how to get in and out, and retire early, and spend the rest of their days working on projects that fulfill their needs

AnimalMuppet 4y ago

"Rewrite all the things in X" is how you get 1 year of experience 10 times, instead of 10 years of experience. It's also how your company burns through tons of money for little substantial result.

Sohcahtoa82 4y ago

> Uses commonly accepted approaches, libraries, style I would argue NOT to do this if you're writing Java. Java paradigms are awful, lead to way too many layers of abstraction, and code that is impossible to debug because your stack traces are just 30 calls of ".invoke()". > Readable by programmers who'll work with that code in the future. And yet Perl became popular.

ben_w 4y ago
Java was the language of choice when I was at university. The way they described it to us, was that everything about it was designed with teamwork (and large teams) in mind. I don't know how well it really did that even by the standards of the era of its introduction, but it has the air of plausibility. Certainly, I expect anyone who is used to that style to prefer to encounter and work with Java written in that style over Java written in the style of C. > And yet Perl became popular. As I recall, the joke being that it was a "write only" language.
- Sohcahtoa82 4y ago
  > As I recall, the joke being that it was a "write only" language. Yeah, which is why I question how it go so popular.
  - ben_w 4y ago
    "Write only" means nobody works with it once it's been written ;)

mgkimsal 4y ago

> which are not likely to happen in the future. Making that determination is something you really only get good at with the experience of making the wrong determination too many times.

jacquesm 4y ago

5 and 6 are super hard decisions. You never really know what your code will be used for in the future, especially not if you make libraries. I try really hard to do this and over the years I've found myself more than once caught out by something that I wished I had foreseen but did not and, conversely, I have spent a lot of time preparing code for changes which seemed to be likely to happen but that never did.

hbrn 4y ago
This is a really good point. Engineers are constantly trying to predict the future, but ability to do so often does not depend on engineering skills at all. Often it is completely out of your control. Instead of trying to make code "extendable" I found that it is much better to make code "disposable". Do not hope you'll make the right prediction. Expect to be wrong and be able to recover fast.
tabtab 4y ago
Knowledge of the domain and general experience with similar domains helps. My horse sense about what's likely to change has improved with time. As far as #6, you don't want to outright limit change because the future surprises, but use a YAGNI-ish view of unlikely changes to keep the system simpler. In other words, you don't make it hard to change, you just don't spend complexity on things unlikely to change. You only spend abstraction-related complexity on things likely to change.

tboyd47 4y ago

Very nice summary here and I agree 100%.

nine_zeros 4y ago

> 4. Readable by programmers who'll work with that code in the future. That could be juniors or seniors, that depends on a particular company and project. Underrated. Layers of unnecessary abstractions or clever solutions (e.g. complex types in python when simple would do) is a mark of a junior engineer.

contravariant 4y ago

While those are all good guidelines (though I'm not too sure about 6) a 'master' programmer should probably know when to break each of those rules. In the end programming is about telling a computer what it ought to do. Making this process as easy as possible is the sign of a good programmer, but there's no reason the process has to be limited to writing code, so talking about what code makes a good programmer seems reductive. Also in this view 6 is usually a mistake as it makes it harder to communicate, not easier. That said some things don't make sense, and therefore probably shouldn't look like they make sense either.

jrumbut 4y ago
One of the aspects of mastery (that I've observed in others) is being able to say yes to 99% of requests but knowing how to steer projects away from that one feature that will cause complexity to explode without delivering commensurate value.

ChrisMarshallNY 4y ago

> does not reinvent things which are not necessary to reinvent. This is one of those "eye of the beholder" things. If I had a quarter for every time I've heard "That's a solved problem," with a reference to a dependency, somewhere, I'd be a rich man. I tend to really avoid external (not written by me) dependencies, because I have had many problems with other people's code. Fixing someone else's badly written open-source code usually takes longer than just writing the small part of their library that I need, and it doesn't involve having to argue with them, or have my PR rejected, because I have "too many comments." I know that's not a popular stance, around here, but it works for me. I use a ton of dependencies, in my work, but I wrote most of them.

mellosouls 4y ago
That's fine if nobody else has to maintain your code. If they do it's difficult to see how your solutions to solved problems aren't going to be significantly more problematic and risky than established libraries.
- ChrisMarshallNY 4y ago
  Not really. I'm pretty good at what I do. Feel free to see for yourself: https://github.com/ChrisMarshallNY#browse-away https://github.com/ChrisMarshallNY#browse-away Most of those repos are dogfood.
  - dragonsky67 4y ago
    And that is all good if the developer is qualified and has time to review your work. Far easier to use something that 1000's of others are using as well. Far more likely for edge case bugs to surface. That said, I have to agree that it can be painful trying to get one of those edge case bugs resolved if you are the only one being impacted. In this case I may be worth just implementing your own functionality and swallowing the future support. But I think it's got to be a backup plan, not your first response. The real problem is that most developers don't have the experience or knowledge to go beyond accepting the "use xyz library" suggestion on Stack Overflow on face value, not having the ability to review xyz library for suitability. We end up with lots of code that is just collections of dependencies where only a very small % of functionality is used and no resources are put into ensuring that using the dependency is not introducing more problems than they solve.

glouwbug 4y ago

Are we talking about industry programming? A good programmer knows how to get in and out, and retire early, and spend the rest of their days working on projects that fulfill their needs