I have skimmed a significant amount of the content. However, after reaching a certain point, it becomes increasingly and intolerably boring.

I chose not to skim the chapter that serves as a summary of the previous chapters. This decision was made because I believed that this particular chapter might provide a more comprehensive understanding of the overall story or concept.

In my opinion, this summary chapter can potentially replace the entire book. It seems to encapsulate the essential points and ideas that are spread throughout the various chapters. By reading this summary, one might be able to gain a good grasp of the main themes and arguments without having to go through the entire book.

Nevertheless, it is important to note that skimming has its limitations. It may not allow for a detailed and in-depth analysis of the text. Some nuances and subtleties might be missed during the skimming process. Therefore, it is advisable to read certain sections carefully, especially those that are of particular interest or importance.

Overall, while skimming can be a useful strategy for quickly getting an overview of a text, it should be complemented with careful reading to fully understand and appreciate the content.

I have a strong desire to print numerous copies of this book.

Not only do I want to print many copies, but I also intend to roll them up neatly.

I envision myself taking these rolled-up copies to meetings with my clients.

During the meetings, in a rather extreme and perhaps comical scenario, I would repeatedly hit them over the head while loudly screaming, "more... than... 30... years... and you... still... don't... understand... anything... stop... making... me... write... bad... software...!"

However, it should be noted that this is just a humorous and exaggerated thought, and in reality, I would handle the meetings and interactions with my clients in a much more professional and appropriate manner. Seriously.

The publishing house asked the author not to change anything from the original text and, furthermore, to add 4 new chapters.

In the last chapters, the author makes an account of the conclusions of the original edition (1974) in relation to what holds true in the era of this anniversary edition (1995).

The technology of the original chapters seems both ancient and extremely interesting (as someone like me, whose first computer was a Sinclair ZX81, would say) to prehistoric (as someone whose first computer was a MacBook Air would say). Nevertheless, the timelessness of the concepts described in the book is impressive.

This shows that despite the rapid advancements in technology over the years, the fundamental ideas presented in the book still have great value and relevance. It is a testament to the author's ability to capture and convey these ideas in a way that transcends time.

Perhaps this is why the book has remained popular and continues to be read and studied by people from different generations and backgrounds. It serves as a reminder that some things never change, and that the wisdom and knowledge contained within its pages can still be applied and learned from today.

The most mind-bending book about software engineering that I've read in my 20-year career is truly a gem.

I had to read and study it two times to truly absorb the timeless wisdom contained within its pages.

The insights and knowledge presented in this book are so profound that I deeply regret not having discovered it earlier in my career.

It offers a unique perspective on software engineering principles and practices that can transform the way one approaches and thinks about this field.

Whether you are a seasoned software engineer or just starting out, this book is a must-read.

It will challenge your assumptions, expand your horizons, and provide you with valuable tools and techniques to enhance your skills and productivity.

Highly recommended!

The first half of the book presented highly insightful perspectives on project management structure. It delved into what elements truly work within a project management framework and provided in-depth analysis on the reasons why projects might derail.

However, the second half of the book turned out to be a bit of a chore to read. This was mainly because it was overly focused on the minutiae of software engineering. Additionally, considering it was written way back in 1975, a lot of the content is extremely outdated.

In today's rapidly evolving technological landscape, the software engineering concepts and practices have changed significantly. What might have been relevant and cutting-edge back then is now almost obsolete.

Overall, while the first half offers valuable lessons and knowledge, the second half fails to keep up with the times and falls short in providing practical and applicable insights for modern-day project managers and software engineers.

The article that was recommended to me by my boss has several issues.

Most of the content in it is either completely useless. For example, it focuses on dealing with 1MB chips, which may not be relevant in today's technological landscape where much larger and more advanced chips are commonly used.

Moreover, a significant portion of the article seems to be outdated by newer frameworks. The mention of Agile and other modern frameworks indicates that the information provided may no longer be up-to-date and may not align with the current best practices in the industry.

Overall, while the article may have had some value at one point, it now appears to be in need of significant updating and improvement to make it more useful and relevant for today's readers.

Fascinating series of essays about building software and managing teams.

Some bits really resonated, especially about the craft of software engineering. Brooks said that the hardest part about learning to program is adjusting to the necessity of perfection, which I think is still true today.

He also had the most apt description of what it feels like to actually write code, and the differences between the essential work of building software and the "accidental" work imposed by poor tools, process, and the quirks of computers.

Unfortunately, Mythical Man-Month has a gender problem. Every pronoun was "he," except for the occasional references to secretaries and nurses, who of course are women.

In addition, the book makes oblique references (a few) to women's place in the home. It's gross, unnecessary, and incredibly frustrating.

Time for a 2016 edition that updates the language and removes these offensive and outdated references.

Perhaps a new edition could also include discussions about the increasing diversity in the tech industry and how to build more inclusive teams.

Overall, while the content of Mythical Man-Month is still relevant and valuable, the gender problem detracts from its message and makes it a less enjoyable read for many.

Libro consigliatomi dal mio migliore amico dopo una particolare conversazione sul software developing. Questo libro è stato un'esplorazione interessante nel campo dello sviluppo software. Tuttavia, lo consiglierei a tutti? Ovviamente no. Credo bisogna sapere un minimo cosa vi sia dietro un programma per poter capire appieno questo saggio.

Parto anche dal fatto che sia stato scritto nel 1975 - con poi dei capitoli aggiunti nel 1986 e 1995 - ovvero anni in cui erano apparsi da poco i computer e in cui bisognava ancora sviluppare un sistema operativo completo più che dei software. L’autore infatti descrive come è stata la sua esperienza in IBM mentre doveva sviluppare OS/360. In soldoni, erano già in ritardo con lo sviluppo, l’autore ha aggiunto più programmatori al progetto per finire in fretta e invece si è verificato l’effetto contrario: il progetto è stato ritardato più del dovuto.

Da questo presupposto, Brooks inizia a spiegare come dovrebbe essere fatta la progettazione di un programma: ovvero fatto di poche persone competenti, che hanno un ruolo ben preciso e che sappiano fare quello che devono fare. Avere poi una buona documentazione, stabilire dei tempi realistici, aggiornare continuamente la documentazione etc. Ma sono cose che nel 2022 si sanno già e non dice niente di nuovo. Però secondo me rimane comunque una lettura interessante, anche se alcune cose ammetto possano risultare “vecchie” e scontate.

The Mythical Man-Month: Essays on Software Engineering by Frederick Brooks is already a classic.

Everyone who is even remotely associated with computers and/or projects simply must read this book. It would also not hurt clients to know how everything really looks.

The Mythical Man-Month is a treasure trove of well-presented observations, ideas, recommendations, and a wealth of other useful material.

100 percent of Brooks' ideas are still relevant today!!!

In Israeli startups, this book is well-known, and the expression "Silver Bullet" has become a household name, and even those who have not read Brooks' book know it.

Here's an example: Brooks' paradigm states that it is impossible to deceive life (which sounds familiar and even sad for some). That is, there is only one real way to complete a project - it is incremental development, in which small parts are regularly integrated into a working project. For those who are in the tank, I will explain with this example: replacing C++ with JAVA-JAVA/C# will not save you, buying a super-duper cool CMS will not help you, and even a recently hired mercenary-super-programmer will not pull your project out.

Silver Bullet is a myth that is actively supported/cultivated by managers who are slackers or burners, eager for free means/budgets. It's all simple, but as they say on the Internet: "The mice cried and wallowed, but continued to stubbornly eat the cactus."

Another interesting aspect that Grandpa Brooks clearly examines is the coolness of architects/designers/programmers. His thesis is simple: Cool ones are 10 times more productive and useful (for business) than good ones (the 80-20 principle states that 20% of people do 80% of the work. Recently, it was found that 80% of people think that they are among these 20%)). This statement really annoys the girls in the HR department (well, like all of ours are wonderful and good). It also doesn't like big bosses, because if you agree with this position, then the question of the salaries of these very cool people immediately arises. Even a joke was made about them:

Supervisor's order:
Provide each programmer employee in the office with a remote control with two inscriptions:
- coffee
- mine
For good employees - these are buttons, for bad ones - lights.

That's how we live!

I classify the book The Mythical Man-Month as the best and must read. Period!

I was truly underwhelmed by just how badly this text has aged.

The references that seemed to make perfect sense 15 years ago simply no longer hold water.

Moreover, the most-referenced-project is definitely no longer the way we write software in the present day.

Although the underlying idea still remains valid to some extent, I firmly believe that the people who write about this text are now more relevant than the text itself.

At most, it can only hold historical value, serving as a relic of a bygone era in the field of software development.

It is a reminder of how much things have changed and how quickly the technology landscape evolves.

Perhaps it can still offer some insights into the past, but it can no longer be considered a cutting-edge or relevant piece of work in the current context.

I did not finish reading this particular piece.

I really struggled with it. It is a really well-known classic in the software world. However, I'm not finding much of what Brookes is conveying especially insightful in the current software climate.

Maybe if I become a project manager, I'll come back to it. I would definitely recommend it to any project manager working in software (from what I have read of it).

It seems that the ideas presented might have been more relevant in the past, but in today's rapidly evolving software environment, some of the concepts may not hold the same level of significance.

Nonetheless, it could still offer valuable perspectives and lessons for those in the software project management field.

Perhaps with more experience and a different perspective as a project manager, I would be able to better appreciate and understand the true essence of what Brookes is trying to communicate.

Until then, I'll keep it in mind and may revisit it in the future.

I have a profound respect for the historicity and pioneering nature of this book. It holds a significant place in the literary or academic realm, having made important contributions and set new precedents. However, despite its remarkable qualities in these aspects, I must admit that it was truly, really boring. The writing style might have been too dry or the content presented in a rather monotonous way. It failed to capture my attention and engage me on a deeper level. I found myself struggling to get through the pages, constantly fighting the urge to put the book down. It's a pity that such a potentially great work had this drawback, as it could have been so much more if only it had been more captivating and interesting.