Live data from Hacker News

Habits of Expert Software Designers

thereader.mitpress.mit.edu

31–40 of 148 posts

Re: Habits of Expert Software Designers

#31

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…

Yea the expert abstraction thing is bad advice, too many juniors (who probably already over abstract everything) will read this and think they need more abstraction. 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 st…

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).

Re: Habits of Expert Software Designers

#32
post #2

This is basically just marketing for a book

This is basically CS lifestyle marketing. There's zero useful, actionable content. There's no evidence the authors have any big-project experience of their own, and the bibliography doesn't help make a case for their expertise. https://softwaredesigndecoded.wordpress.com/annotated-biblio... In fact it seems to be academic back-seat driving by a pair of authors who don't understand the difference between reading about…

> There's zero useful, actionable content.

I agree. With no motivating examples these are just platitudes. Or rather, I suppose if I want the motivating examples and cases, I need to buy the book.

Re: Habits of Expert Software Designers

#34
post #31

Earlier quoted context omitted.

Yea the expert abstraction thing is bad advice, too many juniors (who probably already over abstract everything) will read this and think they need more abstraction. 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 st…

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?!

Re: Habits of Expert Software Designers

#35

Earlier quoted context omitted.

Yea the expert abstraction thing is bad advice, too many juniors (who probably already over abstract everything) will read this and think they need more abstraction. 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 st…

> ...too many juniors will read this and think they need more abstraction. Yes. And that's a good thing. The way you become "an expert" is by making ALL the mistakes yourself, seeing the results, and doing it over and over again in different contexts until you understand and can do it right (most of the time).

Mistakes are always a part of the process and are one way to learn.

However I don't think we would have had Ramanujan if he were left to rediscover all of mathematics on his own. Having an expert validate your insights or point you in the right direction can speed up the learning process a lot.

Re: Habits of Expert Software Designers

#37
post #15

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…

>you're not going to really make sense of this list, not in a way that will actually help you do anything differently.

My thoughts as well. Or, you will think of course, I do these things, when in fact you are ineffective at them.

Re: Habits of Expert Software Designers

#38

Earlier quoted context omitted.

Yea the expert abstraction thing is bad advice, too many juniors (who probably already over abstract everything) will read this and think they need more abstraction. 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 st…

> ...too many juniors will read this and think they need more abstraction. Yes. And that's a good thing. The way you become "an expert" is by making ALL the mistakes yourself, seeing the results, and doing it over and over again in different contexts until you understand and can do it right (most of the time).

A good thing is making those mistakes but never landing most of them into production. It will boost your progress immensely if you have somebody available to critique and guide you in the right direction. Making mistakes but learning only a month later when significant amount of time has been wasted in wrong things won't make you any smarter than figuring them out before-hand. Also you'll be a lot less confident afterwards doing anything by yourself after such a disaster.

So no, don't make "ALL the mistakes". Learn by observing others around you, emulating it and then finally at some point understanding it clearly enough to make something completely novel.

Re: Habits of Expert Software Designers

#39
post #30

Expert Software Designers read. And do it continuously. Not only HN and medium, but big "essence" ideas that you do not get usually on day to day tasks, and mold the perception of problems and solutions. People familiar with Wirth, Kay, McCarthy, Iverson, Moore's (and pals) works have a fundamentally broader vision of problems and their solutions. It's obvious, but all those points are not learnt in a discrete manner…

What readings would you recommend for an advanced reader?
Post reply on HN