this post was submitted on 07 Jul 2023
1101 points (97.1% liked)
Technology
59594 readers
2916 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related content.
- Be excellent to each another!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, to ask if your bot can be added please contact us.
- Check for duplicates before posting, duplicates may be removed
Approved Bots
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I'm a software dev, I can fairly claim to be a software engineer as well
It's not just having a product owner. We have a parable...
A manager asks a senior dev how long it will take him to build a thing. He says 9 months. They ask how long if they get another couple devs on it - he says 8 months. He asks how long if they add a dozen people, and he says it will never be finished
There's plenty of variations, but it's not a joke - how many people built the Linux kernel? How many built C? How many built Apache, how many built transformers, how many built osX?
The answer to the best technologies is always 1 or 2, maybe with helpers. The more people you add, the harder it is to innovate - you can polish all day long, but 1 sharp person can build something better than a dozen equally sharp people. One brilliant person is more effective than one brilliant person with a dozen helpers
It's all about quality, quantity only weighs down the process
At one of my previous gigs our boss was big on the "double the devs/half the time" mentality. Our favorite response was
9 women can't make a baby in 1 monthI think this is somewhat overstated (also a dev), but there's definitely truth to it. The division of work needs to be clear from the start, and ideally the design done collaborative to really have additional devs help.
Part of the problem is we all think different, so even two brilliant devs can step on each others toes and cause problems if they're not synced up on what the plan is.
Linux Kernel is kind of a bad example since its one of the examples of project scaling with many people from many companies. Even if you want to go with its inception, it came from Unix which already had many people. Of course, its also one of the best examples of actual leadership, proper technical people management, which is something very hard to come by. Its also a great example of how to divide your design and make it scalable, so people are working on different parts totally independent on each other.
That's all actual, proper, work, not whatever crappy slide presentation passes as leadership on many places.
Unix has a similar backstory. Prior to its existence, there was a project called Multics aimed at enabling efficient sharing of a computer among multiple users. However, with a lot of teams involved, the project became overwhelmed by excessive complexity and stalled, eventually being regarded as a costly burden and dismantled.
Later, the guys who would later develop the programming language C joined forces and created Unix. They drew inspiration from Multics but took a much simpler approach, and added some innovative ideas. The result was a remarkable achievement.