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

141–150 of 180 posts

Re: The Lone Developer Problem

#141

Post by jwrallie »

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 some software that only exist to fix a particular issue that doesn't require change over time. The typical Perl script that lives unchanged for years doing a single task. For this particular case, quality matters less than portability and relying on solid dependencies that do not require maintenance.

In the end, management does not care about code quality, as long as money is flowing.

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.

Re: The Lone Developer Problem

#142

Post by rglover »

I build everything alone and the way I've solved this is:

1. Use consistent patterns for how you implement things. Don't mix and match; nearly all implementations in a given context/domain rely on the same mechanics.

2. Document the patterns you use. If they're your own, take the time to write up a blog post or tutorial on the how/what/why of them.

This has enabled a surprising number of people to pick up a project I've worked on with very few questions and little effort.

Re: The Lone Developer Problem

#143

Post by kardianos »

As a lone developer, there is some truth. But a good lone developer is still consistent, more consistent then a team. The problem with the lone developer is they often get their efficiency by being "weird". However, I still code review my own code and catch issues with it. To be blunt, most people (developers included) don't actually learn new things easily and when they see a "weird" code base their learning mind shuts down. They aren't used to efficient patterns; they are used developers writing dumb CRUD code that is easy to "understand" but in truth do almost nothing of value.

Re: The Lone Developer Problem

#144

Post by ArcMex »

Hm, I would not call this 'The Lone Developer Problem' but maybe 'Future Comprehension Anomaly' wherein an author today understand their rationale for a design implementation but months down the line, it is as alien to them as it might be to a completely new set of eyes.

One solution is to leave meaningful comments that explain a thought process or design decision where it counts. This nudges future readers of the code in a direction towards total comprehension of the source.

Re: The Lone Developer Problem

#145

Post by hugocbp »

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…

I tend to agree with this as well.

In my own experience, dealing with software written with "forced collaboration" (meaning bringing more than 1 developer just for the sake of saying it was done by a team) usually results in more difficulties in later maintenance than the other way around. Specially in micro/tiny services, where sometimes one person can do most of it quickly.

I agree with you take and had the same feeling that the author just seems to have faced one of those cases and extrapolated.

Re: The Lone Developer Problem

#146

Post by synergy20 »

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…

this is one reason i am picking up golang,in the hope it is more consistent by design thus better for team projects.

on the other hand,soon copilot etc may become the true lone developer for all,though i am unsure if it will have a consistent style,it certainly can

Re: The Lone Developer Problem

#147

Post by MiyamotoAkira »

blue039 wrote: post #58
bitwize wrote: post #5

"Beware of a guy in a room." --Jim McCarthy Software should be developed by teams, period. Ideally with pair or mob programming, but with some sort of code review process for each commit at least. This is how you knowledge share and prevent understanding from being siloed in the mind of a single developer. A good example from the open source world is the works of Fabrice Bellard. Fabrice has a tendency to one-and-don…

Mob programming is such an asinine concept to me. It's like all the people saying holotropic breathwork cures cancer. It's just developer mysticism. There is no amount of himing and hawing that would get me to believe treating one guy, capable of his own expression, as a code-input robot while developers around him bark commands at him is actually productive. Each line of code is so expensive and the probability of a…

> as a code-input robot while developers around him bark commands at him is actually productive.

Nothing to do with mob/ensemble programming. At the end, is a discussion that a) make code easy to understand b) create shared knowledge c) avoid unnecessary work.

Re: The Lone Developer Problem

#148

Post by bob1029 »

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…

> but not real 'team work'

I don't know about this.

There is a large cohort of skilled developers that are desperate for a competent technical leader to come in the room, give them a well-defined work area and let them build widgets exactly to contract specifications. For many, it feels really good to complete these quests. Being placed in front of a blank canvas is overwhelming for most. It takes a lot of patience and experience to start from literally zero with no constraints in sight.

As a technical leader / architect, you don't have enough time to realize your vision throughout. Others have to help. This is exactly what team work looks like.

If some developer is not happy with "helping", then they are welcome to try and carry the entire double-edged sword that is owning 100% of the product architecture. Being king is fantastic when the peasants and customers are happy. It is the worst experience on earth when there is unrest.

Let's be clear - Design by committee works (engineering standards bodies, web standards, et. al.) but this path is usually not competitive in a typical startup environment.

Re: The Lone Developer Problem

#150

Post by MiyamotoAkira »

samsquire wrote: post #4

This might be unusual but I would prefer to read someone's mental model of how the code works than the code itself. With thousands of files and thousands of lines of code it's difficult for me to work out how the code fits together. If you document your mental model of how the code works, I can probably map the code to your mental model and understand the code. I want/like people to create "entrypoint" packages/folde…

> This might be unusual but I would prefer to read someone's mental model of how the code works than the code itself.

The hypothesis under Peter Naur's (the N on BNF) "Programming as Theory Building" paper is that transmitting (by talking) the mental model is far more important than other format of documentation to understand a system.

Post reply on HN