Reddit Reddit reviews The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition)

We found 99 Reddit comments about The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition). Here are the top ones, ranked by their Reddit score.

Computer Science
Computers & Technology
Books
The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition)
NewMint ConditionDispatch same day for order received before 12 noonGuaranteed packagingNo quibbles returns
Check price on Amazon

99 Reddit comments about The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition):

u/samort7 · 257 pointsr/learnprogramming

Here's my list of the classics:

General Computing

u/Little_darthy · 49 pointsr/programming

Edit: I didn't realize the link was just the first chapter. If you really liked it, I do suggest purchasing it. You can find it all online for free, but I do highly recommend just having this book. It's a fun read.

 

Here's an excerpt that I really love right from the beginning of the book.

>>All programmers are optimists. Perhaps this modern sorcery especially
attracts those who believe in happy endings and fairy godmothers.
Perhaps the hundreds of nitty frustrations drive away all
but those who habitually focus on the end goal. Perhaps it is
merely that computers are young, programmers are younger, and
the young are always optimists. But however the selection process
works, the result is indisputable: "This time it will surely run," or
"I just found the last bug."

Here's a link to a Physical copy [on Amazon] (https://www.amazon.com/Mythical-Man-Month-Software-Engineering-Anniversary/dp/0201835959) if you want it.

 

edit: Bonus Dilbert Comic

u/Nezteb · 43 pointsr/compsci

Some book recommendations:

u/feketegy · 25 pointsr/PHP

Every quality software should have tests. So...

Read the unit tests / features tests first. Those will show you how a specific piece of the code works.

Also:

  1. Play with composer packages.
  2. Learn about PHP SPL
  3. Learn about design patterns and beyond
  4. Learn TDD, setup PHPUnit, Behat, Mink, PHPSpec
  5. Read PHP The Right Way
  6. Learn about clean code, EBI, DCI and how to put MVC on a shorter leash here: http://ikke.info/clean_code.html and here http://ikke.info/todo.txt and check out the #cleancode IRC channel on freenode
  7. Read a couple of books like: PHP Objects, Patterns and Practice or Code Complete or Clean Code or The Pragmatic Programmer or The Mythical Man-Month
  8. Start an open-source project or contribute to one


    There are a lot to learn and if you really like programming you will never stop learning.

u/cronin1024 · 25 pointsr/programming

Thank you all for your responses! I have compiled a list of books mentioned by at least three different people below. Since some books have abbreviations (SICP) or colloquial names (Dragon Book), not to mention the occasional omission of a starting "a" or "the" this was done by hand and as a result it may contain errors.

edit: This list is now books mentioned by at least three people (was two) and contains posts up to icepack's.

edit: Updated with links to Amazon.com. These are not affiliate - Amazon was picked because they provide the most uniform way to compare books.

edit: Updated up to redline6561


u/Ruple · 17 pointsr/EngineeringStudents

>I have some questions about courses andsubjects for computer engineering ( Software Engineering)

CE and SWE are....a little different so I'll just talk to both a little bit.

CE is closer to Electrical Engineering specializing in Computers so you'd take more hardware oriented courses. Most CE curriculums [I've seen] take you through Circuit Theory, Electronics, Digital Systems, Signal Processing, Computer Organization (aka CPU design), Computer Networks, Embedded Systems, etc.

SWE is closer to applied computer science and is more about building applications and the software development process. So you'd start going through a lot of the early Comp Sci courses (Intro to Programming, Language Processors, Data Structures and Algorithms, Operating Systems, etc.) then you'd start leaning towards topics more closely related to building an actual piece of software like Software Project Management or Quality Assurance.

>Are they any books that you recommend to a complete noob ? Internet links ?

Who reads books?

u/therascalking13 · 15 pointsr/wow

There's a very popular management book about just this topic.

u/roo-ster · 13 pointsr/sysadmin

This was famously used by the lead manager of the IBM OS360 development project, to explain why adding more programmers wouldn't make it possible to deliver the OS, sooner.

[Edit: For anyone who's interested, he wrote a book called The Mythical Man-Month on this exact topic.]

u/JamesKerti · 13 pointsr/ProtonMail

I don't work for ProtonMail but as someone who worked as a part of a development team, I feel like I have something to contribute to this discussion.

Getting the Bridge done as quickly as possible isn't simply a question of throwing as many people as they can at the problem.

First, it's an established fact in the software world that shoving more programmers at a project can actually make things worse, rather than better.

Secondly, not every developer brings the same thing to the table and has the same expertise.

The ProtonMail web interface uses one technology.
The encryption itself uses another, plus an even deeper level of theoretical understandings.
ProtonVPN is a completely different technology.

To stick with the house analogy, suggesting that building ProtonVPN means the Bridge isn't a priority is like suggesting that the plumbing in the house must not be a priority because you aren't pulling the carpenters off their jobs to help get the plumbing done as soon as possible.

u/dev_bry · 12 pointsr/learnprogramming

You've already done the first step: admitting that college can only teach the fundamentals while the rest of the things you need to know, you will learn while working.

With that out of the way, here's the next step: apply the Joel Test to your new employer.

If it gets an 11 or 12, you'll be fine. Find a senior developer there to mentor you and you'll be a decent software engineer in 1 - 2 years.

Otherwise, while you might learn a lot of new stuff in your first job, they might be inadequate, outdated, or outright incorrect. In this case, plan an exit strategy ASAP so that you can leave to another company that has a much higher score in the Joel Test. In this fast paced software industry, it makes no sense to spend 5 years in a company where you'd only get to grow the same amount as another guy who just spent 6 months in a better company.

Next step: read. No, not those "Teach yourself [insert language that will be deprecated in 2 years] in 24 hours" books - find the books that teach software engineering, lessons that don't get outdated. Here's the usual suggestions:

u/FeepingCreature · 12 pointsr/starbound

I think this is the problem:

this is what you thought you were saying:

> I think "months" is an exaggeration and I think a lot can be picked up by just reading existing docs.

this is what people thought you were saying:

> I think I know better than The Mythical Man-Month. A new programmer can jump right in at 100% without requiring any instruction or support.

this is what you were actually saying

> I don't buy that new programmers need to be taught existing code...

I mean dude, come on. Either you're backpedalling now or you suck at expressing yourself.

u/roodammy44 · 11 pointsr/cscareerquestions

I can't believe noone has mentioned The Mythical Man Month yet. If nothing else, it will help you give better time estimates for your work.

u/Zokleen · 11 pointsr/Denmark

Et godt sted at starte er bogen “The mythical Man-month” af Fred Brooks. https://www.amazon.com/Mythical-Man-Month-Software-Engineering-Anniversary/dp/0201835959

IT-projektledelse er på mange måneder ikke anderledes end projektledelse generelt, men der kræves en væsentlig forståelse for, at opgaverne som oftest kan være enormt komplekse af natur.

Du vil derfor opleve, af din aller aller største hurdle ikke er dit team, som står for eksekveringen, men dine interessenter (aka stakeholder management). Uden at smøre unødigt tykt på stereotyperne, så er det de færreste “projektsponsorer” eller lign interessenter fra forretningssiden, som egentlig har bare en snært af sans for hvorfor IT/softwareudvikling er svært at tids/budget-estimere.

Et klassisk eksempel:

  • Chef: “Jamen det er jo bare en lille knap, hvor svært kan det være..!”
  • Projektleder: “Ok, trækker vejret dybt og finder whiteboard markeren frem ... lad mig forklare det igen....”
  • Chef: “ej det behøver du ikke. Jeg har allerede lovet det til kunden at vi har det klart i næste uge”


    Udfordring nummer 2 er, at din interessenter/ resten af forretningen stort ser altid lever i en “waterfall” verden, også selvom I kører agile eller lign. metoder.

    Dvs, at I som team ofte kan føle jer enormt klemt af, at den eksterne verden ikke forstår eller gider spille med indenfor jeres best practices. (Men det lyder fedt for virksomheden at proklamere “vi er agile”).

    Anyway, det skal siges at jeg til dagligt arbejder med product management, så det er lang tid siden jeg har levet i en “project-only” verden.

    Edit: typos
u/mysticreddit · 9 pointsr/gamedev

Actually, it's a bit of both.

Problems / Criticism of GoF


1. The GoF was written in the era of "OOP is a silver bullet" and single-threaded programs by academics who were generally clueless about the importance of understanding data transforms, data caches, instruction caches, and minimizing cache misses. See: Pitfalls of Object Oriented Programming of how you get massive speedups just by understanding cache usage and re-arranging the data.

2. One of the problem with the GoF methodology is when people turn it into a religion. People start trying to apply design patterns to everything even when it isn't needed and you end up with this over-engineered, bloated, slow, clusterfuck of code.

3. Programmers who focus on performance have also been pretty vocal about "cargo cult programming" and design patterns:

  • Christer Ericson who wrote the phenomenal Real Time Collisision Detection had this to say about design patterns:

    > The “Design Patterns” book is one of the worst programming books ever. Yes, really. I’m 100% dead serious when I say that I think it has set (and will continue to set) the progress of software development back by decades. Why?! Let me offer up a parable; I will call it “The Plank.”

  • Mike Acton, the father of "Data Orientated Design" also agrees when he quoted Eric at a C++ convention:

    > "Design patterns are spoonfed material for brainless programmers incapable of independent thought, who will be resolved to producing code as mediocre as the design patterns they use to create it with."

    4. While abstraction can be a nice way to solve a problem there are ALWAYS trade-offs. The flexibility of abstraction is that you generally tend to lose efficiency. Blinding applying a design pattern means you aren't thinking about the performance issues. In today's age of multi-core software this is a huge disadvantage compared to your competitors.

    And while Ericson and Acton tend to throw the baby out with the bathwater they are speaking from years of experience of writing fast, simple code. This ISN'T an appeal to authority as they aren't just some armchair academics -- they have demonstrated they have understand HOW to write FAST code. Their experience also matches what I've seen.

    5. Another problem is that changing the hardware changes the problem. GoF doesn't take this into account.

    6. Very rarely does OOP "perfectly" model the problem. GoF ignores this.

    7. Another part of the problem is that OOP is NOT scalable. OOP has a design fallacy that "one is the common case." This is almost never the case. The common case is usually you have multiple objects. Again GoF ignores for the most part. They take a stab at it with the Flyweight Design Pattern but that isn't scale when you REALLY do have many, mutable objects such as the particles of a particle system.

    And while I am not as adamant as Ericson or Acton about being "anti-design-patterns" they DO have a point -- not understanding the strengths AND weaknesses of an algorithm makes for a poor programmer IMHO. Remember, there are THREE ways to optimize:

  • Micro-optimizations, aka Bit Twiddling Hacks
  • Algorithms -- using a better O(n) algorithm
  • Macro-optimization, aka Data-Orientated Design -- minimizing cache misses.

    Go ahead and use design patterns for your tools. But for engine/games DoD will usually solve the problem simple and faster then misapplying and blindly applying a design pattern.

    Solution


    Lastly the problem of complexity was summarized by Fred Brooks in The Mythical Man-Month

    > "Show me your flowcharts (source code), and conceal your tables (domain model), and I shall continue to be mystified;
    > show me your tables (domain model) and I won't usually need your flowcharts (source code): they'll be obvious."

    A more modern colloquialism would read:

    > Show me your code and I'll have to see your data,
    > Show me your data and I won't have to see your code.

    The secret to high performance is NOT the algorithm but to focuse on HOW the data is transformed. i.e. The first rule of optimization is:

    Know Thy Data

u/0b_101010 · 9 pointsr/learnprogramming

Hi! I recommend the following books:

u/[deleted] · 8 pointsr/brasil

Cara... interessante esse teu desabafo, porque acredito que isso se passa na cabeça da maioria dos devs.

Trabalho como desenvolvedor há 15 anos já. Como eu vim do Java e sou Backend Engineer, a preocupação (na época que eu comecei a trabalhar) era em certificações (poxa, não tenho a SCWCD etc) e frameworks (Spring, Struts, Hibernate) ou outras API (JasperReports e o escambal).

E ninguém botava fé que na época JS iria ser tão poderoso hoje.

Esse sentimento vem se arrastando por anos mas a real é que as coisas sempre vão mudando, sempre com a preocupação de não estar trabalhando com uma coisa nova como linguagem funcional (Scala, Haskell, Clojure) etc, mas te falar que... no final das contas, qualquer nova tecnologia em TI a gente aprende sem muito esforço (tirando Scala) e nunca vamos saber tudo.

A loucura é que em 2006-2007 eu imaginava que 10 anos depois Java sequer iria existir, tudo ia ser Ruby e on Rails etc mas no final, Java continua firme e forte, sendo o meu ganha pão só que... Os problemas de gestão de projetos continuam a mesma merda, tal como era na década de 70.

A dica que dou é que tu não precisa se preocupar com todas essas sopas de letrinhas. Você não precisa saber COMO usar tudo, mas tendo IDEIA do que é cada coisa (tipo, o que é React, Angular, NodeJS, containers, serverless etc) já é ótimo. Talvez fazer um hello world naquela hora de procrastinação no trabalho já vai ser super lucrativo.

Ah, só um bônus sobre "as dores" dos devs nos últimos 50 anos: https://www.amazon.com/Mythical-Man-Month-Software-Engineering-Anniversary/dp/0201835959

u/dakboy · 7 pointsr/programming

LWRellim is exactly right.

Tomorrow morning, go to your local library or bookstore and find this book. You don't have to read the whole thing right away, but if you can spend the afternoon with it at least, it's worthwhile.

Chapter 11 especially is appropriate here, where you're in the position of "flushing it all down the proverbial crapper." Plan to Throw One Away One can also use a line from The Matrix - everyone falls the first time.

I'm not going to say that every software project bombs the first time around. That's definitely not the case. But many times, especially on your first custom programming experience, no matter how well you think you understand what needs to be built, you will paint yourself into corners and discover all kinds of stuff that you had never considered before you started to build the first version.

Depending on where you are in the project, and how things have been put together, you may have to literally toss everything. In your case, you might be able to salvage some UI bits, but your new developer will probably redo everything else.

u/alex_kendall · 7 pointsr/compsci

The Mythical Man Month published 1975(!)

"Arguably the only classic book in our field"
----------------
Lot of good books listed here, but my advice is to read this book, and play around with some new tool (like git). Now that I think about it, learning git along with reading this book is actually perfect, because you'll learn how to use the tools that we have today that the author dreams of, and why they are so powerful and important.

Yes, this is the perfect break material: git and The Mythical Man Month. Short book too.

u/AMagill · 6 pointsr/engineering

Doesn't quite sound like what you're describing, but The Mythical Man Month is the book I've most often heard described as absolutely essential for understanding problems with managing software projects.

u/Gusfoo · 6 pointsr/startups

Perhaps.

But that aside, you should always throw away version 1. You now know far, far more about the reality of the situation than you did when you built your MVP.

Also. Go and read The Mythical Man Month.

u/MrInvisibility13 · 6 pointsr/wow

more employees = more code = more complex codebase = more bugs.

This is a useful book for understanding what's happening here: https://www.amazon.com/Mythical-Man-Month-Software-Engineering-Anniversary/dp/0201835959

u/obeleh · 6 pointsr/compsci

Perhaps offtopic but... Some books you should read regardless of CompSci branch

u/riking27 · 5 pointsr/linux

I think this is the book you want: Mythical Man-Month

u/tsjr · 5 pointsr/GlobalOffensive

Programming team size doesn't directly relate to its productivity or efficiency. Recommended reading: http://www.amazon.com/The-Mythical-Man-Month-Engineering-Anniversary/dp/0201835959

u/NowTheyTellMe · 5 pointsr/UCI

So this is what I would consider the "Core" reading list for anyone interested in programming games. None of this is really game specific though. These are just the fundamentals you need in order to be an effective Software Engineer.

Learn about...

C++ syntax: Programming: Principles and Practice Using C++ by Bjarne Stroustrup

Software Engineering: Code Complete by Steve McConnell

C++ gems: Effective C++ by Scott Meyer

Software Teams: The Mythical Man-Month by Frederick P. Brooks Jr.

Why we love Joel: Joel on Software by Joel Spolsky

Problem Solving: The Pragmatic Programmer by Andrew Hunt

Common Code Solutions: Head First Design Patterns by Eric Freeman

Pearls!: Programming Pearls by Jon Bentley

I'll do a supplemental on this in a few days that dives into specific topics related to engine development. All of this is generic enough that it will help you regardless of what you do. You'll notice that very little here is actually language specific. Almost all of this is about the art of making software and process of working with a team. These 8 books alone will make you think about making software in a whole new way.

u/Zidanet · 5 pointsr/dogecoin

You should read The Mythical Man Month. It's quite a good explanation of why throwing money and manpower at software does not fix problems and can significantly increase delay.

There's nothing wrong with a small development team using an agile development method.

u/eric_weinstein · 5 pointsr/learnprogramming

Seconding The Pragmatic Programmer and Cracking the Coding Interview. I'd also recommend:

  • Code Complete: verbose and somewhat self-congratulatory, but extremely good.
  • The Mythical Man-Month: a little dated and weirdly religious at times, but has great insights into how software problems are actually people problems and how large projects are (mis)managed.
  • Design Patterns: a.k.a. the Gang of Four book. This one's a classic.
  • Pro Git: you mentioned version control systems. IMHO, you should learn Git if you don't know it, and this book is a great resource.

    If you let us know which languages you primarily write, I can probably recommend some good language-specific titles, too.
u/ckdarby · 4 pointsr/PHP

I have included some links for more information about myself in the original post.

To have a better idea of the type of person I am these are the books within my arms reach right now:

Design Patterns: Elements of Reusable Object-Oriented Software

[Refactoring: Improving the Design of Existing Code](
http://www.amazon.ca/gp/product/0201485672)

The Mythical Man-Month

Along with some other ~50 similar books I've read.

u/Captain · 4 pointsr/programming

> In other disciplines, engineering in particular, there > exist treatises on architecture. This is not the current case in software,

Gee I better throw out all those books on architecture since clearly they don't exist.

We can also ignore Fowler's book, GOF, SICP, and TAOCP since clearly they are treatises on software either.

u/CSMastermind · 4 pointsr/learnprogramming

I've posted this before but I'll repost it here:

Now in terms of the question that you ask in the title - this is what I recommend:

Job Interview Prep


  1. Cracking the Coding Interview: 189 Programming Questions and Solutions
  2. Programming Interviews Exposed: Coding Your Way Through the Interview
  3. Introduction to Algorithms
  4. The Algorithm Design Manual
  5. Effective Java
  6. Concurrent Programming in Java™: Design Principles and Pattern
  7. Modern Operating Systems
  8. Programming Pearls
  9. Discrete Mathematics for Computer Scientists

    Junior Software Engineer Reading List


    Read This First


  10. Pragmatic Thinking and Learning: Refactor Your Wetware

    Fundementals


  11. Code Complete: A Practical Handbook of Software Construction
  12. Software Estimation: Demystifying the Black Art
  13. Software Engineering: A Practitioner's Approach
  14. Refactoring: Improving the Design of Existing Code
  15. Coder to Developer: Tools and Strategies for Delivering Your Software
  16. Perfect Software: And Other Illusions about Testing
  17. Getting Real: The Smarter, Faster, Easier Way to Build a Successful Web Application

    Understanding Professional Software Environments


  18. Agile Software Development: The Cooperative Game
  19. Software Project Survival Guide
  20. The Best Software Writing I: Selected and Introduced by Joel Spolsky
  21. Debugging the Development Process: Practical Strategies for Staying Focused, Hitting Ship Dates, and Building Solid Teams
  22. Rapid Development: Taming Wild Software Schedules
  23. Peopleware: Productive Projects and Teams

    Mentality


  24. Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency
  25. Against Method
  26. The Passionate Programmer: Creating a Remarkable Career in Software Development

    History


  27. The Mythical Man-Month: Essays on Software Engineering
  28. Computing Calamities: Lessons Learned from Products, Projects, and Companies That Failed
  29. The Deadline: A Novel About Project Management

    Mid Level Software Engineer Reading List


    Read This First


  30. Personal Development for Smart People: The Conscious Pursuit of Personal Growth

    Fundementals


  31. The Clean Coder: A Code of Conduct for Professional Programmers
  32. Clean Code: A Handbook of Agile Software Craftsmanship
  33. Solid Code
  34. Code Craft: The Practice of Writing Excellent Code
  35. Software Craftsmanship: The New Imperative
  36. Writing Solid Code

    Software Design


  37. Head First Design Patterns: A Brain-Friendly Guide
  38. Design Patterns: Elements of Reusable Object-Oriented Software
  39. Domain-Driven Design: Tackling Complexity in the Heart of Software
  40. Domain-Driven Design Distilled
  41. Design Patterns Explained: A New Perspective on Object-Oriented Design
  42. Design Patterns in C# - Even though this is specific to C# the pattern can be used in any OO language.
  43. Refactoring to Patterns

    Software Engineering Skill Sets


  44. Building Microservices: Designing Fine-Grained Systems
  45. Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools
  46. NoEstimates: How To Measure Project Progress Without Estimating
  47. Object-Oriented Software Construction
  48. The Art of Software Testing
  49. Release It!: Design and Deploy Production-Ready Software
  50. Working Effectively with Legacy Code
  51. Test Driven Development: By Example

    Databases


  52. Database System Concepts
  53. Database Management Systems
  54. Foundation for Object / Relational Databases: The Third Manifesto
  55. Refactoring Databases: Evolutionary Database Design
  56. Data Access Patterns: Database Interactions in Object-Oriented Applications

    User Experience


  57. Don't Make Me Think: A Common Sense Approach to Web Usability
  58. The Design of Everyday Things
  59. Programming Collective Intelligence: Building Smart Web 2.0 Applications
  60. User Interface Design for Programmers
  61. GUI Bloopers 2.0: Common User Interface Design Don'ts and Dos

    Mentality


  62. The Productive Programmer
  63. Extreme Programming Explained: Embrace Change
  64. Coders at Work: Reflections on the Craft of Programming
  65. Facts and Fallacies of Software Engineering

    History


  66. Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software
  67. New Turning Omnibus: 66 Excursions in Computer Science
  68. Hacker's Delight
  69. The Alchemist
  70. Masterminds of Programming: Conversations with the Creators of Major Programming Languages
  71. The Information: A History, A Theory, A Flood

    Specialist Skills


    In spite of the fact that many of these won't apply to your specific job I still recommend reading them for the insight, they'll give you into programming language and technology design.

  72. Peter Norton's Assembly Language Book for the IBM PC
  73. Expert C Programming: Deep C Secrets
  74. Enough Rope to Shoot Yourself in the Foot: Rules for C and C++ Programming
  75. The C++ Programming Language
  76. Effective C++: 55 Specific Ways to Improve Your Programs and Designs
  77. More Effective C++: 35 New Ways to Improve Your Programs and Designs
  78. More Effective C#: 50 Specific Ways to Improve Your C#
  79. CLR via C#
  80. Mr. Bunny's Big Cup o' Java
  81. Thinking in Java
  82. JUnit in Action
  83. Functional Programming in Scala
  84. The Art of Prolog: Advanced Programming Techniques
  85. The Craft of Prolog
  86. Programming Perl: Unmatched Power for Text Processing and Scripting
  87. Dive into Python 3
  88. why's (poignant) guide to Ruby
u/bautin · 4 pointsr/cscareerquestions

Probably much the same. His book, The Mythical Man-Month, was written in the 70s and given an update in the 90s. The essay, No Silver Bullet, was written in 1986 and included in the anniversary edition of the book.

In the early 00's, it was still highly recommended and I believe one of the books given out when you were hired by Microsoft.

That's because Brooks isn't talking about specifics, he's talking about overall concepts. SCRUM and Agile may be able to mitigate some remaining accidental difficulties, and in some ways, they are influenced by Brooks's works and that of DeMarco and Lister in Peopleware. Trying to reduce the number of communication pathways and reduce turnaround in order to avoid driving towards complexity.

But I think if Brooks were to update the essay to account for SCRUM and Agile, he would still acknowledge that it is still impossible for 9 women to make a baby in a month.

u/SaidWayTooMuch · 4 pointsr/slatestarcodex

The Mythical Man Month has been taught in some CS programs for quite a while; definitely has influenced my thinking.

u/beowulfpt · 3 pointsr/Android

Ah, the mythical man month.

Brooks's Law: "Adding manpower to a late software project makes it later."

u/dmmagic · 3 pointsr/projectmanagement

I'm a consultant with an IT software company, and with the current client I'm working with, I spent my first 3 weeks doing nothing but research and interviews and gathering information. Since you're starting as essentially a junior PM, just ask the senior people or your line manager how long they expect you to research and come to understand the project before needing to deliver anything. Hopefully, if all goes well, it'll be an organic process and will sort itself out in time. Be patient and just take lots and lots of notes.

Since you're in the position of having senior PMs, there's a good chance you won't need to establish objectives, at least right off the bat. You may be doing calculations, maintaining schedules, facilitating communications, etc. I say play that one by ear. Since you're new to the process, I recommend reading The Mythical Man Month and taking it to heart. Be wary of underestimating, and do your best to take reality into account as well as ever-shifting demands.

As to what a PM generally spends their time on, it totally depends on the organization and the project. I'm not a dedicated PM, and my background is actually in IT management. That said, at my last job, I did some PM, and I'm currently getting my master's in project management and will follow that up with a PMP. As a consultant, I'm working with the PMO, among other groups, and I spend a lot of my time in meetings and communicating, both to gather requirements from stakeholders and translate those into stories, and to make sure all stakeholders are on the same page. I spend a lot of time making sure that people have proper visibility into the project, which means good reporting and keeping a lot of notes close at hand. Developing a good system for maintaining your notes is essential if you don't already have one. I rely heavily on Evernote, but I've got a methodology for Outlook, and for my file system (be it in Google Drive or Dropbox or elsewhere), and for Skype.

Making educated decisions is our job. There's a science to PM, but at the end of the day, we're humans dealing with humans. We make the call to the best of our abilities, and take responsibility to fix it if we're wrong.

Regarding passing up the opportunity, I say absolutely not. You'll learn a lot more in this position than at a lower level PC job. Approach it ready to fail and pick yourself back up, and fail fast, and you'll grow quickly. Maintain your confidence as best you can, keep finding more books and resources to read/watch/listen to, and do your best.

Another good resource I'd recommend is the Project Management for the Masses G+ community and podcast. There are a number of different PM podcasts out there that are quite good (I also recommend the People and Projects Podcast), and quite a few good books.

As you get further into it, you'll discover that PM is actually a relatively new field, really just a few decades old. There's a lot to learn, but don't get too stressed about it. Take that energy and go learn more instead :-)

u/bluestudent · 3 pointsr/projectmanagement

I haven't read either of these books so I can't vouch for them personally, but my understanding is that Peopleware and Mythical Man Month are classics.

u/toyg · 3 pointsr/ItalyInformatica

In realtà non mi ricordo esattamente se la citazione viene da The Mythical Man-Month o se da Peopleware, li ho letti praticamente uno dietro l’altro. Se non li conosci, consiglio vivamente.

Non discuto che il “mitico mese-uomo” sia moneta corrente, il discorso è che sappiamo da anni che è una moneta rozza e inaffidabile, e quindi va presa con pinze molto lunghe.

u/curious_webdev · 3 pointsr/compsci

Not all on topic as "CS" books, more general programming, but here's a short list. I also suggest the opening chapter or two of a lot of books for stuff you don't know but are interersted in. They're generally just nice easy to read introductions.

u/IBreakCellPhones · 3 pointsr/kansascity

It's a reference to "The Mythical Man-Month," discussing how throwing more bodies at a late project makes it later. As in what I replied to, there's a certain point where adding workers gives diminishing, and even negative, returns.

u/bdnicho · 3 pointsr/WildStar

Ignoring the fact that these reviews will be biased to the vocally displeased, it does present another opportunity to suggest any software project manager and the executives of such organizations to read The Mythical Man Month.

u/effthisish · 3 pointsr/FortNiteBR

As an actual software engineer, saying "they just need to put a good month of work in" is absolutely fucking hilarious. There's a reason that The Mythical Man-Month has been so influential in software development.

u/theg33k · 2 pointsr/Futurology

I recommend reading The Mythical Man Month. Adding more resources is almost certainly not going to make Watson progress faster. We don't know anything about Watson. It may be terribly designed and nearly impossible to expand. For all we know the best decision might be to scrap Watson altogether and start again from the ground up.

u/ButUmmLikeYeah · 2 pointsr/audioengineering

For OP's reference:

Fred Brooks: The Mythical Man Month (on Amazon) http://www.amazon.com/Mythical-Man-Month-Software-Engineering-Anniversary/dp/0201835959

Reading your post inspires me to perhaps hone my dormant programmer skills. What do I hate? Making spreadsheet filling database inquiries and turning it into meaningful demographic reports. What do I like? Audio. If audio programmers are specialists priced at top dollar... Hmm...

EDIT: Codetosterone... lmao

u/orbitalia · 2 pointsr/TheRedLion

Yeah I heard about Hinkley Point C, wonder if it will happen as it needs a hike in Electricity prices. No role for me, being in Sweden and all.

Glad you asked for recommendations - read the Mythical Man Month, it is a classical piece of literature on Software Development , its from the 60s 70s but holds true even today,

http://www.amazon.com/The-Mythical-Man-Month-Engineering-Anniversary/dp/0201835959/ref=sr_1_1?ie=UTF8&qid=1375051342&sr=8-1&keywords=mythical+man+month

and Code Complete, by Steve Mcconnell (I have met him in the US a few times)

http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670/ref=sr_1_1?s=books&ie=UTF8&qid=1375051372&sr=1-1&keywords=code+complete

probably enough with those two to start with..

u/goblinpiledriver · 2 pointsr/learnprogramming

The Mythical Man Month is the title you're looking for.

u/trashhalo · 2 pointsr/programming

Disclaimer: This may not be true for your job, but it has been for every job I have worked at.

That everything they are teaching you about algorithms will not be useful to you when you get into the field. Your education starts day one at your first job. Clients don't pay us to innovate in algorithms. They pay us to find and glue together other peoples libraries and to use this to present them the requested information.

Code you will actually be writing:

  • Glue code. Integrate Library X with Library Y.
  • Unit tests. To make sure your glue code works as expected.
  • UI code.

    Things you will be doing that CS degree does not prepare you for

  • Fleshing out incomplete requirements documents
  • Dealing with drama between teams
  • Estimation
  • Understanding that 80% is often good enough

    I would suggest reading books like Design Patterns, Mythical Man-Month and Code Complete
u/selv · 2 pointsr/sysadmin

I can recommend books.

u/SofaAssassin · 2 pointsr/cscareerquestions

For more foundational stuff, I'd look at:

  • GitFlow - a successful Git branching model - This is pretty much the prototypical Git usage model. I have seen it used pretty much everywhere I've worked that used Git, and a lot of software supports the model by default (Atlassian Stash, SmartGit, Git Tower, and more).

    • Also take note of alternative Git usage models like GitLab Flow and GitHub Flow. They fit rather different use cases, and GitFlow is typically used for software that follows a more old-school release model where releases happen periodically, or you need to support multiple production releases at any given time. GitLab and GitHub flow are geared more toward software that only sees a single version in production at any given time, and very common release cycles (e.g. daily or even shorter).

      Getting familiar with these branching models will also expose you to many commonly-used Git features like branching, squash merging, rebasing, tagging, and history rewriting.

  • How to write a commit message

    No one's really gonna ask you about this, but you should develop a habit of writing great, clear, and concise commit messages.

  • Continuous Delivery and Continuous Integration

    All the rage right now - having real/near-real time building/unit-testing/packaging/deployment of your software once you've made a code commit. Read the articles I linked, play with services like CircleCI or Travis-CI or CodeShip and integrate them with your projects in GitLab.

  • Test-Driven Development and Behavior-Driven Development

    Probably the two most commonly used overarching test-based software development processes. I'm a strong proponent of TDD (when done right), and many teams you work on will probably employ TDD or BDD.

  • Stemming from the last point, know how to write good unit tests and how they differ from integration tests or acceptance tests.

  • Code organization - a lot of this will likely be influenced by the language/toolset you're working in, but you'll be interested in learning about Layered Architecture and software packaging metrics.

  • Generic software design - all sorts of acronyms to read about and absorb, like YAGNI, KISS, DRY, and SOLID. Also, the Unix philosophy, which guided a lot of development of software for Unix and Linux these days. There will also be patterns that apply to specific languages or types of software, but the stuff above is rather generically applicable.

    Beyond those links, some books that cover a lot of general material are:

  • Clean Code
  • Pragmatic Programmer
  • Mythical Man-Month
  • Software Estimation - Okay, software estimation is really gonna be complex and difficult until you get a lot of experience, and even experienced developers get it wrong. I don't think it's particularly necessary to read this book when you're starting out.
  • Domain Driven Design - I love this book - it's about breaking down complex software designs.
  • Release It! - Nygard is a pretty battle-tested developer, so this book is about approaching software design practically rather than in a vacuum separated from real-world application.
u/DigitalSuture · 2 pointsr/Rainbow6

To expand on what u/dwelknarr pointed out, you can read an excellent book on how more people can actually slow production and other human impacted areas of software engineering.

The Mythical Man Month

u/pxld1 · 2 pointsr/EscapefromTarkov

Not defending BSG's track record here, but software dev is a strange animal. One of those rare things where increasing people can actually make things exponentially more difficult.

Good book that first comes to mind

u/DeadBabyOrgasm · 2 pointsr/AskReddit

There's a book about this? I just thought this was a well known phenomenon apparent in Dilbert comics and any job where code monkeys can be found.

Edit: Link for the lazy

u/SQLSavant · 2 pointsr/learnprogramming

Some of these are directly related to programming and some are not but are additional reading that touch on skills that most every programmer should have some concept or idea of.

I've read all of these at some point throughout my career and can attest to their usefulness. Here's my personal list:

u/jollaffle · 2 pointsr/MonsterHunter

Only for tasks that can be effectively divided among that many people. In software development, adding more people tends to cause the project to take longer, because it requires substantially more coordination and communication.

Check out the Mythical Man-Month to learn more.

u/ominous · 2 pointsr/programming

A Discipline of Programming. Classic but expensive. Read the first few chapters at your library before buying.

Polya's How to Solve It!

The Mythical Man-Month

Finally, The Pragmatic Programmer.

u/andand89 · 2 pointsr/engineering

Maybe not the most technical: The Mythical Man-Month


It's more of a software engineering/project management book. Still something I'd recommend.

u/thenuge26 · 2 pointsr/Minecraft

The quickest way to kill a software project is to add more people to it.

Source.

u/AlSweigart · 2 pointsr/learnpython

WHY DO YOU ASK MAINTAINS THE PROPER ATTITUDE OF A DECENT THING?

:)

> From experience, one book is barely enough to get your feet wet

Ha! Definitely. I keep getting ideas for other books I should write.

I'd recommend the following as good general books to read. They're all good no matter what type of programming you do:

u/CodeTamarin · 2 pointsr/cscareerquestions

I always thought there should have been a subreddit called r/CompSciSoftSkills. I recently read a couple books, Peopleware and then The Mythical Man Month .

Peopleware mentioned that software development was more a sociological process than a technological one and I found that fascinating. I always thought that having a subreddit dedicated to exploring the sociological side of software development would be very interesting and revealing.

... and by extension and exploration of the skills outside whiteboards and code that apply to software dev.

u/a_small_goat · 2 pointsr/csharp

You're not going to want to read things that make you wish you had a computer with you, trust me. You have no idea how many times I have tried to force myself to read stuff like that when traveling or on vacation. Never works. So here's some stuff geared more towards the philosophy of development and programming that will be fun to read and will probably make you want to slow down, relax, and think about the concepts.

u/nkavadias · 1 pointr/reddit.com

Fred Brooks Mythical Man Month should be on your list for sure. Its the most i ever threw up, and it changed my life.

http://www.amazon.com/exec/obidos/ASIN/0201835959/ref=nosim/joelonsoftware/

u/flundstrom2 · 1 pointr/programming

The mythical man-month https://www.amazon.com/gp/aw/d/0201835959/ref=dbs_a_w_dp_0201835959

The first version was published 40 years ago, but its content was reviewed and updated when the current version was written, 20 years ago. And you'll be surprised to realize that developers still keep doing the same mistakes as back then...

BTW: Also check out The pragmatic Programmer. Also focused on best practices gained from real-world experiences.
https://www.amazon.com/gp/aw/d/020161622X/ref=dbs_a_w_dp_020161622x

u/schwiz · 1 pointr/kansascity
u/ItsAPuppeh · 1 pointr/webdev
u/GetOffMyLawn_ · 1 pointr/ProgrammerHumor

This is the guy who gave us that idea. From my other post:

Fred Brooks wrote The Mythical Man Month, one of the classics of IT literature. In it he describes being a software engineering product manager at IBM and the development of OS/360. If you haven't read it yet do so ASAP. https://www.amazon.com/Mythical-Man-Month-Software-Engineering-Anniversary/dp/0201835959

u/houseofsabers · 1 pointr/AskEngineers

continued...

On the nonfiction side:

Free For All is about the history of open source software.

The Mythical Man-Month is a must-read for anyone in a managerial position.

Damned Lies and Statistics is a good one for anyone who knows stats.

u/devrelm · 1 pointr/compsci

Thank you! And that thread contains one of the books I was thinking of, The Mythical Man Month. I know it's more computer programming than computer science, but this is more the type of book I would like to find. Something that's more about the art of computer science as a whole rather than specifics on a certain aspect of it. Still, there are many great suggestions both in this thread and the Stack Overflow thread.

u/SettleDownButtercup · 1 pointr/gamedev

You have very little experience. A stand-alone game is a large, complex project. You don't have an experience with large, complex projects. It's very easy to get lost attempting a big project with so little experience. You should build a prototype first. Build it in a simple easy to use langauge like Javascript (or anything comparable), because C++ is a beast of a language to start with.

If it's supposed to be a 3D game, make it a 2D game. If it's a 2D game, simplify it to the barebone essentials (simple shapes, borrowed assets, use as few buttons as possible, use keyboard input, etc).

Read chapter 11 of The Mythical Man Month; Plan to Throw One Away. Your prototype is the one you'll throw away. You'll have a lot more valuable insight on your 2nd attempt.

u/GlorifiedPlumber · 1 pointr/ChemicalEngineering

I don't know of any that compare, but, the Napoleon's Buttons is SUPPOSED to be good.

http://www.amazon.com/Napoleons-Buttons-Molecules-Changed-History/dp/1585423319/

Other books, engineering related, that I liked are:

Norm Lieberman's Process Troubleshooting books, the guy cracks me up!

Working Guide to Process Equipment (3rd edition probably cheaper): http://www.amazon.com/Working-Guide-Process-Equipment-Fourth/dp/0071828060/

Process Equipment Malfunctions (not as good as the other one, some overlap, but still worthwhile, and covers more breadth for individual issues): http://www.amazon.com/Process-Equipment-Malfunctions-Techniques-Identify/dp/0071770208/

The Prize (mentioned above): http://www.amazon.com/gp/aw/d/1439110123/ref=redir_mdp_mobile/188-3799228-4803548

The Quest (Follow on to The Prize): http://www.amazon.com/Quest-Energy-Security-Remaking-Modern/dp/0143121944/

Oil 101: http://www.amazon.com/Oil-101-Morgan-Downey/dp/0982039204/

The Mythical Man Month (Not engineering directly as it pertains to software, but, projects and project management are huge in engineering, though this book is timeless): http://www.amazon.com/Mythical-Man-Month-Software-Engineering-Anniversary/dp/0201835959/

Piping Systems Manual (You can NEVER know enough about pipe!): http://www.amazon.com/Piping-Systems-Manual-Brian-Silowash/dp/0071592768/

Pumps and Pumping Operations (OMG it is $4, hardcover, go buy now! This book is great... did you know OSU didn't teach their Chem E's about pumps? I was flabbergasted, gave this to our intern and he became not a scrub by learning about pumps!): http://www.amazon.com/Pumping-Operations-Prentice-Pollution-Equipment/dp/0137393199/

Any good engineer needs to understand MONEY too:

The Ascent of Money: http://www.amazon.com/Ascent-Money-Financial-History-World/dp/0143116177/

It's Nial Fergesuon, who has had his own series of dramas and dumb stuff. The Ascent of Money has a SLIGHT libertarian tinge... but it wasn't bad enough that I didn't enjoy it. I consider it a history book, and he attempts to write it like one.

Have fun!

u/Nyandalee · 1 pointr/GameDeals

Please, help yourself to these links:

http://www.amazon.com/The-Mythical-Man-Month-Engineering-Anniversary/dp/0201835959

http://dilbert.com/2010-04-29/

The comic summarizes the main point of the book, and its one that developers end up having to present to the business side of a product over, and over and over again, and this whole idea of just throwing bodies at a project to up its completion speed needs to die. Even with double the team size from the very start, there is no way dev time would be halved. Adding bodies at the start of a project can improve feature richness and software quality, but software tends to grow to the uses of the business, which means progress always begets further changes.

u/the_omega99 · 1 pointr/learnprogramming
u/Forlarren · 1 pointr/Bitcoin

Yes it is. You assume that everyone can just drop the social aspects and work exclusively on the technological, as if man hours are fungible.

Go read this.

u/emosoresex · 1 pointr/dayz

Software engineer here. Making software isn't like building cars at a factory - throwing more people at it (at a point) doesn't get it produced any faster. There's actually a book about this topic, The Mythical Man Month(this book is kind of a bible in the field).

If I recall correctly (and I'm not going to cite this so take it with a grain of salt), Bohemia acquired a few studios that have made their own engines and are having said acquisitions into Bohemia work on the engine. They've made one before, they have the experience and having someone else work on it would be silly.

That still leaves developers that don't need to be working on the new engine.

Bohemia has been doing great lately and I don't think there's any reason to doubt or mistrust their project management at this point. Nothing wrong with scrutinizing it, but at this point nothing seems out of place or suspicious, in fact I'd say the opposite.

u/tau-lepton · 1 pointr/programming

Read this and get back

http://www.amazon.com/The-Mythical-Man-Month-Engineering-Anniversary/dp/0201835959

Or other hundreds of publications on why software development is a fundamentally different practice.

You clearly have very little real world software engineering experience.

u/jxfreeman · 1 pointr/apolloapp

Mythical Man Month by Frederick Brooks - No Silver Bullet chapter. The number of people on a project results in an exponential increase in communication as errors and misconceptions result from from differing and inconsistent implementations. Christian has only to solve the problem once in his own mind and then apply it. On a team it must be communicated, and receivers all have filters and lenses. Concepts can also be understood but inconsistently implemented because of preference, experience, etc. Almost all great software is conceived and implemented by very small teams ... like three or less.

The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition) https://www.amazon.com/dp/0201835959/ref=cm_sw_r_cp_api_i_uMkDDbHNXBBEP

u/xiongchiamiov · 1 pointr/cscareerquestions

Fairly frequently while I was in college; I shopped up to about a shelf's worth then.

I find that I go to books far less frequently now. Part of it is that I'm much more invested in the current technologies I'm using. Another part is that many books are of the "learn X language!" type, and I know enough general programming that those aren't as useful.

The things I still buy are things like The Mythical Man-Month, Scalable Internet Architectures, and Design for Hackers - that is, less reference and more for reading to get ideas from.

u/sfled · 1 pointr/ProgrammerHumor

Required reading: The Mythical Man-Month

u/kerrz · 1 pointr/sysadmin

The book The Mythical Man-Month is about managing tech projects.

When I started Software Engineering, it was required reading.

Now that I'm doing a grad IT/Business program, it gets mentioned again and again.

It comes from a Software side, but it's really more about managing people, and all the things that can go wrong.

u/Elynole · 1 pointr/nfl

I'll throw out some of my favorite books from my book shelf when it comes to Computer Science, User Experience, and Mathematics - all will be essential as you begin your journey into app development:

Universal Principles of Design

Dieter Rams: As Little Design as Possible

Rework by 37signals

Clean Code

The Art of Programming

The Mythical Man-Month

The Pragmatic Programmer

Design Patterns - "Gang of Four"

Programming Language Pragmatics

Compilers - "The Dragon Book"

The Language of Mathematics

A Mathematician's Lament

The Joy of x

Mathematics: Its Content, Methods, and Meaning

Introduction to Algorithms (MIT)

If time isn't a factor, and you're not needing to steamroll into this to make money, then I'd highly encourage you to start by using a lower-level programming language like C first - or, start from the database side of things and begin learning SQL and playing around with database development.

I feel like truly understanding data structures from the lowest level is one of the most important things you can do as a budding developer.


u/tuirn · 1 pointr/AskReddit

All non-fiction:

u/Contrite17 · 1 pointr/learnprogramming

I'd take a look at The Mythical Man-Month if I were you. First thing that sort of matches your description.

u/severalpuddingslater · 1 pointr/JRPG

First of all, as I said this is a management problem and also most certainly includes the dev teams, not matter what iteration for not communicating anyone else's previous failures properly. Replacing a team is a management decision, meaning that management does not necessarily have to be part of the dev team. Putting FFXV aside, even if the developer and publisher are not the same company, it is a failure by both to let projects like this proceed. It almost never works and even when it does, it is even more rare you achieve financial success or design expectations.

Secondly, as someone who has taken over for failed development projects before, usually one of the first things you do is not scale up or try to make something better, but try to scale back and learn from mistakes. Now creating new projects out of old projects might qualify as this, but getting more ambitious does not seem like a reasonable course of action when you are hemorrhaging money. Just because "you" were not there and it is "someone else's" fault is not an excuse in this world, believe me. It is almost par for the course in real software development.

Finally, I don't think fan expectations are the cause here at all. SquareEnix has made all kinds of games with various scopes. The problem here is ego and the branding as Final Fantasy as "the" flagship title. While we can argue that it might be true whether or not fans have high expectations, you don't run a business like that, especially in game development. The first and foremost concern is to make a profit from the game and the longer you spend on trying to revive sunk costs, the more you will fail. Read "The Mythical Man Month" for example to learn more about bad project management.

Having worked with several Japanese companies in the past, the management style and how dev teams are run is often at fault. You can give the dev team a pass here for that if you want, but the time has come for any company, Japanese or otherwise to quit doing stupid things like that. This is what sinks companies, SquareEnix just has an advantage being where they are as a whole.

u/Shadowys · 1 pointr/singapore
u/reten · 0 pointsr/compsci

Good list!

Does it make sense to add a 'methodology' category for the SDLC. I think it's important that software engineers understand good PM/Agile principles.

Not sure the best book but books I like the 'Agile Manifesto', or Alistar Cockburn 'Crystal Clear' (http://www.amazon.com/exec/obidos/tg/detail/-/0201699478/ref=ase_alistaircockburn/102-9370806-2432911?v=glance&s=books)

or a Microsoft SCRUM book.

http://www.amazon.com/Agile-Project-Management-Microsoft-Professional/dp/073561993X

and the Mythical Man Month:

http://www.amazon.com/Mythical-Man-Month-Software-Engineering-Anniversary/dp/0201835959


To me books like these and the feedback loops it teaches will help deliver software that somebody 'wants'..