Live data from Hacker News

Habits of Expert Software Designers

thereader.mitpress.mit.edu

41–50 of 148 posts

Re: Habits of Expert Software Designers

#41
Certainly a book on this topic should be far more interesting than this article makes it look, so rather than dismiss the book out of hand I took a look around.

After looking briefly at the companion site for the book [0] (not much there), then the publisher's page on the book [1] (ditto) I took a look at the table of contents on Amazon [2]. Definitely there are some very interesting items there that I wish they'd used for this article, like:

* Experts sketch: [They] externalize their thoughts

* Experts work with uncertainty: [They] keep options open

* Experts test: [They] are alert to evidence that challenges their theory

Unfortunately, there are no samples of those chapters. Looks like it could be an interesting read, though.

[0] https://mitpress.mit.edu/books/software-design-decoded

[1] https://softwaredesigndecoded.wordpress.com/

[2] Click "Look Inside" https://www.amazon.com/Software-Design-Decoded-Experts-Think...

Re: Habits of Expert Software Designers

#42
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?

I don't consider myself that much advanced, but I think Iverson's "Notation as a Tool of Thought"[1], and Wirth's "A Plea for Lean Software"[2] make one rethink many concepts of our daily programming tasks (the 2 articles work at 2 different levels)

But really, anything you grab from any of them is awesome by default.

1. http://www.eecg.toronto.edu/~jzhu/csc326/readings/iverson.pd...

2. https://cr.yp.to/bib/1995/wirth.pdf

Re: Habits of Expert Software Designers

#43
9) The expert barely tolerates when the title 'expert' is used by everybody else to merely justify their lack of knowledge in a given area.

"I don't know nothing about databases, but X/Y can solve it because he/she is the software expert".

"I heard you are the expert in firmware, can you fix the coffee machine?"

More or less like the fact one cannot play like Mozart just because Mozart was a 'genius' (putting aside all the effort he put into it since childhood), the same applies to the 'expert'.

Edit: "The expert" https://www.youtube.com/watch?v=BKorP55Aqvg

Re: Habits of Expert Software Designers

#44
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…

It does say they have a book coming out. I think this is a teaser, with the book having more detail on each technique.

Re: Habits of Expert Software Designers

#46
I am trying to learn more about distributed systems architecture. Currently almost finished reading "Designing Data Intensive Application". Is there any recommendation from HN what book should I read next? I am thinking - Building Microservices - Desining Distributed systems

Any thoughts?

Re: Habits of Expert Software Designers

#47

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

Learning abstractions is really hard, mainly because over or under abstracting doesn't break the code, it just wastes work, and if you keep on erring the same way you won't have a reference for how much work something should have taken.

Re: Habits of Expert Software Designers

#48
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

I think the premise is that if you did not looked at users before and now you know that you should be, it's a huge difference and you will start thinking about questions like you asked and will figure out the answers over time.

I think sometimes the hard part is not knowing what you don't know, because those might be very hard to discover.

Re: Habits of Expert Software Designers

#49

I am trying to learn more about distributed systems architecture. Currently almost finished reading "Designing Data Intensive Application". Is there any recommendation from HN what book should I read next? I am thinking - Building Microservices - Desining Distributed systems Any thoughts?

Hey, I'm currently writing a book for PragProg that's going to announced soon. It's tentaively titled "Building Distributed Services with Go", and the Go part is secondary if it's not your language of choice. It guides you through building a distributed service from beginning to end. I don't have anything to point you to at the moment other than my mailing list and I'll let you know when the book is in beta: https://travisjeffery.us4.list-manage.com/subscribe?u=1e3ff7.... Thanks.
Post reply on HN