Comment by TruthWillHurt | Hacker News Reader

Comment by TruthWillHurt | Hacker News Reader

Parent Full thread

I had the same experience as you in your company B, and as someone with 20 yrs experience who worked for enterprise, but mostly joined/founded startups -

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.

Just setting up the machine can take 2 weeks.

And they are in their own echo-chamber, thinking every choice they made is the right one and must be used everywhere.

"What? you never used tool A? It's what we use everywhere". Well good for you! I used tool B, C, Z, X, A7, and forgot most of them. Don't give me these looks!

And of course, working in such conditions you can't improve. They exclude you from discussions, give bad looks and comments, and completely erode your confidence.

You might not be the best, but they are definitely worse.

> 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.

Reply on news.ycombinator.com