The Lone Developer Problem
evanhahn.com
The Lone Developer Problem
1–10 of 180 posts
Re: The Lone Developer Problem
#2> Why does this happen?
Inexperience.
Come on, really? There are plenty of tools to keep code legible in any language: linters, documentation comments, design patterns, idioms from authoritative references, etc.
Every time I see code that doesn't really "fit in" with more experienced code in that language I already know it's gonna be wrong in other ways despite technically "working".
I've too suffered from the neuroticism, imposter syndrome, and egotism of being new at something, but damn can't we just admit this? Guaranteed everyone who isn't a developer sees it and has to deal with it even outside the code itself.
Re: The Lone Developer Problem
#3I’ve experienced this first hand. I think the trick is to encode the experience of writing the code. That takes different shapes in different languages, but a test suite that illustrates the problem and the solution is a good example.
You don’t just want the finished film, you want the making off companion piece.
Re: The Lone Developer Problem
#4This 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/folders where entry points and component registries are found. Especially int main() {} So I can follow the control flow of the software.
I think too few people understand cornerstone technologies, including compilers and browsers.
Re: The Lone Developer Problem
#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-done his legendary feats of coding, moving onto the next thing after he'd written something he deems complete. For projects like ffmpeg and qemu, maintenance teams have stepped up to keep them alive but the first, daunting task is always figuring out how the hell he did everything.
Re: The Lone Developer Problem
#6* If you don’t treat maintainability as a requirement, you usually won’t write maintainable code.
* If you don’t know how differently other people model ideas, you usually won’t write maintainable code.
* If you don’t know how differently you’ll model ideas in the future, you usually won’t write maintainable code.
There’s nothing about being a lone developer that means you won’t write maintainable code, but gaining the perspective necessary to do so requires either experience or feedback. So the lone developer problem is only really a problem for early-career developers and incurious ones.
Re: The Lone Developer Problem
#7> Why does this happen? Inexperience. Come on, really? There are plenty of tools to keep code legible in any language: linters, documentation comments, design patterns, idioms from authoritative references, etc. Every time I see code that doesn't really "fit in" with more experienced code in that language I already know it's gonna be wrong in other ways despite technically "working". I've too suffered from the neurot…
I've definitely been on the receiving end of experienced (10+ years) and competent (or, at least, clearly not incompetent) developers solo-developing inscrutable code that their colleagues had to pick up later. In contexts where they contributed code to bigger projects, their code showed more focus on readability.
I'm sure I've inflicted my share of hard-to-understand code too, most likely out of not wanting to spend extra time on some byzantine section of legacy code.
Re: The Lone Developer Problem
#8"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.
> Fabrice Belladd … legendary feats of coding
Maybe you didn’t mean to be so absolute in the first sentence? Our field is an art. An unmediated connection between one’s inner process and the code one writes can produce very compelling work that stands apart from others. In some cases, that work can prove “legendary”. That it may later take some support, documentation, study, and unwinding to make it maintainable doesn’t mean that the solitary effort shouldn’t be pursued in the first place.
Re: The Lone Developer Problem
#9This 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 document, and getting programmers (including myself) to write thoughtful natural language to accompany our code is a constant uphill battle against business pressures to ship more.
Re: The Lone Developer Problem
#10> Relatedly, it’s it’s easier to have bad ideas if you don’t have to explain them.
This resonates a lot.
So many ideas that seem to make sense at first (you’re having the ideas in the first place after all), but start crumbling even with simple rubber ducking. Taking distance to try to explain if to a third party, even if they don’t exist, is underrated.
Funnily enough, writing comments and documentation don’t trigger that switch. There might be some hidden assumption that the reader is supposed to “get on board” and come share the same mental model perhaps.