81–90 of 95 posts
> As more people are added to a project, the complexity of communication increases exponentially. Doesn't it increase by n^2? as per the picture with the graphs?
Laypeople use "exponential" to mean "superlinear". It's fine, probably.
> As more people are added to a project, the complexity of communication increases exponentially. Doesn't it increase by n^2? as per the picture with the graphs?
Laypeople use "exponential" to mean "superlinear". It's fine, probably.
Earlier quoted context omitted.
That’s another book: the Peter Principle, by Laurence J. Peter. It’s also in my “books you need to read if you’re going to work on a development team” list.
Intrigued to hear what else is on your list?
Earlier quoted context omitted.
At university, like everyone else? Sit there, study structures, materials, etc. Get a job, get a charter...
So why can't we have a computer engineering degree as you say?
While there are some parts of new software that are more similar than not, and these are more 'engineering like'. The majority is not.
Evidenced by; if you did a 'diff' between plans of a bridge you would get a limited number of differences. When you do a diff between an os, browser, slack, the code that runs this site you get a lot more differences. You need to consider each and every detail. This is not 'big-picture'. Big pictures do not construct things.
Sure, there are lots of similar projects and maybe you can apply a more traditional engineering approach to those.
It is interesting to note, LLMS are bringing the similarities out. You can ask for something and it can code up something from something it has seen that is similar. But, as anyone who has used them, will know, it's only partially correct in its interpretation of that simimilarity.
Earlier quoted context omitted.
Intrigued to hear what else is on your list?
My go-tos are the mythical man month and Peopleware:productive projects and teams. There’s the Peter principle too. On more technical (slightly) topics, I like the Pragmatic Programmer. I also like people to be aware of re-engineering concepts, so Hammer and Champy’s Re-engineering the Corporation is also good.
Earlier quoted context omitted.
My go-tos are the mythical man month and Peopleware:productive projects and teams. There’s the Peter principle too. On more technical (slightly) topics, I like the Pragmatic Programmer. I also like people to be aware of re-engineering concepts, so Hammer and Champy’s Re-engineering the Corporation is also good.
You should also read the Parkinson's law. It's more about bureaucratic systems but is not any org such a system?
Earlier quoted context omitted.
This is starkly opposed to how Go is marketed, especially here on HN. Go was designed to maximise the number of 'any developers' that could join a project, i.e. 1x developers.
I get the assomption that with go you will avoid 0.2 programmers and make everyone a 1x programmer. But for me, a 10x programmer can generate complex, well engineered systems with a reasonable structure, not by writing everything in low level, super hard code ? From the level a 10x programmer might operate I'm not sure the programming language would be that important ? Expressivity is nice and some languages are bett…
Yeah maybe, but I'm certainly not at that level.
If a 10x programmer exposes foo() and bar() methods to me, I'll call foo().bar() and not realise I've made a mistake, or that I've violated some invariant that's only in his head, not in the low-level code itself.
I am surprised that there's less mention of Brook's proposed team organization, a team of 10 led by a surgeon. The team is supposed to work on a single project. Every org I have seen has much smaller teams with much more individual responsibility and attendant coordination problems. I can see shaving 1-3 people off of Brook's ideal team (we don't need a secretary to type anymore, PM's that organize projects at the be…
Classic "You get promoted until you are incompetent" situation
Earlier quoted context omitted.
This is the thing. A degree is closed-ended. You build things that can be done within a deadline, and have been done within that deadline, by hundreds of groups before you. You study well known problems that are described in many ways in various sources. When you work, you work on building things that don't have a specific end goal, without a specific deadline, where the success criteria are also not purely academic.…
Thats not the only problem. In most engineering you build a mathematical model first, play with it until it's right, and only build the product when you're fairly sure it's going to work. With a bridge, the model tells you about the forces in the structure, the component tolerances, and the likely behaviour under various stressful and extreme conditions. Same with EE. Commercial board design uses schematic simulation…
I think part of the problem is that most of our "raw materials" like nginx and postgres are so robust that you can build really quite large projects without having to do any modeling or other big planning. Things that have millions of users can still be more-or-less slapped together from default parts.