[deleted]
Habits of Expert Software Designers
21–30 of 148 posts
Re: Habits of Expert Software Designers
#22An "illustrated guide" shouldn't mean shallow content without any practical advice decorated with semi relevant stock photos.
There was a good one, where an eager dog was used to represent the user. I'll be sure to refer to my hard headed business users like that and see how far I go. When they use the UI right, I'm going to be there with a treat.
I will definitely try this method next time I do user testing.
Re: Habits of Expert Software Designers
#23Most 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 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? Empirically, they are smart, so they mean something.
This is how you start to detect where the common context is lacking, and look for explanations. Eventually, with enough effort, you bridge the gap and understand what they meant, and why. This is how you grow.
Re: Habits of Expert Software Designers
#24Most 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 think that's where the "look around" point kicks in. You can look at a successful software project and think of ways that "learning about the users" applies to its design.
With some imagination I think that anyone working with software can take something from these points, but it's obviously not a how-to-expert tutorial. Rather, it's what the title says that it is.
Re: Habits of Expert Software Designers
#25This is basically just marketing for a book
This is basically CS lifestyle marketing.
There's zero useful, actionable content. There's no evidence the authors have any big-project experience of their own, and the bibliography doesn't help make a case for their expertise.
https://softwaredesigndecoded.wordpress.com/annotated-biblio...
In fact it seems to be academic back-seat driving by a pair of authors who don't understand the difference between reading about a domain and living in it, and are now communicating in platitudes. With cutesy pictures.
"You know you could try to make your abstractions more elegant? How about focussing on the essence? Or seeing how someone else did it?"
Thanks. When our next intern slot turns up, we'll be sure to keep you in mind.
Re: Habits of Expert Software Designers
#26> Experts focus on the essence
I think this is one of the strongest points of a good developer, and what makes them such good problem solvers in many situations. Often you get confronted with problems, from say a client or through user feedback, which don't amount to much more than "wishes" - with no clear and/or conflicting solutions. A good developer is able to distill the problem down to its core, finds out the true nature of the issue, can communicate that back, while also offering solutions.
Re: Habits of Expert Software Designers
#27While I agree on the content, I think the word "Expert" in the title is misleading. All of these habits are better attributed to Generalists. "Experts" I know are often too focused on certain fields. More power and wisdom comes by connection of experience from different, even orthogonal, domains.
Re: Habits of Expert Software Designers
#28Experts design elegant abstractions and leave us to understand their brilliance after they've left. I'd say elegant abstractions are discovered. Those that are designed tend to have leaky corners. Some manage to rediscover something, implement it poorly, and give it a new name to confuse programmers for the next couple of decades that follow. Experts simulate continually and fool themselves into believing they've tho…
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…
> ...too many juniors will read this and think they need more abstraction.
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).
Re: Habits of Expert Software Designers
#29Earlier quoted context omitted.
It’s only obvious when the article gets read, and in my experience many people who vote don’t bother to read
No it's obvious even before that because as the person I responded to points out it's right there in the footer: >The first hint was at the footer of the page: Illuminating the bold ideas and voices that make up the MIT Press's expansive catalog.
The footer in the article.... if the voter doesn’t read the article I think it’s plainly obvious that they didn’t bother to open the article with the intent of reading it...
Re: Habits of Expert Software Designers
#30Expert Software Designers read. And do it continuously. Not only HN and medium, but big "essence" ideas that you do not get usually on day to day tasks, and mold the perception of problems and solutions.
People familiar with Wirth, Kay, McCarthy, Iverson, Moore's (and pals) works have a fundamentally broader vision of problems and their solutions.
It's obvious, but all those points are not learnt in a discrete manner but they work as a whole and grow on you during the journey.