[HN Gopher] The Guide to Onboarding Software Engineers
___________________________________________________________________
The Guide to Onboarding Software Engineers
Author : ochronus
Score : 168 points
Date : 2022-03-26 10:58 UTC (12 hours ago)
(HTM) web link (leadership.garden)
(TXT) w3m dump (leadership.garden)
| throwaway984393 wrote:
| What kills me about engineering onboarding is how haphazard it
| always is. I don't think I've been in a single company where the
| company has cared about it enough to make sure there was _any_
| engineering onboarding process, much less a centrally-managed
| process. It 's always completely team-specific, so some teams
| have great onboarding and some have none.
|
| I just want a company to give a shit about its employees, y'know?
| It's the little things that make us feel appreciated. (Little
| things like "somebody telling us how to get work done in this
| company") It doesn't even have to be formal documentation if
| there's at least an introductory training that explains it.
| MattGaiser wrote:
| Given that different teams tend to work on different projects,
| can onboarding really be scaled across the company like that?
| Maybe the HR stuff, but your team might maintain a repo all on
| its own.
| throwaway984393 wrote:
| I think it's doable. Teams can keep setup instructions with
| their repos, and commonly repeated docs can be kept in one
| place and linked to. Each team can create one page that links
| to all their setup instructions, and each team manager can
| add their team's page to a single engineering page. Docs that
| are relevant to the entire engineering org need to be created
| by someone assigned by an engineering VP. If nobody tells
| people to do all of that, it doesn't get done.
| mattcwilson wrote:
| I think part of the issue here is "a company" isn't a
| particular human being or team that is specifically
| incentivized _to_ "give a shit about the employees."
|
| What this looks like from my vantage point is: anyone who is a
| director (manager-of-managers) or up is assuming that the line
| managers (managers-of-non-managers) has it taken care of -
| their team, their plan, and they can speak up if they need
| guidance.
|
| The line managers, OTOH, probably don't _individually_ onboard
| terribly frequently, even though _as a cohort_ it's probably
| constant. So the feedback loops / improvement cycles for _a
| given team_ are all slow, and there's no inherent incentive for
| those managers to try to boost the overall experience. Unless
| they're the sort to go "hey, maybe my peers know better plans,"
| they will all individually toil at this and create an overall
| sucky picture.
|
| Being perfectly honest, I was in that boat myself until this
| article appearing this morning prompted me to ask my fellow EMs
| what they're doing, and whether we could find a way to improve
| it overall.
|
| Even if we do though, it's still going to suffer from tragedy
| of the commons a bit, unless we deputize some "onboarding
| improvement" project team to actually drive towards a clearly
| stated objective.
|
| tl;dr - what feels like "this entire company doesn't give a
| shit about me" could just be "my manager is doing what they
| think is the best possible, given limited resources, and having
| little-to-no support or awareness from the rest of the
| organization - and that little bit just isn't enough for me to
| feel understood and cared for."
| ochronus wrote:
| This ^^ exactly my past experience.
| codr7 wrote:
| Now imagine pulling the same crap upstream, have your boss and
| his HR hangarounds click through hours of shitty made up or
| outdated intranet trivia about you and quiz them on it while
| leaving them hanging on the impact of the answers or the
| result.
|
| At least some aren't even pretending; what really rubs me
| sideways is when they pay lip service to caring _while_ wasting
| your time, makes me want to punch someone.
| hbarka wrote:
| Unfortunately what has been somewhat consistent for me during
| onboarding is that my manager did not bother to make sure I have
| the needed credentials and roles in advance. Days and weeks were
| wasted where I had to fend for myself, against NIMBYist "owners"
| of said systems who were more afraid than helpful. You question
| why you were hired. "You're a data _/ */*_? Oh I'm sorry I will
| just give you read-only access for now." "You need access to that
| system to analyze data? I'm sorry but the your mgr has to approve
| and then security director." "You're a senior *?" I'm sorry we
| require you to be part of the sprint team first before <make up
| some shit>". "Oh I should have added you to that <meeting/team
| folder/JIRA/Repo/DB/Cloud> but first let me give you some hurdles
| I can think of because you threaten my status."
|
| This is onboarding. Your manager can do a better job getting this
| taken care of in advance instead of leaving you to slog through.
| Run if you see this kind of culture.
| mattcwilson wrote:
| My experience as a manager has been frustratingly similar.
|
| For the same security and least-access reasons, I don't have a
| view into the systems permissions tables for all of the tools
| that my team uses. I also don't have a "definitely complete"
| list of what those tools even are, or what roles my current
| team members have in them.
|
| So when it comes to presenting IT with a new hire access
| request, often the best I can do is to say "please copy the
| access that person Y (another member of my team) has in system
| Z to a new account for person X"
|
| Because of audit regulations, I have to do this on a one-
| request-per-person-per-system basis. Bulk changes for a group
| of users, systems, or both are verboten.
|
| IMO, it feels like this is another area where no one is
| incentivized to own a holistic and efficient outcome. It's not
| _quite_ laziness, but it _is_ a mountain of tedious and error
| prone tape cutting, compounded by information changing rapidly
| underneath in a way opaque to the people closest to the issue.
|
| I suspect that this could be a lot better in a world where
| "default roles and system permissions for those roles" is a
| centralized and crowd-sourced document. Like a terraform
| config. And then any time access needs change in a non-one-off
| way, you could tf apply the new roles table out to all the
| systems. Such is my dream, anyway
| simonhamp wrote:
| Some really good reminders and pointers in here, especially
| making sure the new hire is given time - both in terms of
| allowing them time to get through things but also making sure
| that their manager and others have time available and set aside
| to help the newbie.
|
| So so critical.
|
| One other thing I would say though is to have them feel they can
| and do make a meaningful contribution right at the start by
| assigning a little task that will encourage and aid their
| learning where things are and how things are done
| ochronus wrote:
| That's a really good point! Thanks for calling it out
| chiefalchemist wrote:
| Early and easy milestones are - for me - a standard pattern for
| any effort. Let ppl loosen up. Touch their toes. Dust off their
| confidence. Survey the team. Etc.
|
| You don't see pro athletes run from the dressing room and start
| playing. There's a reason for this. One or two simple and easy
| X or Y goes along way.
| charles_f wrote:
| I really enjoyed the 30/90/150 days matrix oriented in goals. So
| far I've ever only seen this as a list of activities to be
| completed, but having it as goals makes it more useful I guess -
| you can self assess where you are, and adjust if coming the 30
| days mark you still feel like you don't understand x y or z
| [deleted]
| Arisaka1 wrote:
| I'll never forget the onboarding in my first job. It was almost
| perfect. Senior developers who knew how to communicate without
| making me feel like a toddler (in spite of the fact that I was),
| small tasks that helped both to build confidence and measure my
| comfort zone. All that on top of the fact that I worked fully
| remote.
|
| But my biggest issue was pairing me in the immediate visinity of
| another junior developer. Yes, rationally I understood perfectly
| that people can be different, and that someone may have more
| knowledge in a language or framework than me. Emotionally all I
| kept feeling was fear. Being unable to keep up with him, needing
| more time to complete my assigned tasks, him being more
| chill/casual with the lead devs while I'm hammered with my
| negative self-talk telling me that I waste their precious time
| and they're better off hiring someone else instead. And the worst
| part: Interpreting their positive feedback as professionalism.
| "Surely they don't really mean that, just look at me".
|
| Eventually I moved out of that team and got into another team
| where I'm the only junior developer, meaning that it's finally
| time for my self-talk to accept that I obviously cannot hold a
| candle compared to everyone else, and I can focus on learning the
| codebase and improving myself. Now my self-talk thinks that I got
| soft-booted out of the old team for being unable to keep up with
| the other junior developer.
|
| What I mean is, some problems can be so personal that you cannot
| help even if you do everything right.
| mattcwilson wrote:
| Thank you for sharing. That's helpful perspective for me, as a
| manager, to consider.
|
| One thing I try very hard to do for my new onboarders is to
| establish trust and open dialogue with them, as quickly as I
| can, to make it easier for personal concerns to surface. And
| then listen to those concerns in full sincerity and confidence.
|
| Do you think having something like that established would help?
| If you had any feedback for how your manager may have helped
| further, what would you tell them?
| digisign wrote:
| These kinds of negative thoughts are never helpful. We're all
| learning constantly and had to be the newbie at one time. Push
| them out of your mind.
|
| I will let you in on one superpower that I was lucky to learn
| early... read the manuals, yes _the manuals_ to your most
| important tools and practice. All of them, front to back. Very
| few people are willing to do this for whatever reason. Result
| being even if you don 't know how to do something exactly
| you'll be able to look it up in seconds and knock it out in
| minutes.
|
| Using this strategy, at one job I went from nobody to "god-
| like" (haha) guru-in-demand simply from reading the manual
| front-to-back for the Unix Shell we used... in the span of
| about two months. The resulting scripts I wrote automated about
| 50% of our team's work to single commands, which was greatly
| appreciated.
| knightofmars wrote:
| This! Reading in general manifests to others as if you have
| superpowers at times. Whitepapers, RFCs, manuals, API docs,
| regulations, devour them all and the doors will open so fast
| it will make your head spin. General advice to all, don't get
| bogged down thinking you need to memorize every algorithm and
| data structure to be a great programmer. It's more about
| understanding the domain you work in and knowing how to
| "stand on the shoulders of giants" within that domain.
| picture_view wrote:
| In my first dev job I was hired as 1 in a pair of jrs to start
| at the same time on the same team. We never got along. After
| about a year I was promoted and the other person was let go for
| performance reasons.
|
| I never really put myself in the other jr's shoes so thanks for
| sharing your story. At the time I was pretty intimidated by her
| and all the other engineers, I can only assume it was much
| worse for her.
|
| In retrospect it was obviously a bad idea to hire 2 jrs at
| once. It was a small company (~10 engineers) and we were their
| first jr hires. I think the company thought that it would
| foster camaraderie and a little healthy competition, but I
| think most jrs have too much impostor syndrome for that to work
| out.
|
| On a side note I think they did have a good onboarding program
| for new developers. Outside of normal jr level tasks it was
| roughly 50% technical support: talking to customers, collecting
| bug reports, reproing bugs, then finding the right engineer to
| fix them. Over time I started diving into the code myself to
| see if I could find what was breaking, then eventually putting
| up fixes myself. It was a good way to contribute real value to
| the company while learning how a codebase works.
| pc86 wrote:
| I have such mixed feelings about healthy competition in this
| context. _I_ really enjoy it. If I do something a little more
| performant, or a little faster, I feel good. If I don 't, I
| legitimately look forward to learning what I could have done
| better (sometimes it's just "be faster" and there's not much
| you can do in that respect). But honestly I think I'm in the
| minority in that aspect. I enjoy doing LeetCode even though
| I'm not particularly good at it (50/50 shot at solving a
| medium on the first couple tries, at best). But I know a lot
| of people who are great developers that would crack if they
| thought they were constantly being compared to someone else,
| and these are people with the benefit of a decade+ of
| experience.
| [deleted]
| jrochkind1 wrote:
| I have to admit I don't love pairing at all as a way of
| working, but I have to grudgingly admit it has a lot of value
| -- when pairing a senior and junior, it's the most effective
| way of knowledge transfer and skill building in the junior.
|
| I don't understand why you'd do pair programming with two new
| hires!
| wreath wrote:
| > I don't understand why you'd do pair programming with two
| new hires!
|
| I don't know or think if it's the most effective way but it
| sure did help me build confidence approaching a large and old
| codebase with another new hire. I saw I wasn't the only one
| struggling and we were helping each other out. Maybe I just
| clicked with the fella, because we ended up having a great
| work relationship building awesome shit and friendship too. I
| dunno, maybe it was effective after all.
| jrochkind1 wrote:
| That does make sense!
|
| Really it seems like the best way to do pairing is to
| switch up who's pairing with who often, not stick people
| together permanently. Because there are different
| advantages to different pairings. And an advantage to the
| act of switching it up itself, of developing common shared
| knowledge across the whole field.
| wilmoore wrote:
| > I don't understand why you'd do pair programming with two
| new hires!
|
| There's nothing wrong with two new hires pairing. A few
| things a pair could be doing while the other is writing code:
|
| 1. Spike out a refactor of the current viewable block of code
| that the other pair just wrote or is currently writing.
| Looking at it as a spike instead of a hard refactor allows a
| pair partner to experiment and if the spike doesn't result in
| something better, throw it away; no harm done.
|
| 2. Jump ahead and spike out a function that the pair might
| need soon, but isn't ready to consume yet.
|
| 3. Watch for pair getting stuck and help them think. Ask
| questions like ... are you stuck or just taking a mental
| break? That's a helpful question because it makes them more
| comfortable taking mental breaks when they need one without
| fear that you're judging them.
|
| Keep in mind, pairing is AMAZING when deployed with empathy
| and less judgement. For those that feel like they are being
| judged when pairing is likely because you are a bit
| judgmental when the shoe is on the other foot.
|
| FYI, teams that pair daily, get more done and team members
| feel less lonely and more like a real team. Go Warriors.
| quadrifoliate wrote:
| This 13-step, 150-day program that offloads responsibility on the
| engineer instead of the team that's accepting them is a tired
| repetition of the trope that makes the onboarding person
| miserable. The graphics look good on the webpage, but a practical
| result of this running helter-skelter and trying to check things
| off the 457-line Google Sheet with mismatched fonts that they
| have been given.
|
| It doesn't work. This means you don't have a process, and are
| making the new employee (who is happy to have a job, and doesn't
| want to offend) often work extra hours to compensate for your
| lack of knowing how to onboard.
|
| Here's my alternative 2 cents - actively build in-house software
| for this. There is a lot of room for what the software can do
| since it interacts with your systems - it should be, for
| instance, possible to write a playbook that simulates an
| interaction with a copy of production data, so you can see real-
| world use cases that you will be working to address. Construct a
| set of coherent steps for how your new employees will learn, and
| _enforce those in software_.
| mattcwilson wrote:
| Sounds legit. Do you have a more detailed writeup of how to go
| about this? Not just from a technical standpoint, but how to
| campaign with stakeholders that the value is there, that it's a
| good use of team time? And how to campaign with the team to buy
| them in on establishing and maintaining this onboarding
| software?
|
| One of the practical realities I face often in management is
| that a weak-but-available solution is at least progress, where
| big ideas without a clear plan suffer heavy inertia.
| stjohnswarts wrote:
| The right way is to have them mentor with someone even if that
| slows down the mentor (and it will). Don't assign them to a
| curmudgeon either. If you don't have the "manpower" then just
| let them have a couple of months to adjust (assuming they're
| really hired on and not a consultant) and take it all in,
| they're already stressed and tacking on a thousand (paper cuts)
| points of improvement is going to make them feel awful.
| chihuahua wrote:
| I'm currently having an "interesting" time onboarding at a new
| job. I got to pick the team after being hired, and yet it's the
| worst experience of my 24-year career in software development.
|
| The manager is the nicest person I've ever worked with. But my
| "onboarding buddy" is the most obnoxious, difficult person I've
| ever worked with. At this company, the manager's role is much
| less technical than what I'm used to, so the manager ends up not
| making much of a difference in practical terms.
|
| I feel like a complete idiot every day. Whenever I ask anyone on
| the team a question, I get an answer that only makes sense to
| someone who's been working there for 5 years. Every time I say "I
| don't understand, can you please explain what that means," I get
| another answer that assumes I've been working there for 5 years.
|
| Last week (after 3 months) I reached the point where I knew it
| was time to pull the plug and switch to a different team.
|
| The company has extremely complicated onboarding tools and
| timelines, which are filled with over 100 tasks, which are about
| 99% irrelevant (and non-technical). It's a giant list of things
| to check off, but it's so overwhelming and complex that it's
| useless.
| icedchai wrote:
| It's rare that you get a technical manager in a large company.
| It's fine for HR-ish stuff, but if they do anything technical,
| like enter a Jira ticket, it creates problems. Detail is often
| lacking. This is one of the reasons I prefer smaller firms.
| mattcwilson wrote:
| This was the onboarding program that we had had and I'm trying
| to devise a replacement for. Because yeah, it sucked as both an
| experience and also in terms of effectiveness.
|
| What I'm doing now is a weekly series of recorded hands-
| on/whiteboard sessions, building up from the 10,000 foot view
| of the software (the most fundamental user journey) and working
| piece by piece towards the details. And I'm letting the
| onboarders steer the agenda - they tell me what they're ready
| for next, a few days ahead, and I pull the
| diagrams/exercises/links/docs ahead and then just kinda wing
| it.
|
| It's _more_ effective, and enjoyable, as far as I can tell.
| It's probably not paced as ideally as it could be, but as a
| manager I have likited time to give to something like this.
| We're getting to the point where I think some of the veteran
| engineers could take slices and host the discussion. And the
| recordings will hopefully act as an accelerator for the next
| batch of newbies.
|
| I still feel like there's a lot better a resources and time
| strapped manager could do.
| digisign wrote:
| One smaller thing I liked in my career was a job where each new
| hire was given charge of updating, improving, and editing the
| "new hire" wiki, which was started by the old hands.
|
| It included a brief history of the system, glossary, tutorial,
| reference links, etc. New hires are expected to ask questions and
| improve/update it as they go along.
|
| Pretty darn useful. Meant most boring, repetitive questions were
| quickly answered from "cache."
| JohnCClarke wrote:
| +1 for this!
|
| I've always done this with my teams. And the latest hire
| becomes the "onboarding buddy" for the next, so they know they
| need to understand/update the documentation.
|
| Also, it's really useful to keep a backlog of simple "technical
| debt" type tasks so that the new starters have something real,
| but manageable, to work on as soon as they arrive.
| digisign wrote:
| More good ideas. These allow the interesting questions to
| float up naturally for the experienced folks to answer, so
| they not only tolerate answering, but actually enjoy it.
| jedinix wrote:
| At my first job out of college, I volunteered to put together a
| formal training program for new hires. I did so because my
| onboarding was an unorganized disaster, and I (somewhat naively)
| thought I could spare future new hires the same experience.
|
| A couple of lessons I learned:
|
| 1. You need clearly defined processes and documentation. If you
| can't clearly define your processes, you can't expect a new hire
| to learn them. And if you have nothing written down anywhere,
| your new hires are going to be perpetually lost.
|
| 2. You need buy-in from the team, especially managers/leads. It
| takes time to define processes and write documentation. And it
| takes time to actually onboard and train a new hire. Managers
| should recognize this and ensure these responsibilities are
| distributed across the team.
| chiefalchemist wrote:
| I wish more companies understood that their problem with "The
| Great Resignation" is (often but not always) rooted in (in their
| shite approach to) onboarding.
|
| If you hire open minded, qualified, and "free thinking" people
| but don't spend the time to get them to believe in your "product"
| (i.e., organization) then just like any other sane and self-
| respecting customer, they will look elsewhere.
|
| Why? Because they can.
|
| And these orgs not realizing most of what they have left is
| "can'ts"...well the cycle will just continue. Text book insanity.
| scarface74 wrote:
| I have two recent perspectives about onboarding.
|
| 2018 - the company eventually grew to 60 people before getting
| acquired for 10x revenue. I was the then new CTOs 3rd technical
| hire and the fifth technical person overall. He was bringing
| engineering in house. They were using an outsourcing company at
| first.
|
| I onboarded myself, I scheduled a meeting with sales and the
| product owner and asked them questions as if I were a customer.
|
| The CTO gave me a small project and I reached out to people when
| I had issues. It was much better than getting a brain dump. I
| learn a lot more by struggling through releasing a feature.
|
| On the other hand, my next company was BigTech where there are
| standard corporate, division, subdivision and team specific
| onboarding.
|
| They were both appropriate for the maturity of the company. But
| even in the latter case, I learned by struggling through a
| feature as part of my onboarding.
| pards wrote:
| Here's a few things that I've found to work well
|
| 1. Onboarding docs - this is a working document on our wiki that
| describes the step-by-step process to getting a new laptop ready
| for development, including repos, tools, configs etc. Each new
| joiner is responsible to update the doc as they work through it
| to clarify unclear items, or add/update/remove out-of-date
| instructions
|
| 2. Onboarding buddy - this person is there to answer any
| questions related to onboarding, as well as helping the new
| joiner to navigate the organisation and get to know who's who.
|
| I like the idea of regular touchpoints with expected milestones,
| too. I might try that.
| synergy20 wrote:
| yes, an updated doc with a onboarding buddy is the way to
| go,been there done that and it worked out well.
| mgaunard wrote:
| The quality of the onboarding is directly influenced by the
| quality of your processes.
|
| New people might struggle during onboarding because they find the
| processes unpractical. You can try to force them to learn your
| workflow, or you can listen and use it as an opportunity to
| improve the way you do things.
| codr7 wrote:
| I've tried to intentionally use my fresh perspective in
| constructive ways when in that position, but improving the
| process is unfortunately rarely a corporate goal so it's mostly
| rowing upstream so far.
|
| The way a company reacts to thoughtful observations about their
| process says a lot about how they view their employees.
___________________________________________________________________
(page generated 2022-03-26 23:01 UTC)