6 ms·
Habits of Expert Software Designers (2019)
- tuxie_ 5y agoI was skeptic due to the title at first, expecting generic (yet meaningless) "habits" like "reply emails as soon as they read them" but was positively surprised. Great article.
- achow 5y agoNot so great reviews of the book https://www.amazon.com/Software-Design-Decoded-Experts-Think/dp/0262035189 https://www.amazon.com/Software-Design-Decoded-Experts-Think...
- jwdunne 5y agoYes, I expected the book to go into more detail but it’s actually not. You get as much content in this article as you do the book.
- axiosgunnar 5y agoGiven the bad reviews of this book, could somebody recommend a good book about the topic at hand (software design)?
- dgb23 5y agoNot specifically software design, but insofar related books that take the perspective of programmers with unique insights: - Coders at Work (Seibel) - Working in Public (Eghbal) The first one is very entertaining. Read it a couple years ago and found it gives some valuable perspective. The second one is on my reading list, it was recommended around these boards. Related to software design, there are many. The two that are on my recent list are: - Software Design for Flexibility (Sussman, Hanson) - A Philosophy of Software Design (Ousterhout) I can't comment personally on their content yet, still have to work through those two, but I have zero doubts to learn something valuable. Certainly consider them.
- amelius 5y agoThere's a video by Ousterhout titled "Can Great Programmers Be Taught?" from this year. https://www.youtube.com/watch?v=lgZ7Cxt5uIU https://www.youtube.com/watch?v=lgZ7Cxt5uIU
- clumsysmurf 5y agoTwo books about to be published in this genre which I am excited about: (1) Software Development Pearls: Lessons from Fifty Years of Software Experience (Karl Weigers). I enjoyed his books on Requirements and Software Engineering Culture This zinger really applies to my work place "Lesson #7. The cost of recording knowledge is small compared to the cost of acquiring knowledge" (2) Code That Fits in Your Head: Heuristics for Software Engineering (Mark Seemann). His previous book on Dependency Injection was good
- ku-man 5y agoNothing relevant here, just generic advice. Actually, it's so generic that florists, hairdressers and cabinet makers can perfectly make use of those 'habits'.
- deleted 5y ago[deleted]
- erhk 5y agoExperts design elegant abstraction is equally as useful as saying grandmasters make the best move. Immediately lost interest in the article.
- lmilcin 5y agoHi, my notes: 1) Experts involve the user. Also, experts do not let the user design the software. The user will frequently want to tell you what the software "must" be doing. An expert will disregard this and will want to first understand the domain and then work with the user to find a good mapping to a useful interface. 2) Experts design elegant abstractions I don't agree on this. Oftentimes, I have seen "experts" use solutions because they seemed elegant, intelligent, "nifty". I did that myself. An expert will design simple abstractions that let the job done with little fuss. The software needs to be as simple as possible but not simpler than is needed. Replace "elegant" with "simple", and it sounds about right. An expert software looks dumb and simple, not necessarily super elegant and intelligent. Also, bad software can look dumb and simple. 3) Experts focus on the essence Experts start by focusing on the essence. Then verify by testing how the distilled essence is useful at solving entirety of the problem.
- dgb23 5y ago> Replace "elegant" with "simple", and it sounds about right. Good point, but I would argue they are identical.
- lmilcin 5y agoI don't think so. Let me explain from my experience. I have been asked to create a payment gateway for a company. We found an elegant solution that consisted of general components that we could just configure and wire together so that we will never need to write another payment gateway. This was a mistake and we found it on next project that involved adding new payment method. We found that yes, it could be rewired and configured without any development at all. But the process to do so took so much effort, that we would just be able to write a new payment gateway in less time. The simpler (but less elegant) solution would be to just write the minimum code necessary (of course still neatly and nicely), and then implement the other payment gateway separately. We should have then extracted common model and infrastructure until there is nothing left and we again are left with a single, coherent application. We have prematurely optimized, put a lot of upfront effort for unknown benefit. The benefit happened to be negligible and the resulting code was complex and costly to work with. But sure it looked elegant. Now that I am wiser for this lesson I am trying to use patterns to produce simple dumb code that models the problem well enough without details that are not necessary for the particular instance of the problem.
- Andy_G11 5y agoFrom experience with staff of different levels of expertise, the points seem to hold true, e.g.: Reaching out to other people - generally true that staff w. greater expertise are more likely and comfortable doing so; Form elegant abstractions - also true: experts more likely than newbies to be able to find a simple way to describe something that is built on sufficient complexity to cause at least some bafflement. Also, for staff of a similar degree of experience and role, I have a greater degree of confidence in the outputs produced by those who can answer more searching questions, showing they have drilled down to the fundamentals. I suspect that this type of person is more likely to develop into a real expert than those who adopt the how without caring about the why. Experts may be better at ensuring that the substance of an objective is delivered rather than just the form.
- jorangreef 5y agoI don't know if the book goes into this, but one thing I've noticed about brilliant software people like Jeff Dean or Martin Thompson is that they appear to love doing simple "back-of-the-envelope calculations" (and lots of them). They can iterate designs rapidly in their head or on paper, evaluate the cost or value of a design, know when a design has promise or when it won't work, and where the bottlenecks or low-hanging fruit might be, because they have a good feel for the performance/scaling cost of all the resources involved along the axes of things like branch mispredicts, main memory references, per core memory bandwidth, disk seeks, disk bandwidth, network latency, network bandwidth, expensive memory vs inexpensive storage tradeoffs. Numbers that programmers should know [1] but often don't. In other words, before they even write specifications or start coding, they've probably done tens to hundreds of back-of-the-envelope calculations to put their design in the "roughly right" ballpark. This drastically increase the chances that the design is going to work, and work really really well. And I think this habit is also what tends to set them apart. [1] https://colin-scott.github.io/personal_website/research/interactive_latency.html https://colin-scott.github.io/personal_website/research/inte...
- cinntaile 5y agoThere's a monthly newsletter dedicated to napkin math. He hasn't made one in a few months for some reason, but judging from his tweets he's working on a new one. You can also practice on the old ones of course. https://sirupsen.com/napkin/ https://sirupsen.com/napkin/
- read_if_gay_ 5y agoAlso a nice guest lecture by Kernighan at Harvard: https://youtu.be/kw9KwjJCJH8 https://youtu.be/kw9KwjJCJH8
- bob1029 5y agoOne other very similar path is to start with domain modeling. Figure out what all of the facts, types and relations are in abstract terms before you write a single line of code. Excel is exceedingly capable at this type of design work. I see abstract domain modeling combined with practical engineering constraint solving as the foundations of the discipline. Being able to simultaneously operate in abstract academic terms (e.g. database normalization) while also considering things like cache lines and latency between networked participants is how the magic is done.
- aynyc 5y agoI don't consider myself as experts compare to some of the big names, but my habits have served me well. 1. Don't assume anything. Go in with an open mind and blank canvas. I can't tell you how many times I've been in design meetings where engineers assume they know how things are gonna work, before clients even open their mouths. I can't tell you how many times clients assume they know how technology works before we explain to them. 2. Iterate and validate as fast as you can within reason. Don't do waterfall, at least not at the beginning. Design, build and validate, or even just do napkin design and validate. It'll save you a lot of headaches. 3. Perfect is the enemy of good. When you reach a certain comfort level with your software, ship it. You'll never be able to clean out your tech backlog or bug list.
- hugey010 5y ago#3 is very true, but where is the line? If your website crashes on every request, then it's clearly not ready. If it crashes only on Thursdays when Carl uploads that one spreadsheet, it depends how important Carl's spreadsheet is. The answer is always, it depends. When SLA requirements are nonexistent, or self-defined, what is good enough?
- aynyc 5y agoIf Carl is uploading financial reports or payrolls for the CXO every month TWICE, then I'll just make sure I have a script that can handle that file unless the fix is easy. If you have SLA, that's easy, ship as soon as you hit that SLA. If you don't, then onboard clients very carefully.
- futureproofd 5y agoI'm really digging these days to solidify my foundation of software development so I thought this link might contain some useful information. Perhaps it does, but it seems a little abstract. Being said, I'd rather get deep into the weeds with some technical summer reading. I'd love to get some recommendations from everyone here if possible.
- chillpenguin 5y agoThere's too many subfields etc. to make a suggestion. What areas in particular are you interested in? Another relevant question is where are you in your journey so far? What have you already read? etc.
- futureproofd 5y agoThanks for the response. Right now I'm focused on Javascript professionally (NodeJS for the backend and React on the frontend). I'd say my long term goals are to give back to the community through open source in some capacity. In particular, I'd like to contribute to a library or a framework so I guess that would mean understanding the reasoning and the fundaments of why/how the library was created. Whether that means understanding design patterns of Javascript specifically or software fundamentals, I'm not sure. Sorry if this still sounds too broad, but I'm growing quite bored of working as a typical developer and need a bit of guidance.
- elcapitan 5y agoMy main takeaway from the article is the picture of the guy barbecuing some food over his burning PC. That's something I could see myself adapting.
- AnimalMuppet 5y agoSeconded. Specifically, roasting marshmallows. Seriously, if you haven't looked at the article, just scroll down to see that picture. (You wouldn't want to do this in real life, because a burning PC will give off toxic gasses, and you don't want to eat marshmallows after that. But I thought that the picture itself was hilarious.)
- kuharich 5y agoPast comments: https://news.ycombinator.com/item?id=21191477 https://news.ycombinator.com/item?id=21191477
- agentultra 5y agoI'm curious if any of the expert software designers use mathematical principles to verify their designs or model checkers/analysis to explore their designs. I find there's a lot of informal folk-lore when it comes to "solid" software design. Asking experts is likely to surface answers as numerous as the stars in the visible universe. There may be common threads in popular discourse but it seems only to be buoyed by personality: a popular project lead or evangelist discusses their methodology and a constellation of developers grab on to it in order to emulate their success. Others find harbour elsewhere. And yet very few of them formally state how their approach works to solve real engineering problems. The gang of four book is a book of patterns. The book itself doesn't contain any formal analysis of these patterns. Even among these patterns there is a world of contention about which ones work, which ones are less useful, etc, etc. A beginner into this world, typically an intermediate to advanced programmer with a few years experience under their belt, hits this wall and is left to flounder and find their tribe. I liken it to beliefs about the efficacy of software engineering practices. There's far too little evidence about them to make any strong claims to their effectiveness. And yet people have built careers around evangelizing certain ones. (And often when you ask people to be more forthcoming and give their formal definitions they wave their hands and say that software development is art not engineering and that it's about craftsmanship and beauty not cold, hard, unfeeling things like calculi, categories, or algebras) I have little faith these days. Unless someone can formally describe their abstraction it's neither simple nor elegant to me. Such terms are qualitative in the absence of formal definitions. What is simple to you might be a hodge-podge to me. Code sans sensible abstractions is procedural spaghetti in my opinion: simple to understand in small, local parts, but impossible to comprehend as a whole. But if you can explain to me what the objects are, the operations on them and what they mean, and the algebraic properties of those operations then I'm much more certain about what we're discussing and can agree that given such definitions whether something is simple or elegant. What programming language the system is ultimately implemented in rarely matters as much as getting the design right. Update: I'm curious because while I find these tools useful I often feel like they're under-appreciated and perhaps hardly used outside of certain small circles in practice.
- parafactual 5y ago> (And often when you ask people to be more forthcoming and give their formal definitions they wave their hands and say that software development is art not engineering and that it's about craftsmanship and beauty not cold, hard, unfeeling things like calculi, categories, or algebras) I find it interesting that anyone would see these as mutually exclusive.