Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Lone Developer Problem

evanhahn.com

Post reply on HN
Print view View original

111–120 of 180 posts

Re: The Lone Developer Problem

#111

Post by sjducb »

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.

Re: The Lone Developer Problem

#112

Post by sethammons »

danjac wrote: post #104

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 look…

This note serves mostly to stand vigil against project requirements for 100% coverage, which I've seen a few clueless leads or managers attempt to implement for teams.

100% code coverage as a requirement is usually a waste of time and resources. Test code, especially units, at their edges. This frees you to change implementation details while preserving functionality. In two decades of experience, the best codebases I've worked on have around 50-80% coverage in unit tests. 100% is a false sense of security as bugs still present themselves to users. I've also seen devs burn days of effort chasing code coverage metrics, days of nearly zero-value add to the quality of the project.

I completely agree that "good test coverage" is critical; I've just not seen that it extends to 100%. Pre-commit hooks for linting and formatting and automatic test runs are all best practices. Dog fooding does some amazing things in terms of usability.

Re: The Lone Developer Problem

#113

Post by hyperpape »

globalreset wrote: post #22

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.

One way to put it is in that single developer code will have more variance, when compared to code developed by a group. This variance has a range of effects, and will sometimes be positive, sometimes negative. Certain idiosyncracies are unlikely to survive work in a group, which can be good for the group. But in the case of a single talented unicorn who is inclined to write well-architected code, a group will inhibit that, as each individual pulls in different directions.

Re: The Lone Developer Problem

#115

Post by cauliflower99 »

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.

Re: The Lone Developer Problem

#116

Post by robertlagrant »

danjac wrote: post #106
globalreset wrote: post #22

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.

As a sole dev you are also pushed towards simplicity, because your time and scope is so limited. So a larger team might build some intricate DDD-microservices architecture with a services bus and a complex SPA frontend because, why not? That's what everyone else does. As a single developer managing multiple microservices or separate backend/frontend codebases is a lot of overhead (unless it's a learning project). You…

This is true - you may (possibly) end up in a scalability dead end, but you will likely have been far, far more efficient along the way.

Re: The Lone Developer Problem

#117

Post by davnicwil »

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!

Re: The Lone Developer Problem

#118

Post by jll29 »

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/

Re: The Lone Developer Problem

#119

Post by jdthedisciple »

jll29 wrote: post #118

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 th…

Not to speak against good code but I'm pretty sure users don't care about the code. Just look at the famous Nomadlist story.

Maybe you meant the edge case of 0 co-developers, which in reality isn't so much of an edge case.

Imho it's all about cutting edges at the right places and making educated compromises.

Re: The Lone Developer Problem

#120

Post by mightymosquito »

whstl wrote: post #108
flohofwoe wrote: post #91

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 sprea…

Yeah, exactly the same in my experience too. In fact, the biggest software atrocities I ever saw were team-based, with people having different opinions and wanting to modify the architecture every six months. And getting away with it because there was no vision. This is where a good team lead or technical lead, or even Fred Brooks' "Surgical team", or your example of "single developer and contributors": have one pers…

+1 on this
Post reply on HN