7 ms·

I feel that I made the transition from jr to mid level developer when I was able to come into some new code and judge it, instantly pointing out what was wrong

I feel that I made the transition from jr to mid level developer when I was able to come into some new code and judge it, instantly pointing out what was wrong and how it could be improved, and how it should've been built. I feel that I went from mid to senior when I would enter that same situation and try to understand the why behind the code (even though I probably still thought it was poorly architected) before passing judgement or trying to "fix" it with a refactor.

nostrademons 5y ago
You transition from senior to manager when you first try to understand the importance of the code to the business and whether anyone will ever touch it before bothering to understand the code.
- ThalesX 5y ago
  Your short comment really triggered my management PTSD. I wrote a huge ass post but decided to delete it and just summarize: * Senior tradesman -> manager is not a natural transition; * Senior tradesmen take business into account without needing to transition; * Both technical and business understandings are attributed to management while business is subtracted from senior tradesmen. Hilarious. I'm glad at one point in my life, I have the option to transition to this magical role where all of a sudden I will understand everything and even if the potential users of this potential idea might potentially touch the potential application. I wish I could have written a clearer statement instead of this empty half-rant, but as it stands, I am but a senior engineer so am forced to come to grips with my own limitations. If only I would transition... and after, maybe I'll naturally transition to president of everything.
  - thyrsus 5y ago
    Why does Dunning-Kruger come to mind?
    - CRConrad 5y ago
      On the part of the GP, or the management caste?
- dev_tty01 5y ago
  Senior developers are the ones who understand the code AND the business. One of their jobs is to keep managers from making stupid decisions that would harm the business. In many orgs, managers did NOT come from the ranks of senior developers.
ramoz 5y ago
A big jr->mid tell I look for is how I/a developer debugs.
fragmede 5y ago
Chesterton’s fence is the axiom for understanding the why of the system before refactoring.
- codeflo 5y ago
  The flip side of that is that refactoring can be a surprisingly effective tool for understanding.
  - hn_go_brrrrr 5y ago
    Sometimes by breaking prod. You learn what you didn't understand very quickly then.
    - sorokod 5y ago
      A non prod breaking scenario I have seen - only towards the end of a fairly long refactoring exercise, when tests for certain edge cases start failing, you finally understand the full purpose of the code you are refactoring.
      - hn_go_brrrrr 5y ago
        Not to fall into the obvious trope too much, but: Your legacy code has tests for edge cases? I'm happy when it has any tests. More often, it's untested and I write the tests myself before refactoring the implementation.
larusso 5y ago
I always get triggered when a new team member comes in and starts to rename variables in Pull requests and plans out huge refactorings. I‘m like ok you are five minutes into this code without any knowledge why it is shaped and named like this. Not that the person is or isn’t correct it is just how fast people are willing to change working software because they feel they can make it better in an instant. The second reason I get triggered is that I think it is quite rude to the programmers that came before. I have to swallow a lot of pride over the years because of course ones code isn’t without fault. But to point that out from a newbie in the team who maybe only want to proof that they can code? Super hard for me ;)
- wheybags 5y ago
  I actually think jumping straight in and refactoring is one of the best ways to learn a new codebase. If it's set up consensually and as a learning tool, the combo of refactoring + review from older team members is a great way to learn, even if your changes ultimately don't make it to prod.
  - disgruntledphd2 5y ago
    As long as you have decent test coverage, this is a brilliant idea. It's a terrible idea if you don't.
    - eptcyka 5y ago
      You can still do it without tests as long as you have a version control system that isn't absolute garbage.
      - disgruntledphd2 5y ago
        Can you? I would be incredibly nervous about breaking unknown stuff and it not getting noticed without tests. For context, I work predominantly with stats/DS problems, where errors may not actually cause obvious (or indeed any) warnings/errors.
jeffrallen 5y ago
You will become a master developer when you can explain why the thing never should have been made in the first place and then lead an effort to tear it out and throw it away. The best commits have more red than green.
- capableweb 5y ago
  You become a guru developer when you realise that judging any code based on any metric without knowing the full context is often misleading. Yes, in general removing code is good, but does that mean removing the full project and committing that is the best change you can do?
  - jeffrallen 5y ago
    You become a transcendental developer when you think "Bury it in the desert. Wear gloves." and are enlightened.
  - tryauuum 5y ago
    my system administrator background says yes, sometimes wiping the whole project is the best idea Imagine that you are developing a storage with an s3-compatible API for internal use. Maybe you should give up and install CEPH instead
    - capableweb 5y ago
      Imagine you're developing a storage with S3-compatible API that is meant for public consumption, but you don't actually have something to store. Then yeah, bad idea to write some sort of storage system. Point being, yes, of course you can come up with 1000s of examples where it's good/bad to delete all code. The point of my comment wasn't "It's never good to remove all code for a project" but rather "If this change is good or not depends on variables from outside the Git repository".
- H8crilA 5y ago
  The problem is that this is always, always harder to sell than a new feature/launch/whatever addition. You might be a master developer but you'll not be the highest paid / highest level.
avip 5y ago
Transition to TL: Gently explain what could have been improved instead of fixing it yourself.
- ThalesX 5y ago
  Transition to pro TL: keep the solution to yourself, let everyone speak and piggy back on a team member that comes close to yours without forcing. If no solution matches, also present yours with the added benefit of weighing the pros and cons of the ones before it.
noneeeed 5y ago
This is why I like to ask people to talk me through a change that I think I don't like, or might be wrong, before passing judgement. One of two things happens in the process of them explaining: - they know something about the context that I was unaware of or have an insight that I hadn't thought of and so I learn something and change my mind - they realise they've missed or misunderstood something, or were unaware of something which I can communicate to them, so they learn something and change their mind. Sometimes this can be as mundane as "this isn't idiomatic, we should prefer the community style. It's almost always a learning experience for one of us, frequently both. I've learnt a lot over the years of reviewing other people's code. In the cases where neither of these things happen it's because it's a question of personal taste, there's nothing wrong with the code, I just wouldn't have written it that way. In those cases I leave it alone.
- noneeeed 5y ago
  Hrrrm, so that comment was badly formatted for some reason, I think I should have put a blank line between the two cases in the second paragraph which should have been a two item list :/
zozbot234 5y ago
I thought the whole point of a true refactoring was that it should not lead to any changes in outwardly visible behavior. If you're changing what the code does, that should absolutely be pointed out, regardless of whether it's phrased as "clean up".

nostrademons 5y ago

You transition from senior to manager when you first try to understand the importance of the code to the business and whether anyone will ever touch it before bothering to understand the code.

ThalesX 5y ago
Your short comment really triggered my management PTSD. I wrote a huge ass post but decided to delete it and just summarize: * Senior tradesman -> manager is not a natural transition; * Senior tradesmen take business into account without needing to transition; * Both technical and business understandings are attributed to management while business is subtracted from senior tradesmen. Hilarious. I'm glad at one point in my life, I have the option to transition to this magical role where all of a sudden I will understand everything and even if the potential users of this potential idea might potentially touch the potential application. I wish I could have written a clearer statement instead of this empty half-rant, but as it stands, I am but a senior engineer so am forced to come to grips with my own limitations. If only I would transition... and after, maybe I'll naturally transition to president of everything.
- thyrsus 5y ago
  Why does Dunning-Kruger come to mind?
  - CRConrad 5y ago
    On the part of the GP, or the management caste?
dev_tty01 5y ago
Senior developers are the ones who understand the code AND the business. One of their jobs is to keep managers from making stupid decisions that would harm the business. In many orgs, managers did NOT come from the ranks of senior developers.

ramoz 5y ago

A big jr->mid tell I look for is how I/a developer debugs.

fragmede 5y ago

Chesterton’s fence is the axiom for understanding the why of the system before refactoring.

codeflo 5y ago
The flip side of that is that refactoring can be a surprisingly effective tool for understanding.
- hn_go_brrrrr 5y ago
  Sometimes by breaking prod. You learn what you didn't understand very quickly then.
  - sorokod 5y ago
    A non prod breaking scenario I have seen - only towards the end of a fairly long refactoring exercise, when tests for certain edge cases start failing, you finally understand the full purpose of the code you are refactoring.
    - hn_go_brrrrr 5y ago
      Not to fall into the obvious trope too much, but: Your legacy code has tests for edge cases? I'm happy when it has any tests. More often, it's untested and I write the tests myself before refactoring the implementation.

larusso 5y ago

I always get triggered when a new team member comes in and starts to rename variables in Pull requests and plans out huge refactorings. I‘m like ok you are five minutes into this code without any knowledge why it is shaped and named like this. Not that the person is or isn’t correct it is just how fast people are willing to change working software because they feel they can make it better in an instant. The second reason I get triggered is that I think it is quite rude to the programmers that came before. I have to swallow a lot of pride over the years because of course ones code isn’t without fault. But to point that out from a newbie in the team who maybe only want to proof that they can code? Super hard for me ;)

wheybags 5y ago
I actually think jumping straight in and refactoring is one of the best ways to learn a new codebase. If it's set up consensually and as a learning tool, the combo of refactoring + review from older team members is a great way to learn, even if your changes ultimately don't make it to prod.
- disgruntledphd2 5y ago
  As long as you have decent test coverage, this is a brilliant idea. It's a terrible idea if you don't.
  - eptcyka 5y ago
    You can still do it without tests as long as you have a version control system that isn't absolute garbage.
    - disgruntledphd2 5y ago
      Can you? I would be incredibly nervous about breaking unknown stuff and it not getting noticed without tests. For context, I work predominantly with stats/DS problems, where errors may not actually cause obvious (or indeed any) warnings/errors.

jeffrallen 5y ago

You will become a master developer when you can explain why the thing never should have been made in the first place and then lead an effort to tear it out and throw it away. The best commits have more red than green.

capableweb 5y ago
You become a guru developer when you realise that judging any code based on any metric without knowing the full context is often misleading. Yes, in general removing code is good, but does that mean removing the full project and committing that is the best change you can do?
- jeffrallen 5y ago
  You become a transcendental developer when you think "Bury it in the desert. Wear gloves." and are enlightened.
- tryauuum 5y ago
  my system administrator background says yes, sometimes wiping the whole project is the best idea Imagine that you are developing a storage with an s3-compatible API for internal use. Maybe you should give up and install CEPH instead
  - capableweb 5y ago
    Imagine you're developing a storage with S3-compatible API that is meant for public consumption, but you don't actually have something to store. Then yeah, bad idea to write some sort of storage system. Point being, yes, of course you can come up with 1000s of examples where it's good/bad to delete all code. The point of my comment wasn't "It's never good to remove all code for a project" but rather "If this change is good or not depends on variables from outside the Git repository".
H8crilA 5y ago
The problem is that this is always, always harder to sell than a new feature/launch/whatever addition. You might be a master developer but you'll not be the highest paid / highest level.

avip 5y ago

Transition to TL: Gently explain what could have been improved instead of fixing it yourself.

ThalesX 5y ago
Transition to pro TL: keep the solution to yourself, let everyone speak and piggy back on a team member that comes close to yours without forcing. If no solution matches, also present yours with the added benefit of weighing the pros and cons of the ones before it.

noneeeed 5y ago

This is why I like to ask people to talk me through a change that I think I don't like, or might be wrong, before passing judgement. One of two things happens in the process of them explaining: - they know something about the context that I was unaware of or have an insight that I hadn't thought of and so I learn something and change my mind - they realise they've missed or misunderstood something, or were unaware of something which I can communicate to them, so they learn something and change their mind. Sometimes this can be as mundane as "this isn't idiomatic, we should prefer the community style. It's almost always a learning experience for one of us, frequently both. I've learnt a lot over the years of reviewing other people's code. In the cases where neither of these things happen it's because it's a question of personal taste, there's nothing wrong with the code, I just wouldn't have written it that way. In those cases I leave it alone.

noneeeed 5y ago
Hrrrm, so that comment was badly formatted for some reason, I think I should have put a blank line between the two cases in the second paragraph which should have been a two item list :/

zozbot234 5y ago

I thought the whole point of a true refactoring was that it should not lead to any changes in outwardly visible behavior. If you're changing what the code does, that should absolutely be pointed out, regardless of whether it's phrased as "clean up".