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.
I think you need both intrinsic talent / motivation and external guidance.
Like with research, nobody can take arithmetic and single-handedly discover calculus, number theory, and higher concepts. You're not going to discover good software development paradigms without reading about some of them. You especially can't write anything useful without using high-level libraries and working with others.
At the same time, I think intrinsic motivation significantly helps learning these concepts. To some random person, learning about "one function one purpose" could be like learning random historical dates to me. "Why can't I just copy / paste the code? Why do I need good function names?" These people would have to discipline themselves and power through learning this stuff. But to me, I didn't have to discipline myself, because for some reason I was genuinely interested in writing "clean" code and making my development more efficient. This gave me an advantage. And there are people who love writing code more than I do, so when I get tired and brain fog after a couple hours they keep writing.
In my career, I've had the pleasure of watching a few developers go from enthusiastic newbies to great developers. I'd describe them as self-taught, but none of them developed the whole field of computer science by themselves. They got there by reading other people's code, by writing bad code and getting shown a better way, by reading books and articles and taking a few early CS classes. Of course, I know a few great developers who are older than me. They never made such mistakes or needed such help that I saw. But they were novices once, and they learned from others who came before them.
Nothing in the article contradicts your statement, IMO. Literally none of the things she mentions are things that are taught in school. She’s more stressing the importance of learning from peers, not some guru from on high.
"As she found one error after another, he became more and more amused, rather than more and more defensive[.]"
This has to be one of the snowballing keys to success. Soliciting and rewarding negative feedback, in a way that doesn't threaten the overall.
Works for bugs in code, also for life stuff. Being teased/mocked gives incentive and direction for positive change, so long as it doesnt send one spiralling.
Unambiguity about right or wrong is necessary here. It exists when finding bugs, but not in more subtle things.
For example, asking a junior for feedback as a friendly gesture and exposing him to an interesting problem. If he then takes the opportunity to one-up by explaining his naive opinions about irrelevant details, do you ignore him? He will experience it as being marginalised or "gate-kept".
The problem is that youngish guys have so much ego invested in feeling smart.
I don'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.
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'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.
Not saying that's the best environment for everyone, but it sure is for some of us.
There's a fine line between discouraging questions and making sure new people don't waste the veteran's time with dumb questions. I think a lot of people are scared away from the field because so, so many things in software either work or they dont, and it's pretty straightforward to verify it. When you're new to programming, most of the challenge comes from asking the right question and finding the best answer.
For example, "how do I sort a list of elements in python," which sounds very easy to answer, and it is for trivial cases. The complexity lies in the nuance of the question. For example, what if the list contains strings, numbers, and dates, and they were expecting it to sort by date? What if they need descending sort, not ascending sort? What if they need this for python 3, but they found a result for python 2, and they didn't even know there was a difference?
As you approach solving harder and harder problems in your career, of course you can't just ask google once click the first result, and copy paste the top answer. You need to ask google many questions, click through random forum posts from 12 years ago, read a few books on the topic, write a patch for a legacy package, try a few things, read the documentation, collaborate with other developers, etc.
I think the article is talking about something different, almost orthogonal.
The confrontational environments you've been in - did they carry with them the risk of losing everyone's respect, or getting fired / banned from community as a punishment for trying to talk without knowing your subject enough?
I'm gonna guess no. I've been in such confrontational environments (particularly around friends and colleagues in high school and on IRC) - we'd call each other out on their bullshit and overconfidence, but even the longest IRC flame wars were always on friendly terms. Direct, sometimes very heated, but always friendly banter. Such environment is also psychologically safe (at least for those who can handle the brashness), and is arguably very efficient at leveling up everyone's skill levels.
The problem really starts when you feel at risk of being punished for being wrong - when you worry that a mistake will cost you your job, or that people are judging your code and looking for reasons to push you out come next layoff round. That's what creates a lot of perverse incentives that impede the functioning of teams and companies.
You seem to be talking about bullshitting or posturing that more knowledgeable people find offensive. But asking a dumb question isn't like that. It might be annoying, but doesn't really anger people quite the same as pretending to know something you don't.
I'm with you – I want people around who can call me out when I'm wrong.
My read on what the author is saying: imagine if you or I didn't have anyone to call us when we don't know what we're talking about. Imagine if we didn't have people who would tell us that we were asking questions without doing due diligence beforehand.
That's one side of what it's like to work without anyone to give you useful feedback when you're wrong.
On the flip side, useful feedback doesn't need to be "smashing without mercy." It just needs to be direct and care about accuracy (e.g. Marilyn's review of Bill's code in the post).
I have some small issues with the introduction, but otherwise it's a strong article with many good points.
I particularly appreciate the whole section about "psychological safety". It resonates with me strongly. Thinking back to all the jobs I'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've been much shorter - if I was aware of this, and if my bosses were aware of this too.
I wonder how much of the "first 6+ months of a new engineer is sunk cost of onboarding" 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's one of the few times I noticed myself achieving a new level I didn't know I could reach.
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.
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.
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'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'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're in a rut.
This describes glimpses of a "state", not a process.
To feel "safe" asking dumb questions, you have to accept that the answer is often an irritated "RTFM". Accept first that the worst outcome is being ignored or sneered at, then you won't be so fearful.
Beginners who ask questions usually want affirmation and some sort of "experience of being a peer" or something like it.
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.
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.
If you learned programming on firmware, Windows classic (think Petzold), or Unix, things haven't changed in decades, so your knowledge fundamentally accumulates.
Not the foundation, your tools changes every 36 months. Your foundation is what makes you immediately recognise what paradigms and techniques are used in the new framework and at least have a hunch of the consequences it has for your project.
If you lack those foundations, it will of course feel like everything is new all the time, because you don’t recognise the patterns and you just see a lot of trees everywhere.
[+] [-] tarxzvf|4 years ago|reply
[+] [-] armchairhacker|4 years ago|reply
Like with research, nobody can take arithmetic and single-handedly discover calculus, number theory, and higher concepts. You're not going to discover good software development paradigms without reading about some of them. You especially can't write anything useful without using high-level libraries and working with others.
At the same time, I think intrinsic motivation significantly helps learning these concepts. To some random person, learning about "one function one purpose" could be like learning random historical dates to me. "Why can't I just copy / paste the code? Why do I need good function names?" These people would have to discipline themselves and power through learning this stuff. But to me, I didn't have to discipline myself, because for some reason I was genuinely interested in writing "clean" code and making my development more efficient. This gave me an advantage. And there are people who love writing code more than I do, so when I get tired and brain fog after a couple hours they keep writing.
[+] [-] klyrs|4 years ago|reply
[+] [-] actually_a_dog|4 years ago|reply
[+] [-] sdwr|4 years ago|reply
This has to be one of the snowballing keys to success. Soliciting and rewarding negative feedback, in a way that doesn't threaten the overall.
Works for bugs in code, also for life stuff. Being teased/mocked gives incentive and direction for positive change, so long as it doesnt send one spiralling.
[+] [-] yobbo|4 years ago|reply
For example, asking a junior for feedback as a friendly gesture and exposing him to an interesting problem. If he then takes the opportunity to one-up by explaining his naive opinions about irrelevant details, do you ignore him? He will experience it as being marginalised or "gate-kept".
The problem is that youngish guys have so much ego invested in feeling smart.
[+] [-] Galanwe|4 years ago|reply
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'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.
Not saying that's the best environment for everyone, but it sure is for some of us.
[+] [-] reidjs|4 years ago|reply
For example, "how do I sort a list of elements in python," which sounds very easy to answer, and it is for trivial cases. The complexity lies in the nuance of the question. For example, what if the list contains strings, numbers, and dates, and they were expecting it to sort by date? What if they need descending sort, not ascending sort? What if they need this for python 3, but they found a result for python 2, and they didn't even know there was a difference?
As you approach solving harder and harder problems in your career, of course you can't just ask google once click the first result, and copy paste the top answer. You need to ask google many questions, click through random forum posts from 12 years ago, read a few books on the topic, write a patch for a legacy package, try a few things, read the documentation, collaborate with other developers, etc.
[+] [-] TeMPOraL|4 years ago|reply
The confrontational environments you've been in - did they carry with them the risk of losing everyone's respect, or getting fired / banned from community as a punishment for trying to talk without knowing your subject enough?
I'm gonna guess no. I've been in such confrontational environments (particularly around friends and colleagues in high school and on IRC) - we'd call each other out on their bullshit and overconfidence, but even the longest IRC flame wars were always on friendly terms. Direct, sometimes very heated, but always friendly banter. Such environment is also psychologically safe (at least for those who can handle the brashness), and is arguably very efficient at leveling up everyone's skill levels.
The problem really starts when you feel at risk of being punished for being wrong - when you worry that a mistake will cost you your job, or that people are judging your code and looking for reasons to push you out come next layoff round. That's what creates a lot of perverse incentives that impede the functioning of teams and companies.
[+] [-] exporectomy|4 years ago|reply
[+] [-] TehShrike|4 years ago|reply
I'm with you – I want people around who can call me out when I'm wrong.
My read on what the author is saying: imagine if you or I didn't have anyone to call us when we don't know what we're talking about. Imagine if we didn't have people who would tell us that we were asking questions without doing due diligence beforehand.
That's one side of what it's like to work without anyone to give you useful feedback when you're wrong.
On the flip side, useful feedback doesn't need to be "smashing without mercy." It just needs to be direct and care about accuracy (e.g. Marilyn's review of Bill's code in the post).
[+] [-] wombatmobile|4 years ago|reply
. . .
> There is no apprenticeship for learning how to build Docker containers or dealing with prod outages.
Conversely, we could deduce that the way the industry works, employment in specialised IT teams is de facto apprenticeship.
[+] [-] TeMPOraL|4 years ago|reply
[+] [-] TeMPOraL|4 years ago|reply
I particularly appreciate the whole section about "psychological safety". It resonates with me strongly. Thinking back to all the jobs I'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've been much shorter - if I was aware of this, and if my bosses were aware of this too.
I wonder how much of the "first 6+ months of a new engineer is sunk cost of onboarding" pattern is caused by this - by employees fearing judgement and feeling they need to prove themselves.
[+] [-] xrd|4 years ago|reply
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.
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.
[+] [-] TehShrike|4 years ago|reply
I am where I am today because of my exposure to companies/teams that embody this environment
[+] [-] hnuser83742837|4 years ago|reply
[+] [-] yobbo|4 years ago|reply
To feel "safe" asking dumb questions, you have to accept that the answer is often an irritated "RTFM". Accept first that the worst outcome is being ignored or sneered at, then you won't be so fearful.
Beginners who ask questions usually want affirmation and some sort of "experience of being a peer" or something like it.
The safe environment that people think others are responsible for, is mostly internal in my experience.
[+] [-] mikewarot|4 years ago|reply
[+] [-] bsder|4 years ago|reply
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.
If you learned programming on firmware, Windows classic (think Petzold), or Unix, things haven't changed in decades, so your knowledge fundamentally accumulates.
[+] [-] Ma8ee|4 years ago|reply
If you lack those foundations, it will of course feel like everything is new all the time, because you don’t recognise the patterns and you just see a lot of trees everywhere.
[+] [-] draw_down|4 years ago|reply
[deleted]