Live data from Hacker News

Habits of Expert Software Designers

thereader.mitpress.mit.edu

111–120 of 148 posts

Re: Habits of Expert Software Designers

#111
post #101
post #100

Earlier quoted context omitted.

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 l…

White Light is actually a mix of colours, the rainbow. You can split it into parts with a glass prism, or in good weather a sprinkler?

Light is a bit like a wave through the air and in the blue light the waves are closer together.

The sky aboves us has a small amount of dust.

Because the blue light waves are closer together they hit more dust.

This means they are more likely to bounce towards us, so we see blue when we look up at the sky.

At sunset the blue waves are more still more likely to hit dust, and so be blocked, so we see red.

Not simple enough, but I gave it a go.

Re: Habits of Expert Software Designers

#112
post #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.

> with the book having more detail on each technique

Based on the excerpts you can see on Amazon, not really.

Re: Habits of Expert Software Designers

#113
post #101
post #100

Earlier quoted context omitted.

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 l…

Because that's the color of air.

Re: Habits of Expert Software Designers

#114
post #99
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…

One problem is that Java lacked functions until Java 8. It still sort of lacks them internally, but tat least you can write free-standing functions here and there, and especially as lambdas inline. Another problem is that Java lacks type aliases. If your data have a complicated type like List >>, you have to copy-paste this type everywhere, without a way to name it succinctly. On top of that, Java lacks type inferenc…

Java 10 added the var keyword so it has some type inference finally.

Re: Habits of Expert Software Designers

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

In my case, I can see how to apply those things to personal projects that I have complete control over, but I have trouble imagining myself doing those things in my regular job, in which I have some say in how to implement this or that, but I don't really have any high level control over what features the product is going to have.

Besides having the requisite experience to make decisions, you also need to be in a position of authority that can make decisions, and some degree of veto power over decisions made outside your team that affect your work.

Re: Habits of Expert Software Designers

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

Re: Habits of Expert Software Designers

#117
post #31

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…

There is an easy test for wrong abstractions. A right abstraction makes everything smaller. Most wrong abstractions make everything bigger (in the name if "flexibility", etc).

Most wrong abstractions are created when people anticipate further growth that never comes. I wouldn’t say they are wrong by themselves, but it could be argued you should just refactor your code when you need them.

Re: Habits of Expert Software Designers

#118
post #100

Earlier quoted context omitted.

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 u…

That is one learning style but not the only learning style. That style is reserved for kids, because often explanations are too abstract, so instead of fully understanding what they're doing, they're given tons of examples, turning the process into muscle memory.

If a topic is muscle memory, it becomes very hard to explain or teach to another. This is why it is important to learn topics beyond muscle memory. I had to go through this because I learned how to program before I was a teen. I found it difficult to explain what I was doing to others.

Today when people get stuck early on learning to program I show them decomposition, as it is the most common hold up people get stuck on. Decomposition is the opposite of abstraction, so it leads into a beneficial second lesson later on. (I don't explain decomposition, I show them.)

At the end of the day it comes down to personality and beliefs more than prerequisite experience when it comes to learning. If someone is afraid to stop and go out of their way to learn a prerequisite, because they're afraid to be seen as ignorant, they're going to struggle. Likewise, if someone is afraid to make a mistake / have a misunderstanding, it can cause too much anxiety to quickly pick up topics.

This is why with interns my primary focus is neutralizing anxiety. I try to show ignorance and misunderstanding are okay and acceptable. I lead by example. Little ducks copy unsaid behaviors well. Once that criteria is met, then and only then do I slowly switch into dumping terminology and lessons on them, only once they're ready for it.

Re: Habits of Expert Software Designers

#119
post #100

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.

Take Galois proof of the insolvablity of the quintic. To understand it you first need to understand group theory and then field theory and obviously how these relate to the rational numbers and the ring of polynomials over the rationals. Next you need to understand field extensions and then you can start to make sense of galois groups. Then you need to understand the concept of solvability for groups and prove it’s equivalence for galois groups to solutions to polynomials. Then finally you need to demonstrate a polynomial of degree five whose corresponding galois group is unsolvable.

Now you can hand wave this and get a basic idea of it. But this is also undergraduate mathematics. The abstractions keep building on each other as you go and soon the easy way to explain it is still in terms of other abstractions. This is for instance why research papers in mathematics are impenetrable, because the requisite knowledge takes years to acquire.

Re: Habits of Expert Software Designers

#120
post #100

Earlier quoted context omitted.

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.

Take Galois proof of the insolvablity of the quintic. To understand it you first need to understand group theory and then field theory and obviously how these relate to the rational numbers and the ring of polynomials over the rationals. Next you need to understand field extensions and then you can start to make sense of galois groups. Then you need to understand the concept of solvability for groups and prove it’s e…

On the other hand, if you are VI Arnold, you can teach an honest version to motivated high school students in a relatively short timespan, https://amzn.com/1402021860
Post reply on HN