4 ms·

There's a lot of overhead and inefficiencies in how large companies do anything. It's hard to organize thousands of people well. It's the social equivalent of

There's a lot of overhead and inefficiencies in how large companies do anything. It's hard to organize thousands of people well. It's the social equivalent of the old 'Command-line Tools can be 235x Faster than your Hadoop Cluster'[1] conclusion. You put a hundred developers on a project and you'll generously get twice the meaningful output of ten developers (but 50 times the LOC; as demanded by conway's law). The upside is that this makes it all the more feasible for a small group or even single individual to be surprisingly competitive. Peak productivity per person is probably is probably found in a self-organized 1-3 person team. [1] https://adamdrake.com/command-line-tools-can-be-235x-faster-than-your-hadoop-cluster.html https://adamdrake.com/command-line-tools-can-be-235x-faster-...

mirekrusin 3y ago
People take holidays, get sick and change jobs - having 1-3 ppl team means you'll hit brick wall that will hurt sooner or later, more so if at least one of devs was really good.
- marginalia_nu 3y ago
  This is a real concern if you're looking at it as someone who is managing people... but a 1-3 person team does not need a manager to tell them what to do, and generally is not hired but spontaneously organized. It's an inherently more unpredictable way of working, but that definitely cuts both ways. There are definitely more risks, but also far greater payoffs in terms of what you can do working in this fashion. The principle of ensuring predictable velocity across a team comes a cost of limiting maximal produtivity amongst talented individuals.
- Jensson 3y ago
  It is better to sometimes be hurt than always be hurting. Organizations are so afraid of only 1 person understanding something that they create processes so that 0 persons understand it.
aleph_minus_one 3y ago
> You put a hundred developers on a project and you'll generously get twice the meaningful output of ten developers (but 50 times the LOC; as demanded by conway's law). Based on my job experience, this is rather an artifact of how software projects are (badly?) managed. Give each of the developers some small "hotspots" to work on (i.e. critical code fragment that is - hard to implement correctly and fast - which is critical to implement very fast and correctly - a correct and intended implementation will likely consist of few highly sophisticated lines of code ), and the scaling will be much better. This is a little bit like theses are assigned to students: each thesis is one isolated non-trivial scientific challenge (often open research problem) that is to be solved by the student. I guess the "management incentives" nevertheless prevent such a method: managers prefer/are incentivised to "tell stories" instead of explaining the deep, sophisticated challenges and solutions in making great implementations of these "hotspots".
- dasil003 3y ago
  This assumes you know what you need to build. 90% of the challenge in large scale development is nailing down requirements, especially when the problem space is too big for any individual to fully understand.
  - aleph_minus_one 3y ago
    > This assumes you know what you need to build. This is what in my opinion senior programmers or project managers are for. If they are not capable of handling this task decently, these people simply are not (yet) ready for this role.
    - falling_myshkin 3y ago
      Young engineer here in charge of a project and feeling quite out of their depth, I agree with this. Currently no mentorship and it will take a couple months for a senior hire. Do you have any advice? What does a senior engineer love/hate to see when they come onto a project started by engineers earlier in their career? How can I be most helpful?

mirekrusin 3y ago

People take holidays, get sick and change jobs - having 1-3 ppl team means you'll hit brick wall that will hurt sooner or later, more so if at least one of devs was really good.

marginalia_nu 3y ago
This is a real concern if you're looking at it as someone who is managing people... but a 1-3 person team does not need a manager to tell them what to do, and generally is not hired but spontaneously organized. It's an inherently more unpredictable way of working, but that definitely cuts both ways. There are definitely more risks, but also far greater payoffs in terms of what you can do working in this fashion. The principle of ensuring predictable velocity across a team comes a cost of limiting maximal produtivity amongst talented individuals.
Jensson 3y ago
It is better to sometimes be hurt than always be hurting. Organizations are so afraid of only 1 person understanding something that they create processes so that 0 persons understand it.

aleph_minus_one 3y ago

> You put a hundred developers on a project and you'll generously get twice the meaningful output of ten developers (but 50 times the LOC; as demanded by conway's law). Based on my job experience, this is rather an artifact of how software projects are (badly?) managed. Give each of the developers some small "hotspots" to work on (i.e. critical code fragment that is - hard to implement correctly and fast - which is critical to implement very fast and correctly - a correct and intended implementation will likely consist of few highly sophisticated lines of code ), and the scaling will be much better. This is a little bit like theses are assigned to students: each thesis is one isolated non-trivial scientific challenge (often open research problem) that is to be solved by the student. I guess the "management incentives" nevertheless prevent such a method: managers prefer/are incentivised to "tell stories" instead of explaining the deep, sophisticated challenges and solutions in making great implementations of these "hotspots".

dasil003 3y ago
This assumes you know what you need to build. 90% of the challenge in large scale development is nailing down requirements, especially when the problem space is too big for any individual to fully understand.
- aleph_minus_one 3y ago
  > This assumes you know what you need to build. This is what in my opinion senior programmers or project managers are for. If they are not capable of handling this task decently, these people simply are not (yet) ready for this role.
  - falling_myshkin 3y ago
    Young engineer here in charge of a project and feeling quite out of their depth, I agree with this. Currently no mentorship and it will take a couple months for a senior hire. Do you have any advice? What does a senior engineer love/hate to see when they come onto a project started by engineers earlier in their career? How can I be most helpful?