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

11–20 of 180 posts

Re: The Lone Developer Problem

#11

Post by josephg »

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…

Yep I absolutely agree. As the old quote goes:

"Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious." -- Fred Brooks, The Mythical Man Month (1975)

Its always mystifying to me how often programmers try to show me a new concept in their code starting with some complex functions. Start with your data structures. What data are you storing, why, and when? If you show me that, the code that actually moves that data around is usually pretty obvious. (And if not, your code will be 10x easier to understand once I understand the context).

Re: The Lone Developer Problem

#12

Post by MathMonkeyMan »

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…

A lot of celebrated software began as a guy in a room, and later was adopted by others because they thought it could solve their problems. The software never would have existed in the first place were it not for the lone person in the room.

unix, linux, git, perl, python, c++, javascript, clojure, grep, winamp, ...

If software is constrained to resemble the communication structure of the organization that produced it, well then programmer politics are _boring_, while an individual's mind is _novel_.

Re: The Lone Developer Problem

#13

Post by gavinhoward »

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/branch/master/manua...

[2]: https://www.theguardian.com/books/2008/sep/20/fiction

Re: The Lone Developer Problem

#14

Post by ipaddr »

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.

Re: The Lone Developer Problem

#15

Post by gavinhoward »

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…

> Software should be developed by teams, period.

I disagree.

I have a project developed 96-98% by myself (depending on how you count) that is shipping with FreeBSD and Mac OSX.

It's not common for that to happen, but it certainly can. And for the programmers that work best alone, sometimes they will pull off something nice.

Re: The Lone Developer Problem

#16

Post by whateveracct »

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.

Re: The Lone Developer Problem

#17

Post by swatcoder »

munchbunny wrote: post #9
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 would prefer to read someone's mental model of how the code works than the code itself. I find this is often true for me. If there's a bunch of code that I'm having a particularly hard time understanding, it's usually because I don't actually have a working mental model of what the thing is supposed to do. Problem is, with complex systems often the way to record the mental model is something like a design documen…

I think the success of notebooks can provide a positive influence here.

They give text and readability a higher priority than traditional source code artifacts, and it really might only take a fresh IDE/plugin and comment meta-syntax to make that more normal in production code as well.

Re: The Lone Developer Problem

#18

Post by fwlr »

I have had experiences that contradict this! At the same company there was a ~30kloc frontend built by one developer and a ~20kloc backend built by four developers and the second was much harder to maintain and improve. Multiplying developers on a project can enforce some rigor and extensibility, or it can simply multiply the amount of time and effort available to just hack the next feature in. A single developer can create a mess only they can understand, or they can end up self-enforcing rigor and extensibility in order to handle the scale of the project. (Multiple devs certainly increases the oversight so you’re more likely to know if a mess is being made, so there’s something to be said for this approach).

Re: The Lone Developer Problem

#19

Post by [deleted] »

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…

[deleted]
Post reply on HN