And why it sucks to be a beginner today...
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 drastically becoming a software developer has changed.
Although the Internet has made our lives collectively easier, the dynamic of learning to program 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 Zuckerburg, it has never been cooler to be a software developer.
How the world views developers in the '90s and today:
If you're reading this, you may still 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 actually is listening and impressed.
While the image of developers has changed from some members of the general public -- 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 next latest and greatest programming fad.
A lot of progress is being made in the programming world, but in general there's not a silver-bullet single 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 that you probably will never see trend on HackerNews and 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 some stuff that comes up incredibly frequently on technical interviews.
The disconnect between "UnderbackJS" or whatever is listed on job postings today leave 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.
As 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 as 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 to know 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 with code reviews and communicating about code people can get up to speed. It's possible for people to learn what we as a community took a decade to figure-out in a short period of time in comparison.
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!
As a community we have 10-plus years of baggage we're lugging around. It makes it easy for us to have context about how the world has been 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 ok).
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 with someone who has much more experience than you. This causes beginners 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. It's nobody ever learns everything that they ever need to, and if that 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: Some of the most important lessons about programming you need to learn by messing things up big time.
If you've never made a mistake that brought some mission-critical software component screech to a 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 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 and mongrel.
But today:
Today: git push heroku master. Boom. Good to go.
While this sounds like things are easier than ever, side effects of the complexity of the systems that is abstracted away 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 charm, even on production if apache was setup 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 using 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 setup 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 those API keys you don't want to check-in. You should checkout 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 things a bit tricky to get a handle on. Rails is optimized for usability, not learnablilty, 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 people who have mastered arcane black magic. They see senior developers similar to how I viewed my parent when I was 5 year old: adults with super-powers 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 illuminating the right path and keeping them on track.
I'm lucky to be able to help people looking to enter the world of software engineering find the right path, and go from being super proud of solving problems like FizzBuzz to leveling up to solve traditional CS challenges like Depth First Search, Algorithms Reversing Linked Lists, and complicated Rails Apps, like this chess app, as a team.
I'm a code mentor at theFirehoseProject, and it's been an incredibly rewarding experience to take aspiring web developers under my wing, and to help beginners transition to a new career in web development.
Even though the situation beginners face when breaking into the world of development is radically different than the situation I faced when I was learning, the process is the same: Don't be afraid to break stuff.
This post originally appeared on Medium.