Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Habits of Expert Software Designers

thereader.mitpress.mit.edu

Post reply on HN
Print view View original

71–80 of 148 posts

Re: Habits of Expert Software Designers

#71

Post by oh_sigh »

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.

Re: Habits of Expert Software Designers

#72

Post by unnouinceput »

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

Re: Habits of Expert Software Designers

#73

Post by cobbzilla »

closetohome wrote: post #66
nine_k wrote: post #23

Earlier quoted context omitted.

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? Emp…

Don't spend too much time trying to decipher people who claim to be "levels ahead of you." If they actually understood the topic, they could easily explain it in a way that a novice can understand.

Knowing and teaching are very different things. Did you never have a professor who was a brilliant researcher/scientist but a horrible instructor?

Re: Habits of Expert Software Designers

#74

Post by lazyasciiart »

closetohome wrote: post #66
nine_k wrote: post #23

Earlier quoted context omitted.

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? Emp…

Don't spend too much time trying to decipher people who claim to be "levels ahead of you." If they actually understood the topic, they could easily explain it in a way that a novice can understand.

That assumes that they are trying to explain something to you, but sometimes you are trying to sit in on a meetup aimed at people with more knowledge than yourself, or just following along a discussion between other people.

Re: Habits of Expert Software Designers

#76

Post by molteanu »

auggierose wrote: post #69
bumby wrote: post #65

Earlier quoted context omitted.

I think this illustrates why it's relatively rare to find someone who has a high degree of technical aptitude but also a great communicator. In Feynman's words, "If you can’t explain something in simple terms, you don’t understand it"

The thing is, you can be very good at something without understanding it.

Define 'something'. As it stands, it's too broad.

Re: Habits of Expert Software Designers

#77

Post by austincheney »

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.

Re: Habits of Expert Software Designers

#78

Post by jvanderbot »

tareqak wrote: post #68

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

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.

Re: Habits of Expert Software Designers

#79

Post by bhntr3 »

decasia wrote: 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…

I especially liked the image of the guy roasting marshmallows on his burning computer.

Error might be opportunity but it's best to triage and fix the immediate impacts of the error, document the root causes, then explore any potential opportunities later.

Similarly, you should put out a burning computer with an extinguisher. It might be neat to know that computers can start fires but I recommend matches or lighters if you want to roast marshmallows.

So, I agree, and I think these articles are actually harmful. The biggest skill is knowing what the most important thing to do is, how much of it to do, and why you're doing it. Doing something because you read it's a best practice done by experts is almost the direct opposite of that because it does nothing to help you prioritize, scale or understand.

Don't be marshmallow guy.

Re: Habits of Expert Software Designers

#80

Post by crispyambulance »

tekkk wrote: post #38
crispyambulance wrote: post #28

Earlier quoted context omitted.

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

    > ...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...
I mostly agree.

But the consequences of what "landing a mistake in production" actually means depends on a lot on the environment and the project. Does it mean the deliverable has a hiccup and skids past the deadline a few days? Does it mean there's a bug? Does it mean a hard-to-maintain big ball of mud that makes people miserable for years? Or does it mean a rocket blows up? All those things happen, of course, but to assign blame on any significant number of these to uppity juniors reading articles that are too advanced for them is a bit of a stretch. There are so many ways projects can fail.

I think we all can agree that juniors need the agency to try things out (hopefully with a few guard-rails installed). Sadly having benevolent mentor watch-over juniors is, in many places, a luxury and they're forced to read "articles on the internet" for guidance. It's not optimal but it's OK.

Post reply on HN