When I first got started as a software developer, I had no idea what I was doing.
I was also frustrated. Nothing seemed to make sense, and I didn’t think I’d ever “get it.”
The reason I’m telling you this is that if you have pick up my book, you might feel that exact same way.
Don’t worry, this is normal. In fact, it’s natural.
When you first get started in the field of software development, if you don’t feel overwhelmed and like you just jumped into the deep end of a pool with weights tied to your ankles, you are probably either doing something wrong, or you aren’t human—maybe both.
Anyway, you should expect it to be difficult and confusing starting out, but it’s not always going to be that way—I promise.
How I Started Out
I downloaded the source code from a popular MUD. (That’s a Multi-User Dungeon. Think World of Warcraft, but no graphics—just text. Yes, this was in the “dial up to a BBS system using a modem” days.)
I didn’t even know what I was looking at. All I knew was that I wanted to create my own version of a MUD and add my own features, and the key to doing it was somewhere buried in this pile of strange cryptic strings.
I started messing around. I changed variables to different values. I looked for some code that seemed to control the odds of getting a critical hit on an opponent. I changed it, recompiled the MUD, and saw what happened.
Sometimes it did what I wanted. Sometimes it didn’t even compile. As I saw what worked and what didn’t work, I learned.
I still didn’t know what I was doing, but within a week or so of tinkering around with the code, I had managed to create a version of the MUD that actually had some of my “features” in it.
A long way from becoming a proficient programmer, but it was a start—we all need a start.
The reason why I am telling you this story is because, more than picking up a textbook, more than going to college or a boot camp, more than anything else… I believe this is the way to get started programming.
You have to tinker around and see what works and what doesn’t. (I believe this is the best way to learn, period. See my section on Learning Quickly in Soft Skills: The Software Developer’s Life Manual.)
But learning to code and learning how to get started in the world of software development are two very different things.
Yes, you need to learn how to code, but there is much more to it than that, and this is what this chapter is all about.
Learning About the Profession
First of all, you need to know something about developing software.
It’s both easier and harder than you think.
A whole section of this book is dedicated to the idea of “What You Need to Know About Software Development,” but I’m going to give you a quick overview here.
Software development isn’t just programming. Programming is a large part of it, but just knowing how to code isn’t going to take you very far—especially if you want to make a career out of this vocation.
The idea behind most software development projects is to automate something that is currently manually done in the world, or to create a new automated way to do something that was too difficult to do manually.
Think about the word processing software I’m using right now. I happen to be typing this post using Google Docs.
Without Google Docs or other word processing programs, I’d have to either type this document on a typewriter or hand write it.
If I wanted to format the document to print it, I’d have to manually typeset the letters to be printed.
If I wanted to fix mistakes—especially spelling errors—I’d need to keep a bottle of whiteout nearby. (And probably a bottle of whiskey as well.)
Now it’s not just Google Docs allowing me to do all this. There are a bunch of hardware and software programs involved that allow me to take the manual process of typing or handwriting a book and automate it, but I think you get the point.
Therefore, let me emphasis to you a key concept that you should learn as early as possible as you embark on this journey to be a codeslinger.
You have to be able to manually do something before you can automate it.
Gathering Requirements
Too many aspiring—and experienced—software developers try to write software without fully understanding what it is supposed to do. They want to just jump right in and code.
Obviously, you are smarter than that, since you are reading this book.
The process of software development always begins by first understanding the problem to be solved. What are you automating?
Different software development methodologies do this in different ways, but that’s not important to focus on right now. Right now, the point is that you have to, in some way, gather some kind of requirements and understanding of the problem being solved before you can write any code.
This might be as simple as talking with a potential customer and discussing what needs to be built and how it should function, or it could be as formal a creating a fully documented specification.
Design
Once you achieve that understanding, you then come up with some kind of design of how that problem is going to be solved in code—again, before any code is written.
Think of this as the architectural blueprint for your code. Once again, different software development methodologies handle this in many different ways, but what is important is that you have some level of design before you jump in and start coding.
This applies at the large scale and the small scale. Some developers that learn about Agile software development (we’ll talk about that in a later chapter) think they don’t need to design anything, that they can just start coding right away. While Agile development focuses on less up front design, design is still necessary.
You don’t build a house by randomly just nailing two-by-fours together.
Writing the Code
Once you have some idea of the design of the software, it will be time to either write some tests that will define what the software is supposed to do (also known as Test Driven Development or TDD), or it will be time to get started coding. (We’ll discuss TDD more in later chapters.)
Writing code is a discipline in itself, so we won’t be getting into that here, but I’ll recommend two great books on writing good code that you should definitely read.
First, I recommend Code Complete by Steve McConnell. This is a classic book every software developer should read.
The second is Clean Code by Robert Martin, another classic book which will help you learn to write better code.
These books will help you learn how to structure your code and how to write code that is easy to understand and maintain.
Both of these books had a profound impact on my coding skills, especially in regards to clarity and design.
Testing and Deployment
So, once code is written, we ship it, right?
Wrong. Now comes the process of testing the code. Again, different methodologies are going to handle this in different ways, but in general, some kind of testing has to happen before the code is released to the end user.
For example in traditional, waterfall development projects, testing happens at the very end of a project, but in “agile” projects, testing happens during each iteration, which usually last about 2 weeks.
Once code is tested, it’s ready for deployment, which may be a whole process in itself.
We don’t get into the details just yet—there will be a whole chapter on this topic—but deployment is the process of getting the finished software installed on a server, put into an app store, or made accessible in some other way to the users of that software. (And that process can be quite complex.)
Along the way, code may—ahem, should definitely—be checked into source code repositories where different versions of the code and the changes over time are stored.
In most complex applications that deal with any kind of volume and data, there is also likely to be some kind of a database involved.
The database typically will store user data for the application or configuration information and it may also need to be updated along with the source code.
Many software development teams use some form of continuous integration to build the code automatically when developers “check in” parts of it.
More to Writing Code Than Just Writing Code
And finally, let’s not forget debugging. As a developer, a large amount of your time is going to be spent figuring out why your code—or someone else’s—doesn’t work.
As you can see, there is a lot more to software development than just writing code.
You’ll need to be aware of all of this stuff before you can get a real job as a software developer. Hopefully, you’ll have at least some experience and skills in a few of these other proficiencies as well.
But fear not. The purpose of this book is to prepare you for all that—or at least spin you around and point you in the right direction. You might need to fill up the backpack with all the supplies you need for yourself, but I’ll at least tell you what to pack.
Having a Plan
Ok, John, I get that software development is more than just writing code and that I’m going to spend a lot of time debugging things, but you still haven’t told me how to get started. What gives?
Ah, yes. I see your point, but guess what? Here is the good news:
You’ve already gotten started. Congratulations.
By picking up a book, like this one, and actually trying to understand that software development is much more than just writing code, you have a better start than most software developers will ever have.
Ok, yes, yes, I know that was a bit of feel-good fluff, but it’s honestly true as well. Someday when you get to be a grouchy old software developer like me, you’ll be preaching the same thing.
Now, on the more practical side… you need a plan.
Yes, a plan. A real, actual, no-BS plan for how you are going to go from knowing nothing or next to nothing about software development to a full-fledged software developer.
There are many roads you can take to get there—I’ll be covering some of them in the upcoming chapters—but what’s important isn’t so much what road you take but rather that you pick a road and stick to it.
Putting Together the Plan
Let’s talk about what your plan should entail.
First of all, you need an honest assessment of where you are right now and what things you are going to need to learn.
Do you have any programming experience?
Do you know any programming languages?
Have you ever built an application, or are you starting completely from the beginning?
What about all these other skills I talked about earlier?
Do you have any of them?
Do you know anything about databases, source control, TDD, testing, debugging, or software development methodologies?
Also, ask yourself what kind of software development you want to do.
Sure, everyone wants to be a game developer, but is that practical? And is that where you want to start? Are you willing to put in the long hours and fight with all the competition you’ll face going down that long and lonely road?
So many people set off in a direction in life but don’t think things completely through first.
Take some time to answer these questions, so you’ll be able to come up with a good plan for getting started.
Don’t get me wrong. I’m going to help you as much as possible in this book, but I can only take you so far.
I can give you all the information you need to become a good, even great software developer, but you are going to have to organize it into an action plan that is tailored to you. And then you are going to have to follow it.
Creating the Plan
Once you’ve thought about these questions for a bit, it will be time to develop an actual plan.
The best way to develop your plan is to work backwards from the goal you want to achieve.
Rather than “learning to program” or “becoming a software developer,” you should come up with a specific goal of the kind of software developer you want to be.
In the “What You Need to Know About Software Development” section of this book, I’ll be covering the different kinds of software development roles or jobs you might want to consider, but you can also do some research on your own to determine what best fits you.
You want to be as specific as possible, so that you can know exactly what it is you need to learn, how you want to craft your resume and portfolio, what schools or programs you might want to enroll in, and even what jobs you want to apply for.
I know it’s difficult to make a decision and make a commitment, but I can’t stress enough just how important this is!
The more specific you are about what kind of software developer you want to become, the easier EVERYTHING is going to be.
You’ll be able to clearly know what it is you need to learn and what you need to do for every step of the way.
Who Wants to Be an “Athlete?”
Think of it this way: suppose you wanted to be an “athlete.”
That is pretty dang broad. How should you train to be an “athlete?”
Maybe you should lift weights and run, but maybe you should practice swimming. Maybe you should hit a ball with a tennis racket.
Better do all those things and more, so you are prepared for any sport that you might end up getting on a team to play.
See how ridiculous that sounds?
That is how ridiculous—in fact even more so—it sounds when someone expects to be a “software developer.”
Instead, pick your sport.
Once you know the sport, you can know how to train for that sport and that will make your life much easier—trust me.
Start with the goal and works backwards to determine what you need to know and do in order to reach that goal.
Once you’ve done that, you can work out your plan.
The beginning of your plan should be all about what you need to learn. Figuring out the order of what you need to learn and how you are going to learn it is important.
Then, you should be figuring out what you will need to do to prepare for getting your first job and applying for jobs.
Finally, you need an actual plan for getting the job. Where are you going to look? What are you going to do? What kinds of jobs are you going to apply for?
I’d probably also add a plan for how you are going to continue your personal development and education after getting your first job.
A little overwhelming, I know, but don’t worry. The reason I wrote this book is to make all that easier for you.
In the next few chapters, I’ll be helping you figure out what you need to know and how to gain that knowledge, and in the following sections, I’m going to give you the details about how to get a job.
For now, you can start thinking about what your plan is going to look like, and try to figure out what kind of developer you want to become.
A Concrete Example
I always find real examples useful, so let’s look at a realistic scenario for someone who wants to become a web developer utilizing Node.js as their primary technology:
Goal: become a Node.js developer.
Plan:
Learning
- Learn the basics of JavaScript.
- Learn about web pages and web development technologies like HTML and CSS.
- Learn the basics of Node.js.
- Be able to write some kind of simple Node.js web application.
- Learn about the different frameworks and technologies developers use to develop Node.js applications.
TO-DO:
- Fill in some frameworks or technologies to use with Node.js from research above.
- Learn some kind of database technology to use with Node.js.
- Learn computer science basics:
- Algorithms.
- Data structures.
- Learn best practices for writing good code.
- Learn how to design the architecture of a Node.js app.
Preparing for Getting a Job
- Start looking at job descriptions for a Node.js developer in my area and find out what skills employers want.
- Come up with a list of companies, locally, that I can likely get a job at.
- Start attending user groups in the area.
- Start networking with other local Node.js developers.
- Hire a resume writer to help me write a good resume.
- Practice coding interview questions.
- Practice mock interviews.
- Build a portfolio of a few apps to demo.
Getting a Job
- Contact all the people in my networks to let them know what value I can provide and what I am looking for.
- Start applying for junior-level jobs or internship programs.
- Plan to apply for at least two jobs each day.
- Debrief with yourself after interview and decide what skills need to be worked on.
This is still a fairly rough sketch of a plan, but you can see how this kind of plan gives a clear path getting you from A to B.
Your plan will be rough at first, but as you figure out more about what you need to learn and do, you can fill in more details.
Having some kind of plan in place is important. You can always change and adapt the plan, but if you don’t have a plan to begin with, you’ll be aimlessly floating in random directions and will probably get frustrated and be more likely to give up.
In the next chapter, I’ll help you refine that plan further as we discuss the technical skills that you are going to need in order to become a software developer.
While you're cracking away at your plan, do check out my course: 10 Steps to Learn Anything Quickly
