41–50 of 119 posts
I bought my boss two copies of The Mythical Man-Month so he could read it twice as fast.
- 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
I bought my boss two copies of The Mythical Man-Month so he could read it twice as fast.
If they want to get started with ML, I recommend Hands On Machine Learning with Scikit Learn and Tensorflow.
I'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…
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…
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'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…
E.g. explaining an interesting or significant software problem and it's surrounding environment from each decade for the last 7 or so decades.
I bought my boss two copies of The Mythical Man-Month so he could read it twice as fast.
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…
In writing a proof, you provide an argument that justifies some claim is true. Your argument has to be airtight, so that no matter what kind of counter example or ugly scenario is proposed, your argument still holds.
The same seems true for an airplane. It needs to do its job (fly) and do so on the face of a myriad of different external factors. If you build a plane, it should "never" fail.
Software on the other hand, can be built without thinking about ALL of these edge cases. Obvious it's better if it always works, but it's usually okay if there is some bizarre scenario that causes an error. For some pieces of software it might even be okay if these errors never get fixed (ie: a very small number of users ever experience them). Software can work, even when it (kinda) doesn't.
The Curry-Howard correspondence might be technically true, but we're just as bad at writing specifications for programs as we are at writing the programs themselves. It could be good to acknowledge that and just write the software that solves most, but maybe not all, of our problems.