11–20 of 66 posts
Personal anecdote: Started in a developer position a couple years ago to work on an internal corporate app on an isolated network. Week 1: Get to the desk; meet my neighbors; submit request for necessary network account; and start on mandatory security training for the systems. Week 2: Finish the mandatory training; ping the network owners a few times about the account request; start reading up on unfamiliar parts of…
Ultimately what it comes down to is that lazy engineers will be lazy and that motivated engineers won’t lose their spark just because they spent a week meeting the team. The author seems to think that the opposite is what takes place both counts. I don’t agree with that.
I once got told by a manager that they didn't expect new hires to make big contributions in the first year. That was after I complained I was feeling very unproductive and wanted some help to speed things up. I quit after a few months because the slowness of everything around me was making me depressed. This was at a top5 website company.
And that is how you burn out. In fact, exceeding expectations takes a lot of talent, because you need to exceed in the correct directions. And often, you burn out because of the lack of recognition. It’s a real talent that takes years to learn, not the kind of heroic behavior that someone should strive for in year 1. In year 1, just learn 3 frameworks at home and change jobs often ;)
About the intern: By the middle of the second month he settled down to developing the minimum features that satisfy a maximum of users, but polishing the bugs and buffing out the UX (first impression, etc) and that was awesome, by the third month he was productive at this and came back to school. Damn I didn’t notice he’d learnt so much, but totally outside of programming. I guess the lesson is programming is long if done correctly, don’t expect to do everything by tomorrow or you’ll risk lowering the quality.
Personal anecdote: Started in a developer position a couple years ago to work on an internal corporate app on an isolated network. Week 1: Get to the desk; meet my neighbors; submit request for necessary network account; and start on mandatory security training for the systems. Week 2: Finish the mandatory training; ping the network owners a few times about the account request; start reading up on unfamiliar parts of…
>It takes roughly 2 weeks to form a habit; it takes roughly two weeks to get comfortable in a new environment. A common mistake is to treat a new report’s first couple weeks like college orientation - social, light hearted, get-to-know-you stuff. If your report spends the first two weeks reading C# documentation and having lunch out on the town with the team, guess what, they’ve just normalized that behavior as what…
It can also be disappointing to go through a multi-week onboarding full of outings and lunches and fun activities, only to discover that the real job is nothing like the onboarding. Then you have to learn how to actually do the job after the onboarding.
IMO, the best onboarding strategies give the current employees and the new hire some room to get to know each other naturally, without forcing it into overly structured activities. For example, giving the whole team a budget to go out to a long lunch with the hire 3 days per week on the first 2 weeks.
Unless you have a team of lone-wolf type or antisocial developers, usually the person's peers have a better idea of how to onboard a person than a manager several steps removed. Or worse, a person in HR trying to imagine what a good onboarding activity looks like for engineers.
This article rings true, but I can't tell if it's a chicken or the egg problem. Are firms with long on boarding processes less effective because bad habits are setup and normalized at the start, or are they dysfunctional from the get go and dysfunctional teams setup poorly thought out onboarding processes. At a previous job at a large tech company I was given a period of ~6 weeks of onboarding. This was rather excess…
My favorite onboarding process was to simply give the person's team a budget to do whatever they wanted with the new hire for a day or two, then get to work. Managers would write up a document with all account info, login info, key communication info, and then let the teams fill the new person in on the day-to-day details while they went out to lunches or went go-karting or whatever they wanted.
The more HR tries to structure things, the less effective it becomes at onboarding people. Let the teams handle it and make them responsible for getting the person up to speed quickly. They're closest to the work, and therefore they know best what the person actually needs.
I think, as a senior embedded software engineer, the first couple weeks (months?) should be spent with the last new hire figuring out tools, processes, and keeping internal documentation up to date as you go. Questions should be escalated as necessary, but generally this should not involve much interaction with more senior engineers so their work is not interrupted. New hires should start out with big fixing tasks and not be expected to participate in architecture or feature creation yet. If they display the ability, fine, but set the bar low.
Some companies I've worked at have such complicated development workflows that it regularly takes 3 months for an engineer to become independently productive.