I’ve been the lone developer of a project since the project’s creator and my main collaborator passed away last year. They themselves were the lone developer of this project for a period.
They knew what was coming, and adopted what they coined ‘mortality driven development’. This manifested itself as most of the codebase being comments and tests, and a wealth of diagrams and documents explaining how things worked and the rationale behind them.
And so I never felt lost in their codebase, and sometimes even relied on them to help me write new features long after their death. I can’t say I’ve been half as diligent in my stewardship of the project — but this post helps remind me why it matters.
Another plausible theory: if you’re the sole developer, you can use concepts and mental models that make perfect sense for you, but would be hard to communicate to anyone else. And that makes you a lot more productive, so you do it, and so you’re left with weird code.
It’s similar to your first reason, but with a more positive spin. A team of people can make more understandable code, but they have to move net slower to do it.
I think it can occasionally happen with teams too. I worked in a team of 3 contractors where we basically had this problem. We were all really in sync after 2 weeks and flew through that project. The team we handed the project over to struggled to understand the system we’d built. Which is fair since we built it for the 3 of us to understand. I know they replaced the UI library we spent a good deal of time building. I just think it’s rarer occurrence on a team.
This is why the style guidelines that I wrote for my current project prohibit using abbreviations in identifier names. The folks on my team have a common vocabulary and there are a lot of shorthand forms that we all recognise immediately. It’s easy to sprinkle them over the codebase and end up with something that’s totally incomprehensible to anyone else. It’s also why I try to commit design docs along with (or, ideally, before) new features: so someone can understand why the code is doing something before they read the code.
In an OSS, academic, or indie software context, I’d agree. In the day-to-day of my career in commercial and contract software, however, I’ve found that all too frequently lone developers who have been tasked to build something will neglect the ability of their colleagues to participate (which some see as a territorial threat) or the ease with which it can be extended or maintained (perhaps because either deadlines or job security are more important). They’ll use the tools and idioms that they personally like or are convenient in the moment, regardless of whether they’re appropriate to the context, without any self-reflection or responsibility in the aftermath. This is not true of all lone developers, but those for whom it is leave disproportionately deleterious results.
If that developer leaves the company this can lead to what I like to call “alien artefacts”: software that works, and might work very well, but is hard to comprehend or change by other developers.
This. And it gets much worse if said alien artifact breaks … and then you don’t know how it was working let alone why it isn’t. It’s not a great position to be in.
This is a great term. I have inherited a lot of unknown code and systems when I took over the management of the software team (I primarily focused on the web stuff) and now I have projects this year to break down these Alien Artifacts and either refactor them or at the very least have clear documentation on what they do.
I think this is an interesting subject. I have been a creator and inheritor of many such alien artefacts. I find it much easier to deal with them when I’m given complete authority over them so that I can assimilate the artifact as I understand it. The nightmare scenario is when the creator hasn’t actually left the company but rose in the hierarchy so they outsourced it to you, but they’re still emotionally invested in it so they won’t give you enough authority to assimilate it.
I think that the biggest thing is just that if you know you are working on something yourself, you don’t have to explain yourself.
You can write the one liner you “know is right”. Use some weirdo idiom with the comment, Write the exact set of tests you want to be convinced, without other tests that you would write to convince others.
And for UX questions, absolutely nothing needs justification. Do what you want, include the bespoke behavior you want.
This is super cowboy behavior, but extremely liberating. I recommend everyone have at least one kitchen sink project that they don’t think of sharing with anyone. It also helps you learn what things you really always want to do in terms of maintenance and readability.
I’m the only dev where I work, making and maintaining laboratory/stock/ordering/logistics system for a regenerative medicine company. This is a constant concern.
My strategy is to always build stuff as if someone else is going to take over the project (because one day, they are). So git commit as if someone is watching. Comment and document as if someone is watching.
The other thing that helps is using a framework. One is Symfony one is Rails. It’s not trendy and can be a pain to upgrade on a solo project, but it has a couple of benefits:
a) it’s a common set of guidelines on how to do things
b) it’s well documented
c) it usually comes with a dev community that is tackling a similar set of problems to you
d) when it’s time to hire, you can put the name of the framework in the job listing
I’ve been a lone developer for most of my career, and had I known that programming would turn into a team sport, I might not have even become a programmer. I don’t think I’ve written confusing code, and rarely have I gone back to code I’ve written and not have it make sense to me, even years later. And the one time I did pair programming, it was painful and I don’t wish to do it ever again (I was a mere secretary, taking dictation and shut up! Keep typing!).
Do not worry, you are not alone. If it helps, I found it possible to work on solo projects in every company I ever worked for. And the more senior your are, the easier it is.
I’m being pulled more and more into team-sport-coding. There are days when I just want to lock myself into a room, focus on the problem, and write the code. Sometimes I just can’t deal with the meetings, the pairing sessions, the mentoring, the code reviews. I wish I had a gig as a lone programmer.
This sounds like a good idea, but I’m a bit intimidated by the whole process of finding customers and taking care of my own business. Moreover, in the country I live in, I should earn at least double my present income to live the same lifestyle as a consultant.
Yeah, finding customers can be difficult for introverts without a large network (I have the same problem). You could always frequent those freelancing job boards to get started and hopefully build up a clientele, but realise you’ll likely have to fight bottom-of-the-barrel “developers” on price.
I should earn at least double my present income to live the same lifestyle as a consultant.
Unless you’re raking in tons of cash at a big tech company, if you calculate what you make per hour, you should be able to (eventually) charge double that quite easily. Remember, your employer needs to charge the customer for your time, pay your wage, social securities/pension, rent, employee hardware and “overhead” (wages for managers, reception, cleaners, whatever other roles the company has that don’t work directly for the customer) and still make a profit.
This is funny as I actually thought about this yesterday when I looked at the build-system and source code of imapsync, which is developed by a single person. It is a great piece of software for what it does, but damn, it’s really hard to build and dumps a lot of useless information on you at every turn.
I have been the lone developer for a while and we’re fixing to bring someone else on. I am worried that I’ve been doing this kind of stuff and that they’re gonna be horrified.
The post doesn’t mention Lisp, but it does seem that a few essays over the years have pointed at this being a core issue with Lisp: it’s so mutable that the most productive Lispers make it into their own language, and cooperative development is thus discouraged.
The accessibility of a codebase depends on each person’s own experience. Even the most clear and straightforward code is another person’s booby-trapped spaghetti salad.
I involve other people early, if only because reducing the bus-factor also increases the number of people who can explain why things are the written way they are.
I’ve been the lone developer of a project since the project’s creator and my main collaborator passed away last year. They themselves were the lone developer of this project for a period.
They knew what was coming, and adopted what they coined ‘mortality driven development’. This manifested itself as most of the codebase being comments and tests, and a wealth of diagrams and documents explaining how things worked and the rationale behind them.
And so I never felt lost in their codebase, and sometimes even relied on them to help me write new features long after their death. I can’t say I’ve been half as diligent in my stewardship of the project — but this post helps remind me why it matters.
Earthstar is very cool. Thanks for your hard work on it!!
For others wondering: https://earthstar-project.org/
https://github.com/earthstar-project/earthstar
To the OP, I would recommend putting more links to it on your blog – it’s difficult to find!
Another plausible theory: if you’re the sole developer, you can use concepts and mental models that make perfect sense for you, but would be hard to communicate to anyone else. And that makes you a lot more productive, so you do it, and so you’re left with weird code.
It’s similar to your first reason, but with a more positive spin. A team of people can make more understandable code, but they have to move net slower to do it.
I think it can occasionally happen with teams too. I worked in a team of 3 contractors where we basically had this problem. We were all really in sync after 2 weeks and flew through that project. The team we handed the project over to struggled to understand the system we’d built. Which is fair since we built it for the 3 of us to understand. I know they replaced the UI library we spent a good deal of time building. I just think it’s rarer occurrence on a team.
This is why the style guidelines that I wrote for my current project prohibit using abbreviations in identifier names. The folks on my team have a common vocabulary and there are a lot of shorthand forms that we all recognise immediately. It’s easy to sprinkle them over the codebase and end up with something that’s totally incomprehensible to anyone else. It’s also why I try to commit design docs along with (or, ideally, before) new features: so someone can understand why the code is doing something before they read the code.
In an OSS, academic, or indie software context, I’d agree. In the day-to-day of my career in commercial and contract software, however, I’ve found that all too frequently lone developers who have been tasked to build something will neglect the ability of their colleagues to participate (which some see as a territorial threat) or the ease with which it can be extended or maintained (perhaps because either deadlines or job security are more important). They’ll use the tools and idioms that they personally like or are convenient in the moment, regardless of whether they’re appropriate to the context, without any self-reflection or responsibility in the aftermath. This is not true of all lone developers, but those for whom it is leave disproportionately deleterious results.
If that developer leaves the company this can lead to what I like to call “alien artefacts”: software that works, and might work very well, but is hard to comprehend or change by other developers.
This. And it gets much worse if said alien artifact breaks … and then you don’t know how it was working let alone why it isn’t. It’s not a great position to be in.
This is a great term. I have inherited a lot of unknown code and systems when I took over the management of the software team (I primarily focused on the web stuff) and now I have projects this year to break down these Alien Artifacts and either refactor them or at the very least have clear documentation on what they do.
I think this is an interesting subject. I have been a creator and inheritor of many such alien artefacts. I find it much easier to deal with them when I’m given complete authority over them so that I can assimilate the artifact as I understand it. The nightmare scenario is when the creator hasn’t actually left the company but rose in the hierarchy so they outsourced it to you, but they’re still emotionally invested in it so they won’t give you enough authority to assimilate it.
I think that the biggest thing is just that if you know you are working on something yourself, you don’t have to explain yourself.
You can write the one liner you “know is right”. Use some weirdo idiom with the comment, Write the exact set of tests you want to be convinced, without other tests that you would write to convince others.
And for UX questions, absolutely nothing needs justification. Do what you want, include the bespoke behavior you want.
This is super cowboy behavior, but extremely liberating. I recommend everyone have at least one kitchen sink project that they don’t think of sharing with anyone. It also helps you learn what things you really always want to do in terms of maintenance and readability.
I’m the only dev where I work, making and maintaining laboratory/stock/ordering/logistics system for a regenerative medicine company. This is a constant concern.
My strategy is to always build stuff as if someone else is going to take over the project (because one day, they are). So git commit as if someone is watching. Comment and document as if someone is watching.
The other thing that helps is using a framework. One is Symfony one is Rails. It’s not trendy and can be a pain to upgrade on a solo project, but it has a couple of benefits:
a) it’s a common set of guidelines on how to do things
b) it’s well documented
c) it usually comes with a dev community that is tackling a similar set of problems to you
d) when it’s time to hire, you can put the name of the framework in the job listing
I’ve been a lone developer for most of my career, and had I known that programming would turn into a team sport, I might not have even become a programmer. I don’t think I’ve written confusing code, and rarely have I gone back to code I’ve written and not have it make sense to me, even years later. And the one time I did pair programming, it was painful and I don’t wish to do it ever again (I was a mere secretary, taking dictation and shut up! Keep typing!).
Do not worry, you are not alone. If it helps, I found it possible to work on solo projects in every company I ever worked for. And the more senior your are, the easier it is.
I’m being pulled more and more into team-sport-coding. There are days when I just want to lock myself into a room, focus on the problem, and write the code. Sometimes I just can’t deal with the meetings, the pairing sessions, the mentoring, the code reviews. I wish I had a gig as a lone programmer.
Have you considered going into consulting/freelancing? Depending on the type of job you might be able to work alone on the code.
This sounds like a good idea, but I’m a bit intimidated by the whole process of finding customers and taking care of my own business. Moreover, in the country I live in, I should earn at least double my present income to live the same lifestyle as a consultant.
Yeah, finding customers can be difficult for introverts without a large network (I have the same problem). You could always frequent those freelancing job boards to get started and hopefully build up a clientele, but realise you’ll likely have to fight bottom-of-the-barrel “developers” on price.
Unless you’re raking in tons of cash at a big tech company, if you calculate what you make per hour, you should be able to (eventually) charge double that quite easily. Remember, your employer needs to charge the customer for your time, pay your wage, social securities/pension, rent, employee hardware and “overhead” (wages for managers, reception, cleaners, whatever other roles the company has that don’t work directly for the customer) and still make a profit.
This is funny as I actually thought about this yesterday when I looked at the build-system and source code of imapsync, which is developed by a single person. It is a great piece of software for what it does, but damn, it’s really hard to build and dumps a lot of useless information on you at every turn.
I have been the lone developer for a while and we’re fixing to bring someone else on. I am worried that I’ve been doing this kind of stuff and that they’re gonna be horrified.
The post doesn’t mention Lisp, but it does seem that a few essays over the years have pointed at this being a core issue with Lisp: it’s so mutable that the most productive Lispers make it into their own language, and cooperative development is thus discouraged.
This can be a Perl (mis)feature too.
The accessibility of a codebase depends on each person’s own experience. Even the most clear and straightforward code is another person’s booby-trapped spaghetti salad.
I involve other people early, if only because reducing the bus-factor also increases the number of people who can explain why things are the written way they are.