- Silently checking in 12000 lines of code in the middle of the night and leapfrogging the entire development schedule by months.
- Spending 72 consecutive hours at the keyboard, sustained by caffeinated drinks and a desire to produce an end product that will make your users - and other programmers say 'Wow!'
- Delving into the voodoo and deep magic of a system, consuming it all and spitting it back out with ease, and being regarded with awe by your peers.
Yeah, these are awesome. The Story of Mel was an early encouragement to me; between it and the movie Tron, it put me on the path to being a software developer.
Lots of folks pointed out pro- arguments, so I won't cover those, but there are an awful lot of cons. 20 years plus into my career, I'm seeing some fatal flaws.
The first is the Bus Factor. A solo developer, whether in a group or not, does not facilitate the dispersal of knowledge. There's a difference between documentation - even the elusive technical documentation - and knowledge, and that gulf widens with each feature, bugfix, and release. In my experience, when a solo developer leaves - for whatever reason - it's often easier to start from scratch than try to maintain their software.
That leads us to the next issue, maintainability. As was described above, a solo developer can skip quite a bit; coding style, documentation, modularization, naming schemes, readability, unit testing, automated build and deployment, and so on. I've had to take over so many projects in my life that required more time to set up a working build and test environment than they did to fix the error I had been brought in to tackle. I used to carry a pack of cd's with precompiled versions of sed, awk, as, and other tools for various *nix platforms (and versions of those platforms) because these were often not just pre-requisites for the often complex script-based builds, but often only came in for-pay packages that weren't on the machine I was expected to work off of. I had a set of about 30 just for HP-UX alone (because you have no idea which version-specific behavior a given build relies on). Put it this way: every build required a port.
Of course, it's not just other people's code. I'd come back to something I wrote a year prior and it'd be horrible.
"Why did /THEY/ do this? Wait ... did I do this? Geeze, I USED to write bad code." - me, every. single. time.
I have a theory that only constant modifications to code keeps away the gremlins that cause bitrot. Leave a piece of code alone for a month, no commits (assuming you're even using version control), and they come in and crap all over your beautiful hacks and graceful architecture, rendering it just barely capable of doing what it was designed to do, and sometimes not even that. Yet, you write your code as if a team will handle it, losing most of the benefits of being a solo dev, and it's usable when you come back to it later.
Communication is next, and it ties into the maintainability above, but on a software development lifecycle level. When someone is silently making architectural changes and off doing their own solo thing, sure, they get a lot done. When you're completely by yourself, that's fine. What happens though, when you're doing solo development in a large company? Suddenly there's no code reviews, no understanding of department or organization architectures, or even just updates to them. Your code usually stands on the back of a whole architectural stack, and without two-way conversations, it isn't guaranteed to hold up. It's not just that you might accidentally reinvent the wheel - it's that you could do it wrong and limit the application (or have it die) later, with an expensive to fix systemic issue. Documentation fits in this category too - and why do documentation when you're a solo dev? You can always answer any question, right? You're available 24/7, so your users and other devs shouldn't need it ...
QA is another huge issue. It's very well established that the worst QA engineer is the developer that wrote the code to be tested. Even with tools giving you 100% code coverage, you're probably missing significant permutations just in your unit tests. Assuming you even do any of that. After all, as a solo developer, even unit tests lose most of their value - no code is modified outside your purview so you don't have to worry about regression or integration bugs, and there's no need for tests-as-requirement-documentation, since there's no need for documentation. All that's before we get to system, workflow, or use-case testing.
The last big con has to do with scaling. It's not that a single user can't manage a large codebase. It's that attention is a finite resource. What attention we apply to one set of features is necessarily removed from others. We can only keep so much in the front of our brain at a time, and often I see the solo developer fumble when it comes to interface/api interactions, thread management and synchronization, and other systemic problems.
So, yeah, I'm drawing a distinction between a solo developer who writes code like a solo developer and gains the benefits and detriments associated therein versus a solo developer who writes their code as if someone else is going to read it and eschews all the possible advantages. Personally, I feel everyone is better off if they'd be the latter, rather than the former, but I think the only way people understand this is via experience.