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

91–100 of 180 posts

Re: The Lone Developer Problem

#91

Post by flohofwoe »

In my experience it's more often the other way around.

Most projects I've seen with actually readable code and a consistent overall structure have been written (mostly) by a single coder, of course usually with contributions from others, but not real 'team work'. Of course there are also messy projects by single authors, and readable code bases by teams. But in the latter case: the more the responsibilities are spread, the messier the outcome (IME at least).

I think in the end it comes down to the experience of the people involved.

And then of course there's personal taste, one person's readable code is a complete mess to another.

In any case, the post reads like the author stumbled over one messy project written by a single author and extrapolates from there to all other projects.

Re: The Lone Developer Problem

#92

Post by fredsted »

I've often noticed developers seeing a project for the first time and not long after proclaim it as "bad code" and that it needs to be refactored or rewritten (with zero thought as to whether it's good for the customers or the business.)

Re: The Lone Developer Problem

#93

Post by flohofwoe »

marginalia_nu wrote: post #90

I think part of the "problem" is Amdahl's law. When you're solo developing, the laws of physics are different when it comes to code quality and refactoring. The scaling of the cost of technical debt is different depending on the size of the team. In a team, large refactoring efforts are slow and difficult to do incrementally. The best way would be for one guy to lock the mutex and just go, come out however much time…

> It's so inconceivably expensive it's usually not even an option. So instead the code must stay squeaky clean at all times.

Lol, that's not exactly my experience when a proper refactoring is considered too expensive ;)

Re: The Lone Developer Problem

#94

Post by marginalia_nu »

flohofwoe wrote: post #93
marginalia_nu wrote: post #90

I think part of the "problem" is Amdahl's law. When you're solo developing, the laws of physics are different when it comes to code quality and refactoring. The scaling of the cost of technical debt is different depending on the size of the team. In a team, large refactoring efforts are slow and difficult to do incrementally. The best way would be for one guy to lock the mutex and just go, come out however much time…

> It's so inconceivably expensive it's usually not even an option. So instead the code must stay squeaky clean at all times. Lol, that's not exactly my experience when a proper refactoring is considered too expensive ;)

Yeah maybe "must" should be "ought to if you want to stay productive".

You can absolutely accumulate technical debt as a team and I think it's common and if it's just superficial fairly fixable, but I also think there's a tipping point where it just spirals out of control and more developer time is spent putting out fires than fixing root causes.

Maybe someone will contradict me, but I don't know of any examples where a large multi-developer code base has had systemic technical debt where this has been "fixed".

Re: The Lone Developer Problem

#95

Post by frankreyes »

This is something I learned the hard way. The value on software frameworks such as Java Spring or Python's Django is that it enables teamwork. At least in theory.

They have higher costs when scaling vertically but as a trade-off, it's easier to horizontally scale by the number of developers.

When I realized this is when I started to enjoy dependency injection tools.

Re: The Lone Developer Problem

#96

Post by Garlef »

josephg wrote: post #11
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 structu…

Little sidenote:

people usually try to explain the appeal of typescript by "static type checking leads to fewer errors, etc."

conversely i think the real reason is that it can show you the shape of the data at every step by simply hovering your mouse over a function/variable.

typescript is great because it enforces documentation

Re: The Lone Developer Problem

#97

Post by a_e_k »

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…

Agreed, that sort of documentation is pure gold when done well.

It's something I always try to pay forward by doing in my own code. For example, one of my own lone-developer projects was an STB-style single-header -like rasterizer library for C++. I started the implementation half of the library with a short overview of the rendering pipeline's dataflow and the top-level functions responsible for each stage:

https://github.com/a-e-k/canvas_ity/blob/f32fbb37e2fe7c0fcae...

Re: The Lone Developer Problem

#98

Post by theteapot »

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…

> This might be unusual but I would prefer to read someone's mental model of how the code works than the code itself.

I prefer doing easier things rather than harder things also.

Re: The Lone Developer Problem

#99

Post by cracrecry »

My experience has been the opposite.

For example the project "dear imgui" has been created almost by a single person, Omar, and I find the code amazing.

I have learned a lot from individuals like Norvig, Knuth, Carmack, Johnathan Blow or Casey Moratori or Rich Hickey or Paul Graham. Just reading the code they write.

Pair programming? Seriously? Pair programming only works for me if the person you program with is already an expert. A mediocre one is going to make your program mediocre. Two dull knives don't make for a sharpened one.

Re: The Lone Developer Problem

#100

Post by Tade0 »

marginalia_nu wrote: post #94
flohofwoe wrote: post #93

Earlier quoted context omitted.

> It's so inconceivably expensive it's usually not even an option. So instead the code must stay squeaky clean at all times. Lol, that's not exactly my experience when a proper refactoring is considered too expensive ;)

Yeah maybe "must" should be "ought to if you want to stay productive". You can absolutely accumulate technical debt as a team and I think it's common and if it's just superficial fairly fixable, but I also think there's a tipping point where it just spirals out of control and more developer time is spent putting out fires than fixing root causes. Maybe someone will contradict me, but I don't know of any examples wher…

I for one won't contradict you. I believe it's a rite of passage for a senior developer to realise this, among other things.

I remember trying to push for refactoring back when I was just starting my career and being frustrated with the pushback. Little did I know the cost of doing that was even larger than interest on the tech debt we were dealing with, which in hindsight was still manageable at the time.

By the time I started participating in 20+ person monstrosities I was already aware of this and figured that once tech debt in such projects starts accumulating, there's no going back and my task is to do my best, but start sending out CVs.

Post reply on HN