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

121–130 of 180 posts

Re: The Lone Developer Problem

#121

Post by austin-cheney »

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…

Originality complex, the ability to write original software and document it, is a consideration of personality more so than intelligence. Due to cultural norms and selection bias most people will believe the opposite because education and institutions filter only on intelligence.

I recently learned that conscientiousness correlates negatively with intelligence at about -0.27 which means more than a quarter of the population can organize and architect better than highly intelligent people. This can explain why reliance upon frameworks and third party tools grows proportionally with the size of the team. A single author solving original problems will be less inclined to maintain and juggle concerns beyond the scope and control of their focus area where as larger teams are more inclined to preference administrative concerns, for example configurations and dependency management, over solving for originality.

Re: The Lone Developer Problem

#122

Post by fhd2 »

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…

Or in other words: Conway's Law makes single developer code bases less complex, since there's no communication and responsibility boundaries reflected in it.

That said, I've seen a lot of small teams create a ludicrous amount of microservices. One per independently working team is my usual heuristic.

Re: The Lone Developer Problem

#123

Post by danjac »

sethammons wrote: post #112
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 mean sure, in principle I'd agree with the 50-60% for the average team as a decent metric (and as a caveat, targeting the most business critical or complex parts of the software). As a single developer (and time and needs allowing, of course: a throwaway little project might not warrant any testing) I aim to get as high as possible just because I don't have that coverage that comes from having other people looking at my code.

I know there will still be bugs, particularly in harder-to-test things like the UI, browser issues etc, but it gives me more confidence to move a bit quicker when I don't have others to check me.

Re: The Lone Developer Problem

#124

Post by klabb3 »

cs02rm0 wrote: post #105
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…

Completely agree. I think the flaw is that someone believes they turn up to a project and in reviewing code to fit it to a mental model they understand they believe they're improving the readability for others who think like them. In reality it becomes design by committee, worst of all worlds. Slightly tangential, but I'm about to leave a project where it gets the review process badly wrong - anyone can and will comm…

> I'm about to leave a project where it gets the review process badly wrong - anyone can and will comment on a review, but only a select few can merge.

Ugh, I definitely recognize this. There is often a lack of management behind those things. My heuristic is: If I can’t do my job, I tell my manager and ask for help. If they can’t fix it, there’s no point in going on.

Re: The Lone Developer Problem

#125

Post by matwood »

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…

This is how I have worked most of my career. It takes checking everyones ego, but turns out great software. Also, the same person doesn't have to be the surgeon on every project. If the project is small enough that 1 person can lead with the vision and everyone else helps, it produces a great outcome.

Re: The Lone Developer Problem

#126

Post by danielovichdk »

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!

Re: The Lone Developer Problem

#127

Post by matwood »

cs02rm0 wrote: post #105
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…

Completely agree. I think the flaw is that someone believes they turn up to a project and in reviewing code to fit it to a mental model they understand they believe they're improving the readability for others who think like them. In reality it becomes design by committee, worst of all worlds. Slightly tangential, but I'm about to leave a project where it gets the review process badly wrong - anyone can and will comm…

> They have a massive bottleneck of reviews with many held up by conflicting style preferences

Stuff like this is so frustrating. And it's not only the reviewers fault. I don't consider myself a great coder, but a skill I do have is being able to fit my changes into the codes existing style. Consistency trumps any partial incremental improvement. Unless I have the time and desire to fix the entire code base, new code needs to fit in with the old.

For some reason, I've seen many programmers have a hard time with fitting the style of the existing system. This makes every small change slightly different from others and over time makes the entire system harder and harder to reason about.

Re: The Lone Developer Problem

#128

Post by bregma »

whstl wrote: post #109
skissane wrote: post #69

Earlier quoted context omitted.

Something I’ve repeatedly observed in my career: the rewrite is started, but it never gets finished, and then the rewrite and the original coexist long-term “Never gets finished” takes different forms. Two I’ve observed: Form (1): half the product gets rewritten in the new language/framework/stack, but the other half stays in the original - for whatever reason, rewriting the other half never happens. I once worked on…

Another common issue is the product team just going crazy with new features on the rewrite. Which makes sense from a business perspective but turns it into a Frankenstein-rewrite and dramatically increases the chances of "never getting finished".

Ah, Fred Brooks' Second System Syndrome.

Re: The Lone Developer Problem

#129

Post by klabb3 »

ricardobayes wrote: post #85
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.

This works if there's no time pressure involved.

This is key. Good projects are based on good ideas. Good ideas take a lot of time to develop, and often involves back and forth, iterations, friction and failure.

If you have a good data model and technical architecture, the code almost becomes good on its own, even if it’s implemented by more people that understand the model. The problem is that it’s irrational to spend that amount of time, and it’s directly opposed to incrementalist mainstream paradigms of software development. It’s the process that almost has to happen outside of companies, because management would never let projects be executed in such a way. But when there are personal drivers (either by the creative aesthetic types or sometimes the hacker tinkerer types) you can sometimes, depending on the domain of the problem, get some really coherent systems that make people go “this makes sense, why would it be done any other way?”.

To me, the story of git has many of those traits, especially when comparing to what existed before.

Re: The Lone Developer Problem

#130

Post by re-thc »

austin-cheney wrote: post #121
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…

Originality complex, the ability to write original software and document it, is a consideration of personality more so than intelligence. Due to cultural norms and selection bias most people will believe the opposite because education and institutions filter only on intelligence. I recently learned that conscientiousness correlates negatively with intelligence at about -0.27 which means more than a quarter of the pop…

It's worse than that.

Education and institutions often filter on certain subsets of intelligence or just good memory.

A lot of exams are a memory test. A lot of courses related to software development are either out of date or don't model the current trends / best practices.

Post reply on HN