21–30 of 116 posts
His book is awesome! One takeaway I had: code reviews matter. If your code is undergoing review and a reviewer tells you that something is not obvious, don’t argue with them; if a reader thinks it’s not obvious, then it’s not obvious.
His book is awesome! One takeaway I had: code reviews matter. If your code is undergoing review and a reviewer tells you that something is not obvious, don’t argue with them; if a reader thinks it’s not obvious, then it’s not obvious.
I think there is value in doing a review (specially with junior team members) on their 'design intent' early on, as soon as a prototype/skeleton is up. Proposing a change then is met with a lot less friction.
Earlier quoted context omitted.
Do the business requirements (fundamental assumptions around design to be more generic) of a bridge, car or airliner change dramatically over time? I'd argue not. Software design, in my opinion, is both a science and an art so my stance is that we need both the formal theory and science as well as the philosophy and that they shouldn't be viewed as mutually exclusive.
Mathematics and science can both be viewed as very fleshed out and practical branches philosophy, so they certainly aren't mutually exclusive.
I'm basically talking about "philosophy" the way the book uses the word. Which in short is just the authors opinionated take on software masquerading as something a bit more "official" then just an opinion. I mean would you call your own opinions on software design a "philosophy"?
Earlier quoted context omitted.
Mathematics and science can both be viewed as very fleshed out and practical branches philosophy, so they certainly aren't mutually exclusive.
Everything on the face of the earth falls under philosophy. It's the biggest non-category ever. I'm basically talking about "philosophy" the way the book uses the word. Which in short is just the authors opinionated take on software masquerading as something a bit more "official" then just an opinion. I mean would you call your own opinions on software design a "philosophy"?
Earlier quoted context omitted.
>Software design, in my opinion, is both a science and an art so my stance is that we need both the formal theory and science as well as the philosophy and that they shouldn't be viewed as mutually exclusive. What formal theory have you ever used for designing your software? I would argue you've never used anything. Every abstraction you've ever made was likely a gut feeling, an instinct or following some vague hand…
Just because it doesn't use formal theory now --- does not mean it/we shouldn't use it. I'm talking about needs, not haves.
Things like user-friendliness can be "philosophical". You can separately and selectively apply theory and design where applicable, but they cannot in actuality be unionized in some unholy grafting.
I would say for the topic at hand; Of how to organize and abstract your code, if we ever find a complete formal theory for that, much of design will go out the window and what's left is mostly a calculation.
Earlier quoted context omitted.
Everything on the face of the earth falls under philosophy. It's the biggest non-category ever. I'm basically talking about "philosophy" the way the book uses the word. Which in short is just the authors opinionated take on software masquerading as something a bit more "official" then just an opinion. I mean would you call your own opinions on software design a "philosophy"?
Yes probably. The only real difference between an opinion and a philosophy are the number of people that believe it.
Is this good going to be readable on Kindle? It might be just me, but some software engineering books are hard to read on Kindle due to codes sections could end up with strange format.
No problem on Kindle, the book is mostly text and has only a handful of short code snippets.
Haven't read the book yet but it seems to be about design principles, abstraction, divide and conquer, single responsibility and the like. Man made objects tend to be single-purposed and interact with few other components. Over the years I have come to appreciate the nature more and more. In nature, things are always multi-purposed and exist in a web of relationship. A bat is a pollinator, pest control, fertilizer an…
That’s because your example, a bat, is a high level of abstraction. If you dig into the cellular level things start becoming very single-purpose, even more so down to the atomic level, and so on. The architecture of recursive composition usually done in building large software was found in nature first.
An alternative viewpoint on software: https://www4.di.uminho.pt/~jno/ps/pdbc.pdf Rather then using blurry fuzzy concepts about software. This book is called "Program design by calculation". Which is to view software through the theoretical lens of math, science and engineering rather then "philosophy". Should software design be interpreted using the blurry and hand wavy concepts of philosophy and literature? or shoul…