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

171–180 of 180 posts

Re: The Lone Developer Problem

#171

Post by manv1 »

Why isn't "write documentation" in that list?

I mean sweet Jesus, it's 2023. Write some fucking documentation. There are also these things called comments that you can put in your code so you can explain why you're doing what you're doing.

The code shows what, the comments show why. And it's the why that's important.

Anyway, the more code you read, the better you get at figuring out what code does. But instead of reading the code try to understand the intention behind the code. Think of it as you're reading the mind of the person writing it. Are they lazy? Bad? Overly complicated? Weird structure? What do they always do? What are they bad at? How do they approach what they're doing?

There are developers who are too clever by half, and you can see it in the code; they do something in a complicated way instead of doing it the simple way. They do things that look interesting but which have no real benefit.

Re: The Lone Developer Problem

#172

Post by aleksiy123 »

flohofwoe wrote: post #91

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 sprea…

I'm guessing that lone developer projects have a higher variance as they are a direct reflection of the skill of the single developer. Team projects trend to the average.

If you have a very good developer doing a lone project it's probably going to be good. Because they have full control. But I doubt an unskilled developer will have a very good lone project. You want them on a team environment for the structure and mentorship.

Finally, it's worth mixing your developers as their combined effort is worth more in the macro level rather than the micro level.

Re: The Lone Developer Problem

#173

Post by LeftHandPath »

flohofwoe wrote: post #91

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 sprea…

If you have one developer, he or she will be the expert of that project. If you want a team of multiple developers, and it's infeasible to have any one of them be an expert of the entire system (let alone all of them), then the amount of planning and standardization needed increases quickly. The bigger the team is, the stricter the rules for style need to be, the better the documentation needs to be, etc.

I would expect the cleanest projects to be ones written by single developers because A) these projects will typically be simpler than the ones that require teams, by nature, and B) they will be undistracted / avoid the flaws of design by committee. Think cinema auteur vs. a Marvel or Disney film with an army of writers.

Go lang is a good example of identifying and addressing the problems that appear when your code is managed by a large team.

Re: The Lone Developer Problem

#174

Post by ChrisMarshallNY »

jshier wrote: post #170
ChrisMarshallNY wrote: post #153

Earlier quoted context omitted.

> For lonely programmers, identifying the code that should be high quality (the one you will be looking at continuously) and the one is only there to fix a single problem is really important. I feel your pain. I am the main coder, in a small team. There's one server guy (part time), and one semi-technical graphic designer (also part time), a couple of admin/marketing folks (also part time), and me (full, full time).…

Usage of the nil coalescing operator is not advanced. You've simply used it in a way that makes it less comprehendible to anyone not already familiar with the operator. Any actual Swift developer should be able to understand what's happening. But frankly, this isn't good code, and not just because you're using coalescing like that. 1. You should never have to use a raw object like that. Use a Decodable type and get a…

Cool. If I'm doing it wrong, I wouldn't mind seeing it done right. I'm always willing to learn new stuff, and one thing that I've learned about Swift, is that there's always more/better ways to do stuff.

The obvious issue with not using rawValue, is that we don't use an enum, and that's what I usually see. I like to use enums, where others use static lets, because I can do things with enums, like limit the number of values (good for switches), and repurpose them, from time to time.

Also, since an enum is a type, I can add things like functions to do cool stuff, like extract and interpret the state, or do some good debug stringing. I could also use a struct, but why, if the enum will do it?

And, of course, since it's a type, I can extend it for special applications. I do that, a lot.

One of my "desmeller" exercises, is to go through my code, looking for "magic number constants," and see if I can replace them with enums.

The reason for the Any, is because the code extends another SPM module that I wrote, that forms an infrastructure for preferences, and this is just the bit inside the implementation.

No, the highest Double isn't an invalid value (that's actually the point). It's just one that won't apply to the filtered set that I produce, later on. That means I don't have to put in special branches (keeps the CC low), to look for invalid values.

Here's another thing I do a lot:

    guard (0..
I could also clamp it, but that can have unfortunate side effects, and I can add some assertions in the else clause.

Sometimes, there may be reasons for people doing stuff, other than they suck. I don't suck. I'm not being snooty, but I do this a lot, and have a lot of pretty good stuff, out there.

Maybe, and I know this is just crazy talk, I might actually be a halfway decent programmer.

Re: The Lone Developer Problem

#176

Post by austin-cheney »

re-thc wrote: post #130
austin-cheney wrote: post #121

Earlier quoted context omitted.

Originality complex, the ability to write original software and document it, is a consideration of personality more so than intelligence. Due to cultural norms and selection bias most people will believe the opposite because education and institutions filter only on intelligence. I recently learned that conscientiousness correlates negatively with intelligence at about -0.27 which means more than a quarter of the pop…

It's worse than that. Education and institutions often filter on certain subsets of intelligence or just good memory. A lot of exams are a memory test. A lot of courses related to software development are either out of date or don't model the current trends / best practices.

The role of education is to feed the demands of industry... whatever those are. There is still need for COBOL. There is still need for C and C++.

The problem is expectation management. A bachelor's in CS teaching OOP and SQL will not prepare you to write functional code, event logic, transmission control systems, and so forth. Not at all. For some god forsaken reason people believe achievement of education is like checking a box on a job application otherwise already in hand and that said education prepared them for anything.

Most people lack the skills required to perform as most software platforms are designed. Remember, its all about institutionalization and intelligence only. That doesn't work. There simply aren't enough 145IQ people (2-5% of the population) in the world to fill the demand required to self-train across multiple paradigms of application design architectures. The solution provided by industry is to make it more stupid (easy) so that lower IQ people, as low as 115, can participate (about 35-40% of the population). This occurs because both education and industry only filter for intelligence and high intelligence does not correlate with organization, self-discipline, or any other form of conscientiousness.

The reality is that if industry filtered for personality in preference to intelligence they could choose from 25% of the population without dumbed-down (the need for easy) software platforms. That means less tech debt, better documentation, faster time to market, more valuable/flexible products, less burn out, happier employees. It would also mean they wouldn't have to pay under performing junior developers as much as doctors, and it would make expert developers more identifiable as determined by performance compared to peers when there are fewer restrictive constraints (guardrails imposed by industries artificially easier platforms).

Re: The Lone Developer Problem

#178

Post by dickersnoodle »

bigpeopleareold wrote: post #110
fredsted wrote: post #92

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

Heh - I understand that impulse, but when I thought that, I think I was less rational. Why is it bad? I have seen bad codebases (whether for real or imagined cases) but to unravel something that is bad can be a real big chore. There was one case where I felt and still feel a certain project was overly-engineered, but rewriting it (which I took a little time doing) is a lesson in futility, particularly if there is no…

>From experience, those announcing that a codebase is bad sounds more resume-driven than technical. It sounds like they want to make a mark more than making a functional difference.

Graybeard here (been doing development for money for 40+ years). It's one thing to say a codebase is bad because of style, aesthetics or lack of comment; it's another to try to enumerate what that means. To me, a codebase is bad when it's hard to modify and hard to unit/integration test because of the architectural decisions that were made (which boil down to it not being properly layered and modular, overusing inheritance vs composition, using inscrutable variable names, etc).

Re: The Lone Developer Problem

#179

Post by otikik »

I would not generalize and say that "a lone developer will always produce unreadable code". It's just that it requires a somewhat rare skill.

Think about it: writing readable code requires putting yourself in the shoes of a future reader/reviewer, while writing a complex piece of code, and often under tight time constraints. That is not easy.

It's also difficult to measure consistently. Lack of clarity has a delayed impact in months or years in the future, while it has some immediate benefits (more features produced more quickly, right now). Often the original author doesn't feel the impact at all, since they have moved out to a different project/team by that time. It is externalized to others.

Because all of this, code maintainability is generally not incentivized at the workplace (while producing new features quickly is). The programmer who "produced a single feature, with very maintainable code" quickly learns that he's less valued that the programmer who "produced 3 features very quickly". Code maintainability is not even in the picture.

I know some very talented developers that really struggle with code readability. For those, pairing with someone else can help. But that other person also needs to have the right skills. They must be methodical and organized - that is not rare in programmers. But they must not be afraid of asking the right questions, and signal contradictions, "slowing down" the other developer. That is less common.

Post reply on HN