“ Note: This book does seem to overgeneralize and oversimplify complex situations, but there are still good points.” describes everything by Malcolm Gladwell.
Books I recommend to my software engineering students
101–110 of 119 posts
Re: Books I recommend to my software engineering students
#102Earlier quoted context omitted.
> The 10x cost incurred when moving from stage to stage in waterfall This seems to be a common falsehood propagated by Agile consultants and swallowed whole by an industry that doesn't know any better. It doesn't look like the waterfall model was ever used on a significant scale; not as far as I remember, anyway. https://softwareengineering.stackexchange.com/a/139107
> It doesn't look like the waterfall model was ever used Well - yes, it was used, and still is: it's the default if you're not careful or if you don't think very hard or realistically, or are very naive. The confusion is that is was only given a name to disparage it: W. Winston Royce observed that the way most people managed software projects was completely unrealistic and didn't take into account changing requiremen…
Royce didn't set it up to disparage it. He set up his idealized flow and then proceeded to add details that he believed were critical to making it work. In the end, what he proposes is what most people understand to be Waterfall but with some extra details:
- Feedback loops (because problems or deficiencies will arise)
- Involving the customer (because you don't want to spend 12-60 months building the wrong thing)
- Build a prototype (good advice)
- Document, document, document (he thinks 1500 pages is a good target)
The only thing practitioners seem to have taken away is that last bullet. He still made a strong distinction in his model between analysis, design, and implementation. Though, to be fair, at the time "programmer" was more of a technician level and design often involved making detailed designs like flowcharts and such that could be more easily translated into code. These days, design and implementation are really tangled up, and the documentation is awful an non-actionable (I've been on those teams, it's nightmare inducing). People think prose can replace a diagram, so they fill out their 1500 page quota with lots of words but no clarity.
The name came later, and was enshrined in a DOD standard by people who couldn't read past the first few pages. So they entirely missed the lessons learned he was trying to apply to it.
Re: Books I recommend to my software engineering students
#103Earlier quoted context omitted.
Design Patterns gave us the vocabulary and opportunity to argue about design for a previously ignored level of abstraction. Source: started design patterns study group, still active today.
https://news.ycombinator.com/item?id=22964468
The value of Design Patterns is the shared vocabulary. Abuse of words, grammar drives me nuts too.
But older me now understands every generation goes thru a phase where they think they newly discovered sex.
When I asked my then teenaged son the difference between "emo" and "goth", he informed me that "goth" is for old people.
Re: Books I recommend to my software engineering students
#104Earlier quoted context omitted.
https://news.ycombinator.com/item?id=22964468
The value of Design Patterns is the shared vocabulary. Abuse of words, grammar drives me nuts too. But older me now understands every generation goes thru a phase where they think they newly discovered sex. When I asked my then teenaged son the difference between "emo" and "goth", he informed me that "goth" is for old people.
>The value of Design Patterns is the shared vocabulary.
English is shared vocabulary. What is the point of "design patterns" when you can already define a word for a pattern in english.
My argument is design patterns is 100% the abuse of words.
Re: Books I recommend to my software engineering students
#105Earlier quoted context omitted.
The value of Design Patterns is the shared vocabulary. Abuse of words, grammar drives me nuts too. But older me now understands every generation goes thru a phase where they think they newly discovered sex. When I asked my then teenaged son the difference between "emo" and "goth", he informed me that "goth" is for old people.
>The value of Design Patterns is the shared vocabulary. English is shared vocabulary. What is the point of "design patterns" when you can already define a word for a pattern in english. My argument is design patterns is 100% the abuse of words.
Would you rather argue the precise meaning of words or discuss the nugget of an idea that someone needs your help articulating?
Re: Books I recommend to my software engineering students
#106Blech. Nothing here that's obscure or likely to alter the path of some one's knowledge. No philosophy, no history, and the list includes Gladwell. Actually, the inclusion of Gladwell probably distinctly colors my thinking on the subject. Maybe "How to read a book" or "The Alchemist" or I don't know, something that's not just so totally typical.
I personally don't like philosophy books. I think there's more to be learned about philosophy by reading about specific topics, rather than actually reading about philosophy. Some exceptions like Plato, etc. Absolutely agree with history being useful, though. Any particular periods of history you think are essential to know about, and any particular great books on them?
I'm not the OP, but I agree that history's an essential subject.
History has many themes. These appear in every time and place, sometimes in the forefront, sometimes in the background. I believe the most "essential" period is the one that answers your questions.
So, I'd recommend picking any period that you have a vague curiosity for. I'd go a half step further and recommend avoiding recent periods (late 20th Century).
IMO, it's too recent for there to be consensus on what constitutes good scholarship. There are obviously exceptions to this, but if you're new to history reading, it's difficult to disambiguate the good from the bad.
Examples of periods and geographies that are particularly well-studied, with good accessible literature:
- Late antiquity in the mediterranean (fall of the roman empire)
- Inter-war period in continental europe (Weimar, etc)
- Revolutionary period in France, United States
- Antebellum period in the United States
- Early Russian Revolution (there aren't many good syntheses imo, because this period was incredibly complicated)
- Europe during the reign of Louis XIV (1643-1715)
- Napoleonic wars and aftermath
This list is pretty euro-centric. IMO, these are the safest place to start, as the plurality of english-language scholarship is in these places and periods. After developing a good nose here, you'll feel comfortable reading in areas where the scholarship isn't as deep.
Re: Books I recommend to my software engineering students
#107Earlier quoted context omitted.
>The value of Design Patterns is the shared vocabulary. English is shared vocabulary. What is the point of "design patterns" when you can already define a word for a pattern in english. My argument is design patterns is 100% the abuse of words.
Would you rather argue the precise meaning of words or discuss the nugget of an idea that someone needs your help articulating?
Examine the two actions below:
Given a concept, I name that concept "Gloop" and make it part of a defined word in the "English Language."
Given a concept, I name that concept "Gloop pattern" and make it part of a defined word in "Design patterns."
Independent of the definitions or assuming both mean the same thing, the two actions are one in the same. There is no benefit of using one technique over the other.
Let's give you another angle: Defining a term under the umbrella of "Design patterns" doesn't make that definition any more precise than if you defined that term under the umbrella of the english language. There is no difference period.
Design patterns is shared vocabulary. English is also shared vocabulary. But the words "Design Patterns" is part of the "English Language." By creating the term "Design patterns" in the "English Language" you are essentially recursively adding complexity to the english language by defining a redundant concept in the same concept.
Just use english. Define the pattern in english, there is no need to define the pattern in "Design patterns."
Additionally, many patterns are better described with existing english words. Why use Facade pattern, when you can just say Object wrapper. The word "Design patterns" inserts a sort of false formalism and elitism into what is essentially just creating new vocabulary in the english language. The claim I'm making in this paragraph is that while yes it's good to have some formal nomenclature, it's excessive to give all of these patterns their own names. Let the naming and the definitions flow naturally.
Other fields of programming have patterns but they don't try to turn these patterns into some kind of theoretical field with it's own nomenclature. Currying is just currying nobody calls it the "Curry pattern". Recursion is just recursion, nobody calls it the "Recursion pattern."
Re: Books I recommend to my software engineering students
#108Earlier quoted context omitted.
Would you rather argue the precise meaning of words or discuss the nugget of an idea that someone needs your help articulating?
Examine the two actions below: Given a concept, I name that concept "Gloop" and make it part of a defined word in the "English Language." Given a concept, I name that concept "Gloop pattern" and make it part of a defined word in "Design patterns." Both actions have the potential to fulfill either goal you describe above depending on the definition(s) of gloop and "gloop pattern." Independent of the definitions or ass…
I think you would have loved our study group. Especially the early years.
My personal position on the value of the art of namings, eg Facade, Proxy, Wrapper, Adapter, was somehow capturing the author's original intent. As distinct from the implementation. How it's meant to be used.
Lofty sentiment coming from someone condemned to decades of code maintenance.
Professionally, methinks design patterns, and their misuse, has been mostly detrimental. Maybe because the notions were taken too literally, treated prescriptively rather than descriptively.
Calling everything a Decorator. When it's actually a Chain of Command. And when you try to patiently explain the evils of silent failures, buried deep in the levels of indirection, to the "senior architect" author, that same architect insults your intelligence and walks off.
The mere utterance of Factory and Singleton in public somehow empowering legions of noobs littering entire organizations (and libraries) with innumerable implementations.
Trying to debug something called a "Write thru Cache" when its anything but.
Etc.
Re: Books I recommend to my software engineering students
#109I've advocated for a "canon" of books for software engineering and computer science that could be taught in school. The canon would accomplish several goals: it'd inform students about the less technical but profoundly important ideas within CS (Brooks' No Silver Bullet, The 10x cost incurred when moving from stage to stage in waterfall, how to treat and manage failure, etc.), it'd teach students how to think about p…
I disagree. I think books on software management and process are mostly lost on someone who hasn't been involved in the process. (Hell many of those books are lost on project managers) I think the most important subjects to teach students are javascript, css, & sql (or mongo). Before you teach a beginner wood worker the "Zen of wood" you teach them how to cut a piece of wood without sawing off a finger. The rest will…
Interesting counterpoint. I kind of agree that these books will be lost on people (although I believe I got something out of them and I'm early into my career). But I'm also thinking of it as providing early exposure so that if the students need guidance later on, they know where to visit. Much as high school students find the classics boring, but upon revisiting them later in life, discover their brilliance.
I agree that you should teach the practice. My ideal education would be co-ops combined with a reading course or two on the canon.
Re: Books I recommend to my software engineering students
#110Earlier quoted context omitted.
I disagree. I think books on software management and process are mostly lost on someone who hasn't been involved in the process. (Hell many of those books are lost on project managers) I think the most important subjects to teach students are javascript, css, & sql (or mongo). Before you teach a beginner wood worker the "Zen of wood" you teach them how to cut a piece of wood without sawing off a finger. The rest will…
Any books to recommend for the topics you mentioned? Especially sql or mongo.
I really liked 'The Art of SQL', Stephane Faroult