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

51–60 of 180 posts

Re: The Lone Developer Problem

#51

Post by owyn »

erik_seaberg wrote: post #38
owyn wrote: post #23

Earlier quoted context omitted.

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).

Oh, absolutely, I can't listen to a book on tape and code. I mostly listen to death metal or electronic music with no (intelligible) words. I do think programming engages the language portion of the brain, which is why it can be so rewarding and draining.

But traditional pair programming, like actually sitting next to someone at one computer? I honestly enjoyed it! I might just be old? :) These days IntelliSense is effectively my pair programmer. TypeScript and VSCode allows me to actually enjoy front end dev work for once, fixing the squiggles is fun. But in the old days before Stack Overflow, time spent co-working next to someone who really knew an API or a library or a language was very much worth it.

My current team does do a shared screen pair programming thing a couple of times a week, there's a video call that we can drop in on while we are working on something.

Maybe it's more inspired by Twitch live coding and less like traditional pair programming but I still think it counts? It wasn't even my idea, but I participate because I enjoy it.

Re: The Lone Developer Problem

#52

Post by tshaddox »

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…

The bigger problem is when the code works (ish) but it’s clear that the lone developer didn’t even have a mental model of how the system works.

It’s usually very easy to see in a codebase when someone was flailing, and they wouldn’t be able to explain how or why this line of code works any better than you could. They just have strong conviction that this line of code needs to be there, because it was there at the stage in their flailing that things started working.

And to be clear, this can probably happen just as easily with a codebase with multiple developers.

Re: The Lone Developer Problem

#53

Post by jackblemming »

saurik wrote: post #45

This article makes an explicit assumption: that code that is easy for you to read at a glance is inherently "good". The article then makes weird quasi-moral judgements like, maybe if you are a single person writing difficult-to-read code then "maybe you just don't need to write good code". Code that is optimized to be easy to read often has lots of duplication and very little abstraction. This is even a well-understo…

>Code that is optimized to be easy to read often has lots of duplication and very little abstraction.

Absolutely wrong and people need to stop pushing this narrative or put their money where their mouth is and use assembly. The people repeatedly saying this have probably experienced bad abstractions and gross OOP spaghetti code and improperly generalized this to "DRY bad, abstractions bad".

Re: The Lone Developer Problem

#54

Post by [deleted] »

ilaksh wrote: post #43

I have a different take on this. If my project somehow becomes wildly successful and is acquired, the next team is not going to want to maintain my code anyway. How do I know that? Because no one wants to maintain someone else's code. No one wants to deal with someone else's abstractions and bugs or anything else. 100% of the time if it's feasible, the next version will be a rewrite of all or a significant portion. E…

[deleted]

Re: The Lone Developer Problem

#55

Post by Joel_Mckay »

Some create job security though ivory tower structures. A surreal masterpiece conceived while failing to cure their schizophrenia by licking hallucinogenic frogs while on LSD.

Others in small firms sometimes notice a "team" is not beneficial... especially if some have seniority, rotten intent, and a string of prior failed launches.

Finally, one realizes it doesn't matter, as you're billing by the hour. A grim apathy replaces ambition, as one starts to fantasize about being a plumber. =)

Re: The Lone Developer Problem

#56

Post by siva7 »

This was a poorly written blog post by framing this particular situation as a "problem". It becomes a problem when someone acts inside a team or professional organization like this but the article is about single developer projects. There can be many good reasons why code quality doesn't matter in such instances but framing it from the start as a problem is more akin to clickbait. I would expect higher quality content on HN getting upvoted.

Re: The Lone Developer Problem

#57

Post by NoZZz »

Joel_Mckay wrote: post #55

Some create job security though ivory tower structures. A surreal masterpiece conceived while failing to cure their schizophrenia by licking hallucinogenic frogs while on LSD. Others in small firms sometimes notice a "team" is not beneficial... especially if some have seniority, rotten intent, and a string of prior failed launches. Finally, one realizes it doesn't matter, as you're billing by the hour. A grim apathy…

Ah, pipe dreams =)

Re: The Lone Developer Problem

#58

Post by blue039 »

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 any one of the people barking the code remembering how something works is pretty low. There is significant evidence the action of typing/writing something produces better memory.

It works when you're helping a junior. It's insulting to anyone else. Part of our jobs as programmers is to be able to tease apart another developers mental model and learn the abstraction. If you cannot do this the codebase is either unsaveable or you are. The only codebases I have been unable to untangle in my long career have been either written by contractors or by a pseudo-intellectual moron developer that believes they are the second coming of Turing. Everyone else's code is usually able to be parsed with some patience and a debugger for more complicated tasks. I even gasp use pencil and paper to keep track of code flow often.

Re: The Lone Developer Problem

#60

Post by DawsonBruce »

protonbob wrote: post #28
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.

The good documentation I’m envisioning refers to standardized comments throughout the codebase (we’re working with cpp, so doxygen in this case), with code examples within the header showing how the code should be used.

I’ve found there’s so many custom classes through my discovery if this codebase that it’s not quite clear how to use the classes or where to start, so having code examples along with comments describing their usage is pretty useful.

It’s also nice to utilize version control for the comments, which makes them easy to contribute to, as well as hopefully inspires others to contribute their own thorough comments when designing and contributing new classes to the codebase.

Documentation regarding process, coding guidelines, and the likes are better suited for a platform like confluence or some equivalent. We do that as well.

Post reply on HN