Ask HN: Whatever became of the solo programmer?
Fast forward to today: nearly every software development job advert talks about teams, or specific team-oriented practises ("SCRUM", "Agile", etc.). Searching for "solo developer" or similar brings up a long list of articles about why working on your own is problematic, a few talking about historical solo projects (while pointing out that "we don't do stuff like this any more") and basically nothing in defence of the solo programmer. About the closest I can find to such a defence comes -- a little surprisingly -- from the XP people [1]. This is counter-intuitive to me: tooling has generally improved since the 80s (with a few reservations) and the range of libraries available has increased massively. So a solo programmer has extra leverage and ought to be able to achieve more today, not less.
I suspect there's a degree of ascertainment bias here due to plenty of successful solo programmers churning out useful code but not feeling too much urge to write about it. But really, it does seem like there has been a change over the past decade or so, and very few people are willing to speak out for the solo coder.
Can anyone think of any exception?
[1] - https://web.archive.org/web/20160709203742/http://c2.com/cgi/wiki?TeamOfOne
6 comments
[ 4.2 ms ] story [ 30.4 ms ] threadAnd although you're talking about solo... There's was a 2-man dream team in the DC area. Not sure if they're still working. They would tackle any project and get it done fast. Any language or tech stack. Design docs, requirements, working project, everything. They tackled in-distress projects where a large team and multi-million dollar budge failed.
For commercial software, another constraint is time: a solo developer might be able to create some software in two years, but the product is needed in six months. So the work gets split up.
There are also risk management issues. If there's only one person working on a piece of software, the project takes a big hit if that person leaves or suffers a debilitating accident (there's a "bus factor"[1] of 1).
And there are quality issues: if only one person understands the code they're writing, who's going to review the code to make sure there are no serious bugs or security holes?
I still work pretty much as a solo programmer, but within a large organization. I work on an important component of a large software product, and I'm the only developer who works on (or even understands) that area of the code. I do, however, interact a lot with other groups whose code interacts with mine.
[1] https://en.wikipedia.org/wiki/Bus_factor
Do you hear the "bus factor" and/or lack-of-code review concerns much? If so, how do you respond?
Regarding code reviews: I try to test and self-review my code thoroughly, and hope that the QA people find the bugs that I don't find. My bug rate seems to be comparable to other parts of the product that are worked on by multiple developers.
As for bus factor: if they insist on adding more people to the project, I could deal with that, but it wouldn't make me particularly happy to manage people (I've done it before, but I prefer just being a developer).
That said, greenyoda does bring up some good points: time, risk, and quality are very much issues with the solo approach. But I see these more as opportunities to be addressed via new products or services as the number of solo development businesses grows...