Comment by sverhagen | Hacker News Reader

Comment by sverhagen | Hacker News Reader

Parent Full thread

Like you say, they left after a year. Maybe they really tried to make it work, and now, in retrospect, can see the red flags. And yeah, they're being blunt about it now. But in the moment they may have done a decent enough effort.

Myself, I am very "getting my hands dirty"-oriented, and the corporate onboarding goes over very poorly with me too. Sit through multiple days of material that is dumbed down to the company's lowest common denominator. Having to be giddy with other new hires in departments that you will never have any interaction with anymore. Kill me now. So, if the trainers just go through the motions, why wouldn't the original poster and I just put in the mere minimum to get through it, and start my real job...?

Oh, my real job... in the cafetaria with no desk? So, sure, the manager can forget to put the request in. But would a manager not know that you start, schedule a welcome meeting with you on the first day, touch base a few times in your first week? Plenty of chances, still no desk! It's ridiculous, but I am not surprised. If you don't think that is ridiculous, then, I don't know, maybe you've been conditioned to that sort of environment. With no snark I wish you much joy in your employment there, but then please let the original poster and myself move on^H^H^H^H^H^H^Hrun for the hills.

Here's what onboarding should look like for an Engineering role: you come in at 9:00, do the bare minimum with HR, meet your team, set up your computer, and before the end of your first day, you have your first code changes in production. Then you go home with a feeling of accomplishment. Then, during the rest of the week, some onboarding meetings will happen, but at least you have started with the most important place: your team.

> Here's what onboarding should look like for an Engineering role: you come in at 9:00, do the bare minimum with HR, meet your team, set up your computer, and before the end of your first day, you have your first code changes in production. Then you go home with a feeling of accomplishment. Then, during the rest of the week, some onboarding meetings will happen, but at least you have started with the most important place: your team.

That pretty much describes my department, for the 25 years I ran it.

Of course, it was a fairly small team of experienced, high-functioning, engineers, so I doubt it represented the “industry standard” shop. We hired people with many years of experience, and I found it productive to let each one have a great deal of agency and control of their development environment.

> before the end of your first day, you have your first code changes in production.

Like adding yourself to a maintainer list or some prepared token handholding task? Or what could you possibly do in the first day before having the time to read the code.

At an early startup I worked at (about 10 years ago), it was fixing a small bug. You updated a couple lines of code and got familiar with the deploy process.

Yeah, their statement about expecting to push changes to prod on day 1 is hilariously unrealistic. The sense of entitlement is strong in this one. Glad we don't hire people like this.

Depends on how large your app/org/process is. I have worked in places where it would be expected (6 people org), and absolutely laughable (10k+), not least of which is that any release takes at least two months in the first place.

we have our new engineers update the “our team” wall of faces with their photo on day 1 in prod. Not sure why that’s unrealistic if your deploy process doesn’t suck?

Good lord, why do people have team walls with pictures at all? I've seen it a lot and never understood why, but since you seem to be an advocate for it, I'll ask why my picture matters.

I don’t know why, I don’t have an opinion on it, it’s just something we have done.

My point was only that pushing (any) code to prod on day 1 doesn’t have to be an entitled fantasy.

Oh, yes. You can push some small predetermined change like that through, or something else that doesn't require codebase knowledge. Although that is a thinly veiled test of your knowledge of the build process, in the same way "find a dog" is a made up thing to do for an internal directory tool.

OK there's a lot of good points on both sides of this. For one: pushing meaningful code change on day 1 may be unrealistic. For another: at least we've initiated the new team member into the full process of contributing to the product's code base, and their manager knows there are no administrative blockers (workstation, account, 2FA token, etc.). I know which I prefer. Also fixing a small (and admittedly probably low priority) defect is an achievable goal and a pretty cool way to get your toes wet. At least you're in the pool.

It's one step in building personal connections with your co-workers. It's one thing to get into a fight with somebody who is only a username on your screen. It's very different if you get to know your co-workers, understand how they think, how they work, what their culture is, their way of expressing things. Seeing a face is one of the first steps in this process.

Much of the online ranting (and frankly, hate), including in this thread, would be avoided if people would just spend some time getting to know the human beings behind the text on their screen. The very thing that has been called "infantilizing" somewhere else in this thread.

I think Facebook and the various other forums that attempted a realname policy disprove your claim that civility is connected to real world identity.

I do agree that meeting your coworkers and talking to them can indeed have very beneficial effects. I just don't see how a picture of a face helps that in any way. That's the connection that just doesn't seem to exist. It seems like people who want video on on Zoom calls. There are very few cases where that's a bonus.

And yes, I agree that the people who called getting to know their peers via an onboarding process that was probably somewhat corny "infantilizing" seem way offbase.

I worked in a place where it happened. If you dismiss that, it speaks to your experiences, not to mine. In my current job, it's not quite possible, the developer setup just isn't as mature yet, and it takes a few days. But at least I can aspire to do better. Of course, on your first day, you don't implement a new feature, but a small, well selected bug fix with a clear suggestion of how to fix it already contained in the ticket, is still possible. Also, of course, if you have a 2-month release cycle, it also doesn't work, so this story is from a team with a working Continuous Delivery practice.

Reply on news.ycombinator.com