Becoming a Dev

Several people in my life have pulled me aside and asked me, “What can I do to become a developer? Can I do it without getting a degree?”

I usually have a rambling unhelpful answer readily available. When one of my brothers asked me, I came up with some more systematic answers, but it didn’t seem like enough. Then a good friend of mine from college reached out, and I couldn’t bring myself to fire off a bunch of useful thing to self-learn without some context and structure to it–because I believe he’ll actually do it.

Most people could become software developers if they wanted to.

Degree?

I borrowed and begged about $100,000 to learn the basics, build some connections, and received a ticket to my first software engineering job. Redeemable once, no refunds. Computer Science was one of six career paths I was considering, but the lab fees were cheap, and I found a lot of joy solving problems with my mind alone. I blindly stumbled into a great career filled with intelligent and driven people solving the world’s problems.

Is a degree worth it? I’ll never know. After 2-5 years, no one remembers the degree–they see your work and growth. Software changes constantly, so the people who learn to adapt and teach themselves have the advantage.

Skills

You’ll need some skills, some experiences, a dash of lingo, and some interview practice. After your first job or two in software, (if you continue to be thirsty for knowledge) you’ll be on par or better than your peers.

Be a generalist at solving problems with a wide toolbelt–it will make you resilient to changes. Later, if you want to specialize in a technology you love, you can. These are my top picks for a generalist. Yes, all of these.

This list is not the teaching, if you don’t know what I mean by a term, research it until you understand what it means in the context of a web application. The primary skill of a software developer is to ask questions and sift through google results until you have better search terms to ask. Start now.

Front End

Front end development is all the stuff that runs in a browser (typically). Become familiar with HTML, CSS, JS. These are the basics fo the internet. If you’re fuzzy on how the internet works, brush up on that via YouTube/KhanAcademy. After the basics, learn how to use React, it’s a modern framework that uses Javascript to build powerful, modular components.

Back End

Back end development is all the stuff that runs on the server. Traditional servers will likely run Java (or something like it). Learn the basics of Java as a standalone application (no GUI to save time) and as a webserver (on Apache Tomcat?).

Or skip Java and just learn NodeJs. A lot of modern servers run Node. Node is also easier to learn because it’s Javascript for the server instead of for the browser.

If you do skip Java (or even if you don’t), learn the concept of object oriented design and become familiar with all the terms so you can use them in a conversation comfortably.

Learn MySQL and Mongo. You have to put data somewhere eventually, so you need to learn a database. MySQL is a structured database, similar to many others (the most popular being SQL). Mongo is a non-structured database more often called an object store. Learn the difference and how to plan data for both. Learn what an index is, how to query, make tables, modify tables, etc.

Tooling

Development is about getting or building layers of abstraction to get more work done faster. There are a few very common tools you should learn along the way.

Bash (the Bourne Again SHell) is a terminal language. Learn how to write basic scripts as you’re learning the Linux commandline (pdf)

Do all your projects in Github. Start an account, make projects public, track issues, make branches, ask peers for help/contribution. Github is how developers collaborate and store code. This is also where you’re going to find a lot of examples and help (next after Stackoverflow anyway).

Learn a bit of Python. Learn enough to automate some processes and make your life easier, but not enough to become a crazy python scripter in a basement. It’s a powerful tool for automation, and you need a scripting language. Bash is garbage as a scripting language, but it is required in more pinches than I’d like to admit.

Principles & Other

There are a bunch of other concepts and categories that you should become familiar with. Don’t dedicate your life to these, but spend an afternoon reading and familiarizing yourself with the concepts so that they’re familiar.

• OAuth - how to do security. Never ever write your own, always use an existing solid library
• Design - look at how different companies do software design as a process
• Scaling - how do you scale a webserver?
• Code review - what does a code review look like? how can I welcome changes to code I worked so hard on?
• Testing - how can I automate testing? what are mocks? what frameworks make this easy?
• Agile development - what is agile? why doesn’t anyone actually do scrum?
• SOLID - read and understand the SOLID Principles
• Design Patterns - what is a design pattern? why are they useful?
• AWS - what does Amazon have to do with servers? do a few lambda tutorials, maybe serverless
• Rest - build a Rest endpoint, read rest-ful principles
• GraphQL - why is graphql gaining so much popularity? make a graphql endpoint

It is one thing to follow a tutorial blindly, it is another to understand it. Seek to understand it.

Experiences

Knowledge is one thing, but companies want to know that you can apply your knowledge. The nice thing about applying it, is that you learn as you apply it. If you don’t enjoy the process of learning it, software is likely not for you–it doesn’t get better, it’s gets more of the same. The thrill of learning and applying new pieces to a big problem is the job.

Create your own github projects to solve problems. Make new projects and pick your favorite tools in the list above to automate something, build a website, or solve a real problem. It’s ok if you’re reproducing something that’s already been made, you’re learning and demonstrating. Employers do look at your github projects.

Find an open source project you care about and learn how to contribute. Find a trivial bug or typo in their issues log and solve it for them. Then pick up something a little more challenging. This will exercise your ability to collaborate, solve, test, and contribute–all things employers care about and useful skills to make yourself better.

Interviews

Read The Ideal Team Player by Patrick Lencioni, this is what employers are looking for: people who are humble, hungry to learn/grow/contribute, and socially smart/competent. Basically, will you help them build something great, and do you play nice with others?

Research the company and bring no fewer than 10 serious questions you couldn’t answer with their website (technology, profitability, specific culture questions, work-life balance). Ask good-fit questions not benefits questions, you’ll get those in the offer package if they offer you a job anyway. Surprisingly few interviewees have any questions, and fewer still have good questions. In your research find out what processes, technology stack, hierarchy, recent newsworthy things. Bring your notebook.

If they ask you questions about technology/concepts you don’t know, write it down to study up on later–and tell them that’s what you’re doing. It’s an opportunity to grow and learn more.

Thank them for spending time with you. It costs them a lot to put work aside in order to have multiple conversations with you–especially if you’re not a good fit.