Earlier quoted context omitted.
Then how do civil engineers get their degrees?
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?
The Bluffers Guide to the Mythical Man Month
41–50 of 95 posts
Re: The Bluffers Guide to the Mythical Man Month
#42once, when complaining to a colleague about our workplace and their hiring and staffing idiosyncrasies, I quipped "I should give a copy of TMMM". My colleague, without missing a beat said "You should give him two copies so he can read it faster"
I'm not sure if reading the book would help. If the manager has a technical background (e.g., they have worked as developers before) then they already know the main point of the book. If the manager does not have a tech background, then there's little that the book can do for them.
> they already know the main point of the book.
If the only important information in the book was its main point, it wouldn't have needed to be a book. It could have been a leaflet. Or a bumper sticker - those can be very catchy.
It's worth reading the book for all the other words it contains.
Re: The Bluffers Guide to the Mythical Man Month
#43This is a very shallow summary of the Mythical Man Month, and it leaves out at least one concept that the book is most (in)famous for: the '10 times programmer'. An excerpt: > In one of their studies, Sackman, Erikson, and Grant were measuring performances of a group of experienced programmers. Within just this group the ratios between best and worst performances averaged about 10:1 on productivity measurements and a…
Despite many attempts to ignore this reality, entire languages like Go were invented to try mitigate this disparity.
In the end, Go is indeed effective at making engineers avoid arcane and difficult code, but doing the "difficult" stuff that's not available in Go is definitely not how the most productive engineers are productive.
IMO, someone making code that abuses special features to the point it is difficult for other members (including future members) of the team to read is the definition of a negative-X programmer. Unless they're working solo, of course.
Also, like wavesbelow mentioned in his great comment, the "10x" doesn't come from coding prowess alone: it starts long before that, with the process and planning.
Re: The Bluffers Guide to the Mythical Man Month
#44Earlier 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?
Computer engineering degrees already exist, but they're much closer to the hardware.
Re: The Bluffers Guide to the Mythical Man Month
#45Earlier 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?
It's the softness of software that makes it hard.
Building a bridge is something where external participants cannot really tell you much about what it should look like. They know you can't just double the number of lanes or add a train track as you're doing it.
With a software project, people can ask for all sorts of stuff, and because it's soft, some engineer will say "ok let me see if I can look at that for you".
Not only that, if you write your software so that it's rigid, that's bad code! You need it to be flexible so that you can cater for future concerns.
Softness also means you have to keep up with trends. You can write your next website with a newer, fancier js framework, and people can make these new frameworks are just sitting at home at their desk. They aren't mixing new concretes.
Re: The Bluffers Guide to the Mythical Man Month
#46once, when complaining to a colleague about our workplace and their hiring and staffing idiosyncrasies, I quipped "I should give a copy of TMMM". My colleague, without missing a beat said "You should give him two copies so he can read it faster"
[deleted]
Re: The Bluffers Guide to the Mythical Man Month
#47Earlier quoted context omitted.
I'm not sure if reading the book would help. If the manager has a technical background (e.g., they have worked as developers before) then they already know the main point of the book. If the manager does not have a tech background, then there's little that the book can do for them.
So this book is... not for people with a tech background, AND not for people without a tech background? Should I put the cat in the box now?
They might have been making that joke and nobody got it.
Re: The Bluffers Guide to the Mythical Man Month
#48This is a very shallow summary of the Mythical Man Month, and it leaves out at least one concept that the book is most (in)famous for: the '10 times programmer'. An excerpt: > In one of their studies, Sackman, Erikson, and Grant were measuring performances of a group of experienced programmers. Within just this group the ratios between best and worst performances averaged about 10:1 on productivity measurements and a…
I agree. Mythical Man Month is a book to read. It's clear, interesting, and has better writing than summaries. Many classics like this are so good because the author is among the first to observe new phenomena. They can write down what they have learned without cultural narratives that distort reality. The hardest lesson in the book is the chapter 11 "Plan to Throw One Away". I have never seen this not to be the case…
>The hardest lesson in the book is the chapter 11 "Plan to Throw One Away"
On the contrary, aren't factors like Microservices and all the constant prototyping at large companies encompass this? I feel in some ways they may have embraced the principle too much, to the point where prod doesn't have a properly stable solution to support while they are re-writing an experimetal "improvement".
Re: The Bluffers Guide to the Mythical Man Month
#49I've always had a little bit of a gripe with how the "communications complexity" is presented here. As if the only way to communicate on a team is to have everyone stand in a circle and yell at everyone else. In reality, there is very often opportunity to take 1 project with ~3 engineers, and break it into 2 smaller projects each with ~3 engineers and run them mostly in parallel. Do your best to isolate those project…
Pretty sure it simply represents the upper bound of communication complexity. Any management of it can improve coordination. The conceptual lower bound is that each additional programmer adds 100% more programming speed.
Re: The Bluffers Guide to the Mythical Man Month
#50While Brooks' book is nominally about software processes, in my career of over 40 years, I found it to be applicable to just about every engineering discipline to which I played a part. I read this book back in the 70's and then every 10 years or so and I never failed to learn something new from it. I just wish the managers and companies I worked for would have applied these lessons.