4 ms·

When seniors (and above) complain about the low quality of junior code, I tell them to go look at their own code from 6 months ago. It's an endemic issue, core

When seniors (and above) complain about the low quality of junior code, I tell them to go look at their own code from 6 months ago. It's an endemic issue, core to the problem of poor software. > My goals used to be to write code that looked and felt cool to myself and others, ... My goals are now to: - make code so easy to read it’s boring Same for me, and I'm sure same to many of the folks that have advanced past senior level. The problem of other people, other senior people, needing to read, understand, and significantly modify your code is one of the reasons why you can't really advance past senior in a startup. There aren't enough experienced folks that you have to write "up to". Of course the other part of being post-senior is the ability to scale your expertise, but now I'm digressing quite far. Then once you're that advanced, you don't want to take a pay and scope cut to work at a startup. This is a major contributor to startup technical debt accumulation, one that can't readily be solved. I still do write "cool code", for code that I will only use myself that doesn't go into production. But for all others, I write easy-to-read code. And I review code with that in mind. When comments have a typo that alter the meaning of the comment, I insist that be fixed. Juniors hate me for being too picky. (and I hate them for being too sloppy.) Remember, the most important part of your job as senior+ is not what you do yourself, it's how you guide others.

taneq 7y ago
> seniors [...] complain about the low quality of junior code [...] their own code from 6 months ago. What classes as 'senior' that their own coding style has changed that much in 6 months? O.o > I still do write "cool code", for code that I will only use myself that doesn't go into production. But for all others, I write easy-to-read code. Good dev. Remember, you are not your audience. Unless you're just writing play-code in which case go nuts and be as 'clever' as you want. :D > When comments have a typo that alter the meaning of the comment, I insist that be fixed. Juniors hate me for being too picky. Then they're wrong, and tbh that's not something I'd accept more than once from an employee.
- tomsmeding 7y ago
  > > seniors [...] complain about the low quality of junior code [...] their own code from 6 months ago. > What classes as 'senior' that their own coding style has changed that much in 6 months? O.o Your code style can remain exactly the same, and it would still happen. The reason is not that you would write the code differently today, but that you forgot the issues and edge cases that made you write it like that then, and that at the time you focused too much on the writing, not on the reading.
  - taneq 7y ago
    ...you don't remember what you were doing 6 months ago? I'm sorry, that's still not a good excuse. Maybe you don't remember every tiny facet but hopefully you'd have a general idea. And above all that, if you're a senior dev then you'd understand that "this code is unfamiliar" does NOT mean "this code is bad." I mean really, "this code is unfamiliar therefore it's messy therefore we should rewrite it" is a flaming red flag. Chesterton's fence, people!
    - pjscott 7y ago
      One of my favorite things about comments in programming is that you can stick a label on that fence explaining why it's there. One of my biggest frustrations is that so many people don't bother, even when it would literally be just one little sentence.
      - thaumasiotes 7y ago
        > One of my favorite things about comments in programming is that you can stick a label on that fence explaining why it's there. This is routine for ordinary cultural practices as well. However, the common explanation for a given cultural practice usually has nothing to do with the actual reasons it might be a good idea.
  - jdsully 7y ago
    Here we get to the real heart of the problem. Engineers of all levels seem to default into “this code is shit - I could do better” instead of having some empathy and considering they don’t have the whole picture. But the wrong lesson seems to be taken away from this. It’s not that all code is shit - it’s that you aren’t good at reading the code yet if you can’t see all the little hairs and bug fixes.
- beat 7y ago
  Unknown unknowns. My coding style hasn't really changed in years - frankly, I don't write a lot of code, I do other things. But I often run into situations where I'm irritated at my own bad code from months earlier, when the shortcomings of the code are actually driven by things I know now that I didn't know then.
alexanderdmitri 7y ago
Review process surely mitigates differences between "junior" and "senior" code?
- Aeolun 7y ago
  Not really. It just ensures no really atrocious code makes it into master. Of course you can stall any junior merge request until it looks like senior code, but at that point you might as well write it yourself.
  - alexanderdmitri 7y ago
    I don't know if it's stalling so much as taking the time to request changes / pair up and teach. If bad code is getting merged, that's tech debt / time someone else is going to have to spend anyway, plus the time needed to identify the issue and triage down the line. I would think it's better investment to use that time up front and help the jumior level up too.
- AdamM12 7y ago
  This also would require that devs who are on the PR reviews ACTUALLY look at the code. In about every job I've worked at in my short career there are people I work with that I don't trust them to actually review my code. I've come to accept that. I instead make sure the people I know will do a decent job are on the PR. Some people will just look at the diff and an even smaller few will actually pull the branch locally so they can see the entire context. That being said I always do my best to review other peoples code regardless of whether or not they will review mine.

taneq 7y ago

> seniors [...] complain about the low quality of junior code [...] their own code from 6 months ago. What classes as 'senior' that their own coding style has changed that much in 6 months? O.o > I still do write "cool code", for code that I will only use myself that doesn't go into production. But for all others, I write easy-to-read code. Good dev. Remember, you are not your audience. Unless you're just writing play-code in which case go nuts and be as 'clever' as you want. :D > When comments have a typo that alter the meaning of the comment, I insist that be fixed. Juniors hate me for being too picky. Then they're wrong, and tbh that's not something I'd accept more than once from an employee.

tomsmeding 7y ago
> > seniors [...] complain about the low quality of junior code [...] their own code from 6 months ago. > What classes as 'senior' that their own coding style has changed that much in 6 months? O.o Your code style can remain exactly the same, and it would still happen. The reason is not that you would write the code differently today, but that you forgot the issues and edge cases that made you write it like that then, and that at the time you focused too much on the writing, not on the reading.
- taneq 7y ago
  ...you don't remember what you were doing 6 months ago? I'm sorry, that's still not a good excuse. Maybe you don't remember every tiny facet but hopefully you'd have a general idea. And above all that, if you're a senior dev then you'd understand that "this code is unfamiliar" does NOT mean "this code is bad." I mean really, "this code is unfamiliar therefore it's messy therefore we should rewrite it" is a flaming red flag. Chesterton's fence, people!
  - pjscott 7y ago
    One of my favorite things about comments in programming is that you can stick a label on that fence explaining why it's there. One of my biggest frustrations is that so many people don't bother, even when it would literally be just one little sentence.
    - thaumasiotes 7y ago
      > One of my favorite things about comments in programming is that you can stick a label on that fence explaining why it's there. This is routine for ordinary cultural practices as well. However, the common explanation for a given cultural practice usually has nothing to do with the actual reasons it might be a good idea.
- jdsully 7y ago
  Here we get to the real heart of the problem. Engineers of all levels seem to default into “this code is shit - I could do better” instead of having some empathy and considering they don’t have the whole picture. But the wrong lesson seems to be taken away from this. It’s not that all code is shit - it’s that you aren’t good at reading the code yet if you can’t see all the little hairs and bug fixes.
beat 7y ago
Unknown unknowns. My coding style hasn't really changed in years - frankly, I don't write a lot of code, I do other things. But I often run into situations where I'm irritated at my own bad code from months earlier, when the shortcomings of the code are actually driven by things I know now that I didn't know then.

alexanderdmitri 7y ago

Review process surely mitigates differences between "junior" and "senior" code?

Aeolun 7y ago
Not really. It just ensures no really atrocious code makes it into master. Of course you can stall any junior merge request until it looks like senior code, but at that point you might as well write it yourself.
- alexanderdmitri 7y ago
  I don't know if it's stalling so much as taking the time to request changes / pair up and teach. If bad code is getting merged, that's tech debt / time someone else is going to have to spend anyway, plus the time needed to identify the issue and triage down the line. I would think it's better investment to use that time up front and help the jumior level up too.
AdamM12 7y ago
This also would require that devs who are on the PR reviews ACTUALLY look at the code. In about every job I've worked at in my short career there are people I work with that I don't trust them to actually review my code. I've come to accept that. I instead make sure the people I know will do a decent job are on the PR. Some people will just look at the diff and an even smaller few will actually pull the branch locally so they can see the entire context. That being said I always do my best to review other peoples code regardless of whether or not they will review mine.