The power of one
There’s nothing like being able to work on a project by yourself and having complete control of every single aspect of the solution. Everything from the front-end stack to the storage. Using the latest and greatest frameworks and libraries. This is heaven for any software developer. But regardless of any of the above technology-focused aspects, there is one major advantage being that single developer, namely: speed! But there are pitfalls when writing software alone.
When a developer knows every aspect of a system, they have a mental map of the code and the problem domain. They know how the code flows, how business rules are implemented, the architecture and sometimes even the line-numbers of specific functions! Having this mental map is a tremendous advantage, but is only possible because there is no need to communicate with other developers.
Being socially unacceptable
Being the only developer that delivers and end-to-end solution also leads to a feeling of great pride. It’s like being superman. The feeling that people can throw anything at you and you can get it done. Bring on any challenge and you will be up for it. Confidence in your solutions and decisions.
Everything isn’t really shiny in solo-town, though. For many, this ever-growing feeling of confidence can spill over to overconfidence which leads to a larger ego. Egos require constant feeding, and may lead to many interactions that don’t end up going your way in the long run. When challenged you have so much confidence in your approach or opinion that you completely ignore others perspectives. You enter tunnel-vision mode and may end up discussing or even arguing to get your point across. This could be with other developers, leaders, users or even clients. Just because you believe you know what’s right in a given circumstance, doesn’t mean you can force the solution on others. Doing so will alienate everyone else in the process then you’ve started digging a hole in which you’re going to find hard to climb out of.
Some leaders adore these people. They come in, say harsh words that force change then move to the next project. This may be a very efficient way of getting ones point across, but it’s definitely not the most effective in the long run considering all the people who are forced into a decision. Being right doesn’t give you the right to be inconsiderate.
From clarity to confusion
Even if you avoid the ever-growing sense of ego, there is the technical aspect of being alone. Your code is going to suck. I mean this in the most polite way possible. The fact of the matter is that when you are the only person writing that code, your incentive to create quality software goes down. There will be an increasing tendency to take the path of least resistance in your code. What this means is that unit-tests go out the window, SOLID coding practices become a nice-to-have and bugs creep up constantly. There’s also a tendency to either under or over-engineer solutions, leading to even more bugs. Returning to one of these code bases after some time away is also a scary matter…your mental mind-map is gone! Even worse: when somebody else takes over one of your projects and have to maintain that code, can’t make any sense of it and ends up re-writing it again. Not good for the next guy and definitely not good for your reputation.
Tunnel-vision and Echo-chambers
Working alone tends to lead to a certain amount of tunnel-vision with what you are doing. This means that the further down a path you go, the more likely you will continue. This also leads to being your own one-man echo-chamber. Your view of the world becomes the de-facto view, and you end up seeing everything through your eyes only. This further strengthens the tunnel-vision an makes you blind to any other opinions other than those that match yours.
Having like-minded people near or around you will also strengthen this echo-chamber effect. If everyone you follow on twitter says that library X is the only way to write code, then you will be oblivious to everyone using library Y or Z. Most importantly though you will fail to realize that Y or Z even are alternatives that may better suit the problem at hand.
A different approach
There is a fine line in having confidence in what you know and embracing the fact that you don’t have all the answers. On the one hand you need to leverage what you know for the right cases, but at the same time have the knowledge and courage to say that you may not have an answer yet. By balancing this line you always have the option to reach out for other approaches based on actual feedback or advice. The key here is to listen and understand what is needed. Move beyond the regular “this vs that” discussions and get to the core of what different technologies are good for. Listen to the needs of a client, user or domain expert. Sometimes your one-way of solving everything is just what they need, but do so deliberately and know that the next project may not require that same approach.
But how to be open to other approaches to begin with? Well, break out of you echo-chamber! If you are a loner, then its extremely important to embrace community events or projects. Follow people with opposite opinions than you have on twitter. Read articles that challenge your beliefs. It’s only by exposing yourself to other opinions you can consider what the correct approach is in any given context. There are no silver bullets!
Embrace code-quality. Always write for your future self. Imagine you’re coming back to a code base after several years and need to jog your memory. Firstly; kudos that your software has been alive that long! Secondly; You need to have some way of picking up where you left off. Having understandable code that actually expresses (some of) the why things are the way they are through tests, good abstractions, good commit messages and explanatory naming will save you a lot of effort. But maybe it’s actually easier trying to imagine someone else looking at this code? How would a 3rd party reviewer figure out what’s happened here? Imagine having that conversation with another developer trying to explain the code to them. Personally, this is what I feel works the best. This will gain you a reputation as someone who cares for code and your craft.
The bottom line
Even when working alone, software development doesn’t have to be a lonely one-man experience. Embrace our connected communities online and offline. Reach out and listen to your users and approach your projects with a learners mind. Make software a social experience even if you are developing by yourself and you won’t truly be alone.
I would love to hear your thoughts on the matter. Drop off a comment below or reach out to me on twitter
