In an ideal world, I completely agree with you, and that is how everything should work.
I can say, both from my experience consulting, and through helping friends enter the industry recently, that we don't live in that world. Not everywhere, at any rate.
Boeing didn't need experienced developers, because their codebase was so mature...
(not a joke).
Some too-big-to-fail consultancies start by signing contracts, and only interviewing to hire after the ink is dry.
And not just for general consumer websites and admin panels, but for anything else they can put programmers on.
Even if a company wanted to do the right thing, if they were entering a new space (let’s stick to pacemakers, just as an example), they have a bunch of devs that have a bunch of experience with high-level hardware, say...
...but none of them have any experience with medical devices, regulated devices, or mission/life-critical devices.
These people not only can't ask each other for code reviews, they don't even have enough knowledge and experience to hire the correct person to be able to do so.
And the management might assume everything is fine, because the regulators will make sure it's safe... in a lot of industries, though, regulators just check your documentation and approve things based on how similar they are to things that have been done before. Rather than being the pinnacle of excellence in that domain, they likely don't have any hands-on software/hardware experience in it (again, see Boeing).
And so it is, when you have consultancies asked to come in and be experts at something they are good at, but touching some completely novel domain...
...or when you have expanded too quickly, with a lot of new developers, in a tricky domain, and have also burned out (or laid off) your experienced developers, so nobody is left to course correct. Or the ones left are unfortunately antisocial or overwhelmed.
Also, given recent events, there is a lot of competition for a reduced number of roles. At least around here, and so a lot of people are being asked to take a lot of responsibility with no safety net (because there is none the employer is willing to give). Much of me wants to say "just let it fail and they’ll learn their lesson”. And then the other part of me thinks about what that means for planes and pacemakers.
Not suggesting any of this is good, or right. But it's also not a solved problem.
@seanmay
(I couldn't reply directly to you due to threading in dev.to)...
These people not only can't ask each other for code reviews, they don't even have enough knowledge and experience to hire the correct person to be able to do so.
I work in a heavily regulated environment - to be able to conduct a sensible code review, you don't need specialists - you just need people that will be honest.
I'm the most senior person on my team, in many ways (length of time for the company, length of time in the language, most responsibility yadda yadda yadda). I'm not, however, infallible. I'll happily have anyone that can just about read the language and still has warm blood critique my code.
End of the day, if a senior looks & spots a bug, great. If a brand-new-first-week-on-the-job junior looks at my code & doesn't understand what it's doing, I've done something very wrong & it needs re-work. I want them to tell me they don't understand, so I can re-write it and I can help mentor them if that's appropriate. Or they should be questioning me on why I implemented the way I did.
If the same junior reads the ticket I'm working on, and doesn't understand it, then we all did something wrong during Sprint Planning, because we accepted a ticket that couldn't be "picked up by anyone" (caveat, if all they need is a domain specific dictionary, that's fine).
To go back to your medical analogy for a moment - I'm perhaps a little strange. A while ago, I went into hospital for a scan on my shoulder. Being that there's nothing particularly hard for the CT to see, they had to inject dye. Right into the middle of my shoulder. They had a student doctor on duty, and asked if I minded. Before I replied, she said she'd not done this exact procedure herself before. "Sure, you've got to start somewhere... if you're confident enough to give it a crack, get on with it."
25mins later (for a relatively straight forward injection) she's still poking my shoulder & rummaging around. Then she says that she needs to go get someone else, because this isn't working the way she expected. More experienced doctor comes in, 30 seconds later, job done.
She couldn't apologise enough, but as I see it, she was a junior trying her best, and she asked for a peer review so she could learn. Can't ask for much better than that, and I'm sure she won't want to make the same mistake in future. (turns out, I have a misaligned A/C joint)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
In an ideal world, I completely agree with you, and that is how everything should work.
I can say, both from my experience consulting, and through helping friends enter the industry recently, that we don't live in that world. Not everywhere, at any rate.
Boeing didn't need experienced developers, because their codebase was so mature...
(not a joke).
Some too-big-to-fail consultancies start by signing contracts, and only interviewing to hire after the ink is dry.
And not just for general consumer websites and admin panels, but for anything else they can put programmers on.
Even if a company wanted to do the right thing, if they were entering a new space (let’s stick to pacemakers, just as an example), they have a bunch of devs that have a bunch of experience with high-level hardware, say...
...but none of them have any experience with medical devices, regulated devices, or mission/life-critical devices.
These people not only can't ask each other for code reviews, they don't even have enough knowledge and experience to hire the correct person to be able to do so.
And the management might assume everything is fine, because the regulators will make sure it's safe... in a lot of industries, though, regulators just check your documentation and approve things based on how similar they are to things that have been done before. Rather than being the pinnacle of excellence in that domain, they likely don't have any hands-on software/hardware experience in it (again, see Boeing).
And so it is, when you have consultancies asked to come in and be experts at something they are good at, but touching some completely novel domain...
...or when you have expanded too quickly, with a lot of new developers, in a tricky domain, and have also burned out (or laid off) your experienced developers, so nobody is left to course correct. Or the ones left are unfortunately antisocial or overwhelmed.
Also, given recent events, there is a lot of competition for a reduced number of roles. At least around here, and so a lot of people are being asked to take a lot of responsibility with no safety net (because there is none the employer is willing to give). Much of me wants to say "just let it fail and they’ll learn their lesson”. And then the other part of me thinks about what that means for planes and pacemakers.
Not suggesting any of this is good, or right. But it's also not a solved problem.
Thanks for such a lengthy response. I liked both the original article and your article!
@seanmay (I couldn't reply directly to you due to threading in dev.to)...
I work in a heavily regulated environment - to be able to conduct a sensible code review, you don't need specialists - you just need people that will be honest.
I'm the most senior person on my team, in many ways (length of time for the company, length of time in the language, most responsibility yadda yadda yadda). I'm not, however, infallible. I'll happily have anyone that can just about read the language and still has warm blood critique my code.
End of the day, if a senior looks & spots a bug, great. If a brand-new-first-week-on-the-job junior looks at my code & doesn't understand what it's doing, I've done something very wrong & it needs re-work. I want them to tell me they don't understand, so I can re-write it and I can help mentor them if that's appropriate. Or they should be questioning me on why I implemented the way I did.
If the same junior reads the ticket I'm working on, and doesn't understand it, then we all did something wrong during Sprint Planning, because we accepted a ticket that couldn't be "picked up by anyone" (caveat, if all they need is a domain specific dictionary, that's fine).
To go back to your medical analogy for a moment - I'm perhaps a little strange. A while ago, I went into hospital for a scan on my shoulder. Being that there's nothing particularly hard for the CT to see, they had to inject dye. Right into the middle of my shoulder. They had a student doctor on duty, and asked if I minded. Before I replied, she said she'd not done this exact procedure herself before. "Sure, you've got to start somewhere... if you're confident enough to give it a crack, get on with it."
25mins later (for a relatively straight forward injection) she's still poking my shoulder & rummaging around. Then she says that she needs to go get someone else, because this isn't working the way she expected. More experienced doctor comes in, 30 seconds later, job done.
She couldn't apologise enough, but as I see it, she was a junior trying her best, and she asked for a peer review so she could learn. Can't ask for much better than that, and I'm sure she won't want to make the same mistake in future. (turns out, I have a misaligned A/C joint)