If you, like me, became a software engineer before the Internet was at scale— back in the good-old-days when AOL was spamming our physical mailboxes with CDs —  you may not appreciate how becoming a software developer has dramatically changed. Although the Internet has made our lives collectively easier, the dynamic of learning to program is totally different from when I was starting out.

When the heck did learning to code become cool?

When I was teaching myself to program in high school, the attitude people had was, “that’s just because Ken sucks at football,” not that I was some kind of glamorous rock star.

With the prevalence of social media and the epic rise of companies like Instagram and “tech celebrities” like Zuckerberg, it has never been cooler to be a software developer.

How the world viewed developers in the 90’s and today:

If you’re reading this, you still may not believe me when I say in certain circles, it’s very cool to say you can code. If you don’t believe me, there are a bunch of talks on YouTube where you can watch people brag about how awesome they are because they can code, to an audience that is actually listening and impressed.

While the image of developers has changed— and I don’t have to feel embarrassed telling people I program computers for a living anymore— beginners that are looking to become software developers face a whole slew of problems that I never had to face.

Problem #1: You NEED to Learn HTML9 Responsive BoilerStrap JS (or whatever JS Framework is trending today on HackerNews)

There’s a lot of hype out there about the latest and greatest programming fad.

A lot of progress is being made in the programming world, but in general, there’s not one, silver-bullet technology someone can learn that will immediately cure all their problems.

Beginners are often encouraged to start digging into solutions for problems they don’t understand yet.

The hype can cause someone to try to learn about things like the Virtual DOM, or Shadow DOM, before they even understand what the regular DOM is. When beginners are starting out, there isn’t a lot of talk about “learning to crawl before you learn to walk.” Instead, there is a lot more about the latest and greatest fad.

As a seasoned web developer, I love playing with these new technologies as they come out, but I know that it’s important to use the right tool for the job. Beginners often feel like learning how to fit a square-peg through a round-hole is the fastest way to level up their coding skills.

In the grand scheme of things, learning the latest trend isn’t important. Nobody is really saying this explicitly to the community.

Problem #2: Fundamentals Aren’t Sexy

Here’s a list of things you probably will never see trend on HackerNews that are also seldom put in most job postings:

Data Structures, Linked Lists, Trees, Depth First Search, Floyd’s Cycle Detection Algorithm.

However, it’s also a list of stuff that comes up incredibly frequently on technical interviews.

The disconnect between “UnderbackJS” or whatever is listed on job postings today leaves beginners thinking they need to chase and catch up with the latest trend to get the job, not get a solid foundation in what really matters.

The “Learn to Code Community” is very much an echo chamber that can confuse beginners. Unfortunately, people with years of experience communicating with other seasoned developers don’t realize what they say will likely be taken out of context by beginners.

For experienced developers, most of the time we care more about a solid foundation and analytical skills, rather than experience with the specific tools of the trade. Having hired many solid engineers who learned the specific technologies on the job, knowing specific stuff is generally overrated.

Problem #3: People (Kind Of) Know What They Are Doing Now

I wrote some seriously bad code on my first jobs as a web developer. Frameworks were just coming out and everyone had been developing in either PHP or CGI. This whole framework thing was relatively new, so I started on relatively equal footing with everyone else.

I made every mistake in the book, and my second job in web development had me asking questions like, “what the heck is a unit test?” Live and learn. The developer in me is a little bit afraid that a lot of the code I wrote long ago when I was starting out is still alive in the wild.

But now, people have been writing web applications for many years and have developed a lot of best practices. On the one hand, this means that code reviews and communicating about code have allowed people to get up to speed. It’s possible for people to learn in a comparatively short period of time what we as a community took a decade to figure out.

On the flip side, it’s a bit overwhelming to try to fully grok some of the nuances that the community currently talks about. Things like:

• Monoliths are great!
• Microservices are where it’s at my friend!
• Microservices are overrated. Monoliths are back in vogue!
• Turbolinks?

As a community, we have 10+ years of baggage we’re lugging around. It makes it easy for us to have context about how the world was in the past, but hopefully the beginners of today will never have to muck through a big shitty monolith similar to what I was building in 2008.

Problem #4: People Still Have No Idea What They’re Doing (And That’s Okay)

When starting out, it’s normal to compare yourself to other people, but in general, doing so is a bad idea.

It’s hard to compare yourself to someone who has much more experience than you. This causes beginners to often think to themselves:

When am I going to learn everything I need to know? I still feel like there’s a lot out there that I need to learn.

The answer of course, is a hard one for them to fully appreciate. Nobody ever learns everything they will ever need to know, and if it ever happens that you’re not learning something new every day, it’s time to look for a new and more challenging set of problems to tackle.

Watching talks by Aaron Patterson where he dives into Ruby’s C source code, or using RubyVM::InstructionSequence to figure out what happens under the hood or how journey implements routing in rails with finite automata instead of regexes still melts my face. Watching those talks is a good reminder of how clueless I am about the inner workings of a lot of things…

Problem #5: You need to learn some of the most important lessons about programming by messing things up big time.

If you’ve never made a mistake that brought some mission-critical software component to a screeching halt, you’ve never really been under the gun to fix things. If that’s the case, there are still lessons to learn.

Non-technical people walking to your desk to tell you about some problem you already know about teaches you a lot. Especially if you are busy desperately trying to fix it. Books can’t teach these kinds of lessons.

Problem #6: Systems Have Gotten Complex

Here’s an example of how things have gotten more complex with Ruby on Rails:

In 2008: In order to have your site live on the Internet, you needed to spin up a server yourself and configure all the components: apache & mongrel.

But today:

Today: git push heroku master. Boom. Good to go.

While this sounds like things are easier than ever, it is only because the complexity of the systems is abstracted away, and side effects quickly come up.

Take this example back in 2008:

In 2008: To get image uploading working in a project, you needed around 5 lines of code in a model, which on a request, would copy the multi-part form data into a file on the system’s hard drive. This worked like a charm, even on production if apache was set up properly.

Or today:

Today: It takes one line of code in your model, after integrating with something like carrierwave/paperclip, which does all the stuff you need to get file uploading working. This one line is kind of magic, but it gets the job done.

Unless you’re on heroku— heroku is nice and scales horizontally easily for us, but this causes the use of the filesystem for image uploading to fail in this case.

 

That means if you’re on heroku, you should probably use AWS as a storage layer. It’s pretty easy to set up AWS; all you need to do is click around the UI. When you sign up, you need to enter a credit card and they’ll verify your phone number by calling you, but they won’t bill you for your first gigabyte. Promise.

 

After you create a user group and a policy and roles by clicking around 10 or so pages on the Amazon site, you can create a bucket and get your Amazon API credentials.

 

Oh yeah. Your app is probably on GitHub as a public repo too. That means you don’t want to check-in those API keys. You should check out the figaro gem. It’s a real great way to store things in your computer’s environment variables. What are environment variables you ask? Let me tell you…

Each of the incremental steps in the right direction has made it a bit tricky to get a handle on things. Rails is optimized for usability, not learnability, because building real apps in the real world is complicated. This is a great thing, but feeling a bit overwhelmed by all the stuff out there is just part of the learning process these days.

———

In retrospect, when I was starting out, my biggest problem was that I had too much bravado and a lack of self-awareness about how much maturity actually mattered.

Today, the opposite is true for people starting out. They often view people with years of experience like they have mastered arcane black magic. They see senior developers similarly to how I viewed my parents when I was 5 year old: adults with superpowers that I’d never get.

But in other ways, the path to becoming a solid software engineer is the same. People starting out just need a little light to illuminate the right path and keep them on track.

Even though the situation beginners face when breaking into the world of development is radically different than the one I faced when I was learning, the process is the same: don’t be afraid to break stuff.

What helped you the most when you first started coding? Get in on the conversation on Facebook, and share your personal experiences and advice!