Habits of Expert Software Designers • Hacker News Board

Re: Habits of Expert Software Designers

#81

Post by nscalf » Tue, Oct 08, 2019, 6:16 PM UTC

markus_zhang wrote: post #58

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 agree with you. From my perspective (I'm a BA, non-developer), for sure I agree that every abstraction should be elegant. But how to define "elegant"? I probably need years and years of GOOD experience and code reading to get that point.

Elegant is one of the more complicated terms in software engineering. Depending on who is using the word, it can mean some combination of: efficiently designed, easily understood (regardless of complexity), surprisingly brilliant, fault tolerant in a clean manner, very insightful on a problem area, etc. Sometimes code is elegant relative to what has been in place, so going from highly complex to slightly complex might be called an elegant solution. Honestly, I've seen elegant used in just about every way imaginable.

While there may be a TON of things alluded to when calling something elegant, generally people mean that it's easy to understand, thoroughly solves the problem, and isn't likely to break. I would imagine that many elegant solutions become legacy code eventually because they don't easily die and don't necessitate placement all on their own.

I'd be interested to hear how other people view/use this word. I haven't given it much thought, but now that I am, it seems to be very important.

Re: Habits of Expert Software Designers

#82

Post by perlgeek » Tue, Oct 08, 2019, 6:20 PM UTC

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

Re: Habits of Expert Software Designers

#83

Post by username90 » Tue, Oct 08, 2019, 6:24 PM UTC

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…

> Learn by observing others around you

Or even better, learn by making mistakes and have great coworkers who can catch those in code reviews.

Re: Habits of Expert Software Designers

#84

Post by beachy » Tue, Oct 08, 2019, 6:34 PM UTC

unnouinceput wrote: post #72

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

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.

Re: Habits of Expert Software Designers

#85

Post by jlg23 » Tue, Oct 08, 2019, 6:40 PM UTC

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…

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

So how should "these bullet points" explain those things "outside of real life context"?

These points give you abstract points to consider and to then apply to your problem.

Re: Habits of Expert Software Designers

#86

Post by bumby » Tue, Oct 08, 2019, 6:49 PM UTC

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.

To the OP's point, just because you're good at something doesn't mean you can explain it well to others, especially if you don't understand it. Or at least, if you only intuitively understand it

Re: Habits of Expert Software Designers

#87

Post by jschwartzi » Tue, Oct 08, 2019, 6:58 PM UTC

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 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 the requisite knowledge so that they can see things the way I'm trying to explain them.

Re: Habits of Expert Software Designers

#88

Post by mjlangiii » Tue, Oct 08, 2019, 6:59 PM UTC

cobbzilla wrote: post #73

closetohome wrote: post #66

Earlier quoted context omitted.

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?

+1, and anecdotally I've seen most good developers are bad teachers and that I have always gotten much more from my peers just one or two levels ahead of me (regardless of my peer's ability to teach).

Re: Habits of Expert Software Designers

#89

Post by mjlangiii » Tue, Oct 08, 2019, 7:02 PM UTC

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…

When I read this I just assumed it was a checklist for people that know these things - a good reminder. But now that I think about it, it probably was also meant to get people to look out for these things as they learn. I doubt this is enough to really help anyone learn these things.

Re: Habits of Expert Software Designers

#90

Post by yodsanklai » Tue, Oct 08, 2019, 7:11 PM UTC

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.