61–70 of 148 posts
Part 2 is online: https://ocw.mit.edu/resources/res-6-004-principles-of-comput...
Seriously, aren't we over this "winners do this" bullshit yet?
Experts read Hacker News.
How on earth is content this shallow drifting to the top of HN? Is any "non expert" software designer walking away from this enlightened in some way?
This article is adapted from the book “Software Design Decoded: 66 Ways Experts Think“ I imagine the idea is that if you want to go further, you buy the book.
Most of these points (like the crucial importance of context/looking around, of users, of figuring out what you're not doing, etc) are important parts of software development. But the problem is, unless you already have the requisite experience to show you what these bullet points really refer to in practice, you're not going to really make sense of this list, not in a way that will actually help you do anything diff…
In Feynman's words, "If you can’t explain something in simple terms, you don’t understand it"
Most of these points (like the crucial importance of context/looking around, of users, of figuring out what you're not doing, etc) are important parts of software development. But the problem is, unless you already have the requisite experience to show you what these bullet points really refer to in practice, you're not going to really make sense of this list, not in a way that will actually help you do anything diff…
It is always hard to learn from people several levels ahead of you. What they do is amazing and impenetrable. What they say seems to make little sense. You lack too much of the common background. This is why, when I find myself in a situation like that, I try hard to understand the point. Why do these people do these strange things? What do they mean by saying these sentences that seem detached from the practice? Emp…
Most of these points (like the crucial importance of context/looking around, of users, of figuring out what you're not doing, etc) are important parts of software development. But the problem is, unless you already have the requisite experience to show you what these bullet points really refer to in practice, you're not going to really make sense of this list, not in a way that will actually help you do anything diff…
I think this illustrates why it's relatively rare to find someone who has a high degree of technical aptitude but also a great communicator. In Feynman's words, "If you can’t explain something in simple terms, you don’t understand it"
Earlier quoted context omitted.
There is an easy test for wrong abstractions. A right abstraction makes everything smaller. Most wrong abstractions make everything bigger (in the name if "flexibility", etc).
Are you listening, Java people?!
Java forces programmers to choose a point on the spectrum of "more flexibility" "smaller program size". In languages like Lisp, by contrast, the more generic a function is, the smaller it is. When I choose to make a function less flexible (i.e., making it more specific to improve performance), it gets longer. The spectrum in Lisp is "more flexibility + smaller program size" "more performance + larger program size", and that's almost always an easy choice to make. Every function and macro in core.clj, for example, is impressively concise.
When I write Java, I tend to go for simple first, and then have to rewrite everything 20 times as I discover what axes of flexibility I need. In Lisp, I tend to write a function once in the simplest possible way, and then re-use it in its original form forever. It's already at max-simplicity and max-conciseness by default. Except in the rare case where it ends up being a bottleneck, it's done.
What I want above all is "more maintainable". In Java, the two factors that drive this are on opposite ends of the spectrum. There's no ideal design, and whatever point I pick today will turn out to be the wrong choice later.