At Hacker School we work on becoming better programmers, help each other become better programmers, and talk about that process. Here are some of the things I've said in that context.

On a Julia Evans post, "Fear Makes You A Worse Programmer":

Back to fear - this piece by Skud includes a bit of a horror story -- bad or missing code review led to a bad deploy which led a volunteer to drop out entirely, partly due to fear of messing up again. And here's a story where paranoia by management led to the firm going out of business.

....So the distinction de Becker makes [in The Gift of Fear] is that fear is your subconscious telling you about a genuine threat, because your intuition has put together the facts faster than your conscious self has -- whereas anxiety comes from the messages on the 10 o'clock news, racism, etc. Fear is a friend and anxiety is an interloper. If I were to use that framing, I would say that one characteristic of a mature programmer would be: she has a healthy sense of fear, and the reflex to mitigate scary risks ("we need to put this into version control NOW"), but she has control over anxiety ("people say C is hard to learn, maybe I'm not smart enough").

On choosing your own learning path:

I think you might like this reflective post by Ben Rosenbaum on "the moment in which I actually started to determine my education." (And a few current thoughts, by Indian students speaking to other Indians, that by implication say a lot about breaking expectations.) I try to be conscious of how others explicitly and implicitly guided me into certain achievement paths and avoid doing that with others, avoid making assumptions (so, for instance, I have retrained myself to avoid asking, "where did you go to college?").

On Philip Guo's post about "command line bullshittery" as a barrier to research:

I agree with Philip Guo so thoroughly, especially about the demoralizing effect of the gulf of execution, and that a leader should reduce the incidental complexity that slows down the people she's serving.

....As a card-carrying fan of Neal Stephenson's "How to Win Friends and Influence People^H^H^H^H^H^H^H In The Beginning Was The Command Line", and of [readings] on the usage and philosophy of Unix concentrating on the command line, I do not consider the command line bullshit. But Philip's right to consider the specifics of *getting research software installed and set up* as incidental complexity in the context of his students' substantive work. And that process takes place on the command line. It's like me calling the process of getting across town in Manhattan "L train bullshit"; it is good that the L train exists but arrrrgh.

On better ways to ask and answer code-related questions online (and the concept of a "yak trace," understanding the series of steps a person has taken to make something or debug a problem):

basically I think a yak trace emerges most easily in conversation with a generous interlocutor, whereas many fora online where people ask for help would prefer that help-requesters' initial speech act be delivered with the concision and throughput of a paramedic running alongside a gurney

....In my experience *building even the faintest of relationships* with the asker/user makes it a million times easier to ask the question. In IRC, for example, I've had tremendous success by *starting off saying* (roughly) "Hi [person's nickname]! I'm Sumana, [thing I do] and I live in NYC. Good to meet you, although sorry for the circumstances :/" [wait for reciprocation; most people will reciprocate by giving their name at least] "That problem sounds frustrating. Do you mind if I ask a couple diagnostic questions?" Now we are people together and not just Supplicant and Expert, and I can ask about the environment, and I can say something like "the approach you're using is sort of unusual so I want to check whether you're accidentally making it harder for yourself and there's an easier way to get the functionality you want :) " (although I can't remember the last time I had to literally explicitly say that; usually by this point they are open to talking about their process, their macro goal, etc.).

IMO the affordances of a lot of online tech-help-seeking spaces discourage this kind of necessary trust-building conversation.

In longer-term dev scenarios, understanding the user's underlying goals is a task that product managers and user experience designers have a lot of tools to do. Qualitative interviews. Ethnography. Market research. Looking at traffic stats and discovering/making funnels. IMO Val's insight about what the application developers really wanted was a user experience insight (some folks call it DX, Developer Experience, for stuff like this).

The API usability chapter in Greg Wilson's and Andy Oram's Making Software influenced my thinking thoroughly on this stuff.

Words, other than proper nouns and HTML, in this post that my in-browser spellchecker dislikes: bullshittery, arrrrgh, gurney, IRC, etc., IMO, affordances, tech-help-seeking, dev, stats, DX, API.