A Cautionary Tale of Learning to Code

How a reasonably balanced individual nearly went insane

I was just a guy in a suit in an office with a vague healthcare idea. Then I decided to learn to fix teeth.

I overheard some guy at a happy hour bragging about how easily he was able to automate his overbite by using a technique called "4 Handed Dentristry". I thought, "huh, 4 Handed Dentistry." I went home, googled it, and within 15 seconds, I was working through a random 4 Handed Dentistry tutorial.

A week later, I went to my first dentalspace meeting. Everyone was talking about techniques like orthodontics, endodontics, and maxillofacial surgery. There was so much to learn. I borrowed three O'reilly books and got about 50 pages into each of them.

Most dentistry books start off nice and easy before making big assumptions about your prior knowledge.

A friend told me I should get good at drilling, and gave me his drill bits. I spent a few hours learning basic foot controls so I could further configure it.

Then some guy walked by and saw me drilling. "Why are you drilling?" he asked me. "Don't you know lasers are better?" "Hm. Lasers." So I started memorizing dozens of laser shortcuts.

Most arguments about restoration techniques are what dentists call "religious wars" - rooted more in historical differences than practical merit.

At the time, it seemed reasonable to think that the faster I could drill, the faster I could fix teeth. I switched to a hydraulic drillset because, hey, it was objectively the most efficient method a dentist could use.

Can you count how many letters, numbers and teeth are in their original oral positions? I'll give you a hint - it's in the low single digits.

On the days I could actually get my netbook to successfully boot DentalCAD - and that I was able to drill more than 10 teeth per minute - I studied oral surgery by working through books and Udacity courses.

After 7 months of grueling self-study and going to dental events, I landed my first Dental HMO job...

You kinda get the idea by now? I dunno, I think what we do is every bit as professional as dentistry. So why don't posts like OP's seem as absurd as mine?

[UPDATE: For those of you who have suggested that programmers don't have others' well-being in their hands, actually quite a few of us have, just not as directly as dentists. We are a profession and we do do important work. A few examples in an old post: https://news.ycombinator.com/item?id=2882620]

He shouldn't be taking random advice to learn emacs/VIM from people, or use a new keyboard, or (a lesser extent) a new operating system. He needed a guiding instructor to tell him to learn how to code first and focus on building projects instead of trying to turn a 3-5 year education into a 1 year accelerated course so he can be like the cool kids.

I'm self-taught as well, so I'll never say university or professional accreditation is the right answer. But that doesn't mean we should be without effective mentors.

Speaking of which, I've been meaning to look into mentoring...

Technical people are, necessarily, very adamant about the technologies they use. When you're first starting out, you just want the "best."

Among the most common misunderstandings for non-technical people is what a programming "language" is. You don't realize that almost all programming languages are made up of very similar constructs. For example, knowing what I can do with a string in JavaScript and transferring that knowledge over to Ruby is a thirty second, syntactical exercise. Non-technical might imagine that you have to learn everything over from scratch. That's probably a result of etymology; when you hear the word "language" you think Russian vs. Spanish - completely different alphabets, concepts, grammar structures, etc. It would make more sense for those who can't program to think of it in terms of "dialects" or something like that, instead of "languages."

It doesn't actually mater what language you learn first, even if it's (god forbid) PHP. But we don't tell that to would-be programmers enough.

I probably wasted a month of my time because I started using zshell and oh-my-zsh on the recommendation of some guy I talked to at a meetup. He loved a tiny aspect of the flexibility of the prompt's highlighting. I barely knew how to use the command line. So heaven knows I didn't understand what happens to my $PATH when I'm dropping whatever the github repo is telling me to into ~/.bashrc instead of ~/.zshrc.

The time I really started to learn was when my company got into an accelerator, and all of the sudden I was the de-facto front-end guy. The only CSS I had ever written was tweaking colors on my blog, and I really had no idea what I was doing. But that didn't matter - I had to build, and it was a real project -- one that was seen by 10s of thousands of people on day one. It doesn't have to be that stressful to learn, but you have to build something and solve challenges learning along the way. There's really no other path that works.

So, my advice to budding programmers or those who may learn to code: Pick a language/framework and don't move on until you are fairly adept with that stack. Your tech buddies may mock your technology choices, someone will say you're an idiot because "this would be so much cooler in Lisp," but you don't have to be writing functional Haskell when you're learning to program. Take things form beginning to end, start to finish, and start changing technologies once you are well versed enough to understand the shortcomings of what you're currently using.

I really wish someone had sat me down and told me that when I started. I'd probably have saved six months of after-hours and early morning struggling.