The Isolated EngineerAlejandro WainzingerBlockedUnblockFollowFollowingFeb 10Through some set of circumstances you end up silo’ed away from the rest of the group and left to your own devices.
Normally you’d celebrate the freedom that comes with this, but prisons come in all shapes and sizes, and the world of ambiguity that arises from this can be just as trapping as the strictest micromanagement.
You’ve become a trusted entity, trusted enough to operate with independence and impunity, and trusted to do this work in the darkness, far away from the judging eyes of your peers, and far from their reach.
In the darkness there is no light, only growing uncertainty that the choices you make are the right ones, and rising stakes as the result of your choices may one day spell disaster.
In software, as in many worlds, peer review and oversight are of paramount importance.
No matter how smart we may think we are, or how careful we pretend to be, it’s only a matter of time before our blind spots and pride lead to collapse.
No person, no matter how skilled or disciplined, is exempt from the temptations of taking shortcuts, or from the pitfalls of bad architectural design that result from designing in complete isolation.
While it’s completely fine and even great to start an idea or a project alone, it’s rarely advisable to continue this pursuit in isolation for too long, as early mistakes multiply in cost over time, and it becomes easy to sweep issues under the rug, being the only author.
This is an exploration of how someone can end up isolated, the effects of isolation on the individual and the group, and how to both get out of this situation and avoid it in the future.
Cut OffHow do people end up isolated in the first place?Excessive trustPeople can be victims of their own success.
Do well enough for long enough, and people will stop looking over your shoulder.
This can be comforting at first, but zero checks over time can lead to mistakes slipping through.
However, given the high level of trust, nobody will notice those mistakes unless and until they surface high enough, and even then, mistakes are forgiven because of the high level of buy-in you’ve managed to achieve from someone else.
Insufficient or non-existent peersEngineers may be in high demand, but they are by no means in high supply.
A low headcount, or a headcount of 1 (that’s you) can mean that there is nobody qualified to look at your work, be it design or code.
This is just an economic or political reality and a difficult hurdle to overcome, as it may not be up to you.
Orthogonal peersIn this age of microservices and countless apps, it’s possible that nobody is familiar enough with your language or specific domain to be able to offer useful feedback, and rather than offer fluff, choose to offer nothing at all.
As people specialize more and more, they become less and less capable of aiding the people next to them.
Sometimes languages can be similar enough, like Python and Ruby, or Kotlin and Scala, or databases similar enough, like MySQL and PostgreSQL, that it’s easy enough to offer good reviews, but in separations like web frontend (e.
g.
SPA) to backend, or even to infrastructure, the crossover is tenuous at best.
Web engineers and data scientists?.You are on your own.
Silent peersPeople sometimes try to stay out of each others’ way to avoid conflict.
While some people come to work and want to improve themselves and help others where they can, others see inherent risk in human interaction and avoid potentially stepping on toes.
Yet others have a lack of interest in the affairs of their peers, and choose to stay in their own cave.
The silence can be deafening.
AdriftWhat are the effects of isolation?Nobody to call you on your bullshit.
Bullshit continues, compoundsWith nobody to stand in your way, you build and build and build.
Any bad decision just compounds on the next.
Odd design patterns that are difficult to decipher by anyone but yourself begin to dominate the code.
A single 5 minute review from someone else could reveal issues, but with no such process in place, you dig a hole straight to the center of the Earth, and only when you hit magma do you realize how far you’ve dug.
Uncertain if making sane decisionsYou’re likely aware on at least some level that there be dragons of your own making, and this uncertainty of your approach begins to grow.
Oftentimes the constant but silent gnawing deep within yourself does more psychological damage than the certainty of committing known mistakes.
Eventually this takes on one of a few forms: you silence the voice even as it tears at you from the inside, or you convince yourself that your designs are flawless.
(see: cognitive dissonance).
Either way, you have strayed from the path of sanity and begin to grow in an abnormal way, and the damage can take a long time to recover from.
Missed opportunities for learning from othersLet’s say you’re quite self-disciplined and intelligent, and despite all odds produce sane, readable, scalable, good code.
The world is vast and approaches are many, and someone else may have stumbled upon a great design pattern, library or methodology that you just happened not to have encountered.
While it’s possible you may one day find it, it could take longer to find out, and yet longer to learn it alone, than with a mentor.
Slower growth is not generally a problem, but if your rate of learning is slowed excessively by isolation, your longer-term job security could be at risk.
RustingThe longer the isolation goes on, the more vulnerable you eventually are when someone else finally does come along to take a look inside and find the rat’s nest you’ve built, at which point your credibility is in tatters along with your ego.
Like an abandoned blade dulled by the winds of time, you will not be sharp, you will not be ready, and you will be of little use.
You will find difficulty in defending and explaining your decisions, since you were never forced to think them through, and because in some cases, they are indefensible.
DepressionPerhaps the most devastating of consequences is the personal toll it can take on the individual.
Working alone for long periods of time can lead to loneliness, and eventually depression.
Not all people will fall into this, as some people rejoice in being left entirely to themselves, but humans are generally social creatures, and work is no exception.
Going to work becomes more difficult, dealing with even minor problems can become a giant obstacle, and progress can come to a grinding halt.
After all, nobody really knows what you’re doing, or not doing.
With nobody to reach out to who will understand your problems, you internalize the damage which compounds with interest, ultimately yielding high returns of nothingness and suffering.
You are a void.
OutputIn terms of work, in the best case you will be producing operational (enough) software that nobody else can look at or touch, and in the worst case, you will end up with brittle, slow programs that you strive to keep running.
For the group, this means a bus factor of 1 for potentially critical software, putting them in a highly vulnerable position, and forcing everything to go through you, a completely unscalable approach for everyone involved.
If left long enough, it becomes difficult to train a second coworker or replacement for the position, leading to either you being let go and a replacement scrambling to figure out the mess you’ve left behind, or taking a long time to onboard someone new, and having difficulty retaining them if this is what they must deal with.
Nothing good in any case.
SalvationOnce you’re in this position, how do you escape?Force reviewsIf you have someone who is even tangentially in the same domain or uses similar tools, convince them to review your work.
Even if the level of granularity in the review doesn’t match the optimal levels, it may help to catch some of the more egregious mistakes in design, or bring about helpful suggestions.
Perhaps over time, each of you can cross into each others’ domains a bit more, and both sides benefit.
This can often be socially awkward or difficult, but is a viable way out of the isolation.
Discuss with othersIf you can’t get a code or design review, simply discussing things at a high level with someone else can be enlightening, sometimes it can even yield end-user-level insight that even an engineer might not be able to provide.
While not optimal, this addresses both isolation and review to some degree.
Engender skepticismThis one might seem counterintuitive.
After all, we spend so much effort trying to build up trust with others.
Pushing other people to give you critical feedback and to ask difficult questions can help to break through the ice by emphasizing to others your fallibility, and if people feel more comfortable giving you feedback, they will likely do so more often.
This can be quite difficult due to a few conflicts of interest involving people wanting to preserve the peace and not wanting to criticize others, as well as you not wanting people to distrust you, but will ultimately lead to a much healthier working relationship, and can cure the isolation.
Sometimes this requires giving some unsolicited feedback to others, which will free them of inhibitions of returning the favor.
As long as it doesn’t become a tit-for-tat, this can be a valuable way to get the conversation flowing.
Hire someoneBudget and office politics willing, just hire someone else with a similar skillset to complement your own.
This may not be up to you, but you can mention to your boss the advantages of an added headcount.
In many cases all it takes is just another trained set of eyes, but your boss is not a mind-reader and may not be acutely aware of your problem of isolation.
Have that talk.
Code outside of workThere are times when the work situation is unchangeable, because life is not perfect, and maybe you can’t jump to another job.
In this case, work on snippets of open source code that are open to peer review outside of work.
It won’t translate directly to the job, but will help be a sanity check in general, and will influence your work.
PreventionIsolation is not inevitable, and precautions can be taken when possible.
No engineer left behindAlways assign a minimum of 2 people per project, and if possible, 3.
They are far more likely to raise problems since they can discuss the work and move things forward together.
A third can break ties in design decisions and code reviews.
Manager 1:1sAlthough many 1:1 meetings are driven by the individual contributors, a manager should suss out problems of isolation in these meetings.
Many times there may be hints of burnout or otherwise which have isolation as a root cause.
Sometimes an IC may not realize they’re in this position, but a good manager should notice and take appropriate action.
No news is not always good news.
Seek helpManagers can’t always successfully suss out problems, especially if they’re distracted, or they go the route of willful ignorance.
Raise the issue and try to get it addressed.
It sounds obvious, but this first step can be pretty hard for many people.
Prioritize it.
Isolation is a real and constant danger in many fields of work.
The important thing is to be able to identify it and take the proper measures to deal with it.
The consequences to mental health as well as general productivity are worth taking this issue seriously.
The best engineers can fall prey to isolation, but may find it a difficult trap to identify and escape from.
Be alert, be proactive and sincere in offering help, and let’s keep engineers happy, connected and productive.
.. More details