Hacker News new | ask | show | jobs
by JohnCurran 1883 days ago
This line in the opening paragraph really rubs me the wrong way:

> “I'm ashamed to say most of my Elixir education has been through trial and error, figuring things out as I go along“

This attitude is so prevalent in software as if we are all supposed to be divined with programming knowledge the moment our IDE spins up. In every other industry that’s exactly how you learn: Get your hands dirty, make mistakes, and fix them.

There’s a lot of things wrong with software engineering - harboring this attitude that self-taught learning is bad or shameful makes it unnecessarily worse

Great write-up otherwise

6 comments

There's a middle ground between (relatively) blind trial and error and being divinely granted insight. Deliberate reading of documentation (be it API, language standard, books, tutorials (better ones), etc.) lets you learn without just trying things or piecing a theory together from examples (underdocumented ones that don't explain the why of their choices).
you could also pay for education, attend workshops, code projects on a team, etc.
OP here -- I know what you mean. "Ashamed" is probably too strong a word. I think the feeling I was trying to convey was just that I'm not exactly an authority on Elixir, so take everything I say with a grain of salt, and nitpick away :)
I know the feeling though, sometimes it feels like other people's code just comes in to being immaculate and pure, while I just beat my head against the keyboard until one of us gives up.
Self-learning is one thing, but uninformed trial and error based on a lack of research is another beast entirely.
> There’s a lot of things wrong with software engineering - harboring this attitude that self-taught learning is bad or shameful makes it unnecessarily worse

This is an interesting question.

There's nothing wrong with being an autodidact, per se, but in my experience in hiring people and working with autodidacts: Autodidacts are not very good at recognizing their own limitations[0] and they usually do not have a lot of breadth of knowledge outside their area of interest. This can even go so far as not knowing that there is such a thing as "Entire Field of Study Foo". (Let's say Foo is Discrete Mathematics.)

Will they be bad hires? It depends on what you need -- and they can absolutely perform as well or better than any "more educated" person. It very much depends on the actual person... as almost all work does.

[0] This explicitly ties into the second point about breadth of knowledge. It's about knowing what you don't know and are willing to research further. The problem with autodidacts is often that there's such an insane leap from "oh, i know this" to a seemingly totally unrelated field which has deep connections to what you're doing. That's what a "broad" education in CS is there to teach you. Are you going to use all of that? Hell no! But just maybe that 5% you do end up using makes up for the 95% you don't.

It's not about being self taught, its about the phenomena of dabbling around a conceptual component in aOS/Runtime/Framework/Language that you aren't quite ready to commit to fully understanding and you just want to know enough to get something done. Quite often, this is a pragmatic choice, but if the thing you are dealing with is a central part of your system, then this becomes untenable long term. Unfortunately this is actually semi common and some very strange software gets written because things weren't properly understood. This article is the authors commitment to learn one of these concepts.
Do you think that you can install a gas turbine the wrong way start it up and fix it later?
Like most things, you build up to it.

You start software development with "Hello, world!" and then you do more, like getting input from the user, storing it in a variable, then eventually you're using classes and working with objects, then you're tying together a bunch of classes and working with APIs.

No one just "studied" how to create a gas turbine and wah-la, it was made. The entire process of literally everything was one learning exercise after another. We started by using rocks as tools. Here we are, having built better tools from experience and a lot of trial and error and fooling around with things.

Hell, Lego are the same exact idea.