The Lone Developer Problem

In my experience it's more often the other way around.

Most projects I've seen with actually readable code and a consistent overall structure have been written (mostly) by a single coder, of course usually with contributions from others, but not real 'team work'. Of course there are also messy projects by single authors, and readable code bases by teams. But in the latter case: the more the responsibilities are spread, the messier the outcome (IME at least).

I think in the end it comes down to the experience of the people involved.

And then of course there's personal taste, one person's readable code is a complete mess to another.

In any case, the post reads like the author stumbled over one messy project written by a single author and extrapolates from there to all other projects.

Does not fit my experience. Best software I've seen was always single good developer. Plenty of great single-person open source software out there to prove it.

The problem is - good devs are actually very rare. A single not so good developer doesn't get any feedback, yet they have all the clarity and context in what their code is doing, so they can take their terrible code quite far.

I have a different take on this. If my project somehow becomes wildly successful and is acquired, the next team is not going to want to maintain my code anyway. How do I know that? Because no one wants to maintain someone else's code. No one wants to deal with someone else's abstractions and bugs or anything else.

100% of the time if it's feasible, the next version will be a rewrite of all or a significant portion. Especially for relatively small projects in terms of lines of code, which all of mine are.

Now the fact that it's plain JavaScript and messy, console.logs all over the place, I would argue, actually helps that new team. Because it makes it easy for them to trash my code. Which they definitely will want to do anyway. Why? Because they don't want a back end in JavaScript. Actually they didn't want it in TypeScript either. They wanted it in Python.

What if it was in Python? Well chances are they wanted it to use a different Python framework. Or actually Rust.

But what if the front end was very very well factored React. AND the front end team loves React. Well sorry but it uses React Hooks which they hate. And they really switched to Svelte months ago actually.

I would argue the part that matters the most is just not having a lot of code. Which you accomplish by not reinventing the wheel. Another big part is having relatively small functions and low cyclical complexity, and descriptive but not overly long names.

So in my mind although my code is a mess on the surface and easy to trash, and could be organized better, it will be easier than average to rewrite they way the want. And easy to trash means less likely to be stuck maintaining someone else's code for an extended period of time.

What I care about is getting a usable product out that has features that provide value before I run out of money. I could do half the features and MAYBE if I am lucky they won't trash my code.. but they will actually be worse off because then they will be stuck maintaining a code base that actually isn't using the frameworks they preferred anyway.

This might be unusual but I would prefer to read someone's mental model of how the code works than the code itself. With thousands of files and thousands of lines of code it's difficult for me to work out how the code fits together.

If you document your mental model of how the code works, I can probably map the code to your mental model and understand the code.

I want/like people to create "entrypoint" packages/folders where entry points and component registries are found. Especially int main() {} So I can follow the control flow of the software.

I think too few people understand cornerstone technologies, including compilers and browsers.

This article makes an explicit assumption: that code that is easy for you to read at a glance is inherently "good". The article then makes weird quasi-moral judgements like, maybe if you are a single person writing difficult-to-read code then "maybe you just don't need to write good code". Code that is optimized to be easy to read often has lots of duplication and very little abstraction.

This is even a well-understood tradeoff, and is why people working as cogs in massive organizations are often expected to code in languages like Java, Go, or C, which all purposefully offer very little in the way of abstraction, so the code is somehow more "obvious" and easier to read by whomever comes into the codebase next and needs to rapidly make some kind of change without breaking stuff.

The problem is... this is actually really shit code. The more duplication you have and the less abstraction you have leads to way more places for bugs to creep in. Yes: having the weird unified mechanism that no one is used to to handle memory management or authentication might seem a bit annoying when you sit down to someone else's code, as they are effectively using a bespoke framework.

But, let's reframe that: they are using a "framework"! And it probably has some kind of internal logic, and was likely designed for a reason to solve a real problem! If you take a few moments to orient yourself in the codebase, rather than assuming "I don't understand this so I guess it is bad code" you might come to understand it and then appreciate the work that went into the abstraction.

The alternative to this is frankly code that I enjoy, as I'm a security engineer looking for bugs: I'm going to look for things that are duplicated for bugs that were fixed in one place but not the other or for correct--yet somehow slightly different--behaviors which lead to parser differential vulnerabilities; even just boilerplate: the chance you got it right everywhere is about 0.

Being the only person able to program in a small team, I know I am the target of the criticism in this post.

I think it is mostly true, I wish there were other people looking at my code, but for years I've been working on projects alone.

What I came to realize is that there are some kinds of software where quality is paramount, mainly the code that will carry on for years, and require constant changes.

But there are some software that only exist to fix a particular issue that doesn't require change over time. The typical Perl script that lives unchanged for years doing a single task. For this particular case, quality matters less than portability and relying on solid dependencies that do not require maintenance.

In the end, management does not care about code quality, as long as money is flowing.

For lonely programmers, identifying the code that should be high quality (the one you will be looking at continuously) and the one is only there to fix a single problem is really important.

As a lone developer, there is some truth. But a good lone developer is still consistent, more consistent then a team. The problem with the lone developer is they often get their efficiency by being "weird". However, I still code review my own code and catch issues with it. To be blunt, most people (developers included) don't actually learn new things easily and when they see a "weird" code base their learning mind shuts down. They aren't used to efficient patterns; they are used developers writing dumb CRUD code that is easy to "understand" but in truth do almost nothing of value.

I don't think this is really a "lone developer" problem. If you jump into any large-scale application codebase you'll be lost and confused, even if it was developed by hundreds of developers.

Maybe the reason people perceive this as a "lone developer" problem is lone developers usually share their code for free (or for equity), so anyone trying to get up to speed on it won't be paid for their efforts (at least not right away).

So I've noticed the same underlying phenomenon here: looking at code I wrote 1 year ago and being kind of disgusted. What's interesting is it seems the author came to a completely different conclusion from me.

For me I didn't think "oh, so 1 man team === bad code" - I instead thought "ok so I have no excuse. I have to focus on keeping the code non-confusing and writing comments even when alone". I've found that if I put in the effort, I can write code that's less disgusting 1 year later than if I hadn't cared.

So if you ask me, I don't think there's that much of a correlation between number of people on a team and code "quality". I don't even know what code quality is, honestly, because it's not all methods being <= 10 lines like some linters might have you believe.

For me personally, I have the best time reading code with comments. The self-documenting code thing just hasn't panned out for me. And of course I don't mean "var x = 1 // set x to 1" style comments - I mean as others posted the kinds of comments that just explain the code author's mental models or reasons for doing things.

The article kind of touches on this when it says scrambling for the first 10 users.

For me the big realisation was that my company was more likely to fail because of lack of product market fit or demand, rather than unmaintainable code. Once I had that realisation code quality went out the window.

Just get something half working as fast as possible, then put it in front of customers. Probably the customers don't want what you've built, so throw it away and build something else. Repeat until a customer gives you money. When you're getting a reasonable MRR then start thinking about long term maintenance.

I think part of the "problem" is Amdahl's law.

When you're solo developing, the laws of physics are different when it comes to code quality and refactoring. The scaling of the cost of technical debt is different depending on the size of the team.

In a team, large refactoring efforts are slow and difficult to do incrementally. The best way would be for one guy to lock the mutex and just go, come out however much time later with something cleaner.

If you have 10 people waiting for a week-long refactoring of some central aspect of the code, that's 1 week put in and 9 weeks of work put on hold. It's so inconceivably expensive it's usually not even an option. So instead the code must stay squeaky clean at all times.

On the other hand, if you're just one guy and nobody is waiting for you, it's that would-be impossibly expensive big-bang refactoring task that cost 10 weeks for the team is 1 week of work like any other.

If the primary outcome is not the code itself, but the software it compiles into, I think you're an absolute fool if you don't lean into this as a solo dev. You can be so much faster than a team dev. You can code dirty, cut all manner of corners and fix it later if and when it becomes an obstacle exactly because large code base changes are on a massive discount.

Although as the article notes, it's difficult when the team of 1 grows to more, or the project changes hands, as the solo dev may have known all the weird jank and how to fix it, but the new developers won't. That said, refactoring is cheap, so as long as there's not been an busses involved, a hand-over is very doable given some preparation.

In my experience coding clearly in order to keep code alive in the long term as various contributors come to it is a skill all its own. Developers who integrate writing documentation and tests into their coding write much clearer code whether they are integrated with a team or working on their own.

The particular related point that strikes me is that current hiring processes are dramatically against this. Writing clear code with documentation and tests takes extra time and consideration and often goes slowly. But what gets people hired is quick leetcoding. Reverse the link list quickly or write a sort routine that will go fast and be as quick as you can! Does that imply good coding skill? Maybe. Does it imply the skill to write clear code and the patience and communication to produce documentation and tests along with the code? Absolutely not. Leet coding is the opposite of clear coding for long term utility and ability to readily share the code. So organizations want mature and responsible coders but hire twitchy hyperactive kids instead and then wonder that the results are not as expected.

When I was a teen a couple decades ago, I taught myself Java from a book I bought at a library. I forget the name of the book and the author, but the last chapter included advise on how to program in a team. And the advise went like this: never give negative feedback unless there is a very important reason to do so. Appreciating others' styles and choices reinforces a positive culture and makes everyone in the team happy. This is more important than what background color has been chosen for a UI, or what design pattern has been used for some code. I have followed this rule all through my life. This might make me a non-challenger, but I know from experience that feeling good about the people you work with is what produces the best results

*I actually am a very annoying reviewer, but it always is due to code tidiness (comments, indentation, simplicity, etc), rather than my personal view on what pattern or design needs to be implemented

I'm honestly shocked how some companies I've seen rely on single sourcing

They'll have one (arguably very smart) developer make a component that is crucial to multiple projects. Documentation? Non existant. Coding style? Unreadable mess. They just hope that this one developer is never sick, never takes holidays and hopefully never retires.

> Relatedly, it’s it’s easier to have bad ideas if you don’t have to explain them.

This resonates a lot.

So many ideas that seem to make sense at first (you’re having the ideas in the first place after all), but start crumbling even with simple rubber ducking. Taking distance to try to explain if to a third party, even if they don’t exist, is underrated.

Funnily enough, writing comments and documentation don’t trigger that switch. There might be some hidden assumption that the reader is supposed to “get on board” and come share the same mental model perhaps.

My experience has been the opposite.

For example the project "dear imgui" has been created almost by a single person, Omar, and I find the code amazing.

I have learned a lot from individuals like Norvig, Knuth, Carmack, Johnathan Blow or Casey Moratori or Rich Hickey or Paul Graham. Just reading the code they write.

Pair programming? Seriously? Pair programming only works for me if the person you program with is already an expert. A mediocre one is going to make your program mediocre. Two dull knives don't make for a sharpened one.

Some create job security though ivory tower structures. A surreal masterpiece conceived while failing to cure their schizophrenia by licking hallucinogenic frogs while on LSD.

Others in small firms sometimes notice a "team" is not beneficial... especially if some have seniority, rotten intent, and a string of prior failed launches.

Finally, one realizes it doesn't matter, as you're billing by the hour. A grim apathy replaces ambition, as one starts to fantasize about being a plumber. =)

I’ve experienced this first hand. I think the trick is to encode the experience of writing the code. That takes different shapes in different languages, but a test suite that illustrates the problem and the solution is a good example.

You don’t just want the finished film, you want the making off companion piece.

If you're a sole developer you can do quite a few things short of bringing in other developers: good test coverage, linters and formatters (in git pre-commit hooks or CI) etc.

For example, I try to aim for 100% test coverage in solo projects - that might be overkill in a project of multiple team members all reviewers and testing each others' code, but keeps me from making stupid mistakes when there's no-one else looking over my shoulder.

Another thing is how much you dog-food your project - if you are building something you use yourself every day, you are going to surface bugs and feature requirements better.

> Why does this happen?

Inexperience.

Come on, really? There are plenty of tools to keep code legible in any language: linters, documentation comments, design patterns, idioms from authoritative references, etc.

Every time I see code that doesn't really "fit in" with more experienced code in that language I already know it's gonna be wrong in other ways despite technically "working".

I've too suffered from the neuroticism, imposter syndrome, and egotism of being new at something, but damn can't we just admit this? Guaranteed everyone who isn't a developer sees it and has to deal with it even outside the code itself.

One of my measures of a good programmer, is the ability to grok, debug, and extend code written by someone else, regardless of its perceived quality.

I’ve recently joined a team where the vast majority of the code used across different projects has been written by a lone developer. The code quality is quite good, however, nothing is documented thoroughly and it’s mostly understood by a single person.

We’ve started to code review all new code being merged to the the codebase, we’ve been pair programming occasionally, and I’ve also been writing documentation about how to use the code as I get a handle on it. It’s been helpful so far.

Please document your code. Please provide examples.

I think you can beat the lone developer if the original developers take the time to thoroughly explain their code, at minimum in the comments, where it is good to point to papers explaining algorithms and techniques used. But also lots of example use cases explaining the various features of the code base -- not just "here is something cool you can do" examples, but "here is how these various functions can be used together, and this example shows how you can generalize to a larger problem." White papers can be useful for larger projects. There also needs to be some teaching work done: one-on-one conversations with colleagues for small projects, online videos presentations, and/or attending conferences for larger frameworks.

If you don't put effort into explaining your project to others, very few people will take the effort to learn it on their own, since the effort to understand your code might cost more in man-hours than the effort required to program everything from scratch.

Life is too short to poorly build a house, a house that will break down, with the windows and doors in the wrong place.

Likewise, life is too short to write poor code. Either you already know from the outside it's going to be used, or you don't think it is going to be used and life surprises you. In both cases, you will want to have written good code. Only the edge case of 0 users is compatible with poor code, and that is perhaps code that should not be written at all, because your time is limited on earth.

Exception: code to learn.

N.B.: There is beautiful code written by single people (e.g. SQLite, REDIS, Dave Hanson's LCC compiler and his beautiful "C: Interfaces and Applications" library [1], Stanford GraphBase) and ugly code written by groups (not giving examples here not to offend folks - some of it is also still very useful, and used by me!).

[1] https://drh.github.io/cii/

Unless you're disciplined or have strong external motivations, there's no incentive to write code that's easy to understand for other people. Everyone struggles with this in all sorts of places in life. Diet, exercise, keeping your house tidy, and so on. Few are self disciplined enough, some need to exercise with a friend, some need a personal coach, some need to have friends over to visit.

While it helps to have other eyes judging your work, expectations can also fade once your relationship with them starts to get closer. For example if you have a relationship with someone where you're both messy, you might be trying to make things tidy for each other in the beginning, but as you start trusting each other and letting your guard down things become messy.

Perhaps something like copilot that focuses on judging you rather than doing the work for you would help. Like a laundry list of areas in the code that are difficult to understand.

This is something I learned the hard way. The value on software frameworks such as Java Spring or Python's Django is that it enables teamwork. At least in theory.

They have higher costs when scaling vertically but as a trade-off, it's easier to horizontally scale by the number of developers.

When I realized this is when I started to enjoy dependency injection tools.

Another solution you can use to protect you from yourself here is using a relatively mature framework, and keep to its conventions.

To underline -- the older, more stable, and more boring, the better!

What you have then is at least some well understood, well documented foundation for others to immediately understand the basic structure and flows of the code.

The hardest thing here is being disciplined about sticking to the conventions, even when they seem suboptimal for your 'special' usecase.

Really try hard to not do things like pulling in 'community plugins' and the like, using language features the framework was not designed to work with, or in the worst case forking the framework or going off on your own path with custom code that reimplements some of its features! Stay as boring as possible!

I have had experiences that contradict this! At the same company there was a ~30kloc frontend built by one developer and a ~20kloc backend built by four developers and the second was much harder to maintain and improve. Multiplying developers on a project can enforce some rigor and extensibility, or it can simply multiply the amount of time and effort available to just hack the next feature in. A single developer can create a mess only they can understand, or they can end up self-enforcing rigor and extensibility in order to handle the scale of the project. (Multiple devs certainly increases the oversight so you’re more likely to know if a mess is being made, so there’s something to be said for this approach).

I would not generalize and say that "a lone developer will always produce unreadable code". It's just that it requires a somewhat rare skill.

Think about it: writing readable code requires putting yourself in the shoes of a future reader/reviewer, while writing a complex piece of code, and often under tight time constraints. That is not easy.

It's also difficult to measure consistently. Lack of clarity has a delayed impact in months or years in the future, while it has some immediate benefits (more features produced more quickly, right now). Often the original author doesn't feel the impact at all, since they have moved out to a different project/team by that time. It is externalized to others.

Because all of this, code maintainability is generally not incentivized at the workplace (while producing new features quickly is). The programmer who "produced a single feature, with very maintainable code" quickly learns that he's less valued that the programmer who "produced 3 features very quickly". Code maintainability is not even in the picture.

I know some very talented developers that really struggle with code readability. For those, pairing with someone else can help. But that other person also needs to have the right skills. They must be methodical and organized - that is not rare in programmers. But they must not be afraid of asking the right questions, and signal contradictions, "slowing down" the other developer. That is less common.

I haven’t experienced this much, as a frontend developer. Not in my own code from years ago and not in other’s code on projects I’ve inherited.

I’ve joined some teams where the code was horrific after rounds of patchwork by people who didn’t understand the system. But by and large, systems made by one person have been really easy for me to work in. Except for the various cases of overengineering by senior engineers or when junior engineers try to apply too many ‘cool’ frameworks that aren’t necessary.

Maybe it’s because most webapps solve simple problems in simple ways. There are collections and entities and relationships and almost everything is a page or a list or a form.

I suspect most of these "problems" aren't really problems. If you're a lone developer and you want to make a 'great' product, then you really don't need to be concerned with writing great code. You just need it to be good enough, just readable enough, and - most importantly, an actual product that people are using.

95% of good software is just well-marketed software. Part of being well-marketing is filling an actual need, and doing it well. When it works, no one cares what's happening under the hood unless it causes a problem.

Part of the issue here is most people do not know how to actually attack a problem together in a non personal way. What I've noticed is one of the following issues:

Can't accept cristicism of their solution. Too much ego.

Don't really care about finding the best solution.

Can't communicate well enough to discuss the problem at hand in the moment.

Don't have enough domain knowledge to add meaningful feedback.

In essence, a lot of features are built by the lone developer. The only saving grace is the process, breaking up the a task into smaller chunks and code review.

I think the lone developer problem is really in truth the lack of good documentation. I have taken over plenty of code that was well documented where I definitely written it that way, but I understood it. In a lot of cases I rewrote parts and made sure that what I changed was well documented.

I have also worked on code where functions or variables were labelled a, b, c or aa, bb and orange! I don't recall who said it but one of the hardest problems in computer science is naming things.

I build everything alone and the way I've solved this is:

1. Use consistent patterns for how you implement things. Don't mix and match; nearly all implementations in a given context/domain rely on the same mechanics.

2. Document the patterns you use. If they're your own, take the time to write up a blog post or tutorial on the how/what/why of them.

This has enabled a surprising number of people to pick up a project I've worked on with very few questions and little effort.

Code has a strong dependency on context. It is not understandable without a context. Hence reading code is much harder than writing it.

More often than not, that context is something you need to guess - by reading the code - and then establish the context. Often it's a best guess because the author did not explicitly document the mental and required technical context by which the software was written.

In terms of coding standards and diverging designs, as other people has mentioned, this comes down to both tooling and leadership. It's an integrity question really; Do you wish to write software that other people understand ?

It's a pretty established fact that the brain only have so much cognitive ability, so by writing software that the brain can absorb is of course key. One way of doing this is writing small and well documented context-based code.

I highly recommend that if you are in a team, set up ruleset for how things should be and have your tool to enforce it. Class lenghts, spaces, variable names, null reference checks etc.

It's easy to be a lone developer. Everyone can write code. If you can get someone else to understand it while reading it, you're one step closer being a really good developer!

The over riding premise seems to be, get feedback. Always a good reminder.

However, this can be taken too far and contributed to me leaving my last job. I was pushed for review on too many things, in my opinion. It got to the point where it was a waste of time trying to decide anything for myself. I had to invite people from multiple disciplines in the off chance a good idea would surface. Not only did it demoralize the experts, it slowed progress from weeks to months with no appreciable difference in quality. Most meetings were met with little or no feedback because the people involved had no experience in the stack. Most suggestions were to solve the problem within their own area of expertise, the web service guy would always suggest a web service, the DBA would always suggest TSQL, etc.

What I would recommend is develop the ability to recognize when more feedback would be beneficial and schedule a review or meeting for that and act like a working professional and take responsibility when things don't go perfectly. Which suggests the real root of the problem and need for getting feedback all the time...

Guys, this is obviously a marketing piece.

The number of developers usually is a velocity problem.... But this guy would like to work with you on the one person code.

The lone developer problem I see is that it's cheap to start things, get them working and then it's really hard and boring to maintain things. So it's just easier to make more stuff.

Like consumerism, development creates stuff that just won't rot away, A lot like polystyrene cups. Code lives too long and of course it gets hard to understand as the domain experts retire or move on.

I work on a legacy software stack that started just before php was invented, Parts of it are php2. There's some aspx junk in there and a bit of crazy c-sharp inside sql server procs. It's wild.

However, I'm learning the business logic as we repair it and port it to a more standard stack. The young people who work with it are also learning it and that helps everyone understand what was going on.

If this project has lasted 5 years the cowboy shit that was done in the 90's wouldn't matter. But here we are, fixing things and writing tests and putting it in CI/CD so we can get a more orthodox boring solution because I know it's easily got another 20 years on the books.

I work alone, but not out of choice.

It's because no one wants to work with an "old."

This is something that the folks currently refusing to work with me, can look forward to.

It's ridiculous. We are highly unlikely to one day, wake up a different race, or [slightly more likely] wake up a different gender, but we will all become "old" (the alternative kinda sucks).

I suspect a lot of SV folks are already experiencing the "hoist by their own petard" problem. This will become a really big deal, with all these layoffs.

Also, the code I write isn't "overengineered," or "spaghetti." It's advanced code. Many modern corporations are obsessed with hiring the least possible qualified candidates, and throwing them at advanced ship projects. In these cases, someone right out of JS bootcamp, is supposed to take over a native Swift iOS app. They won't have fun.

Too cheap to hire the right people? You get what you pay for. Too bigoted to hire experienced people? You get what you ask for.

Depending on what your objectives are, I would argue that code is usually a means to an end, rather than the product. It's great if you enjoy writing beautiful code, but usually shipping it is what counts. It's fun to maintain beautiful code, but there won't be any maintenance if it never ships.

As a single developer, the #1 objective (unless you're working on fun/hobby projects) should be to ship, not to consider future maintainability. People have this perception that code "is permanent", which may be the case for code, but not for the environment its sitting in. Everything changes, all the time. Perfect code will be perfect but isolated from its surrounding progress, if not rewritten, thrown away, redone over and over again.

In most cases, I'd rather ship a product people use, albeit with horrible code, than glance at my Github repo of beautiful code optimizations that have so far gathered zero interest by the rest of the world.

Why isn't "write documentation" in that list?

I mean sweet Jesus, it's 2023. Write some fucking documentation. There are also these things called comments that you can put in your code so you can explain why you're doing what you're doing.

The code shows what, the comments show why. And it's the why that's important.

Anyway, the more code you read, the better you get at figuring out what code does. But instead of reading the code try to understand the intention behind the code. Think of it as you're reading the mind of the person writing it. Are they lazy? Bad? Overly complicated? Weird structure? What do they always do? What are they bad at? How do they approach what they're doing?

There are developers who are too clever by half, and you can see it in the code; they do something in a complicated way instead of doing it the simple way. They do things that look interesting but which have no real benefit.

Unmentioned reason: for the lone developer, the temptation to be "clever," or do interesting experiments is harder to resist. For me, sometimes that's driven by boredom. I've occasionally found myself switching paradigms ("This time I'm going to try a functional style (in python)...") just to keep things interesting, even if in the long run it might not be ideal. Even in the same project! Or, without the guardrails of peer criticism, I'll think "ok, this is a great time to try new library/framework X."

IMHO, there are some benefits to the above! Experimentation and trying new techniques/frameworks is how we learn and progress. The danger arises when the experiments congeal into half-baked production code.

I've often noticed developers seeing a project for the first time and not long after proclaim it as "bad code" and that it needs to be refactored or rewritten (with zero thought as to whether it's good for the customers or the business.)

One way to mitigate this as a solo developer is to step away from the code for a while and forget about the structure. You become the facepalming teammate at that point and start doing a better job of documenting and organizing your code for the day 6 months from now when you need to upgrade something or fix a bug. Eventually you start building with less abstractions, and more clearly worded variables, and better folder structure. Unlike teams where someone can keep making mistakes that impact others, you are your own worst enemy if you have to keep dealing with your own code over time. The solution to incompetence or laziness is ownership.

* If you don’t treat maintainability as a requirement, you usually won’t write maintainable code.

* If you don’t know how differently other people model ideas, you usually won’t write maintainable code.

* If you don’t know how differently you’ll model ideas in the future, you usually won’t write maintainable code.

There’s nothing about being a lone developer that means you won’t write maintainable code, but gaining the perspective necessary to do so requires either experience or feedback. So the lone developer problem is only really a problem for early-career developers and incurious ones.

Hm, I would not call this 'The Lone Developer Problem' but maybe 'Future Comprehension Anomaly' wherein an author today understand their rationale for a design implementation but months down the line, it is as alien to them as it might be to a completely new set of eyes.

One solution is to leave meaningful comments that explain a thought process or design decision where it counts. This nudges future readers of the code in a direction towards total comprehension of the source.

i write a lot of stuff solo. i also realize that 75% of writing software is making sure others can read it. so what I usually do is this:

- write documentation upfront (with Hugo or something like that) to explain what I'm building, why, how to use and/or compile it, and how to test it. i do this before i lay down any code. this also helps me re-justify the time investment i'll be spending on writing the thing. (it is much much easier to maintain documentation before you start coding than after. once you're in the zone, you're in)

- write behavior/end to end tests that describe what major components of the software will do and how they will interact with each other. these tests usually change, but I consider this a second layer of documentation

- make code as readable as possible, i.e. small functions, high modularity, reasonable var names, etc. i also use linters heavily.

- i try to break up major pieces of work into pull requests despite me being the only contributor and explain what happened and what the work introduces within them. i'll also add comments to sections of the code that don't make sense. i use PRs for this instead of git commits or (only) comments because i've found them to be much better at digesting large codebases, and they are great spaces for discussing changes within context.

This was a poorly written blog post by framing this particular situation as a "problem". It becomes a problem when someone acts inside a team or professional organization like this but the article is about single developer projects. There can be many good reasons why code quality doesn't matter in such instances but framing it from the start as a problem is more akin to clickbait. I would expect higher quality content on HN getting upvoted.

Check out Adadot - A tool that helps developers improve as a team and as an individual. https://adadot.com/

Writing a readable, maintainable and future-proof code is a distinct skill, widely different from writing code per se. One-time contractors with fixed result-based pay are tend to ship "just working" code, thus most of closed-source commercial one-developer code is an utter garbage. Looking into open-source projects may give a totally different perspective, because OSS authors are actually care what other will say.

I always consider this a corollary of Conway’s law.

In the absence of any organizational division of labor, there is no communication structure which the system is forced by Conway to mimic, so instead other attractors in architectural space dominate - notably the ‘big ball of mud’ which is where code wants to end up unless you continually fight the entropy gradient with frequent refactorings and trimming and cleaning internal boundaries.

A lone developer within a strong engineering org probably creates better code b/c they'd would need to have the street cred to solo a project.

The opposite would happen in orgs where one person who happens to be the most technical has the responsibility for all the development

Adding more people decreases the variance. The end result is usually a bland standard which some people may like b/c it hooks into existing mastery.

Single developer work is akin to single point of failure. This article brings to memory a famous article from an author name that it eludes me at the time. The article reads a line that goes alone this idea: "With enough eyeballs, all bugs are shallow". You wouldn't board a plane that was built by one single guy right?

This is my experience as well. I built an app in Go from scratch without prior experience in Go. I have 5 years experience in general, but in other languages.

The start was not bad and I think code was pretty good, but now I feel like lost my way at some point, and code has started degrading.

I hope when we hire new developers they will not hate me as much as I think.

This is the power of teams of software developers. When it comes to maintenance, if each team member remembers the same 40% and a few team members each uniquely remember 5%, then the team has only forgotten a small percentage of the code and can work together to produce those "Oooh now I remember what this is" moments.

Even you're in a team, same thing happens. Which causes the illusion of "seniority" when you think you're experienced.

It's not. Most of the time, you're debugging messy code. It's not the experience one might want to accquire. It's like ad-hoc knowledge.

Lone developer or not is not the issue.

I generally agree but for my own side projects, I like to keep a lot of code in one class if it makes sense to be there so I'm not jumping around a lot. For work code, I follow SOLID, DRY and 12 Factors so multiple people can be working in multiple classes and not usually running into conflicts.

Too many times have I found myself looking at some code I wrote couple of months back that don’t really make any sense, and then proceeding to refactor it only to find out that the original code was there for a reason… documentation is the key

A solution I thought about is documenting the architecture of your codebase.

It's not just a lone developer problem. Jumping into a sizeable, foreign, codebase is always daunting for me because pieces are often inter-related.

I think this is true. Single developer code is often hard to read and understand. However, team-developed code is also often hard to read and understand.

Are we sure this isn't just because lone developer projects are more likely to have the whole dev team gone when you want to ask questions?

I basically do user studies on people using my modules and code. It’s so effective that I’m just perplexed that nobody else seems to want to do it.

Wouldn't extensive comments alleviate this? Older appliances used to come with schematics and manuals so you could fix them.

Sounds like this theoretical lone developer doesn’t bother with TDD. Or documentation. Both of which are the antidotes to chaos.

Wasn't redis (often considered an incredibly approachable codebase) initially written by one person?

Does this apply so much when there's model boilerplate, folder structure tooling?

If a lone developer does things like design documents, flow charts to explain infra and documentation.

I think the lone dev would be a problem if they didn't setup with a commercial interest. Not to mention time to setup everything properly instead of just getting things working.

"Beware of a guy in a room." --Jim McCarthy

Software should be developed by teams, period. Ideally with pair or mob programming, but with some sort of code review process for each commit at least. This is how you knowledge share and prevent understanding from being siloed in the mind of a single developer.

A good example from the open source world is the works of Fabrice Bellard. Fabrice has a tendency to one-and-done his legendary feats of coding, moving onto the next thing after he'd written something he deems complete. For projects like ffmpeg and qemu, maintenance teams have stepped up to keep them alive but the first, daunting task is always figuring out how the hell he did everything.