I’m a big supporter of helping software developers develop “soft skills” in addition to their technical skills — in fact, I wrote a complete book about it — but there is no denying: technical skills are important.
I mean, if you can’t actually write code and develop software, all the soft skills you learn won’t really do you much good. Perhaps you’d make a good manager or coach, but not a software developer.
But if you are reading this section of the book, I’m assuming you are interested in becoming a software developer — or a better one — so let’s talk about the technical skills you are going to need to know.
The Skills That Pay the Bills
Now, this is a topic that tends to overwhelm many beginning software developers because it can feel like there is so much to know, and it can be difficult to even know where to start.
I’m going to try and break it down here into what the most essential and beneficial technical skills are that are going to benefit you the most in your quest to become a software developer.
This chapter is by no means meant to be an exhaustive list of all the technical skills you could possibly need as a software developer, but I’ve tried to list the essential ones and give you an overview of them here.
Fear not. In the section of this book titled “What You Need to Know About Software Development,” I’ll be dedicating a chapter to pretty much every one of these skills, and we’ll take a much deeper dive.
So, without further adieu, here is a brief overview of the technical skills I find most important.
One Programming Language
I think it’s best we start with this one, don’t you?
Can’t really be a programmer without knowing a programming language — you know what I mean, Vern? (See Ernest P. Worrell if you don’t get that reference. Enjoy.)
We’ll talk about selecting which programming language to learn in the chapter cleverly named “What Programming Language to Learn,” so don’t stress out about that just yet.
I will say very quickly, though, that the choice of which programming language to learn is not as important as you may think it is.
Instead, let’s talk about why I’d suggest starting with just one programming language and not trying to learn everything there is under the sun.
Many beginning programmers try to hedge their bets by learning several programming languages at once or before they try to take on their first job as a software developer.
While I think that you should eventually learn more than one programming language, I would advise against doing it upfront because it will just lead to confusion, and it will divert your energies from many of the other technical skills you are going to need to learn.
Instead, I’d advise you to go deep and focus on learning the ins and outs of a single programming language, so you can feel really confident in your ability to write code in that language.
Remember how we talked about being as specific as possible when deciding what kind of software developer you were going to become?
That’s the idea here.
How to Structure Code
After learning a programming language—or preferably while learning it–I am a firm believer that the next thing you need to know is how to properly structure your code.
I’ve already given you an excellent resource to help you to learn this extremely valuable skill: Code Complete by Steven McConnell.
What do I mean by structuring your code?
I mean to write good, clear, understandable code that doesn’t require a large amount of comments because the code itself is communicative.
Many software developers go through their whole career without learning this skill, and it’s unfortunate because this is the primary way I—and many others—judge the skill and competence of a software developer.
Good code structure shows a dedication to the craft beyond just getting the job done.
Structuring your code is really the art part of software development, but it’s also critical because you and your co-workers who have to work with your code will spend considerably more time maintaining existing code rather than writing new code.
I’m not going to go into how to properly structure your code in this book since—like I said—I’ve already provided you with an excellent resource, but you should strive to learn how to write good, clean code from the beginning rather than learn this skill afterwards.
I can just about guarantee that, even if you are a beginner, if you can write good, clean, concise, and understandable code that expresses its meaning in the structure itself, just about any interviewer who sees your code is going to assume you are an experienced professional.
And to some degree you will be, or at least on the path to be, because you’ll be treating this career as a profession, not just a job: a sign of a true craftsman.
This one is debatable, especially if you are learning a program language that isn’t object oriented (OO), but enough of the software development world thinks in terms of OO design, so you need to make sure you understand it.
Object oriented design is a way of designing complex programs that breaks them down into individual classes or objects (instantiations of classes), which encapsulate functionality and have specific roles and responsibilities.
In software development, we are always trying to manage complexity.
Thinking in terms of objects helps us do that because it allows us to define and design a complicated system out of a bunch of interacting components, rather than trying to tackle the entire complexity as a whole.
There are plenty of functional programming languages out there today, but the most popular languages and patterns you’ll find in software development are still heavily, if not completely, influenced by object oriented design and analysis.
You should have a good understanding of what a class is, what the different types of inheritance are — and when to use them — as well as understanding terms like polymorphism and encapsulation.
Algorithms and Data Structures
This is a large portion of what you will or would learn if you took a traditional college or university program to get a degree in computer science.
Algorithms are the common ways of solving various computer science / programming problems.
For example, there are several algorithms that are commonly used for sorting lists of things programmatically. Each of these sorting algorithms has a different set of properties regarding speed, memory size requirements, and the ideal kind of data it works on.
There are many of these algorithms in the field of computer science, and it is also important tounderstand how to write your own variations of these algorithms to solve the kind of tricky problems you might encounter when solving real programming problems.
Often, being good with algorithms can allow one developer to solve a problem in an hour that might take another developer several days to figure out.
Unless you are familiar and good with algorithms, you won’t even know an elegant solution already exists out there. So, for this reason alone, I consider it a valuable skill to acquire.
Data structures fall into a similar category and work in conjunction with algorithms.
There are several data structures all software developers should be familiar with including:
- Arrays or vectors
- Linked lists
By having a good grasp of data structures and algorithms, you can easily and elegantly solve many difficult programming problems.
When I first started programming, I was really bad at data structures and algorithms because I was mostly self-taught.
I didn’t realize the true value of them until I started competing on a site called TopCoder where knowing data structures and the algorithms that operate on them gave you a serious competitive edge.
Quickly, it became apparent how useful these skills were in the real programming world as I encountered problems that I previously had no idea how to solve, and which are now extremely easy—and fun.
In fact, I consider this to be one of the most fun areas of software development. It’s really rewarding to work through a difficult problem and to utilize data structures and algorithms to develop a clean, elegant solution that performs really well.
The best resource, at the time of this writing at least, is by far Gayle Laakmann McDowell’s excellent book, Cracking the Coding Interview.
In this book, she goes over just about everything you need to know about algorithms and data structures.
It’s a challenge to learn this stuff, but well worth it. This is one of those skillsets that can set you far above your peers. A MAJORITY of software developers are pitifully ill-equipped in this area.
And if you want to pass an interview at a company like Microsoft or Google, you will definitely need to master this skill set.
A Development Platform and Related Technologies
You should have some experience and mastery of at least one development platform and the related technologies or frameworks that go with it.
What do I mean by platform?
Well, generally it means operating system (OS), but it can also apply to other abstractions that act similar to operating systems.
For example, you could be a Mac developer or Windows developer focusing on the Mac or Windows operating systems, but you could also be a web developer focused on a specific web platform.
I don’t want to pull this down into a discussion about what exactly a platform is—different people will have different opinions—but for the purpose of this discussion, I’m going to define a platform as a specific environment that you develop for, which has its own ecosystem and particularities.
Again, this is another one of those things where I don’t think it’s so important what you choose, so much as it is that you choose something.
Companies usually hire developers to develop for a specific platform or technology.
You’ll have a much easier time getting a job as an iOS developer if you have expertise with that specific platform.
This means being familiar with the platform itself, as well as what development tools, idiomatic patterns, and common frameworks programmers typically use when developing for that platform.
You might think the choice of a programming language determines the platform, but that is actually rarely the case.
Take C# today. You can be a C# developer and write code for Windows, Mac, iOS, Android, Linux, and even embedded systems.
So don’t just pick a language; pick a platform as well.
Framework or Stack
In addition to learning a specific programming language and platform, I’d also highly advise learning a framework or, better yet, a complete development stack that goes with it.
What is a framework?
What is a stack?
A framework is simply a set of libraries that are used to develop code on a particular platform or on multiple platforms. It usually makes common programming tasks on that platform easier.
Going back to the C# example. Most C# developers use the .NET Framework for writing C# applications. The .NET Framework consists of many libraries and classes that allow a C# developer to work at a higher level of abstraction since he doesn’t have to completely reinvent the wheel every time he wants to do something.
For example, part of the .NET Framework contains code for manipulating images. This code would be extremely difficult to write from scratch, so the framework is a huge benefit for C# developers writing code that needs to manipulate images in some way.
A stack is a bit different. A stack is a set of technologies, usually including a framework, that are commonly used together to create a full application.
For example, there is a common stack called the MEAN stack. It stands for MongoDB, Express.js, AngularJS, and Node.js.
MongoDB is a database technology.
Express.js is a Node.js framework for creating web applications.
It’s not important that you understand all that—unless you are going to be a MEAN developer—but what is important to understand is that, if you know all those technologies and frameworks, you’ll be able to develop an entire web application.
Stacks make it easier to create applications because they provide a common paradigm which many developers are using to develop applications, so knowledge can easily be shared and you can be sure that a particular set of technologies are proven to work together.
Learning a stack can be extremely valuable because it means you have all the required skills to develop a full application. Many companies that have an application which was developed using a particular stack will be looking for software developers that are familiar with that stack and can hit the ground running.
Basic Database Knowledge
Even though the landscape of databases has changed quite a bit in the last few years, I don’t see databases going away any time soon, so I think you probably should know a thing or two about them, don’t you?
At the time of writing this book, there are two main database technologies: relational databases and document databases.
I would say that a developer today should at least be familiar with relational databases and probably should have some understanding of document databases as well.
In software development, databases are often used to store data for an application.
Some teams will, of course, have dedicated database developers or database administrators (DBAs), but that doesn’t really excuse you from not knowing at least the basics of databases.
At the very least, you should know:
- How databases work
- How to perform basic queries to get data
- How to insert, update, and delete data
- How to join datasets together
In addition, you are probably going to want to know how to retrieve and store data programmatically from your code with your chosen platform and / or framework.
Most developers are expected to be able to write code that can interact with a database.
Source control is an integral part of any software development project.
Back in the day, before we used source control, we’d have a network share with all the files for a project on it, or we’d pass thumb drives back and forth with different versions of the software on them.
I’m ashamed to admit that I’ve participated in these shenanigans more than once.
But, I was young. I was stupid. You don’t have to be.
Almost all professional developers today are expected to know how to use source control to check in code, check out code, and hopefully merge changes from multiple sources.
Source control at its most basic level allows you to keep a history of the changes made to different files in a software project.
It also allows for multiple developers to work on the same code at the same time and to merge those changes back together.
We won’t get into the details here, but you should know how to use at least one source control system very well, and you should be familiar with most of the basic source control concepts.
Just about all professional software development teams will use some kind of source control in today’s software development world.
Build and Deployment
Today, most software development projects have some kind of automated build and deployment system.
There are several different software applications out there that help teams to automate both of these tasks, which used to be manual and, for some teams, still are.
What is build and deployment, you ask?
Well, you know how you write that code and check it into a source control system?
It would probably be a good idea to have some way to make sure that code actually works after you check it in.
That’s where a build system comes in.
At the very least, a build system is going to compile all the code and make sure there are no compilation errors.
A sophisticated build system may also run unit tests or user tests, run code quality checks, and provide some reporting on the current state of the code base.
A deployment system will be responsible for deploying the code either to a production machine or perhaps to some kind of a test environment.
You don’t have to be an absolute expert in these technologies, but it’s pretty important that you understand at least the basics of how these systems work, and the process of building and deploying code.
Often, the actual responsibilities for creating and maintaining a build and deployment system will belong to a quickly growing field called DevOps (short for developer operations).
But, that doesn’t excuse you from understanding at least the basics of how this process works.
It used to be that developers didn’t have to know much about testing.
It used to be that we’d write a bunch of code and “throw it over the wall” to a bunch of testers who would find all kinds of bugs in our code, we’d fix the bugs, and that was that.
With so many software projects adopting what is called an Agile process, (we’ll discuss this more when we get to methodologies), software developers and testers are having to work much more closely together.
Quality has really become the responsibility of the entire team—I’d argue that it always has been.
With that said, you need to know something about testing.
You should at least be familiar with some basic terms like:
- Whitebox testing
- Blackbox testing
- Unit testing (not really testing)
- Boundary conditions
- Test automation
- Acceptance testing
A good developer—and I’m assuming you want to at least become a good developer—tests their own code before giving it to someone else.
If you really want to be considered a professional and not just a hack, this is non-negotiable.
Ah, many a novice software developer has his dream smashed on the rocks of the debugger.
Everyone wants to write code, am I right?
But ain’t nobody want to debug their code? Ya hear me?
Ya feel me?
You are going to spend perhaps 90% of your time as a software developer figuring out why the hell your code doesn’t work.
I know this isn’t glamourous. I know you just want to write new code all day, but the world just doesn’t work that way.
If you apply a methodology like test driven development, you’ll probably spend a whole lot less time in the debugger, but regardless, whatever you do, no matter how you try and get around it, you are going to have to learn how to debug your code or someone else’s.
So, rather than taking a haphazard approach to something you know you are going to have to do, you should just bite the bullet and actually learn how to do it effectively.
In the chapter on debugging, I’ll talk more about this, but for now, just know, you gotta know how to do it.
Intimidated yet by the laundry list of things you need to know?
If not, here’s one more—but I promise this is the last one.
While some software development teams just start writing code and get things done when they are done, most teams have some kind of methodology they at least pretend to follow.
(By the way, side note here: don’t expect any team to actually really follow the software development methodology they profess to use. I’m not trying to be cynical or point fingers here. I’m just a realist, and I happen to know there are a whole lot of people who say they are doing software development methodologies like Scrum just because they have a meeting where everyone stands up every day.)
For this reason, it’s critical that you are at least familiar with some of the basic ideas behind the most common software development methodologies.
Today, I would say those are waterfall development and Agile development.
Most teams will claim they are doing Agile. Agile itself is a pretty loose concept, but there are some practices and, dare I say, rituals that you should be aware of if you want to be able to talk the talk, so to speak, and fit in on an Agile team.
We’ll talk about this more in depth in the chapter on software development methodologies.
Overwhelmed? Don’t Be
I know this is quite a bit of stuff, and I’ve barely scratched the surface on most of these topics.
Right now you might be feeling a bit overwhelmed and like you don’t understand most of what these technical skills are.
That’s ok. You aren’t supposed to yet—unless you are already a practicing software developer, in which case, shame on you! (Just kidding. I love you, but you really better get your shit together—really.)
Anyway, I’m going to be covering most of these topics in much more depth in the section of this book titled, “What You Need to Know About Software Development.”
So, just chillax as they say.
Next, I’ll be telling you how to learn technical skills in general, so by the time you get to the actual chapters on these technical skills, you’ll be ready to go.