Raw Materials to Become a Programmer
Raw Materials to Become a Programmer
There's more to writing code than simply writing code. Learn more about the process of becoming a true programmer here, with some additional book recommendations.
Join the DZone community and get the full member experience.Join For Free
All of us have heard this question a lot: what are the first steps to becoming a programmer?
I recently read a book, The Complete Software Developer's Career Guide by John Sonmez, that explained the answer, and I want to share the answer to this question in a concise way with you.
Learning About the Profession
First of all, you need to know something about developing software. 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 a manual process, 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.
Without Google Docs or other word processing programs, I’d have to either type this document on a typewriter or handwrite 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 automate the manual process of typing or handwriting a book, but I think you get the point. Therefore, let me emphasize to you a key concept that you should learn as early as possible as you embark on this journey to be a code-slinger.
You have to know how to manually do something before you can automate it.
Understanding the Problem
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. Which is fine for learning to code—as in my example with the MUD—but not for creating production software.
The process of software development always begins by first understanding the problem to be solved.
Once you achieve that understanding, you then come up with some kind of design for 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 who learn about Agile software development think they don’t need to design anything, that they can just start coding right away. While Agile development focuses on less upfront 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 start 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 lasts 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, the code may—ahem, should definitely—be checked into source code repositories where different versions of the code and its 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.
Pick a road and stick to it.
Opinions expressed by DZone contributors are their own.