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

161–170 of 180 posts

Re: The Lone Developer Problem

#161

Post by CharlieDigital »

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…

Fred Brooks had a term for this: Conceptual Integrity. When there's one mind working on the codebase, it's natural that it will have a higher degree of Conceptual Integrity.

A team can achieve this, but they need to have been working together a long time or have a very, very strong technical lead.

For the single developer case, I think maintainability and scalability then comes down to whether the developer follows good practices or not. Commenting, refactoring, reorganizing code, unit testing, etc. But a product or codebase with high Conceptual Integrity is generally easier to expand on because there are common patterns throughout the code, even if it's lacking in comments.

Re: The Lone Developer Problem

#162

Post by jonnycomputer »

jwrallie wrote: post #141

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…

if only i were more successful at predicting which pieces of my software would end up carrying on and on.

I've been at my position long enough (as sole dedicated dev on the team) that 90% of the problems in the code base are my own damn fault.

Re: The Lone Developer Problem

#163

Post by saiya-jin »

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…

my experience too - if I am the guy for that piece of software (supporting testing, fixing prod issues etc.) then I have all the motivation in the world to make my work as simple and effective as possible. No place for fluff just because its in the vogue and 'big beards' of industry talk about it.

Measure of success of software is pretty straightforward in normal situation - users are happy using it, they don't care about technical details a bit. That and efficiency via simplicity above is how to do this for a decade, instead of building 1-man cathedrals with practically inevitable results

Re: The Lone Developer Problem

#164

Post by avgDev »

bruce511 wrote: post #40
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.

Obviously experience will vary from person to person. But your point is well made. The quality of the code depends a lot on the quality of the programmer. Better programmers write better code. Of course very few of us are great programmers on day 1. we learn and get better. I'm spending a reasonable amount of my time now re-writing code I built 25 years ago. Equally, we grow better, and learn faster, when we get feed…

I have been a lone programmer for a few years.

Whenever, I'm doing bug fixes I dive deeper into "how someone else would approach this".

It is actually quite easy to keep improving on your own. I read books on refactoring, clean architecture, etc. as part of my daily routine. The time not spent debating with another dev is spent learning.

I guess as a lone dev it is easier to do no self-improvement and keep apps chugging along until something terrible happens.

Re: The Lone Developer Problem

#165

Post by ted_bunny »

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…

Why isn't a "when in Rome" attitude more common? Personally I'd feel obligated to copy the existing style, if it's not my project.

Re: The Lone Developer Problem

#166

Post by ChrisMarshallNY »

fhd2 wrote: post #122
danjac wrote: post #106

Earlier quoted context omitted.

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.

In Apple development, there's actually a couple of programming methodologies that were specifically designed to make the code more complex, so it can be farmed out to multiple devs.

In my experience, it's a real good idea to stick to writing basic MVC, when working alone, on a UIKit codebase. If I was working with SwiftUI, I would probably consider MVVM, but I don't really like to take it much past that.

Re: The Lone Developer Problem

#167

Post by pc86 »

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've been places where this has happened, but it's usually a fairly easy fix. Two things that are usually not that controversial: 1) Comments on unmodified code are either deleted/ignored or you create a ticket for the actual issue (and whoever made the comment is reminded this isn't helpful or appropriate in a review). 2) Nitpicky/stylistic things are handed via prettier, precommit hooks, etc. so that everything is consistent and largely doesn't need to be thought about.

And the potentially controversial one: anyone can merge into [almost] any branch, and you merge your own code - so quite often you'll get a PR approval and might wait a day or two to merge it until you decide it's ready. We let anyone merge into any branch but our production branch, however that gets merged automatically and deployed daily unless it's proactively cancelled.

Re: The Lone Developer Problem

#169

Post by Consultant32452 »

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…

Similarly, my experience is that it requires a single person on the team who cares “too much” about code quality, consistency, etc. They basically forced everyone to comply. This is not intended to be a negative.

Re: The Lone Developer Problem

#170

Post by jshier »

ChrisMarshallNY wrote: post #153
jwrallie wrote: post #141

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…

> 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. I feel your pain. I am the main coder, in a small team. There's one server guy (part time), and one semi-technical graphic designer (also part time), a couple of admin/marketing folks (also part time), and me (full, full time).…

Usage of the nil coalescing operator is not advanced. You've simply used it in a way that makes it less comprehendible to anyone not already familiar with the operator. Any actual Swift developer should be able to understand what's happening. But frankly, this isn't good code, and not just because you're using coalescing like that.

1. You should never have to use a raw object like that. Use a Decodable type and get a real Double from the parser. Among other things you have no error handling here to tell you when that as? Double cast fails. First thing you do in Swift is embrace the type system.

2. Fallbacks like that probably shouldn't be done inline. Instead, there's usually a facade on top of things like UserDefaults to properly name and handle different properties consistently. Using rawValue that much should be an obvious smell.

3. Use of untyped Any is almost always a bad idea in Swift. Create a proper type that encapsulates exactly what you should see and you'll likely write less code with fewer bugs.

4. A CLLocationDistance created from .greatestFiniteMagnitude is obviously an invalid value, so I assume you're checking it further down the line to see that. Better to just produce an error or a nil value when you don't have an actual distance than to pollute your system with invalid data.

Post reply on HN