The Local Minima of Suckiness

Feels like a take from an alternate reality. I can’t think of a single great developer I know who was not self-taught. In my experience, if you got the will, drive, attitude, and curiosity, you had it for a while, and any given situation can only slow or accelerate your pace. And if you don’t got them, you don’t got them, and no sage shove from the outside is going to help.

&quot;As she found one error after another, he became more and more amused, rather than more and more defensive[.]&quot;<p>This has to be one of the snowballing keys to success. Soliciting and rewarding negative feedback, in a way that doesn&#x27;t threaten the overall.<p>Works for bugs in code, also for life stuff. Being teased&#x2F;mocked gives incentive and direction for positive change, so long as it doesnt send one spiralling.

I don&#x27;t think things are as black and white as the article suggests. Especially the part about having an environment where its encouraged to mess up and ask random questions.<p>My experience so far has been the exact opposite. I have mainly been in confrontational environments, from my teen years on IRC to my work places. What I have learned is that if you say shit that are wrong, or if you try to talk without knowing your subject enough, you&#x27;ll get smashed without mercy. I think this kind of atmosphere played a huge role in my development, on the positive side. If I had to intervene on a subject, I would be damn sure to know it well. If I had an issue at work, I would work hard to solve it and understand all the implications before asking for help.<p>Not saying that&#x27;s the best environment for everyone, but it sure is for some of us.

&gt; In the Middle Ages, the way that communities passed on best practices to future generations in the trades was through apprenticeships.<p>. . .<p>&gt; There is no apprenticeship for learning how to build Docker containers or dealing with prod outages.<p>Conversely, we could deduce that the way the industry works, employment in specialised IT teams is de facto apprenticeship.

I have some small issues with the introduction, but otherwise it&#x27;s a strong article with many good points.<p>I particularly appreciate the whole section about &quot;psychological safety&quot;. It resonates with me strongly. Thinking back to all the jobs I&#x27;ve done, I can see a clear pattern: I started doing by best work when I reached a level of comfort around people in the company, so that I stopped worrying about being judged by my co-workers and my bosses. This process usually took a lot of time (~6-8 months) - and now I think it could&#x27;ve been much shorter - if I was aware of this, and if my bosses were aware of this too.<p>I wonder how much of the &quot;first 6+ months of a new engineer is sunk cost of onboarding&quot; pattern is caused by this - by employees fearing judgement and feeling they need to prove themselves.

I can think of one place where this was the norm. People pair programming, reviewing code. It was really safe to be there. I leaned so much, it&#x27;s one of the few times I noticed myself achieving a new level I didn&#x27;t know I could reach.<p>And, I know of multiple places that were not safe places to make mistakes. It was awful, I was demoralized quickly and wrote bad code and got fired.<p>It makes my whole body shiver to think about places where the entire organisation would pull to make it psychologically safe. It takes real courage and thoughtfulness for those in leadership to create that kind of culture because there are so many barriers (namely awful people) who will be pulling in the other direction.

One of the best &quot;how to get gud at programming&quot; posts I&#x27;ve read in a while!<p>I am where I am today because of my exposure to companies&#x2F;teams that embody this environment

I can see that being open to criticism, sharing what one has and does, could be a good way to improve skills. But why is improvement the goal, not pride and appreciation? It doesn&#x27;t really matter what I mean in the world, on some absolute scale, compared to how much joy I get out of the thing, no? At least as a proposition. Dialing down one&#x27;s ego seems like a fine plan, but dialing down other people seems good too. Though I suppose no one likes to feel like they&#x27;re in a rut.

This describes glimpses of a &quot;state&quot;, not a process.<p>To feel &quot;safe&quot; asking dumb questions, you have to accept that the answer is often an irritated &quot;RTFM&quot;. Accept first that the worst outcome is being ignored or sneered at, then you won&#x27;t be so fearful.<p>Beginners who ask questions usually want affirmation and some sort of &quot;experience of being a peer&quot; or something like it.<p>The safe environment that people think others are responsible for, is mostly internal in my experience.

Writing code to get things done is something you can learn fairly well by yourself. But writing code that is an actually user friendly and powerful tool, that requires mentoring.

I would argue it depends upon your choice of substrate.<p>If you learned programming by programming phones or the web, your foundations change every 36 months so your improvement lags because your knowledge decays with time.<p>If you learned programming on firmware, Windows classic (think Petzold), or Unix, things haven&#x27;t changed in decades, so your knowledge fundamentally accumulates.