> Expecting someone to contribute day1 is bad mentality, proof of bad management. Bad CTOs and Tech Leads can't understand that they hold knowledge of years building the code estate (while often skipping documenting it), which is difficult for newcomers to accuire.
Getting up to speed quickly in that sort of situation can be difficult, but it's not impossible. However it's a skill that requires development just like any other. If you've never done it before you will likely struggle the first few times, but get better over time. I don't agree this is _just_ bad management... but rather a mixture of that and just misaligned expectations and background. It could certainly have been handled better, but saying that expecting a quick ramp up is proof of bad management is a bit too far in my mind.
There's no such thing as developing the skill to install / configure misc undocumented services, requirements, etc. "Oh, you have to set xyz environment variable in dev for this db to work", "Yeah, the documentation for that was before we migrated to typescript", etc. If you expect new team members to contribute it is your responsibility to give them a functioning environment.
There absolutely is. This is a skill i take pride in - being able to run into a random failure and dig through logs, exceptions, code etc. to figure out what is missing.
Being able to quickly understand and debug a large vertical slice of a system across many layers like that without docs or handholding is really valuable in a broad SRE/production engineering type role or a do everything early engineer type role when docs/handholding are in short supply.
Not to say you have to have it. Many engineers are bad at this but way better at consistently putting out solid bug-free code quickly than me and thats a huge chunk of engineering as well.
But it is a learnable skill. 90% is honestly just reading errors carefully, googling them and following the trail but many people have sort of a panic/ignore response when a weird looking error messsage comes up somewhere and interrupts the flow.
> This is a skill i take pride in - being able to run into a random failure and dig through logs, exceptions, code etc. to figure out what is missing.
And your manager wanders over and sees you haven’t written a single line of code in the last three hours and makes a mental note that you might need a kick in the pants to get up to speed.
I’m pretty good at hunting bugs but once in a while I just can’t figure out why something isn’t working and if I had to worry about being “that guy” because I had to ask for help I’d…well, things would go really bad really fast.
Assuming the OP didn’t overly exaggerate their skill set to get the job that place sounds like a nightmare to work at.
I don't know why you feel the need to shit on my calling it a skill. Yes asking for help is important too when you don't need to do this, particularly as a junior. But some times you are the guy who others come to asking to for help and are the one who has to figure it out.
For sure this is a learnable skill.
I made Linux packages for open source projects that were not my own, and definitely learned a lot about this. If anyone wants practice today, go set up a bunch of random GitHub projects.
Getting up to speed quickly in that sort of situation can be difficult, but it's not impossible. However it's a skill that requires development just like any other. If you've never done it before you will likely struggle the first few times, but get better over time. I don't agree this is _just_ bad management... but rather a mixture of that and just misaligned expectations and background. It could certainly have been handled better, but saying that expecting a quick ramp up is proof of bad management is a bit too far in my mind.