16 ms·

Habits of Expert Software Designers

711 points by headalgorithm 7y ago

Jedi72 7y ago
This is basically just marketing for a book
- ruvis 7y ago
  It's pretty obvious too.
  - justin66 7y ago
    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.
    - mlevental 7y ago
      the point is why does it get posted and upvoted if it's so obvious
      - rmilejczz 7y ago
        It’s only obvious when the article gets read, and in my experience many people who vote don’t bother to read
        mlevental 7y ago
        No it's obvious even before that because as the person I responded to points out it's right there in the footer: >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.
        rmilejczz 7y ago
        The footer in the article.... if the voter doesn’t read the article I think it’s plainly obvious that they didn’t bother to open the article with the intent of reading it...
- charliepark 7y ago
  That's the point of the entire site, though. "Illuminating the bold ideas and voices that make up the MIT Press's expansive catalog. We publish thought-provoking excerpts, interviews, and original essays written for a general reader but backed by academic rigor."
- avip 7y ago
  Sounds like you didn’t focus on essence. You could restructure the problem space and just read it.
- TheOtherHobbes 7y ago
  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-bibliography/ 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 a domain and living in it, and are now communicating in platitudes. With cutesy pictures. "You know you could try to make your abstractions more elegant? How about focussing on the essence? Or seeing how someone else did it?" Thanks. When our next intern slot turns up, we'll be sure to keep you in mind.
  - JackFr 7y ago
    > 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.
agentultra 7y ago
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 thought of everything. Humans are able to predict the outcomes of complicated systems through heuristics. However we're especially bad at specifying invariants of complicated behaviors when it involves live-ness and safety. Experts know when to model a system and use automation to check their designs. If that is overkill they write property tests. At the very least we write a tonne of unit and integration tests. There's nothing like writing out the math and having the solution pop out at you. Experts think about what they are not designing and they write it down as an invariant of their model. This seems like a blog-vert for a book and while I love learning about how other engineers practice their craft this looks like it's going to be a mixed bag. It might help listing some of the experts involved in this project. Similar to how Coders at Work did.
- dangerface 7y ago
  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 stuff and think they should abstract things then they will be like the experts.
  - crispyambulance 7y ago
    > ...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).
    - 7y ago
coldcode 7y ago
Beside the obvious marketing spin, how do you define an "expert software designer"? I remember a long time ago in the pre internet era someone defined an expert as "anyone 40 miles from home". How am I supposed to evaluate someone's opinion as to whether or not I should even pay attention to their habits?
gwn7 7y ago
An "illustrated guide" shouldn't mean shallow content without any practical advice decorated with semi relevant stock photos.
- gonzo41 7y ago
  There was a good one, where an eager dog was used to represent the user. I'll be sure to refer to my hard headed business users like that and see how far I go. When they use the UI right, I'm going to be there with a treat.
  - gwn7 7y ago
    I will definitely try this method next time I do user testing.
- asdfman123 7y ago
  Yeah, I didn't find it helpful at all. It was basically saying, "Experts do great work!" Thanks, I already knew that.
- gwn7 7y ago
  Actually I'm kind of taking back the "semi relevant stock photos" part. On second look I think the illustrations are fine and relevant. The problem is not with the illustrations and not even with the text which is fine too but the mismatch between the title and the content. A bit clickbait-y.
decasia 7y ago
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 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.
- czr 7y ago
  Agreed. I think this is an instance of: > 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.
- martincmartin 7y ago
  Agreed. Think of them as a list of skills that software engineers have to learn. Junior engineers may not even realize they need to learn them; this post might open their eyes. It may get them talking to users when they might not have otherwise, and through practice, developing those skills.
- nine_k 7y ago
  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? Empirically, they are smart, so they mean something. This is how you start to detect where the common context is lacking, and look for explanations. Eventually, with enough effort, you bridge the gap and understand what they meant, and why. This is how you grow.
  - closetohome 7y ago
deleted 7y ago
[deleted]
KaiserPro 7y ago
None of these are habits. 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.
NotATroll 7y ago
This article has sold me on not buying that book. I mean, what is this. Not even a point on how Expert Software Designers get bored and browse hacker news for 5 hours? Terrible.
tabs_masterrace 7y ago
> Experts focus on the essence I think this is one of the strongest points of a good developer, and what makes them such good problem solvers in many situations. Often you get confronted with problems, from say a client or through user feedback, which don't amount to much more than "wishes" - with no clear and/or conflicting solutions. A good developer is able to distill the problem down to its core, finds out the true nature of the issue, can communicate that back, while also offering solutions.
smartmic 7y ago
While I agree on the content, I think the word "Expert" in the title is misleading. All of these habits are better attributed to Generalists. "Experts" I know are often too focused on certain fields. More power and wisdom comes by connection of experience from different, even orthogonal, domains.
rgrau 7y ago
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 but they work as a whole and grow on you during the journey.
- throw51319 7y ago
  What readings would you recommend for an advanced reader?
  - rgrau 7y ago
    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.pdf http://www.eecg.toronto.edu/~jzhu/csc326/readings/iverson.pd... 2. https://cr.yp.to/bib/1995/wirth.pdf https://cr.yp.to/bib/1995/wirth.pdf
- commandlinefan 7y ago
  > Expert Software Designers read “Read? Books? With pages? And chapters? I don’t pay you to read, I pay you to program! And I’ve seen programming, programming is done with a keyboard, so I’d better hear typing! And I expect you to tell me exactly what you’re going to be doing, hour by hour, for the next two weeks, or ‘sprint’ or whatever you nerds call these things these days, and I’d better see lots of commits to the repository because I’m checking who’s committing the most because I don’t pay you to read and learn, I pay you to know and if you don’t already know there are a thousand foreigners lined up to do your job for ten cents a day so you’d better get in line, programmer!”
  - rgrau 7y ago
yvsong 7y ago
Experts read Hacker News.
- twic 7y ago
  Judging by the comments on this article, that is not the case.
slashblake 7y ago
I'd buy all of these if it started with #1: Experts deliver.
- justbaker 7y ago
  Delivery over elegance of delivery any day.
mseidl 7y ago
.... sort +2n | more less > more
jt2190 7y ago
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 https://mitpress.mit.edu/books/software-design-decoded [1] https://softwaredesigndecoded.wordpress.com/ https://softwaredesigndecoded.wordpress.com/ [2] Click "Look Inside" https://www.amazon.com/Software-Design-Decoded-Experts-Think-ebook/dp/B071CM2M1F/ref=tmm_kin_swatch_0?_encoding=UTF8&qid=&sr= https://www.amazon.com/Software-Design-Decoded-Experts-Think...
scoutt 7y ago
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 https://www.youtube.com/watch?v=BKorP55Aqvg
drummyfish 7y ago
> Experts design elegant abstractions And a lot of times the most elegant abstraction is no abstraction cough oop cough. Unnecessary abstraction is as wrong as a wrong abstraction.
- Roboprog 7y ago
  Yeah, I’m gonna disagree with the “paste, paste, paste “ / “generate mass spam” school of development here. Many feel like you, though. I just don’t want to maintain their effluent.
christiansakai 7y ago
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?
- travisjeffery 7y ago
  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=1e3ff7d7791b26a8f60b9f16c&id=653935be08 https://travisjeffery.us4.list-manage.com/subscribe?u=1e3ff7.... Thanks.
  - christiansakai 7y ago
    Awesome! I will subscribe!
remon 7y ago
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?
- ArnoVW 7y ago
  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.
  - uwuhn 7y ago
    Yes, it's an advertisement.
  - remon 7y ago
    Okay. Not very effective then.
commandlinefan 7y ago
“Eight good recommendations that modern software management practices like Kanban and Scrum work effortlessly to destroy”
TurkishPoptart 7y ago
Epstein.
deleted 7y ago
[deleted]
deleted 7y ago
[deleted]
whydoyoucare 7y ago
Most comments cover what I thought about this article (obtuse and too abstract to be practical), so I won't repeat them. However, I did find "The Principles of Computer System Design: An Introduction" by Saltzer to be the best book combining theory and practice. Part 2 is online: https://ocw.mit.edu/resources/res-6-004-principles-of-computer-system-design-an-introduction-spring-2009/online-textbook/ https://ocw.mit.edu/resources/res-6-004-principles-of-comput...
marcus_holmes 7y ago
Non-experts also do all of these, just badly. Seriously, aren't we over this "winners do this" bullshit yet?
deleted 7y ago
[deleted]
tareqak 7y ago
The picture for "8) Experts think about what they are not designing:" looks like an optical illusion, but I can only see the two people with their arms on either side. What is the other picture? My guess would be some kind of Lovecraftian monster e.g. Cthulhu [0]. [0] https://en.wikipedia.org/wiki/Cthulhu https://en.wikipedia.org/wiki/Cthulhu
- jvanderbot 7y ago
  They are probably using negative space (e.g., what they did not fill in) to show the picture. Sure, this is often used to show two pictures at once, but I don't think that's the case here. I think it's mirrored vertically to further reinforce the trope from preschool of cutting out shapes from folded construction paper.
oh_sigh 7y ago
Why should we listen to these authors? Yes, they have a lot of academic credentials, but is there any evidence they have worked on large systems that have benefited from their designs in practice? To put it another way, I think that I would find a book about writing by Stephen King to be more informative as a budding author than, say, the dean of the English department at Harvard. As with all things, I'm sure there may be value on many of the things they've written, but you may need to already be an expert software designer to realize what advice is useful and what isn't.
unnouinceput 7y ago
1) Experts involve the user That right there is the most important one in the list. Also, as a developer, you can be the user. Try to use your design and start punching data using your designed interface. After entering 100 times you'll catch any bad crap you put there and wish for a faster or smarter way to enter it, trust me. Also, monkey your interface to your wife/kid(s)/non-technical friend(s) and they will point fast whatever they find is boring. No need to deploy in the wild to catch the bad design
- abraae 7y ago
  I started a new company recently and we are a major user of the same back end in our platform that our customers use. I can say that hopefully never again will I work on a system where the users are remote and isolated from Dev. The benefits of dog fooding are enormous. So many small and large UI discoveries that you would never know about if the input trickled in through jira tickets. If you want to build an elegant, user-friendly system, then use it yourself. Constantly. Repetitively. Then scratch your own itch.
jwilliams 7y ago
The subtext here is that experts are never "experts", you are constantly iterating and learning.
austincheney 7y ago
Point 6 could be rephrased to be more clear. Experts are great at providing original solutions, but they may not always see problems worthy of solutions. By looking around at existing attempted solutions they can estimate the gap between stated and actual problems from their proposed solutions and instead minimize that gap with a better solution.
perlgeek 7y ago
What happened to avoid listical titles? > If the title begins with a number or number + gratuitous adjective, we'd appreciate it if you'd crop it. E.g. translate "10 Ways To Do X" to "How To Do X," and "14 Amazing Ys" to "Ys." Exception: when the number is meaningful, e.g. "The 5 Platonic Solids."
- tejisant 7y ago
  Agree
chrisweekly 7y ago
This reminds me of a great little gem of another MIT Press book: "Software Design Decoded - 66 Ways Experts Think". Clever illustrations and useful, concise insights FTW. Edit: haha, next time I should RTFA (which clearly mentions it's taken directly from the book I remembered and pulled off the shelf). But my recommendation remains unchanged! :)
yodsanklai 7y ago
I don't think there is anything practical to be learned from this writing... Anecdotally, I've been working in the software industry for only one year (used to be in academia), but I really feel like the main challenge is collaboration and team organization. That, and tackling huge code bases. Designing abstractions, algorithms, and all that technical stuff really is the easy part.
doanguyen 7y ago
> 2) Experts design elegant abstractions: I really appreciate the thing called "abstraction" not only in Software Designer but also in general, it often takes large amount of time to be an expert in the field before one can create/design an abstraction out of the problems.
danielovichdk 7y ago
What's an expert?
janee 7y ago
Haha I keep reading 'Eating Habits of Expert Software Designers' Thinking ohh that sounds weird, and then seeing it correctly. Feel bad saying it but I'm sort of disappointed now :p
Aeolun 7y ago
Why is it that all these lists that are seemingly aiming to teach me something always a list of ‘common sense’ items. Good designers use good abstractions, it’s good to talk to your users... of course, there is nobody that disagrees with these things, but even the most junior of designers knows that. What the dodo is a software designer by the way. Something from academia?
WalterBright 7y ago
These lists tend to be trite, and this one is no exception. For example, "Experts are not satisfied with just any abstraction, they deliberately seek elegant abstractions through which complex structures can be introduced, understood, and referred to efficiently." Every developer I've ever talked to believed down to their core that this was what they were doing. Yet 99% of software is utter bilge. This includes mine. I look at everything I've written 5 or more years ago, and it's all garbage. Most of the work I do is rewriting it. There's no way around it, it takes a lot of experience to be even able to recognize a good design, let alone write one. No list of 10 rules is going to help much. It's like painting. No "10 Habits of Famous Artists" is going to help you become a great artist.
- erikpukinskis 7y ago
  > > they deliberately seek elegant abstractions through which complex structures can be introduced, understood, and referred to efficiently." > Every developer I've ever talked to believed down to their core that this was what they were doing. Really? I’ve worked with a lot of people who are just trying to make the thing do the thing. Even most of the people who are interested in good abstractions often are under such pressure to perform “I’m just shipping here don’t mind me” that they largely stop thinking about the right abstraction. Maybe I’ve worked at too many troubled startups though lol.
  - hinkley 7y ago
    Not all developers are doing this, no. But pretty much all the ones I’d like to strangle are. It’s elegant! No, your dumpster fire of a Second System Syndrome is not elegant. Fractal designs are not elegant. Also you are in your late 30’s. Why are you just having your second system syndrome now? </oddly specific>
- andrewstuart 7y ago
  >>I look at everything I've written 5 or more years ago, and it's all garbage. From Walter Bright? Sorry I don't buy this. I can accept that you might feel it could be better, but garbage? No.
andrewstuart 7y ago
I'm not going to claim "expert", but I have designed more software than I can even remember. Some of my approach: -- I strive primarily to form a clear and simple mental model of the system that the software will represent. -- Simplicity is everything in software design and should be priority one. Conversely, you must actively avoid complexity, and when part of a system is starting to feel complex, take a step back and rethink the approach. Sometimes systems must include complexity, try to contain this all into a tightly constrained area of the system. -- Loose coupling of system components is next most important - priority two - when designing large interconnected systems - you'll succeed in designing something big if you can instead make a number of smaller systems that know as little as possible(ideally nothing) about the other parts of the system. -- Software is like painting - you can't plan every brush stroke in advance - instead you get the broad brush strokes in place and then paint ever finer levels of detail. -- I strive for consistency, but not slavishly. Try to use the same approaches/technologies everywhere if possible. When not possible, choose the most suitable technology/approach and use that. -- I'm extremely hesitant to allow special cases or exceptions, but I will happily do so when it is clearly necessary. -- I grant myself time to think about possible solutions even when there is pressure (typically from myself) to be actually implementing/coding a solution. -- I do my best to "design out" or get rid of software - the fastest, easiest to write and most reliable code is no code. -- I try to lean heavily on the capabilities of existing systems like database and web servers. If you really understand what existing systems are capable of at a deep level then often you can avoid reinventing the wheel and hook in to what those existing systems do. -- I'm not a fan of complex systems such as containers and kubernetes. I have been able to build all my software architectures without them. -- The project build should primarily aim to put together a working ended to end system that does the absolute minimum to enable the integrated whole to work - i.e. you need to build just enough of each thing to put a pig in one end and get sausages out of the other..... without much attention to anything like user interface or error handling or really much of anything else at all. This is because it is much easier to complete a system that is working, even if only minimally. -- I'm happy to throw away previous decisions and system components if they have proven to be wrong. About 1,000 other things I don't have time to think out right now.
makach 7y ago
okay, personally I thought that piece was a little fluffy and made me think of this quote from the Billy Madison movie: <<At no point in your rambling, incoherent response were you even close to anything that could be considered a rational thought. Everyone in this room is now dumber for having listened to it. I award you no points, and may God have mercy on your soul. Billy Madison : Okay, a simple "wrong" would've done just fine.>>
lozzo 7y ago
I opened the link and I searched for the word "Simplicity" Found 0 of 0. I decided not to read it in order not to hurt my ego. I might not be an expert software designer as my number one item would have been "seek simplicity"

711 points by headalgorithm 7y ago

Jedi72 7y ago

This is basically just marketing for a book

ruvis 7y ago
It's pretty obvious too.
- justin66 7y ago
  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.
  - mlevental 7y ago
    the point is why does it get posted and upvoted if it's so obvious
    - rmilejczz 7y ago
      It’s only obvious when the article gets read, and in my experience many people who vote don’t bother to read
      - mlevental 7y ago
        No it's obvious even before that because as the person I responded to points out it's right there in the footer: >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.
        rmilejczz 7y ago
        The footer in the article.... if the voter doesn’t read the article I think it’s plainly obvious that they didn’t bother to open the article with the intent of reading it...
charliepark 7y ago
That's the point of the entire site, though. "Illuminating the bold ideas and voices that make up the MIT Press's expansive catalog. We publish thought-provoking excerpts, interviews, and original essays written for a general reader but backed by academic rigor."
avip 7y ago
Sounds like you didn’t focus on essence. You could restructure the problem space and just read it.
TheOtherHobbes 7y ago
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-bibliography/ 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 a domain and living in it, and are now communicating in platitudes. With cutesy pictures. "You know you could try to make your abstractions more elegant? How about focussing on the essence? Or seeing how someone else did it?" Thanks. When our next intern slot turns up, we'll be sure to keep you in mind.
- JackFr 7y ago
  > 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.

agentultra 7y ago

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 thought of everything. Humans are able to predict the outcomes of complicated systems through heuristics. However we're especially bad at specifying invariants of complicated behaviors when it involves live-ness and safety. Experts know when to model a system and use automation to check their designs. If that is overkill they write property tests. At the very least we write a tonne of unit and integration tests. There's nothing like writing out the math and having the solution pop out at you. Experts think about what they are not designing and they write it down as an invariant of their model. This seems like a blog-vert for a book and while I love learning about how other engineers practice their craft this looks like it's going to be a mixed bag. It might help listing some of the experts involved in this project. Similar to how Coders at Work did.

dangerface 7y ago
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 stuff and think they should abstract things then they will be like the experts.
- crispyambulance 7y ago
  > ...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).
  - 7y ago

coldcode 7y ago

Beside the obvious marketing spin, how do you define an "expert software designer"? I remember a long time ago in the pre internet era someone defined an expert as "anyone 40 miles from home". How am I supposed to evaluate someone's opinion as to whether or not I should even pay attention to their habits?

gwn7 7y ago

An "illustrated guide" shouldn't mean shallow content without any practical advice decorated with semi relevant stock photos.

gonzo41 7y ago
There was a good one, where an eager dog was used to represent the user. I'll be sure to refer to my hard headed business users like that and see how far I go. When they use the UI right, I'm going to be there with a treat.
- gwn7 7y ago
  I will definitely try this method next time I do user testing.
asdfman123 7y ago
Yeah, I didn't find it helpful at all. It was basically saying, "Experts do great work!" Thanks, I already knew that.
gwn7 7y ago
Actually I'm kind of taking back the "semi relevant stock photos" part. On second look I think the illustrations are fine and relevant. The problem is not with the illustrations and not even with the text which is fine too but the mismatch between the title and the content. A bit clickbait-y.

decasia 7y ago

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

czr 7y ago
Agreed. I think this is an instance of: > 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.
martincmartin 7y ago
Agreed. Think of them as a list of skills that software engineers have to learn. Junior engineers may not even realize they need to learn them; this post might open their eyes. It may get them talking to users when they might not have otherwise, and through practice, developing those skills.
nine_k 7y ago
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? Empirically, they are smart, so they mean something. This is how you start to detect where the common context is lacking, and look for explanations. Eventually, with enough effort, you bridge the gap and understand what they meant, and why. This is how you grow.
- closetohome 7y ago

deleted 7y ago

[deleted]

KaiserPro 7y ago

None of these are habits. 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.

NotATroll 7y ago

This article has sold me on not buying that book. I mean, what is this. Not even a point on how Expert Software Designers get bored and browse hacker news for 5 hours? Terrible.

tabs_masterrace 7y ago

> Experts focus on the essence I think this is one of the strongest points of a good developer, and what makes them such good problem solvers in many situations. Often you get confronted with problems, from say a client or through user feedback, which don't amount to much more than "wishes" - with no clear and/or conflicting solutions. A good developer is able to distill the problem down to its core, finds out the true nature of the issue, can communicate that back, while also offering solutions.

smartmic 7y ago

While I agree on the content, I think the word "Expert" in the title is misleading. All of these habits are better attributed to Generalists. "Experts" I know are often too focused on certain fields. More power and wisdom comes by connection of experience from different, even orthogonal, domains.

rgrau 7y ago

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 but they work as a whole and grow on you during the journey.

throw51319 7y ago
What readings would you recommend for an advanced reader?
- rgrau 7y ago
  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.pdf http://www.eecg.toronto.edu/~jzhu/csc326/readings/iverson.pd... 2. https://cr.yp.to/bib/1995/wirth.pdf https://cr.yp.to/bib/1995/wirth.pdf
commandlinefan 7y ago
> Expert Software Designers read “Read? Books? With pages? And chapters? I don’t pay you to read, I pay you to program! And I’ve seen programming, programming is done with a keyboard, so I’d better hear typing! And I expect you to tell me exactly what you’re going to be doing, hour by hour, for the next two weeks, or ‘sprint’ or whatever you nerds call these things these days, and I’d better see lots of commits to the repository because I’m checking who’s committing the most because I don’t pay you to read and learn, I pay you to know and if you don’t already know there are a thousand foreigners lined up to do your job for ten cents a day so you’d better get in line, programmer!”
- rgrau 7y ago

yvsong 7y ago

Experts read Hacker News.

twic 7y ago
Judging by the comments on this article, that is not the case.

slashblake 7y ago

I'd buy all of these if it started with #1: Experts deliver.

justbaker 7y ago
Delivery over elegance of delivery any day.

mseidl 7y ago

.... sort +2n | more less > more

jt2190 7y ago

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 https://mitpress.mit.edu/books/software-design-decoded [1] https://softwaredesigndecoded.wordpress.com/ https://softwaredesigndecoded.wordpress.com/ [2] Click "Look Inside" https://www.amazon.com/Software-Design-Decoded-Experts-Think-ebook/dp/B071CM2M1F/ref=tmm_kin_swatch_0?_encoding=UTF8&qid=&sr= https://www.amazon.com/Software-Design-Decoded-Experts-Think...

scoutt 7y ago

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 https://www.youtube.com/watch?v=BKorP55Aqvg

drummyfish 7y ago

> Experts design elegant abstractions And a lot of times the most elegant abstraction is no abstraction cough oop cough. Unnecessary abstraction is as wrong as a wrong abstraction.

Roboprog 7y ago
Yeah, I’m gonna disagree with the “paste, paste, paste “ / “generate mass spam” school of development here. Many feel like you, though. I just don’t want to maintain their effluent.

christiansakai 7y ago

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?

travisjeffery 7y ago
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=1e3ff7d7791b26a8f60b9f16c&id=653935be08 https://travisjeffery.us4.list-manage.com/subscribe?u=1e3ff7.... Thanks.
- christiansakai 7y ago
  Awesome! I will subscribe!

remon 7y ago

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?

ArnoVW 7y ago
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.
- uwuhn 7y ago
  Yes, it's an advertisement.
- remon 7y ago
  Okay. Not very effective then.

commandlinefan 7y ago

“Eight good recommendations that modern software management practices like Kanban and Scrum work effortlessly to destroy”

TurkishPoptart 7y ago

Epstein.

deleted 7y ago

[deleted]

deleted 7y ago

[deleted]

whydoyoucare 7y ago

Most comments cover what I thought about this article (obtuse and too abstract to be practical), so I won't repeat them. However, I did find "The Principles of Computer System Design: An Introduction" by Saltzer to be the best book combining theory and practice. Part 2 is online: https://ocw.mit.edu/resources/res-6-004-principles-of-computer-system-design-an-introduction-spring-2009/online-textbook/ https://ocw.mit.edu/resources/res-6-004-principles-of-comput...

marcus_holmes 7y ago

Non-experts also do all of these, just badly. Seriously, aren't we over this "winners do this" bullshit yet?

deleted 7y ago

[deleted]

tareqak 7y ago

The picture for "8) Experts think about what they are not designing:" looks like an optical illusion, but I can only see the two people with their arms on either side. What is the other picture? My guess would be some kind of Lovecraftian monster e.g. Cthulhu [0]. [0] https://en.wikipedia.org/wiki/Cthulhu https://en.wikipedia.org/wiki/Cthulhu

jvanderbot 7y ago
They are probably using negative space (e.g., what they did not fill in) to show the picture. Sure, this is often used to show two pictures at once, but I don't think that's the case here. I think it's mirrored vertically to further reinforce the trope from preschool of cutting out shapes from folded construction paper.

oh_sigh 7y ago

Why should we listen to these authors? Yes, they have a lot of academic credentials, but is there any evidence they have worked on large systems that have benefited from their designs in practice? To put it another way, I think that I would find a book about writing by Stephen King to be more informative as a budding author than, say, the dean of the English department at Harvard. As with all things, I'm sure there may be value on many of the things they've written, but you may need to already be an expert software designer to realize what advice is useful and what isn't.

unnouinceput 7y ago

1) Experts involve the user That right there is the most important one in the list. Also, as a developer, you can be the user. Try to use your design and start punching data using your designed interface. After entering 100 times you'll catch any bad crap you put there and wish for a faster or smarter way to enter it, trust me. Also, monkey your interface to your wife/kid(s)/non-technical friend(s) and they will point fast whatever they find is boring. No need to deploy in the wild to catch the bad design

abraae 7y ago
I started a new company recently and we are a major user of the same back end in our platform that our customers use. I can say that hopefully never again will I work on a system where the users are remote and isolated from Dev. The benefits of dog fooding are enormous. So many small and large UI discoveries that you would never know about if the input trickled in through jira tickets. If you want to build an elegant, user-friendly system, then use it yourself. Constantly. Repetitively. Then scratch your own itch.

jwilliams 7y ago

The subtext here is that experts are never "experts", you are constantly iterating and learning.

austincheney 7y ago

Point 6 could be rephrased to be more clear. Experts are great at providing original solutions, but they may not always see problems worthy of solutions. By looking around at existing attempted solutions they can estimate the gap between stated and actual problems from their proposed solutions and instead minimize that gap with a better solution.

perlgeek 7y ago

What happened to avoid listical titles? > If the title begins with a number or number + gratuitous adjective, we'd appreciate it if you'd crop it. E.g. translate "10 Ways To Do X" to "How To Do X," and "14 Amazing Ys" to "Ys." Exception: when the number is meaningful, e.g. "The 5 Platonic Solids."

tejisant 7y ago
Agree

chrisweekly 7y ago

This reminds me of a great little gem of another MIT Press book: "Software Design Decoded - 66 Ways Experts Think". Clever illustrations and useful, concise insights FTW. Edit: haha, next time I should RTFA (which clearly mentions it's taken directly from the book I remembered and pulled off the shelf). But my recommendation remains unchanged! :)

yodsanklai 7y ago

I don't think there is anything practical to be learned from this writing... Anecdotally, I've been working in the software industry for only one year (used to be in academia), but I really feel like the main challenge is collaboration and team organization. That, and tackling huge code bases. Designing abstractions, algorithms, and all that technical stuff really is the easy part.

doanguyen 7y ago

> 2) Experts design elegant abstractions: I really appreciate the thing called "abstraction" not only in Software Designer but also in general, it often takes large amount of time to be an expert in the field before one can create/design an abstraction out of the problems.

danielovichdk 7y ago

What's an expert?

janee 7y ago

Haha I keep reading 'Eating Habits of Expert Software Designers' Thinking ohh that sounds weird, and then seeing it correctly. Feel bad saying it but I'm sort of disappointed now :p

Aeolun 7y ago

Why is it that all these lists that are seemingly aiming to teach me something always a list of ‘common sense’ items. Good designers use good abstractions, it’s good to talk to your users... of course, there is nobody that disagrees with these things, but even the most junior of designers knows that. What the dodo is a software designer by the way. Something from academia?

WalterBright 7y ago

These lists tend to be trite, and this one is no exception. For example, "Experts are not satisfied with just any abstraction, they deliberately seek elegant abstractions through which complex structures can be introduced, understood, and referred to efficiently." Every developer I've ever talked to believed down to their core that this was what they were doing. Yet 99% of software is utter bilge. This includes mine. I look at everything I've written 5 or more years ago, and it's all garbage. Most of the work I do is rewriting it. There's no way around it, it takes a lot of experience to be even able to recognize a good design, let alone write one. No list of 10 rules is going to help much. It's like painting. No "10 Habits of Famous Artists" is going to help you become a great artist.

erikpukinskis 7y ago
> > they deliberately seek elegant abstractions through which complex structures can be introduced, understood, and referred to efficiently." > Every developer I've ever talked to believed down to their core that this was what they were doing. Really? I’ve worked with a lot of people who are just trying to make the thing do the thing. Even most of the people who are interested in good abstractions often are under such pressure to perform “I’m just shipping here don’t mind me” that they largely stop thinking about the right abstraction. Maybe I’ve worked at too many troubled startups though lol.
- hinkley 7y ago
  Not all developers are doing this, no. But pretty much all the ones I’d like to strangle are. It’s elegant! No, your dumpster fire of a Second System Syndrome is not elegant. Fractal designs are not elegant. Also you are in your late 30’s. Why are you just having your second system syndrome now? </oddly specific>
andrewstuart 7y ago
>>I look at everything I've written 5 or more years ago, and it's all garbage. From Walter Bright? Sorry I don't buy this. I can accept that you might feel it could be better, but garbage? No.

andrewstuart 7y ago

I'm not going to claim "expert", but I have designed more software than I can even remember. Some of my approach: -- I strive primarily to form a clear and simple mental model of the system that the software will represent. -- Simplicity is everything in software design and should be priority one. Conversely, you must actively avoid complexity, and when part of a system is starting to feel complex, take a step back and rethink the approach. Sometimes systems must include complexity, try to contain this all into a tightly constrained area of the system. -- Loose coupling of system components is next most important - priority two - when designing large interconnected systems - you'll succeed in designing something big if you can instead make a number of smaller systems that know as little as possible(ideally nothing) about the other parts of the system. -- Software is like painting - you can't plan every brush stroke in advance - instead you get the broad brush strokes in place and then paint ever finer levels of detail. -- I strive for consistency, but not slavishly. Try to use the same approaches/technologies everywhere if possible. When not possible, choose the most suitable technology/approach and use that. -- I'm extremely hesitant to allow special cases or exceptions, but I will happily do so when it is clearly necessary. -- I grant myself time to think about possible solutions even when there is pressure (typically from myself) to be actually implementing/coding a solution. -- I do my best to "design out" or get rid of software - the fastest, easiest to write and most reliable code is no code. -- I try to lean heavily on the capabilities of existing systems like database and web servers. If you really understand what existing systems are capable of at a deep level then often you can avoid reinventing the wheel and hook in to what those existing systems do. -- I'm not a fan of complex systems such as containers and kubernetes. I have been able to build all my software architectures without them. -- The project build should primarily aim to put together a working ended to end system that does the absolute minimum to enable the integrated whole to work - i.e. you need to build just enough of each thing to put a pig in one end and get sausages out of the other..... without much attention to anything like user interface or error handling or really much of anything else at all. This is because it is much easier to complete a system that is working, even if only minimally. -- I'm happy to throw away previous decisions and system components if they have proven to be wrong. About 1,000 other things I don't have time to think out right now.

makach 7y ago

okay, personally I thought that piece was a little fluffy and made me think of this quote from the Billy Madison movie: <<At no point in your rambling, incoherent response were you even close to anything that could be considered a rational thought. Everyone in this room is now dumber for having listened to it. I award you no points, and may God have mercy on your soul. Billy Madison : Okay, a simple "wrong" would've done just fine.>>

lozzo 7y ago

I opened the link and I searched for the word "Simplicity" Found 0 of 0. I decided not to read it in order not to hurt my ego. I might not be an expert software designer as my number one item would have been "seek simplicity"