Learning to program with a purpose
Back in 2003 was a great time to start learning web development. At the time the landscape was very simple, there wasn’t seemingly thousands of languages and technologies to pick from to start building something. Dynamic websites usually deferred to either PERL or PHP, that was it.
With time, though, other languages started also gaining a lot of traction. Ruby (with a good amount of help from Ruby on Rails) became a hugely popular language for developing web applications. Frontend development started growing bigger roots in web development cycles. You had jQuery, MooTools, Scriptaculous, etc… to allow a modal appear to confirm an action. Database wars were waged over schemaless vs relational. Javascript, initially a frontend only language, has become incredibly prevalent in the backend of many websites. Companies now package software in container images. And now we decided to forgo long lived processes entirely and use Functions as a Service.
A beginner that wants nothing more than to say “Hello World” through a browser window has to duck and dodge through opinion overload nowadays. The only thing that matters when you’ve just left tutorial island is to just to start. Pick a technology and run with it.
3 Pieces of Advice
Web Development can be an incredibly rewarding skill to obtain and further throughout the years. It’s constantly reinventing itself as the years move on. I still remember times when I would skyrocket out of my desk chair when I would get an ambitious feature working after days of toil and google searches scattered across my browser tabs. With that said, I’d like to look back and derive 3 concrete pieces of advice for you if you’re jumping into this world.
Opinions can be trip wires
Take every opinion you hear with a grain of salt. You’ll read a blog post saying “Develop this way!”, meet someone at a meet up town crying “Use this technology!”, or even “That language is terrible!”. The opinions in the early stages of a developers career are nothing but noise in many ways. Eventually you’ll have so much contradiction with which language to use or software design you’ll struggle to pick one and eventually just end up doing nothing, or worst, a weird hybrid. To effectively learn and acquire experience, avoid analysis paralysis at all cost and just build something, anything. It’s not for them, it’s for you. Experience isn’t know what to do, it’s knowing what not to do. By that definition, you need to build things that sputter or explode completely. If I’m honest, this is the honeymoon stage of programming. Building without consequences should be cherished.
Existing Websites are just a template for you
Please stop worrying about being a copycat. If opinion overload doesn’t stop you, odds are you’ll sit down and just wonder to yourself “what unique idea can I build right now?”. Only to find that you get writers block. By the time you get a name chosen you look outside to see it’s dark out. To avoid this, pick something that exists already and just build that. Twitter, Pinterest, CatFacts, etc, are all fine to build. The reason I give this advice is simple: odds are whatever you’re building will never make it into a production environment that people use when you’re just getting started. These early projects are for you to gain experience. One other reason I like this piece of advice is that you don’t spend time trying to figure out what features to build. They’re right there already! You have an example that is already built and functional.
While we teach, we learn
My last piece of advice is to write about your experience. Medium is a great platform for writing about software. Write a tutorial on how to vertically align something using CSS. Not because the tutorial doesn’t exist but because teaching others solidifies your own knowledge. Or put by Seneca, “While we teach, we learn”. Early in my career I wrote tutorials by scrapping together other tutorials from around the internet. I still remember over a decade later some of the silly nuances of problems such as CSS vertical alignment merely because I wrote a 250 word tutorial on it.
The TL;DR of this post could be summarized as “Build for you and no one else when you’re just getting started”. It was easier 15 years ago because the fact of the matter is early learners didn’t have the problem of opinion overload and analysis paralysis. The only option was to build and not look back.
My name is Robert Ross, but people like to call me Bobby Tables. I’m a full time software engineer during the day and a tutorial enthusiast at night on Blindside.io. I’m building a Ruby on Rails application from scratch and recording the whole thing, check it out!
