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

101–110 of 148 posts

Re: Habits of Expert Software Designers

#101

Post by nine_k »

onei wrote: post #100
jschwartzi wrote: post #87

Earlier quoted context omitted.

Some of the things that I know about would take months or years to explain to a novice in such a way that they would understand what I was talking about. Not by way of metaphor or by analogy, but to truly see things the way I'm seeing them when I give an explanation. We can try to meet halfway but the requisite knowledge may be lacking. In effect this is what I'm doing when I coach interns and juniors -- giving them…

Out of curiosity, what sort of topics require months of years of explanation? I find that most complex topics can be broken down to a point where an average adult could digest them if they're interested enough in learning them. I wouldn't necessarily say that a 5-10 min explanation means that they could apply it in the field, but enough to understand a specific scenario.

A question from a five-years-old: why is sky blue?

A correct answer: you need to learn how to read, then some mathematics, then quantum physics, then you can calculate how sunlight scatters on molecules of air. Understanding the physiology of color vision won't hurt, too.

This is not very useful. But at least you see some topics to learn more about, and a simplified picture may be built: sunlight contains some blue light, and it gets stuck in the air, while reds and greens pass in more easily. Hey, you just understood why sunsets are orange and red! Go on.

Re: Habits of Expert Software Designers

#102

Post by atq2119 »

onei wrote: post #100
jschwartzi wrote: post #87

Earlier quoted context omitted.

Some of the things that I know about would take months or years to explain to a novice in such a way that they would understand what I was talking about. Not by way of metaphor or by analogy, but to truly see things the way I'm seeing them when I give an explanation. We can try to meet halfway but the requisite knowledge may be lacking. In effect this is what I'm doing when I coach interns and juniors -- giving them…

Out of curiosity, what sort of topics require months of years of explanation? I find that most complex topics can be broken down to a point where an average adult could digest them if they're interested enough in learning them. I wouldn't necessarily say that a 5-10 min explanation means that they could apply it in the field, but enough to understand a specific scenario.

It is said of a lot of things in mathematics that you simply need to get used to them. This process does take months or years, and once you went through it you probably no longer understand how it feels to not understand those things.

The 5-10 minutes explanation is what you get in a lecture. You may even think that you understand afterwards. Years later, you're going to look back and realize that you really didn't understand much at all.

Re: Habits of Expert Software Designers

#103

Post by chrisweekly »

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! :)

Re: Habits of Expert Software Designers

#104

Post by leetcrew »

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.

some things are irreducibly complex. if I ask a theoretical physicist about their work, they may not be able to explain anything meaningful about it to me.

Re: Habits of Expert Software Designers

#105

Post by npo9 »

onei wrote: post #100
jschwartzi wrote: post #87

Earlier quoted context omitted.

Some of the things that I know about would take months or years to explain to a novice in such a way that they would understand what I was talking about. Not by way of metaphor or by analogy, but to truly see things the way I'm seeing them when I give an explanation. We can try to meet halfway but the requisite knowledge may be lacking. In effect this is what I'm doing when I coach interns and juniors -- giving them…

Out of curiosity, what sort of topics require months of years of explanation? I find that most complex topics can be broken down to a point where an average adult could digest them if they're interested enough in learning them. I wouldn't necessarily say that a 5-10 min explanation means that they could apply it in the field, but enough to understand a specific scenario.

These bullet points are not for specific scenarios. They are broad general activities. Their specifics will change from situation to situation.

The first bullet point — listening to users, but not taking what they say at face value is fantastic advice for all businesses. Executing on it is a high-skill activity.

I can give examples of when this was neglected and things went poorly. I can give examples of it done very correctly. Only after practicing it for years can I get a smell for what a user really needs, or how to steer a corporate customer to the solution they need and not the one they want.

Re: Habits of Expert Software Designers

#107

Post by dromen »

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 tactic makes sense when you want to communicate to people on a much lower level than you are at, and you want them to get the surface level rapidly.

If this were to be levied at me accusingly I'd throw a programming Bible at them, get thee hence and study.

Re: Habits of Expert Software Designers

#108

Post by tyleo »

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.

I agree. The best engineers I have worked with have been able to justify decisions to a whole team. They were able to educate those who weren’t up to speed elevating the group.

The worst engineers dismissed others out of hand, saying they lacked the requisite knowledge for a discussion.

Re: Habits of Expert Software Designers

#109

Post by nitrogen »

onaraft wrote: post #92
ken wrote: post #70

Earlier quoted context omitted.

I've come to realize the problem with Java is not the programmers. Most of the strategies they want to use are legitimate improvements in flexibility, and in other languages they do make the source code smaller. Java is simply a poor vehicle. Java forces programmers to choose a point on the spectrum of "more flexibility" "smaller program size". In languages like Lisp, by contrast, the more generic a function is, the…

I would argue that no matter what language you pick, adding abstraction always behaves like this: Suppose I have a thing I need to do, called X. I write a program to do X. Then later I need to do Y, and I realize that if I think of X as (A + B) and Y as (A + C), then if I re-organize to have one segment of code to do A, then wrap it so that B or C happen afterwards based on context (whether that be polymorphism or di…

I'll give a concrete example where adding abstraction will make code shorter. This comes from my recent experience, with some details changed for the sake of discretion and simplicity.

Suppose you wanted to simplify the generation of contextual metadata for structured logging in an API service. The service handles requests that manipulate stored records, run logic, etc. Basic CRUD plus business logic.

The starting point is a bunch of raw calls to MDC.put() if a Java service, or an equivalent in another language[0].

An abstraction-free approach might give you a logUser method, a logUserAndAccount method, a logAccount method, a logTransaction method, a logTransactionAndAccount method, etc. This does at least simplify the actual request processing code from the starting point and make the logging consistent, but makes the program longer.

Alternatively, one could have a generic Loggable interface, with a function that returns metadata for the object to be logged, and a logWith method that takes a Loggable as a parameter. You can get fancy and provide a default implementation if all of your entities have common methods like id(). There are probably still ways to improve from here, but now instead of a dozen functions, you have one.

[0] Years ago I wrote a rubygem for this, but was not able to open source the bulk of it.

Re: Habits of Expert Software Designers

#110

Post by Roboprog »

drummyfish wrote: post #45

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

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.

Post reply on HN