13 ms·

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 softwa

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

czr 7y ago
Agreed. I think this is an instance of: > It is only by harsh experience that we learn which principles take priority over which other principles; as mere words they all sound equally persuasive.
martincmartin 7y ago
Agreed. Think of them as a list of skills that software engineers have to learn. Junior engineers may not even realize they need to learn them; this post might open their eyes. It may get them talking to users when they might not have otherwise, and through practice, developing those skills.
nine_k 7y ago
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.
- closetohome 7y ago
  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.
  - cobbzilla 7y ago
    Knowing and teaching are very different things. Did you never have a professor who was a brilliant researcher/scientist but a horrible instructor?
    - mjlangiii 7y ago
      +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).
  - lazyasciiart 7y ago
    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.
  - leetcrew 7y ago
    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.
  - jschwartzi 7y ago
    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.
boomlinde 7y ago
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.
Isamu 7y ago
>you're not going to really make sense of this list, not in a way that will actually help you do anything differently. My thoughts as well. Or, you will think of course, I do these things, when in fact you are ineffective at them.
thrav 7y ago
It does say they have a book coming out. I think this is a teaser, with the book having more detail on each technique.
- greymalik 7y ago
  > with the book having more detail on each technique Based on the excerpts you can see on Amazon, not really.
kissgyorgy 7y ago
> you're not going to really make sense of this list I think the premise is that if you did not looked at users before and now you know that you should be, it's a huge difference and you will start thinking about questions like you asked and will figure out the answers over time. I think sometimes the hard part is not knowing what you don't know, because those might be very hard to discover.
markus_zhang 7y ago
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.
- nscalf 7y ago
  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.
  - jnbiche 7y ago
    > efficiently designed, easily understood (regardless of complexity), surprisingly brilliant, fault tolerant in a clean manner, very insightful on a problem area, etc. I think your description of elegant is good. One more aspect of elegant is: doing all those things you list here in a manner idiomatic to the language and paradigm you're working in. So for example, regardless of how efficient or easily understood your solution is, if you're using loops and mutation in a functional language, it would rarely be considered "elegant" by experienced people working in that paradigm (that's not to say that loops and mutation aren't very occasionally a good idea in functional languages, but they'd still not be considered elegant).
bumby 7y ago
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"
- auggierose 7y ago
  The thing is, you can be very good at something without understanding it.
  - molteanu 7y ago
    Define 'something'. As it stands, it's too broad.
    - raindropm 7y ago
      I can think of example in other field: Art. Some people just great at using/picking color. They just pick the color they want quickly and paint without thinking about perfect harmony color scheme theory at all, yet their art always result in great color combination. Just ask them why they pick that certain color and you won't find rational behind it. They just...did, their hand just move to that color, paint it, and it looks good—the results of tons of practices over the years. Not to mention some artist didn't even have proper art education, not to mention art theory. Why and how it happened to be the same combination as in the color harmony theory is surely hard to explain.
      - bumby 7y ago
        It sounds like you are describing intuition. I think there are occasional savants born with this, but for the majority of experts that subconscious decision mechanism is honed after years and years of work.
        barrkel 7y ago
        Often it's the other way around. The solution is found, and it is justified with a rationale. But the rationale came later, it is built with knowledge of critical theory and analysis of solutions. The trouble is you can't teach the intuition.
bhntr3 7y ago
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.
jlg23 7y ago
> 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.
mjlangiii 7y ago
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.
elihu 7y ago
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.

czr 7y ago

Agreed. I think this is an instance of: > It is only by harsh experience that we learn which principles take priority over which other principles; as mere words they all sound equally persuasive.

martincmartin 7y ago

Agreed. Think of them as a list of skills that software engineers have to learn. Junior engineers may not even realize they need to learn them; this post might open their eyes. It may get them talking to users when they might not have otherwise, and through practice, developing those skills.

nine_k 7y ago

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.

closetohome 7y ago
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.
- cobbzilla 7y ago
  Knowing and teaching are very different things. Did you never have a professor who was a brilliant researcher/scientist but a horrible instructor?
  - mjlangiii 7y ago
    +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).
- lazyasciiart 7y ago
  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.
- leetcrew 7y ago
  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.
- jschwartzi 7y ago
  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.

boomlinde 7y ago

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.

Isamu 7y ago

>you're not going to really make sense of this list, not in a way that will actually help you do anything differently. My thoughts as well. Or, you will think of course, I do these things, when in fact you are ineffective at them.

thrav 7y ago

It does say they have a book coming out. I think this is a teaser, with the book having more detail on each technique.

greymalik 7y ago
> with the book having more detail on each technique Based on the excerpts you can see on Amazon, not really.

kissgyorgy 7y ago

> you're not going to really make sense of this list I think the premise is that if you did not looked at users before and now you know that you should be, it's a huge difference and you will start thinking about questions like you asked and will figure out the answers over time. I think sometimes the hard part is not knowing what you don't know, because those might be very hard to discover.

markus_zhang 7y ago

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.

nscalf 7y ago
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.
- jnbiche 7y ago
  > efficiently designed, easily understood (regardless of complexity), surprisingly brilliant, fault tolerant in a clean manner, very insightful on a problem area, etc. I think your description of elegant is good. One more aspect of elegant is: doing all those things you list here in a manner idiomatic to the language and paradigm you're working in. So for example, regardless of how efficient or easily understood your solution is, if you're using loops and mutation in a functional language, it would rarely be considered "elegant" by experienced people working in that paradigm (that's not to say that loops and mutation aren't very occasionally a good idea in functional languages, but they'd still not be considered elegant).

bumby 7y ago

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"

auggierose 7y ago
The thing is, you can be very good at something without understanding it.
- molteanu 7y ago
  Define 'something'. As it stands, it's too broad.
  - raindropm 7y ago
    I can think of example in other field: Art. Some people just great at using/picking color. They just pick the color they want quickly and paint without thinking about perfect harmony color scheme theory at all, yet their art always result in great color combination. Just ask them why they pick that certain color and you won't find rational behind it. They just...did, their hand just move to that color, paint it, and it looks good—the results of tons of practices over the years. Not to mention some artist didn't even have proper art education, not to mention art theory. Why and how it happened to be the same combination as in the color harmony theory is surely hard to explain.
    - bumby 7y ago
      It sounds like you are describing intuition. I think there are occasional savants born with this, but for the majority of experts that subconscious decision mechanism is honed after years and years of work.
      - barrkel 7y ago
        Often it's the other way around. The solution is found, and it is justified with a rationale. But the rationale came later, it is built with knowledge of critical theory and analysis of solutions. The trouble is you can't teach the intuition.

bhntr3 7y ago

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.

jlg23 7y ago

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

mjlangiii 7y ago

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.

elihu 7y ago

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.