One of my measures of a good programmer, is the ability to grok, debug, and extend code written by someone else, regardless of its perceived quality.
The Lone Developer Problem
31–40 of 180 posts
Re: The Lone Developer Problem
#32This 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 started doing that with my own project after I reverted a (correct) change a few weeks later because I forgot to write down the original reasoning anywhere. No other contributors so far, so I can't say how much it helps on that front, but it has helped me a lot and I feel safer making big changes without fearing I'll break anything.
The entry point docs are here: https://github.com/trane-project/trane/blob/master/src/lib.r...
Re: The Lone Developer Problem
#33"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]
Re: The Lone Developer Problem
#34One of my measures of a good programmer, is the ability to grok, debug, and extend code written by someone else, regardless of its perceived quality.
Took me two years but I finally have a glimpse into the previous developer’s reasoning. Maybe a couple years from now I can explain it all.
Re: The Lone Developer Problem
#35One way to mitigate this as a solo developer is to step away from the code for a while and forget about the structure. You become the facepalming teammate at that point and start doing a better job of documenting and organizing your code for the day 6 months from now when you need to upgrade something or fix a bug. Eventually you start building with less abstractions, and more clearly worded variables, and better folder structure. Unlike teams where someone can keep making mistakes that impact others, you are your own worst enemy if you have to keep dealing with your own code over time. The solution to incompetence or laziness is ownership.
Re: The Lone Developer Problem
#36One way to mitigate this as a solo developer is to step away from the code for a while and forget about the structure. You become the facepalming teammate at that point and start doing a better job of documenting and organizing your code for the day 6 months from now when you need to upgrade something or fix a bug. Eventually you start building with less abstractions, and more clearly worded variables, and better fol…
If you work on a project long enough eventually you forget about how parts of your project work, and this automatically happens
Re: The Lone Developer Problem
#37I don't think this is really a "lone developer" problem. If you jump into any large-scale application codebase you'll be lost and confused, even if it was developed by hundreds of developers.
Maybe the reason people perceive this as a "lone developer" problem is lone developers usually share their code for free (or for equity), so anyone trying to get up to speed on it won't be paid for their efforts (at least not right away).
Re: The Lone Developer Problem
#38Earlier 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…
I might need you to explain how your API works, but I cannot write code while I’m listening to you talk, I need peace and quiet (or at least headphones).
Re: The Lone Developer Problem
#39> 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 trigge…
Except that rubber ducking is literally a way to be a lone developer. :)
Re: The Lone Developer Problem
#40Does 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 feedback. All too often the lone programmer is not reading code written by others, and is not getting feedback on his own code. So growth is slowed, or in some cases stopped for decades. Bad habits from 20 years ago still exist because there's no-one to rail against them.
So yes, lone programmers can be great, especially if they are outstanding to begin with. But the vast majority are mediocre and need the assistance of peers, and seniors to grow.
On the other hand those that grow up under seniors with bad habits, who _enforce_ those habits, are screwed.