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

21–30 of 180 posts

Re: The Lone Developer Problem

#21

Post by charlie0 »

Part of the issue here is most people do not know how to actually attack a problem together in a non personal way. What I've noticed is one of the following issues:

Can't accept cristicism of their solution. Too much ego.

Don't really care about finding the best solution.

Can't communicate well enough to discuss the problem at hand in the moment.

Don't have enough domain knowledge to add meaningful feedback.

In essence, a lot of features are built by the lone developer. The only saving grace is the process, breaking up the a task into smaller chunks and code review.

Re: The Lone Developer Problem

#22

Post by globalreset »

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.

Re: The Lone Developer Problem

#23

Post by owyn »

ipaddr wrote: post #14
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…

That's a recipe for the worst code base. Pair programming is designed to level up someone while bring down the other which is helpful in some situations but not in most. If you have two people who know little perhaps together they can produce something. Large teams break up tasks so individuals can work on pieces that fit together. Imagine a team of 20 sitting around debating that next line.

Pair programming is designed to level up someone while bring down the other

Wow, that is not what pair programming is "designed to do" at all. I never felt like pair programming brought me down. One of the best ways to learn something is to try and explain it to others. I am not talking about pair programming where one person just types like a robot and another one explains what to do. I'm referring to the situation where two people work on a problem that one of them is having. I think both participants benefit. In explaining the problem you have, you learn. In offering possible solutions, especially ones that don't work, you also learn. When you solve it together, you build teamwork. I really don't see any downsides. Especially with remote work, it's a great way to share knowledge and build rapport with your team mates. What real project is specified to the point where all programmers are interchangeable and can work separately without EVER talking to each other?

Re: The Lone Developer Problem

#24

Post by DawsonBruce »

I’ve recently joined a team where the vast majority of the code used across different projects has been written by a lone developer. The code quality is quite good, however, nothing is documented thoroughly and it’s mostly understood by a single person.

We’ve started to code review all new code being merged to the the codebase, we’ve been pair programming occasionally, and I’ve also been writing documentation about how to use the code as I get a handle on it. It’s been helpful so far.

Please document your code. Please provide examples.

Re: The Lone Developer Problem

#25

Post by swatcoder »

owyn wrote: post #23
ipaddr wrote: post #14

Earlier quoted context omitted.

That's a recipe for the worst code base. Pair programming is designed to level up someone while bring down the other which is helpful in some situations but not in most. If you have two people who know little perhaps together they can produce something. Large teams break up tasks so individuals can work on pieces that fit together. Imagine a team of 20 sitting around debating that next line.

Pair programming is designed to level up someone while bring down the other Wow, that is not what pair programming is "designed to do" at all. I never felt like pair programming brought me down. One of the best ways to learn something is to try and explain it to others. I am not talking about pair programming where one person just types like a robot and another one explains what to do. I'm referring to the situation…

Yeah, not all people work optimally that way, and many of those that don’t do uniquely good work regardless. There’s room for all of us.

> What real project is specified to the point where all programmers are interchangeable and can work separately without EVER talking to each other?

I have no idea what this has to do with anything that anyone said here. But lots of projects don’t require a lot of ongoing collaboration. You may just be working in a very particular sector if you’re kicking around all these narrow absolutes. It’s a really big industry with lots of different practices and projects.

Re: The Lone Developer Problem

#26

Post by owyn »

gavinhoward wrote: post #13
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…

> 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 agree. This is something that I tried to do with my best project. [1] Only time will tell if I succeeded because it's really hard to document a mental model; it's like trying to explain to yourself what water is when you're a fish. [2] [1]: https://git.gavinhoward.com/gavin/bc/src/bra…

This is great! I don't know if I'll have a project that I expect to last long enough to worry about bus factor, most of the work I do is either throw away stuff for myself or already part of a large shared team effort. But I love the idea. It's long but I skimmed it quickly and I think it's got a very good level of detail and is overall very readable with just the right amount of snark. :)

Re: The Lone Developer Problem

#27

Post by nickpeterson »

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…

I’m sure there is a real name for this, but I tend to call it a “Document of Intent”. It isn’t meticulously trying to explain every nuance, it’s a coarse treatment of the purpose of things and what they’re meant to do.

Re: The Lone Developer Problem

#28

Post by protonbob »

DawsonBruce wrote: post #24

I’ve recently joined a team where the vast majority of the code used across different projects has been written by a lone developer. The code quality is quite good, however, nothing is documented thoroughly and it’s mostly understood by a single person. We’ve started to code review all new code being merged to the the codebase, we’ve been pair programming occasionally, and I’ve also been writing documentation about h…

What does well documented code look like for you? For me if I look at a new (webapp) repo I start from the controller level and look at the services and models. Would a good swagger page count as good documentation? My worry with documentation is that it can lie but the code doesn't.

Re: The Lone Developer Problem

#29

Post by paiute »

whateveracct wrote: post #16
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…

I do this for all code I add devs to or hand off to. For instance, startup code I walk away from and hand over to contractors. A markdown doc with some high-level concepts + a hierarchical bulleted list explaining the module structure goes a long way.

it's amazing how uncommon this is in the big business world. Individuals have pride, cogs do not. I've been in both camps. Currently I'm a cog because it's better for my life at the moment. I'm frustrated by the lack of simple documentation - but at the end of the day I'm not really interested in fixing it.

Re: The Lone Developer Problem

#30

Post by gavinhoward »

owyn wrote: post #26
gavinhoward wrote: post #13

Earlier quoted context omitted.

> 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 agree. This is something that I tried to do with my best project. [1] Only time will tell if I succeeded because it's really hard to document a mental model; it's like trying to explain to yourself what water is when you're a fish. [2] [1]: https://git.gavinhoward.com/gavin/bc/src/bra…

This is great! I don't know if I'll have a project that I expect to last long enough to worry about bus factor, most of the work I do is either throw away stuff for myself or already part of a large shared team effort. But I love the idea. It's long but I skimmed it quickly and I think it's got a very good level of detail and is overall very readable with just the right amount of snark. :)

Thank you so much!

I wrote it in snatches of time nearly always late at night, so the snark just...happened. I was worried how it would be taken, so thank you for the encouragement, including about the level of detail.

Post reply on HN