Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Bluffers Guide to the Mythical Man Month

codemanship.wordpress.com

Post reply on HN
Print view View original

51–60 of 95 posts

Re: The Bluffers Guide to the Mythical Man Month

#51

Post by hotpotamus »

poulsbohemian wrote: post #8
lordnacho wrote: post #5

Earlier quoted context omitted.

Yeah I also get this feeling that a lot of junior devs decide they don't really want to do it anymore. It's hard to get numbers on it because they will still have a related job title.

Almost 30 years ago I was a freshman cs student and a prof rolled out data that said by the time we were 30 years old, most if us would have already left the field. I can tell you that almost no one I graduated with is still working in tech, and not because we retired early off stock. It’s a challenging field for so many reasons.

Based on my own experience, I don't find it hard to believe that so many want out, but I do find it hard to believe that so many get out and so quickly. These days I find myself wishing I had gone the route of physician's assistant so I could do some tangible, socially-needed work that still pays the bills.

I've actually ended up in a tech job that hits those a bit, so I am doing a bit better these days at least.

Re: The Bluffers Guide to the Mythical Man Month

#52

Post by [deleted] »

Aeolun wrote: post #15
jwestbury wrote: post #11

Earlier quoted context omitted.

I think a big part of the "old people in the trenches" problem is that tech has historically had an "up or out" mentality. It seems like most of the older engineers I know either get pushed out or end up as principal engineers where they aren't routinely interacting with the younger people. I've encountered a few people who have managed to avoid this, but it's rare. It doesn't help that our industry has been incredib…

> I know either get pushed out or end up as principal engineers where they aren't routinely interacting with the younger people. It doesn’t really help that young people always feel like they know better either. Even if there’s an experienced architect, it doesn’t help if they’re surrounded by 10 rookies. Nobody has the time to guide all of them.

[deleted]

Re: The Bluffers Guide to the Mythical Man Month

#53

Post by karmakaze »

Aeolun wrote: post #15
jwestbury wrote: post #11

Earlier quoted context omitted.

I think a big part of the "old people in the trenches" problem is that tech has historically had an "up or out" mentality. It seems like most of the older engineers I know either get pushed out or end up as principal engineers where they aren't routinely interacting with the younger people. I've encountered a few people who have managed to avoid this, but it's rare. It doesn't help that our industry has been incredib…

> I know either get pushed out or end up as principal engineers where they aren't routinely interacting with the younger people. It doesn’t really help that young people always feel like they know better either. Even if there’s an experienced architect, it doesn’t help if they’re surrounded by 10 rookies. Nobody has the time to guide all of them.

In my experience rookies/interns/jr devs are a pleasure to work with: knowledge sponges. It's a small subset of ones becoming sr devs that can be difficult.

Re: The Bluffers Guide to the Mythical Man Month

#54

Post by taeric »

sizzzzlerz wrote: post #50

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

I'm a bit of a broken record on the idea, but I'm fairly convinced that much of what we think is unique to software is not that unique. Coordinating work with people is hard, pretty much period.

Re: The Bluffers Guide to the Mythical Man Month

#55

Post by polygotdomain »

WJW wrote: post #9
poulsbohemian wrote: post #8

Earlier quoted context omitted.

Almost 30 years ago I was a freshman cs student and a prof rolled out data that said by the time we were 30 years old, most if us would have already left the field. I can tell you that almost no one I graduated with is still working in tech, and not because we retired early off stock. It’s a challenging field for so many reasons.

It would be interesting to see how that compares with other professions. Do carpenters or dentists leave for other fields at the same rate? How about other types of engineers?

I can only speak of my experience having gone to school for Architecture. They told us that with each recession, the profession loses a generation of Architects. I was wrapping up grad school just before the Great Recession, and professors were surprised that a relatively greater percentage of graduates had stayed in the field due to continued economic prosperity since the mid 90s and the dot com boom hadn't impacted the Architecture field all that much.

Of course, once the Great Recession hit, myself and many others that I graduated with either left the profession for other employment or simply never found jobs to begin with (that was me). Luckily I was already programming in grad school, and what was something I was filling my time with while looking for an architecture job became a new profession and I never looked back. Given all the comparative benefits of Software Engineering over Architecture, it's been a good move for me.

Re: The Bluffers Guide to the Mythical Man Month

#56

Post by mushufasa »

INGELRII wrote: post #19
misja111 wrote: post #3

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

Well, this was a bigger issue when this book was written and software was typically developed on disks that couldn't be updated after sale. In the SaaS world, I think deploying your MVP and then rewriting/improving while you have customers running into real world feedback and pain points, and also generating revenue to validate market demand, is strictly preferable to taking an extra cycle and not be in market.

Re: The Bluffers Guide to the Mythical Man Month

#57

Post by kwertyoowiyop »

INGELRII wrote: post #19
misja111 wrote: post #3

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

Such great writing. Clear, compelling, and entertaining.

Re: The Bluffers Guide to the Mythical Man Month

#58

Post by kwertyoowiyop »

civilized wrote: post #39
misja111 wrote: post #3

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

Has anyone else started feeling the following? In the last year or so, reading a banal, superficial, and platitudinous summary of something has, for me, become inflected with this feeling that it was written by GPT. In the case of this article, there are little details that suggest it was written by a person, like randomly choosing to abbreviate the book to T-MMM. But still, it's started happening for me that an arti…

I’m just glad they read it.

Re: The Bluffers Guide to the Mythical Man Month

#59

Post by kwertyoowiyop »

sizzzzlerz wrote: post #50

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

Every engineer would benefit from it too.
Post reply on HN