Live data from Hacker News

Books I recommend to my software engineering students

web.eecs.utk.edu

51–60 of 119 posts

Re: Books I recommend to my software engineering students

#51
post #42

I would also recommend two more good books. They are relevant to almost every aspect of life and creation process: - Antifragile: Things That Gain from Disorder by Nassim Nicholas Taleb[1] - Skunk Works: A Personal Memoir of My Years at Lockheed by Ben R. Rich[2] [1] https://www.goodreads.com/book/show/13530973-antifragile [2] https://www.goodreads.com/book/show/101438.Skunk_Works

Can I dive straight into Antifragile without having read the author's previous books?

Re: Books I recommend to my software engineering students

#54

Earlier quoted context omitted.

Design Patterns by Gamma, Helm, Johnson, and Vlissides (aka GoF)

I still don't understand why people worship this book. Contrary opinion here but I think this book is actually below average. I think it's good that it introduces the overall concept of Design patterns, but the book itself isn't really about the general concept of Design patterns. The book is focused on OOP techniques and tricks. It makes the assumption that OOP is the most general way to modularize things and think…

Yeah, I hated that book. I didn't really understand it. Then I read "Head First Design Patterns" and it clicked. I went back to the Gamma book and now it makes sense, but not as a first book on Design Patterns.

Re: Books I recommend to my software engineering students

#55
post #47

Earlier quoted context omitted.

I still don't understand why people worship this book. Contrary opinion here but I think this book is actually below average. I think it's good that it introduces the overall concept of Design patterns, but the book itself isn't really about the general concept of Design patterns. The book is focused on OOP techniques and tricks. It makes the assumption that OOP is the most general way to modularize things and think…

The book didn't introduce people to design patterns, it invented the concept within the discipline of software programming. Perhaps one needs to have been in industry before and after this book to appreciate how it introduced a common vocabulary, a mechanism for documenting and sharing experience, and a framework for thinking about common problems.

>The book didn't introduce people to design patterns, it invented the concept within the discipline of software programming.

By introduced I mean, introduced to the world for the first time. Invented is debatable concept as in was math invented or discovered? I avoid that debate by using the word "introduced."

>Perhaps one needs to have been in industry before and after this book to appreciate how it introduced a common vocabulary, a mechanism for documenting and sharing experience, and a framework for thinking about common problems.

Humans invent vocabulary for everything that they do, giving patterns names is inevitable. I would hardly call it revolutionary. This book just gave the concept of naming patterns a meta name in itself: "Design patterns." I think it's good that this was given a name but its importance is largely exaggerated.

Case in point: Other disciplines of programming don't use the term "Design patterns" or formal pattern names that frequently. In fact, technically, there are tons and tons of "Design patterns" in procedural programming, declarative programming and functional programming, yet experts in these respective fields don't feel the need to give these concepts over-inflated and complicated nomenclature.

Take currying for example. Functional programmers don't call it the "Curry pattern" nor do they refer to it as a design pattern (even though it technically is). A name just arose naturally. No need to give the concept of naming concepts another word.

To take the illustration even further, imagine driving techniques. Should I give the concept of naming driving techniques some name to exaggerate its importance? Perhaps I can, I'll call it: "Vehicular Translation patterns." And instead of talking about cars using regular English like a normal person I'll just communicate like this: "Execute the drift pattern in composition with the slide pattern and inverse throttle pattern to maneuver through that turn." Talking like this helps me sound smarter while obfuscating communication to the point where it can only be understood by a select few. The book design patterns introduced to the programming world what could potentially be done for driving as well. Needless to say, if it's pointless to do this for driving then does that mean it's pointless to do for programming? In my opinion the answer to that question is, "Yes."

In short, use english for most concepts and name things only where it matters and as it comes naturally. No need to invent an entire discipline and inflate it with made up epistemology.

I realize race car driving does have it's own nomenclature but it's not over used to the extent of design patterns nor did they feel the need to give the nomenclature it's own nomenclature (vehicle translation patterns, VTS theory for short)

Re: Books I recommend to my software engineering students

#56
post #47

Earlier quoted context omitted.

I still don't understand why people worship this book. Contrary opinion here but I think this book is actually below average. I think it's good that it introduces the overall concept of Design patterns, but the book itself isn't really about the general concept of Design patterns. The book is focused on OOP techniques and tricks. It makes the assumption that OOP is the most general way to modularize things and think…

The book didn't introduce people to design patterns, it invented the concept within the discipline of software programming. Perhaps one needs to have been in industry before and after this book to appreciate how it introduced a common vocabulary, a mechanism for documenting and sharing experience, and a framework for thinking about common problems.

I agree with the first reply that the book is overrated. While it's not irrelevant, I wouldn't think it fits into a "must read" list for people learning software engineering. I often hear, "Head First Design Patterns" as a better reference if you're interested in design patterns. I own the GoF book, but have thumbed through Head First and am inclined to agree.

What I think is missing is the idea that design patters are often language smell. They're common patterns to compensate for deficiencies in the language. The GoF is most applicable to C++ code that uses a lot of OOP. Like the previous reply said, reaching for these patterns too quickly complicates things. Like using unnecessarily large words when simpler language would suffice.

Re: Books I recommend to my software engineering students

#59

Earlier quoted context omitted.

From what I recall, it talks about 3 somewhat related things. First is that adding people slows things down in the short term. The second is that due to overhead, adding people won't give linear speed up in completion time. And third, adding people won't help a project that is linear in nature. The common example is using 9 women to get a baby in 1 month.

That's a good summary. My years suggest that he wasn't nearly pessimistic enough.

You mean if you add 9 women you get a baby in 81 months?

Re: Books I recommend to my software engineering students

#60
post #31

I don't think you can teach software engineering. Writing software is more like writing proofs than building airplanes. Take a formally verifiable language like Agda for example. Proofs are indistinguishable from programs in that language. The Curry-Howard correspondence shows this is true for program-proofs in general. Large software systems fail continuously in countless ways all the time. Google search will still…

[deleted]
Post reply on HN