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.
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.
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.
"Feynman was a truly great teacher. He prided himself on being able to devise ways to explain even the most profound ideas to beginning students. Once, I said to him, 'Dick, explain to me, so that I can understand it, why spin one-half particles obey Fermi-Dirac statistics.' Sizing up his audience perfectly, Feynman said, 'I'll prepare a freshman lecture on it.' But he came back a few days later to say, 'I couldn't do it. I couldn't reduce it to the freshman level. That means we don't really understand it.'"
-- David L. Goodstein, Feynman's Lost Lecture: The Motion of Planets Around the Sun, ISBN:978-0393039184.
I hope so. I've always thought the quintessence of science is pushing back the boundaries of ignorance. To advance we must first understand the true outline of our incomprehension. In that light, I don't think Feynman's remark is a negative sentiment at all.
To know what what you do not know, etc. (c.f. confucious 2:17, rumsfeld 2:02)
I always seek clarity, and quite often 'complex' science is just about that, you get to see differently, eurekas. And when there's no eureka, to me then something is wrong, and the science has been accepted at face value which is also wrong.
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.
"Let's start with you reading (and demonstrating to me a core competence of) the basic texts of physics leading up to Rayleigh scattering--in this case, that would be Newton, Liebniz, Maxwell, Einstein, Heisenberg, and Schrödinger. When you have those six down, I'd be happy to explain to you why the sky is blue."
And at the end of all that, it ends up boiling down to "It's the result of a superposition of states collapsing into a single state upon observation, and the mechanism by which that state gets selected is non-deterministic" and now you have a very confused five-year-old.
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.
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.
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.
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
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.
+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).
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.
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.
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.
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.
You make a good point, then again many people though they understand something cannot communicate it to noobs on account of curse of knowledge issues. Afaik, Fenyman regularly refreshed himself on the basics, he felt it helped his own understanding I think, but that probably had a lot to do with what made him a great teacher as well.
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.
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.
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.
> 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.
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.
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
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.
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.
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.
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.
> 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.
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.
> 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).
> 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.
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.