11–20 of 148 posts
An "illustrated guide" shouldn't mean shallow content without any practical advice decorated with semi relevant stock photos.
Earlier quoted context omitted.
I've always suspected The MIT Press Reader had a secret agenda. The first hint was at the footer of the page: Illuminating the bold ideas and voices that make up the MIT Press's expansive catalog.
the point is why does it get posted and upvoted if it's so obvious
An "illustrated guide" shouldn't mean shallow content without any practical advice decorated with semi relevant stock photos.
Earlier quoted context omitted.
the point is why does it get posted and upvoted if it's so obvious
It’s only obvious when the article gets read, and in my experience many people who vote don’t bother to read
>The first hint was at the footer of the page: Illuminating the bold ideas and voices that make up the MIT Press's expansive catalog.
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 differently.
"Always learn about the users" for example is much too vague: which users? how do you talk to them? when do you trust them and when do you not take their feedback at face value? I don't think you can learn this sort of thing outside of a real life context.
Experts design elegant abstractions and leave us to understand their brilliance after they've left. I'd say elegant abstractions are discovered. Those that are designed tend to have leaky corners. Some manage to rediscover something, implement it poorly, and give it a new name to confuse programmers for the next couple of decades that follow. Experts simulate continually and fool themselves into believing they've tho…
The difference I think the author was trying to hit is that an expert uses abstraction to achieve separation of concerns, an important and difficult thing to do.
A junior doesn't know what separation of concerns is but they see the experts abstracting stuff and think they should abstract things then they will be like the experts.
they might be considered skills.
The only two skills on there that are useful are involving users, and looking around.
Elegant abstractions? Meh, so long as its simple and works.
What they are not designing? Pfft. if you can't create a clear spec, then you shouldn't really be designing
"as you are such an expert, what is missing?"
1) Communication. If you can't communicate, then you aren't helping
2) Documentation. If its not documented, then its not designed
3) consistency. Just because there are new and shiny thing, doesn't mean you should slam them in.
4) pragmatism. All choices have tradeoffs. Limit the innovation to get things done in time.
There are more, but this is all I can think of right now.
I mean, what is this. Not even a point on how Expert Software Designers get bored and browse hacker news for 5 hours?
Terrible.
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 only by harsh experience that we learn which principles take priority over which other principles; as mere words they all sound equally persuasive.
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…