Changing perspectives for software engineers
Published
When you hire a skilled software engineer, how long does it take for them to feel comfortable with the product they have to build?
Probably between several days to several weeks.
How long does it take for a skilled tradesperson or contractor to feel comfortable when building a wall?
It’s closer to several minutes.
Why do these two professions have such a difference when it comes to onboarding for a new job? I feel it might be because of an advantage tradespeople have over software engineers: perspective.
When a tradesperson begins they get to see the full scope of the work ahead of them. Drawings, renderings and plans are available, but there’s something more valuable: a tangible construct (the wall). As they move around the construction site they can see more details and quickly gain a greater understanding of the task ahead of them. Every corner, defect, measurement and material is on full display.
Let’s change the question a little: how long would it take for a skilled tradesperson or contractor to feel comfortable building a wall if they could only see one nail, brick or stud at a time? They pick up a piece of timber, go grab a nail and the timber becomes invisible. It would be chaos on a building site.
That’s a situation software engineers have to work with. Yes, there are designs and mockups, but we don’t get to see the full scope of the work like the tradesperson. IDEs will list every file in the repository but we can’t keep them all open at once because monitors have physical limits. We might work on several files at a time, but not at the same time. Our efforts might result in a shiny UI for clients, but everything we see is basically text.
But what if software engineers could view their work differently? Change their perspective so that they could view the entire code all at once without being overloaded?
Researchers at GitHub Next tried it with their fingerprinting tool. It takes a repository and gives it a visual representation. This is what the reactjs/redux library looks like:
See that src folder? That’s the code used when you import it. It’s tiny compared to the examples and docs folders.
I really like the idea of seeing everything like that. Unfortunately it can only be used with GitHub Actions. Those using BitBucket, GitLab or others don’t have that as an option.
Not yet anyway.
Again, I really like the fingerprinting idea. Being able to zoom in to see how much nesting occurs, seeing connections between files and being able to quickly navigate in a more natural way would make learning a new codebase considerably easier.
I like it so much that I’ve started work on an extension for VS Code so I can use it on any workspace I want. It’s still in early development, but the current progress is very promising. This is what it generates from the previous variable-dropdown project:
It needs a lot more work, but it already shows more than I could have hoped for. The zoom is a nice touch:
There’s no ETA on when it will be available for others, but I want to use it on other projects as soon as possible so there’s some incentive for me there.
My hope is that this can help software engineers understand the scope of their work like tradespeople can, dive into a codebase quickly without having to navigate through every single file, and speed-up the onboarding of new engineers as a company grows.
I want the MVP to be simple, but I’m open to ideas for future releases. Leave a comment if you think there’s more that could be done to help us engineers quickly pick up a new project.