Onboarding, Technical Debt and The Future Self

Any organizational leader is always challenged by the ability to quickly get new engineers active and effective as they join the company.  This is commonly called “onboarding”.  Common approaches include

  • Boot Camps similar to Facebook,
  • Intern style mini-projects
  • The dreaded fix-a-few-bugs in the first week
  •  The sink or swim, here is your desk, hit the ground running

All of these approaches (except the last one) attempt to

  • Familiarize a developer with the code base
  • Do generally low-risk changes and get the code into mainline or production
  • Start to understand the systems and tools that the team uses

Generally, the stated intent of on-boarding an engineer is to bring them up to speed and be productive.  In this post, I’d like to turn this on it’s head and ask the industry to not look at the onboarding process as a way to get an engineer started, but rather a way that the existing engineering team showcases the code, the architecture, the behavioral norms and the vibe of the engineering team.

I’ll lean on the analogy of an rich elderly aunt visiting from out of town throughout this post.  The onboarding process is like that awkward first few minutes where you walk through the house showing the washroom, kitchen, where they are sleeping and other items that are needed to make the stay welcoming.  However that five minute tour is usually at the end of a few days of frantic cleaning, scrubbing, removing trash, setting rules for how the kids should act, and so on.  After all your familial reputation is on the line here.  Who want’s an awkward Thanksgiving or Christmas where there are the little comments, the glances and whispering from the aunt who has formed her opinion of  how you operate as a family.

When a new engineer arrives at a company, the deepest scrubbing we usually do is to make sure their desk is clean and the computer is there.  It leads to an awkward recruiting moments when the reputation of the company is passed on to other engineers as the new engineer is asked ‘How’s the new Job’.  In the same way the elderly aunt is associated, but not vested with you. So is the the new employee who hasn’t quite felt part of the team.

Inverting Onboarding

Turning the onboarding process on it’s head also has some material impact on the way the engineering team see’s itself.   When you have a visiting relative, you want to show that you are a the good part of the family, and have your things in order.  Use the onboarding experience as a way to ensure that the team presents a real demonstration of how the team is awesome.  You can’t fake awesome for very long.

Make your leaders of the organization accountable for how the team is presented to the new hire.  Make those leaders ensure that the 2-4 week honeymoon period for the new hire sets the basis for a long term relationship.    The discussion shouldn’t be whether an engineer is now productive for the company, it should be whether the company has made an engineer productive.

That inversion goes a long way to extend that honeymoon from a few weeks to a few year.  That inversion helps engender an organization that fosters growth and development during an engineer’s tenure.  That inversion changes the way the organizational leaders look at how they run the organization.

Make Your Leaders Accountable for Onboarding

The critical part of this inverted view of onboarding is making the leaders of your engineering team responsible and accountable for the onboarding of the engineering team.  Some indicators of issues to consider when examining the onboarding  process.

  • Can the new engineer checkout and build with no major hiccups?  Typically there is a verbal tradition that carries engineers from the written references to being productive.  (“Oh yeah, you need to this or that, we should update that”).
  • Does the new engineer need to talk to other engineers for a basic bootstrap of their environment?
  • Does the new engineer need things explained on a whiteboard?

Realistically, the new engineer doesn’t have the ability to influence how quickly they come up to speed.  There will be an intrinsic ability that the new hire carries, but the largest influence of how the new hire onboards is carried by the organization.

By making the hiring manager and their lead engineers responsible for the effectiveness of the new engineer, it forces introspection on the team about how they manage their development how much of the way the team operates is transparent, captured, and communicable and how much is opaque and a form of verbal tradition.

Some measures that I push my teams to meet for a new dev are:

  • After the initial orientation and first login, be able to sync the code and start a build within 1 hour.  (This forces the hiring manager to ensure the permission groups, environments and access is all done before the hire starts.)
  • Have the engineer be involved in a code review within the first day, but before their first change. (This sets the bar for how the code reviews operate and the expected conduct for the engineers on the team).
  • Have a problem or proving task able to be resolved and pushed to a staging environment, device, into a build within the first day. (This drives an understanding of the way the development goes from the developer to production).
  • Have a debrief after the first day and the first week about the questions, points of confusion, suggestions and best practices that the new hire misses.  (This helps drive introspection for the team for the next round of hires).

Equivalence to Technical Debt

A lot of these negative indicators and the difficulty in achieving the measures are driven by the technical debt that an organization is carrying either consciously or subconsciously.  Finding opportunities to spot the technical debt that is causing friction within an organization are golden.

Technical debt in a development team is most visible to a new hire.  They walk headlong into it with open eyes and an inquiring mind.

Helping the Future Self

The future self concept covers the lack of familiarity that an engineer will have with some code or a system that you are currently working at some point in the future when you need to go back to it.  Over time, poorly written code – even written by yourself, becomes that code written by the clueless engineer a few years back.

Technical debt is usually correlated with old crappy code.  However while the engineers are writing the code, there is not the assumption that the code that is going in is crappy.

A new engineer being onboarded to a new system is in exactly the same place that a future self or a new transfer into the team will be seeing.    They don’t have the history and so it will always be more jarring to them.  Future selves and new transfers will have enough history that they will orient themselves back to familiarity very quickly.  Warts and all.

Learn From the New Engineer’s Honeymoon Period

Engineering leaders, should look closely at the questions, feedback, and interactions that a new hire has with their new code, systems, and team.  They don’t have the history or familiarity with the code that helps them skip the opaque or confusing bits of how you do development.  This will help not only with onboarding new hires, but also the engineer’s future selves, and people switching into the team.

Those first few weeks of a new engineer are extremely valuable, use it as a barometer for how effectively the team is managing technical debt and creating maintainable code and systems.

Don’t squander those first few weeks.  Also, keep your house in a state that your elderly aunt would like.


As always, vehemently opposed positions are encouraged in the comments, you can also connect with me on twitter @tippettm, connect with me on LinkedIn via matthewtippett, and finally +Matthew Tippett on google+.  You can also follow me on Quora, or simply follow this blog.

#ByMoonlight – Yosemite

Unfortunately it was a new moon when we where in Yosemite for a mid week getaway.  So I traded the moon for a flash or phone LED torch to do some light painting.  Enjoy!

Your typical landmarks –

  • Half Dome (from Glacier Point) just after sunset, with a painted tree in the foreground.
  • El Capitan, just after sunset (note the two lights which are climbers camped for the night) with the meadow in the foreground highlighted by passing cars.
  • The Yosemite park sign, much later in the evening, painted with phones in torch mode with stars in the background.

All photos are as captured, with no post-processing.

Feel free to comment below or reach out to me if you want to discuss.

Translating an Ancestral Tablet

Some time ago in Toronto I purchased what I thought was an antique Chinese sign from an antique dealership. Once I had brought it home I did a bit more research on it and found that it is an old ancestral tablet.

This page covers provides some photos to provide an online reference to it and potentially bring some more information as it becomes available.  I’ve also created a Quora question to see if the smarts of the Internet can help translate or otherwise provide deeper insight into the tablet.

The tablet itself is about 45″ (115 cm) tall – not including the base that would inserted into a stand or similar.  The width is about 13.5″ (34 cm).

If anyone who comes across this page can help translate or provide more information, I’ll update the page.

Read more of this post

Using Google’s “+” Email For Opting Out and Catching SPAM

Fortunately, with strong spam catching features in most of the mail systems, the bother of spam is considerably less than it was 10 years ago.  It is clear that the perennial concern about opting out being a magnet for new sources of spam is well and truly founded.  Fortunately, you can use the “+” option for email to opt-out safely as well as getting a solid read on the how the opt-out either cuts down on or increases spam. Read more of this post

Converting a ChromeBook to a Dev Environment

Chromebooks are inexpensive, generally single purpose devices that are 90% of what most people need for day to day use.  Developers however need just that little bit more.  My preferred development environment includes using the atom.io text editor among other tools.

When my normal OSX development environment was not available, I re-purposed an Intel based ChromeBook to being a dev environment.  This article describes the process and some of the final thoughts.

The steps needed are

  1. Backup local storage
  2. Enable Developer Mode
  3. Install Crouton
  4. Install the Crouton Extension
  5. Install Atom

Note this gets a developers editor, but does not set up other development tools (compilers, etc).  I’ll leave this as an exercise for the reader.

Read more of this post

Code and the Written Word

Code history is like a narrated history of code.  The ability for git rebase to reorder, rework and polish commits allow a developer (and code reviewers) to curate the code history so that it tells a well structured story.  This post will wander through how strongly the analogy can work.

TL;DR version in the slides.  Read on for the long form.

Read more of this post

New #bymoonlight images

A quick photo #bymoonlight photo for tonight.

las-palmas-bymoonlight