But it isn’t 2013 anymore, Toto, so it’s probably not interesting to you what I read back then (honestly I don’t even know why you’re reading this at all). So let’s talk about…

If I were doing it all again today

I would replace W3Schools with MDN’s Learn Web Development — it’s great. But MDN’s search is as useful as a chocolate kettle, so you’ll want to complement MDN with devdocs.io. You’ll then have fast search returning MDN content. These two go together like peaches and pepper.

Advice: if you’re starting out and looking for reading sources, the above should keep you busy for a few months. I suggest that you finish it before reading any blogs or tutorials or anything based on opinion. More on that later…

Ice, ice, baby

A decision I made early on was to do everything the vanilla way. I figured that every minute spent learning jQuery or CoffeeScript or MooTools was time not spent learning the underlying languages. And I hoped that I would be faster in the long run if I knew every little corner of HTML/CSS/JavaScript. I’m pretty sure that played out well.

Advice: Go vanilla. Learn Node’s http before using express , learn fetch before reaching for axios , learn the joys of imperatively manipulating the DOM before using React. You’ll have both a better understanding and a better appreciation for the folks that write these libraries and give them to you for free.

Another approach I’m glad I took was to repeat things a lot. For years, I never created a new HTML file from a template, I would type out the whole thing every time, from <!DOCTYPE html> right through to </html> . Years later I would still be typing out every Webpack config from scratch. And to this day I will not copy/paste code from the internet, ever.

Advice: be repetitive. Throw stuff out and start from scratch. Now — in your formative web years — is not the time to come up with shortcuts to save keystrokes.

A little regret

About 6 months in, I decided I wanted to make a line chart to show the survival rates of DeathRabbit users. But instead of loser lines, I wanted splines. And I wanted to drag a point on a spline up and down to edit the underlying data (the stats for asbestos jobs were looking pretty grim).

I didn’t understand, at the time, exactly how difficult all this was.

I was committed to pure-vanilla, which meant writing complicated functions to calculate curves and output them as strings to set as the d attribute of a <path> , learning the NS variants of things like setAttribute , touch events, getting cursor positions, working out how to turn that back into data and redraw the line as I dragged the mouse.

It was incredibly time consuming and deeply demoralising. I struggled so much it stopped being fun — and normally I love biting off more than I can chew (you should see me eat, it’s quite the spectacle). I began to feel like I wasn’t smart enough for this whole programming game. I felt as though I’d overestimated my intelligence in general, for my whole life. And only now — when actually faced with a difficult task — did I realise the truth: that I’m just not that good. I probably would have scampered back to my old job at this point if I hadn’t left a little going away present in my boss’s top drawer 💩.

In the end (as you may have guessed) I got the draggable spline chart done. It felt so great I burst into my happy dance (which is the same as my sad dance, but much faster and with my eyes open).

So, all in all, 2013 was a pretty good year. I’d managed to stay focused and do a year full of 50-hour weeks. I knew how to arrange rectangles and words on the screen, do network things, database things, authentication things, how to deploy to a server and I’d even bought some hoodies so I could dress like a developer.

But cash was running low, and it was time to get a job.

2014

My first interview was not the fresh hell I was expecting. The company was looking for someone with consulting experience, of which I had plenty. I waved my arms around a lot in the interview and said lots of enthusiastic things about web development. It seemed not to matter that I had never been a web developer before, and I got the job. I was very pleased and on the way home treated myself to a ride down the street in a shopping trolley. I love that so much.

The work was good too: a lot of bite-sized, interesting projects that required a lot of learning on the job. Basically it was 2013 plus money and pants.

I didn’t want to call a complete halt to my structured study, so I started a habit that would last many years: arrive at work at 7am, read till 8am. Leave at 4, home by 5. From 5pm to 7pm: work on whatever my current pet project was. After 7: none of your business.

A solid thee hours a day of study; significantly down from the chock-full days of 2013, but I was learning a lot throughout the day, so I’d say the pace of learning stayed pretty high.

Advice: decide how much time you’re going to invest in learning each day and commit to it. Reward yourself when you do it. Punish yourself severely when you fail. 30 minutes is better than nothing. An hour is twice as good. The bigger the number, the better the developer you will be — there is no substitute for practice. IMO that’s the most important bit of advice on this page. I could afford 3 hours a day because I prefer being alone to being with people, and keeping busy is the only depression weapon that works for me. If you’ve got a ‘family’ and a ‘social life’, then perhaps you’ll have less time available for study. Sucks to be you.

Deciding what to learn

In hindsight, I worried too much about whether I should learn some particular API/technology/whatever. Which doesn’t make much sense when you think about it. It was the order in which I should learn things that really mattered. I got this wrong and dove too deeply into esoteric APIs, at the expense of more practical topics.

Advice: don’t think in terms of whether you should learn something. Think in terms of the order in which you learn things. Should you learn how the event loop works? Wrong question. Should you learn how Flexbox works? Wrong question. Should you learn Flexbox before you learn about the event loop? Good question. Yes.

A steady flow of info

Also in 2014, I signed up for JavaScript weekly, a great newsletter that I still read every week, along with several other excellent weekly newsletters from Peter Cooper and co. The great thing about these newsletters is that I can be aware of things, even if I don’t learn them. I have seen the rise of Vue, but have spent exactly zero seconds reading about Vue. I’ve read the title to 50 blog posts about React hooks, but have spent no time learning them. (I will when I need to.)

Advice: subscribe to these newsletters and read every heading every week. You’ll see tools and tutorials and every new feature of JavaScript, CSS, and I guess HTML too. Go now, subscribe.