Photo by Vidar Nordli-Mathisen on Unsplash
Being a solo developer - inside a company.
For six months now, I've been in a man-made hell: I am a solo developer. Employed in a company.
I am project initiator, architect, programmer, communicator, product owner and administrator. I am leader and manager of a team. That team is myself.
Holy shit, that hurts sometimes.
That moment when you get jittery in meetings because they last longer than 15 minutes. That moment when you get jittery because you're talking about a project in the meeting, when you want to put every precious minute into development to make what you're talking about in the meeting real.
That moment when you're pushing a very technical project that's harder for non-developers to understand. You start explaining the project in analogies. These analogies take on a life of their own in the minds of your superiors. You start wishing you never mentioned the analogies.
That moment when, in your role as communicator, you explain the next steps of the project to your manager while being careful not to over-promise because, as your own manager, you know exactly the team capacity.
You try to communicate as truthfully as possible: that there are unknown unknowns in the project. That you are therefore extremely reluctant to make certain commitments. Your counterpart gives you the feeling that you will manage all that. You hope so and are only more afraid of that day. That day when you realize that what you have set in motion was a dream after all. That it's too hard. That it is impossible.
You go on.
You solve partial problems. With the solutions come new problems. You solve them, too.
You avoid binding commitments in meetings more and more - because every commitment ends up directly in your pile, as a pile of tickets in your Kanban board.
You stoically continue to plow your paths, like a steel plow through a cold, snowy field. Hoping that this soil will be fertile.
Then it happens.
The pieces come together to form a great whole. Your architectural concepts come to fruition. Your abstractions prove to make real sense. You build speed. Fundamental decisions become decisions about new features. Abstract tickets like 'Brainstorm solutions to solve problem X generically' become concrete tasks like 'Add boundary checks'.
The waters become calmer. Your confidence rises. Confidence that this work done will serve its purpose. That other developers can continue here.
Oh, if it would come to that.
"First comes the ebb, then comes the flood." -Kristoffer Jonas Klauß