6 ms·

I've noticed many of these articles about what it takes to be a good software engineer talk about code quality. I recently started to work in a team of very se

I've noticed many of these articles about what it takes to be a good software engineer talk about code quality. I recently started to work in a team of very senior engineers (with relatively little experience) and what I've noticed is that code quality is rarely mentioned. Everybody write "good enough" code and there's never much discussion around code quality (occasionally a few remarks in code reviews) or design. Generally, there's very little bikeshedding on code quality and that kind of things. People are pragmatic and wants to get the work done. It also means there are trade-offs regarding code quality (also dictated by management and pressure to deliver). The challenges are elsewhere. Prioritising, communication, relationships with colleagues, setting up roadmaps and milestones, proposing designs, solving various challenges. Generally, I found software engineering is less and less about writing code. I'm impressed how my colleagues are good at everything. Fluent in most programming paradigms, able to debug complex production issues, do low level performance analysis and so on...

pjmlp 4y ago
Make it work, then make it pretty. Undelivered pretty code doesn't deliver any business value. Same applies to 100% code coverage that isn't running on customers computers.
- karmicthreat 4y ago
  There are a ton of people at all levels that don't get this.
  - cainxinth 4y ago
    I think it was Judd Apatow who said “You have to give yourself permission for the first draft to be shit.” The hardest part of making anything is getting to the minimal viable product. Editing and refining and upgrading aren’t necessarily easy, but they are typically less daunting than staring at a blank page that you need to fill.
    - dinosaurdynasty 4y ago
      Problem is the business will often never let you improve it. So you better not tie your self worth to the quality of the things you produce.
  - vsareto 4y ago
    It's not a universal thing. You can go into some interviews, say you write code just good enough to ship, and that will be a red flag to them. You have to choose your tribe on this issue and be comfortable with the other tribe hating your style.
    - pjmlp 4y ago
      Surely, I have given up to the pretty tribe on a couple of pull requests, as I have better things to do with my time, and it is easier to make their wishes come true than endless arguing.
- tpoacher 4y ago
  The counterpoint to this is "Rough Prototypes have a bad habit of being shipped out as End-Products". And technical debt 'does' kill products. There's probably an optimum somewhere in the middle of each philosophy, but it's certainly not close to either extreme.
  - karmicthreat 4y ago
    I would say technical debt is a better problem to deal with. At least the project is alive at that point and you are able to get feedback from actual users.
  - Retric 4y ago
    > an optimum somewhere in the middle Reasonable code isn’t technical debt. The obvious tipping point is when spending X hours now likey saves people less than X hours in the future. Which unfortunately depends a great deal on the details of the actual project involved and therefore requires experience not some universal methodology.
  - pjmlp 4y ago
    Sure, in the other extreme they never got shipped in first place, and that marvelous piece of art ended up in a museum. It is a balance that needs to be learnt, and a trait of seniority.
- mupuff1234 4y ago
  I don't care if it's pretty. Make it work and make it as straightforward as possible.
  - nsxwolf 4y ago
    If by "straightforward" you mean "readable" I agree. If I can read it easily, it's pretty enough.
- ericmcer 4y ago
  It depends, if it has a bunch of nested loops and easily abstracted code but it works sure, who cares. If someone decides to store JSON as a string in the db that will work and deliver business value, but 8 months later when you want to query information in that JSON string you have a very difficult/dangerous migration due to someone just "making it work". This philosophy less relevant in larger companies with more engineers also.
  - pjmlp 4y ago
    One of the traits of seniority is to understand what that "it depends" means in reality.
  - P5fRxh5kUvp2th 4y ago
    Do you know of any RDBMS's that can't take a text column and treat it as BSON? I get your point, I just question the specific example.
- ignoramous 4y ago
  > Undelivered pretty code doesn't deliver any business value. See also: https://apenwarr.ca/log/20211024 https://apenwarr.ca/log/20211024 (Wants, needs, and chasm crossing).
goodpoint 4y ago
Learning how to write good code is a topic for juniors. Any senior would already know how to that so we focus on other things.
pmelendez 4y ago
It depends what is understood as code quality. After a while, writing code that is not verbose, fairly maintainable, and readable, is a given. There is a minimum bar that each team set and it is gated by code reviews. The tradeoff start to happen after those minimums are reached. I think quality in terms of correctness is always the target, and performance usually has a target SLA.
deleted 4y ago
[deleted]
lhnz 4y ago
I wouldn't fully agree, because while senior engineers don't often discuss "code quality" syntax/aesthetic issues, it is quite common for people to discuss bugs/edge-cases that need fixes or to discuss simpler approaches to achieve business goals or getting rid of difficult to maintain logic/services.
hellisothers 4y ago
At some point your craft is good (or good enough) that progressing further on it is not moving you forward as an engineer. It is often a difficult thing to notice and a trap one can easily fall into of over-focusing on craft and not realizing you’re plateauing your overall career or skill set.
rullelito 4y ago
IMO too many coders can't write high quality code even if they tried. So when they write code that they feel is good enough, it rarely is good enough objectively.
- xeromal 4y ago
  What even is high quality code? I was on a project with a seasoned grey beard once and all he bitched about was dumb stuff like insisting NOT to prepend variable names with is and forcing a python project to have dependency injection. Sure, those things can make a high quality project but often misplaced and strangely opinionated.
tom-thistime 4y ago
For benefit of a friend new to HN (and anyone else who might be new here): Yes, the comments and the articles are almost separate, parallel discussions. The articles can be interesting in themselves, but for purposes of reading the comments, the articles are often just kind of inspirations or writing prompts. So, yeah, the OP doesn't even mention code quality. The comments do. That's ok. It's just how the site works.
- yodsanklai 4y ago
  Article start with variable names (which pertains to code quality) > Variable names are important because they communicate to the reader what’s happening. That’s their only job in code, so it’s important to name them well. Long verbose names don't cost anything:
  - johnthuss 4y ago
    Except in JavaScript ;)
    - blueblob 4y ago
      And legacy c/opengl, where the variables names tell you the return type...
- twic 4y ago
  HN maintainers should optimize page load time by just omitting the actual link to the article. The discussions would be pretty much the same.
ebiester 4y ago
It's certainly there, but it comes in different avenues: tech lead meetings (where is our technical debt?), early in projects (as everyone is building a consensus for the project), and code reviews (where they're talking about a facet to make code more understandable or testable or otherwise fulfilling non-functional requirements.) The conversations aren't about code quality -- they're about a finer point of it and in concrete terms rather than in beginner terms.
adamsmith143 4y ago
Sounds like a startup? Title inflation is pretty rampant at smaller newer companies. The expectation is definitely ship the product before all else. Obviously if you are an established company serving services to hundreds of thousands or millions of customers code quality and reliability becomes an order of magnitude more important.
dionidium 4y ago
I used to work with a guy who took "gets shit done" to a level I'd never seen before. It changed the way I look at programming. He was actually a pretty good engineer. Wrote good-enough code. But he wasn't precious about anything and he didn't care all that much about finding the 100%-guaranteed-socially-approved-correct way to do things. What he had was an incredible ability to diagnose and fix problems quickly, strong intuition about how to architect greenfield projects, and the complete confidence of his bosses, with whom he very quickly earned a reputation as the person to go to when something absolutely needed to get done. He knew what to prioritize. He knew which parts of the code to plow through and which to take his time on. He knew exactly where in the code to start looking when a bug came in. And he knew which things were important to management and which weren't. I learned way more from him than I ever have from the kind of peers who have opinions about how to structure every line of code.
- ignoramous 4y ago
  If I may, you should encourage your ex team-mate to share their side of things: https://staffeng.com/stories https://staffeng.com/stories
- enraged_camel 4y ago
  In my experience it is useful to have such people on the team, but if they make up most of the team then the codebase becomes a gigantic mess over time, and it negatively impacts everyone else.
  - mmmpop 4y ago
    Perhaps but having "that programmer that management likes" is worth 10x more than whatever mess is generally being made.
  - skrtskrt 4y ago
    Yep I tend to be more on the spectrum of focusing on code & architecture quality over raw productivity, and I find the "plow through it and get it done" engineer to be the perfect foil to have on my team. Ultimately it gets done faster than it would if the whole team was my personality, but with higher quality than if the whole team was their personality.
debacle 4y ago
There are a few hard and fast rules around code quality (and every rule is meant to be broken), everything else is just preference.
ChrisMarshallNY 4y ago
Depends on where you are. In the company I used to work at, code quality was a huge deal. I think, destructively so. Nevertheless, I exercise pretty extreme code quality in my work (see for yourself[0]). It's long reached the state of "muscle memory," and I work very quickly. As I am the person that most frequently has to go back and fix the code I write (I eat my own dog food), I write code that is what I want to see, when revisiting, six months later. On another note, this industry considers six years to be "senior." I find that interesting. [0] https://github.com/ChrisMarshallNY#browse-away https://github.com/ChrisMarshallNY#browse-away
- yodsanklai 4y ago
  > I exercise pretty extreme code quality in my work I'd say maintain good code quality on your own project is much easier than within a team. It's like living in a house with different people: not everybody has the same standard regarding keeping the place tidy and clean, and compromises have to be made. This was one of the biggest pain point for me, moving from my own personal projects to working with other people.
  - ChrisMarshallNY 4y ago
    This is true. Many things suddenly become much more difficult, when even one other person is involved. Managers often neglect to take team overhead seriously.
opmelogy 4y ago
> Everybody write "good enough" code and there's never much discussion around code quality (occasionally a few remarks in code reviews) or design. This approach probably works out because you have senior engineers laying out a lot of the core structure and architecture for how things built. There's a tendency for newer people to tacitly adopt patterns that already exist and replicate. However, this approach can be really problematic when you have a team that's primarily newer engineers. I've seen it multiple times and it's always the same result - productivity almost grinds to a halt over time because there are so many problems in the code base. The worst example I saw was switching teams and seeing the team velocity. We measured all the work in story points and used the exact same task as a baseline story point. The previous team with mostly senior engineers, a point took .5 days. With the new team that was started by all fresh grad engineers, a story point took a minimum of 3 days and usually bumped up to 4 days. This velocity lasted multiple years, even when the team had a much more balanced spread of senior, mid-level, and fresh grad engineers.
- pca006132 4y ago
  Are you sure that the discussion should be around code quality but not architecture? I think they are quite different...
  - P5fRxh5kUvp2th 4y ago
    In addition, I think it's the fault of management if it's all young engineers. I've often said the difference between a senior and a junior isn't writing software successfully, it's writing software that's maintainable 5 years down the road. The only way to learn that skill is to deal with a project over years and learn the pain points that aren't immediately obvious w/i the first 18 months.
mad_vill 4y ago
This is touching on something I have been thinking a lot about as I progress in my career. The thing good and bad code have in common is the fact that it needs to updated. Either for bugs or changing business need. So focusing on the operational side becomes much more important. Code is the trivial part. Creating systems that can be modified reliably is the hard part. I rather have ownership over a "poorly" coded service with proper ci/cd, integration tests, monitoring, and a team that reasons about and follows strong operational processes, rather than some beautiful code in a vacuum.
- zmgsabst 4y ago
  My experience is that “good” code enables all of that — CI/CD, meaningful testing, monitoring/logging, operational tooling, etc. Making any of that work for spaghetti is rough, since it lacks the boundaries and entry points those things rely on. And even if you ostensibly have it for “bad” code, it tends to be fragile and unreliable. (As my many, many overnight pages have shown.) Of course, that may be different perceptions of “good”.
smrtinsert 4y ago
Depends on the seniority imo. If you don't make code quality a thing with early in their career devs, you might open up a door to some bad habits to take hold.
toomanyrichies 4y ago
> I recently started to work in a team of very senior engineers (with relatively little experience) and what I've noticed is that code quality is rarely mentioned. Everybody write "good enough" code and there's never much discussion around code quality (occasionally a few remarks in code reviews) or design. I'll play devil's advocate and argue that this could just be the code equivalent of privatizing the benefits while socializing the costs. You mention that your team writes code without explicit discussion of its quality. The benefits of that choice are front-loaded, while the costs of that choice won't be apparent until later. Furthermore, the team members who have to pay those costs may not even be the current team members - it may actually be those on the team months or years from now, after the original code authors have left for greener pastures. So it may be too early to declare that your choice was a successful one. As the article mentions, code is read much more often than it's written.
- yodsanklai 4y ago
  I'm not saying that my team writes unmaintainable code, but rather that because they're all strong and experienced, writing decent code is a given and the focus is on other, more challenging, problems. That being said, our code is definitely not as readable as it could be, but I understand it's a trade-off and there are more important things to do than refactoring code, unless it really gets in the way.
battery_glasses 4y ago
I used to feel this way until I started working with a very senior engineer (20+ years) who writes some of the worst code I have ever had to work with. Functions are regularly 50+ lines with 10+ logical expressions. Most features are written as single classes with 3k-5k lines. Everything is written imperatively (that 50 line function declares a variable at the top and mutates it 10 times as it works through the control flow.) The same magic values are redeclared multiple times through the codebase instead of using a shared constant. His PRs are usually 3k-5k lines and take hours to work through. etc. etc His code takes way more effort to understand and takes orders of magnitudes longer to change than it reasonably should. Also his code works. It generally does what its supposed to do, covers edge cases, and is reliable. He also delivers with decent speed, but all that saved time is being pushed on the poor sap who has to work with the code next.
nine_k 4y ago
For me, code quality boils down to two aspects: (1) current operation cost and (2) future maintenance / alteration cost. You can cut a lot of corners, as long as you don't paint yourself into a corner. OTOH an extra hour not spent today on doing the right thing may and will result in extra weeks and extra thousands of dollars spent in a few months.
P5fRxh5kUvp2th 4y ago
yep. A common refrain is that if you're not looking at code you wrote 6 months ago and thinking it's poor quality then you're not growing as a developer. This is probably true for the first few years of a developers career, but there are only so many ways to build an authentication system (for example). At some point your improvements are at the design and systems level. You start to develop a nose for what can be problematic and how to avoid it. Linus Torvalds referred to it as 'taste'. And as you said, often times there are organizational and procedural challenges that have a much larger effect on the success of a project than purely code concerns. Not that code concerns are irrelevant, but good enough is good enough, there's generally an expectation that developers can read code. In the same way there's an expectation that readers of a novel are at the literacy level to understand novels. No one would blame James Clavell if a 5th grader couldn't understand Shogun, even though it's true that Shogun could certainly be improved from a prose perspective.

pjmlp 4y ago

Make it work, then make it pretty. Undelivered pretty code doesn't deliver any business value. Same applies to 100% code coverage that isn't running on customers computers.

karmicthreat 4y ago
There are a ton of people at all levels that don't get this.
- cainxinth 4y ago
  I think it was Judd Apatow who said “You have to give yourself permission for the first draft to be shit.” The hardest part of making anything is getting to the minimal viable product. Editing and refining and upgrading aren’t necessarily easy, but they are typically less daunting than staring at a blank page that you need to fill.
  - dinosaurdynasty 4y ago
    Problem is the business will often never let you improve it. So you better not tie your self worth to the quality of the things you produce.
- vsareto 4y ago
  It's not a universal thing. You can go into some interviews, say you write code just good enough to ship, and that will be a red flag to them. You have to choose your tribe on this issue and be comfortable with the other tribe hating your style.
  - pjmlp 4y ago
    Surely, I have given up to the pretty tribe on a couple of pull requests, as I have better things to do with my time, and it is easier to make their wishes come true than endless arguing.
tpoacher 4y ago
The counterpoint to this is "Rough Prototypes have a bad habit of being shipped out as End-Products". And technical debt 'does' kill products. There's probably an optimum somewhere in the middle of each philosophy, but it's certainly not close to either extreme.
- karmicthreat 4y ago
  I would say technical debt is a better problem to deal with. At least the project is alive at that point and you are able to get feedback from actual users.
- Retric 4y ago
  > an optimum somewhere in the middle Reasonable code isn’t technical debt. The obvious tipping point is when spending X hours now likey saves people less than X hours in the future. Which unfortunately depends a great deal on the details of the actual project involved and therefore requires experience not some universal methodology.
- pjmlp 4y ago
  Sure, in the other extreme they never got shipped in first place, and that marvelous piece of art ended up in a museum. It is a balance that needs to be learnt, and a trait of seniority.
mupuff1234 4y ago
I don't care if it's pretty. Make it work and make it as straightforward as possible.
- nsxwolf 4y ago
  If by "straightforward" you mean "readable" I agree. If I can read it easily, it's pretty enough.
ericmcer 4y ago
It depends, if it has a bunch of nested loops and easily abstracted code but it works sure, who cares. If someone decides to store JSON as a string in the db that will work and deliver business value, but 8 months later when you want to query information in that JSON string you have a very difficult/dangerous migration due to someone just "making it work". This philosophy less relevant in larger companies with more engineers also.
- pjmlp 4y ago
  One of the traits of seniority is to understand what that "it depends" means in reality.
- P5fRxh5kUvp2th 4y ago
  Do you know of any RDBMS's that can't take a text column and treat it as BSON? I get your point, I just question the specific example.
ignoramous 4y ago
> Undelivered pretty code doesn't deliver any business value. See also: https://apenwarr.ca/log/20211024 https://apenwarr.ca/log/20211024 (Wants, needs, and chasm crossing).

goodpoint 4y ago

Learning how to write good code is a topic for juniors. Any senior would already know how to that so we focus on other things.

pmelendez 4y ago

It depends what is understood as code quality. After a while, writing code that is not verbose, fairly maintainable, and readable, is a given. There is a minimum bar that each team set and it is gated by code reviews. The tradeoff start to happen after those minimums are reached. I think quality in terms of correctness is always the target, and performance usually has a target SLA.

deleted 4y ago

[deleted]

lhnz 4y ago

I wouldn't fully agree, because while senior engineers don't often discuss "code quality" syntax/aesthetic issues, it is quite common for people to discuss bugs/edge-cases that need fixes or to discuss simpler approaches to achieve business goals or getting rid of difficult to maintain logic/services.

hellisothers 4y ago

At some point your craft is good (or good enough) that progressing further on it is not moving you forward as an engineer. It is often a difficult thing to notice and a trap one can easily fall into of over-focusing on craft and not realizing you’re plateauing your overall career or skill set.

rullelito 4y ago

IMO too many coders can't write high quality code even if they tried. So when they write code that they feel is good enough, it rarely is good enough objectively.

xeromal 4y ago
What even is high quality code? I was on a project with a seasoned grey beard once and all he bitched about was dumb stuff like insisting NOT to prepend variable names with is and forcing a python project to have dependency injection. Sure, those things can make a high quality project but often misplaced and strangely opinionated.

tom-thistime 4y ago

For benefit of a friend new to HN (and anyone else who might be new here): Yes, the comments and the articles are almost separate, parallel discussions. The articles can be interesting in themselves, but for purposes of reading the comments, the articles are often just kind of inspirations or writing prompts. So, yeah, the OP doesn't even mention code quality. The comments do. That's ok. It's just how the site works.

yodsanklai 4y ago
Article start with variable names (which pertains to code quality) > Variable names are important because they communicate to the reader what’s happening. That’s their only job in code, so it’s important to name them well. Long verbose names don't cost anything:
- johnthuss 4y ago
  Except in JavaScript ;)
  - blueblob 4y ago
    And legacy c/opengl, where the variables names tell you the return type...
twic 4y ago
HN maintainers should optimize page load time by just omitting the actual link to the article. The discussions would be pretty much the same.

ebiester 4y ago

It's certainly there, but it comes in different avenues: tech lead meetings (where is our technical debt?), early in projects (as everyone is building a consensus for the project), and code reviews (where they're talking about a facet to make code more understandable or testable or otherwise fulfilling non-functional requirements.) The conversations aren't about code quality -- they're about a finer point of it and in concrete terms rather than in beginner terms.

adamsmith143 4y ago

Sounds like a startup? Title inflation is pretty rampant at smaller newer companies. The expectation is definitely ship the product before all else. Obviously if you are an established company serving services to hundreds of thousands or millions of customers code quality and reliability becomes an order of magnitude more important.

dionidium 4y ago

I used to work with a guy who took "gets shit done" to a level I'd never seen before. It changed the way I look at programming. He was actually a pretty good engineer. Wrote good-enough code. But he wasn't precious about anything and he didn't care all that much about finding the 100%-guaranteed-socially-approved-correct way to do things. What he had was an incredible ability to diagnose and fix problems quickly, strong intuition about how to architect greenfield projects, and the complete confidence of his bosses, with whom he very quickly earned a reputation as the person to go to when something absolutely needed to get done. He knew what to prioritize. He knew which parts of the code to plow through and which to take his time on. He knew exactly where in the code to start looking when a bug came in. And he knew which things were important to management and which weren't. I learned way more from him than I ever have from the kind of peers who have opinions about how to structure every line of code.

ignoramous 4y ago
If I may, you should encourage your ex team-mate to share their side of things: https://staffeng.com/stories https://staffeng.com/stories
enraged_camel 4y ago
In my experience it is useful to have such people on the team, but if they make up most of the team then the codebase becomes a gigantic mess over time, and it negatively impacts everyone else.
- mmmpop 4y ago
  Perhaps but having "that programmer that management likes" is worth 10x more than whatever mess is generally being made.
- skrtskrt 4y ago
  Yep I tend to be more on the spectrum of focusing on code & architecture quality over raw productivity, and I find the "plow through it and get it done" engineer to be the perfect foil to have on my team. Ultimately it gets done faster than it would if the whole team was my personality, but with higher quality than if the whole team was their personality.

debacle 4y ago

There are a few hard and fast rules around code quality (and every rule is meant to be broken), everything else is just preference.

ChrisMarshallNY 4y ago

Depends on where you are. In the company I used to work at, code quality was a huge deal. I think, destructively so. Nevertheless, I exercise pretty extreme code quality in my work (see for yourself[0]). It's long reached the state of "muscle memory," and I work very quickly. As I am the person that most frequently has to go back and fix the code I write (I eat my own dog food), I write code that is what I want to see, when revisiting, six months later. On another note, this industry considers six years to be "senior." I find that interesting. [0] https://github.com/ChrisMarshallNY#browse-away https://github.com/ChrisMarshallNY#browse-away

yodsanklai 4y ago
> I exercise pretty extreme code quality in my work I'd say maintain good code quality on your own project is much easier than within a team. It's like living in a house with different people: not everybody has the same standard regarding keeping the place tidy and clean, and compromises have to be made. This was one of the biggest pain point for me, moving from my own personal projects to working with other people.
- ChrisMarshallNY 4y ago
  This is true. Many things suddenly become much more difficult, when even one other person is involved. Managers often neglect to take team overhead seriously.

opmelogy 4y ago

> Everybody write "good enough" code and there's never much discussion around code quality (occasionally a few remarks in code reviews) or design. This approach probably works out because you have senior engineers laying out a lot of the core structure and architecture for how things built. There's a tendency for newer people to tacitly adopt patterns that already exist and replicate. However, this approach can be really problematic when you have a team that's primarily newer engineers. I've seen it multiple times and it's always the same result - productivity almost grinds to a halt over time because there are so many problems in the code base. The worst example I saw was switching teams and seeing the team velocity. We measured all the work in story points and used the exact same task as a baseline story point. The previous team with mostly senior engineers, a point took .5 days. With the new team that was started by all fresh grad engineers, a story point took a minimum of 3 days and usually bumped up to 4 days. This velocity lasted multiple years, even when the team had a much more balanced spread of senior, mid-level, and fresh grad engineers.

pca006132 4y ago
Are you sure that the discussion should be around code quality but not architecture? I think they are quite different...
- P5fRxh5kUvp2th 4y ago
  In addition, I think it's the fault of management if it's all young engineers. I've often said the difference between a senior and a junior isn't writing software successfully, it's writing software that's maintainable 5 years down the road. The only way to learn that skill is to deal with a project over years and learn the pain points that aren't immediately obvious w/i the first 18 months.

mad_vill 4y ago

This is touching on something I have been thinking a lot about as I progress in my career. The thing good and bad code have in common is the fact that it needs to updated. Either for bugs or changing business need. So focusing on the operational side becomes much more important. Code is the trivial part. Creating systems that can be modified reliably is the hard part. I rather have ownership over a "poorly" coded service with proper ci/cd, integration tests, monitoring, and a team that reasons about and follows strong operational processes, rather than some beautiful code in a vacuum.

zmgsabst 4y ago
My experience is that “good” code enables all of that — CI/CD, meaningful testing, monitoring/logging, operational tooling, etc. Making any of that work for spaghetti is rough, since it lacks the boundaries and entry points those things rely on. And even if you ostensibly have it for “bad” code, it tends to be fragile and unreliable. (As my many, many overnight pages have shown.) Of course, that may be different perceptions of “good”.

smrtinsert 4y ago

Depends on the seniority imo. If you don't make code quality a thing with early in their career devs, you might open up a door to some bad habits to take hold.

toomanyrichies 4y ago

> I recently started to work in a team of very senior engineers (with relatively little experience) and what I've noticed is that code quality is rarely mentioned. Everybody write "good enough" code and there's never much discussion around code quality (occasionally a few remarks in code reviews) or design. I'll play devil's advocate and argue that this could just be the code equivalent of privatizing the benefits while socializing the costs. You mention that your team writes code without explicit discussion of its quality. The benefits of that choice are front-loaded, while the costs of that choice won't be apparent until later. Furthermore, the team members who have to pay those costs may not even be the current team members - it may actually be those on the team months or years from now, after the original code authors have left for greener pastures. So it may be too early to declare that your choice was a successful one. As the article mentions, code is read much more often than it's written.

yodsanklai 4y ago
I'm not saying that my team writes unmaintainable code, but rather that because they're all strong and experienced, writing decent code is a given and the focus is on other, more challenging, problems. That being said, our code is definitely not as readable as it could be, but I understand it's a trade-off and there are more important things to do than refactoring code, unless it really gets in the way.

battery_glasses 4y ago

I used to feel this way until I started working with a very senior engineer (20+ years) who writes some of the worst code I have ever had to work with. Functions are regularly 50+ lines with 10+ logical expressions. Most features are written as single classes with 3k-5k lines. Everything is written imperatively (that 50 line function declares a variable at the top and mutates it 10 times as it works through the control flow.) The same magic values are redeclared multiple times through the codebase instead of using a shared constant. His PRs are usually 3k-5k lines and take hours to work through. etc. etc His code takes way more effort to understand and takes orders of magnitudes longer to change than it reasonably should. Also his code works. It generally does what its supposed to do, covers edge cases, and is reliable. He also delivers with decent speed, but all that saved time is being pushed on the poor sap who has to work with the code next.

nine_k 4y ago

For me, code quality boils down to two aspects: (1) current operation cost and (2) future maintenance / alteration cost. You can cut a lot of corners, as long as you don't paint yourself into a corner. OTOH an extra hour not spent today on doing the right thing may and will result in extra weeks and extra thousands of dollars spent in a few months.

P5fRxh5kUvp2th 4y ago

yep. A common refrain is that if you're not looking at code you wrote 6 months ago and thinking it's poor quality then you're not growing as a developer. This is probably true for the first few years of a developers career, but there are only so many ways to build an authentication system (for example). At some point your improvements are at the design and systems level. You start to develop a nose for what can be problematic and how to avoid it. Linus Torvalds referred to it as 'taste'. And as you said, often times there are organizational and procedural challenges that have a much larger effect on the success of a project than purely code concerns. Not that code concerns are irrelevant, but good enough is good enough, there's generally an expectation that developers can read code. In the same way there's an expectation that readers of a novel are at the literacy level to understand novels. No one would blame James Clavell if a 5th grader couldn't understand Shogun, even though it's true that Shogun could certainly be improved from a prose perspective.