Why should you learn how to program? What is programming? What specific steps can you take? How can you apply programming?
While there’s many ways to apply programming outside of getting computers to do what you want, it’s even more important if you’re dealing with software. If you’re a manager in a software company, then your insight will enable you to hire better programmers. If you’re selling software, then you’ll really have an advantage. And if you’re writing a high-tech thriller, then it’s likely that one of the main characters will need some coding skills.
I don’t blame you if you’ve taken a programming course before and either didn’t like it or didn’t understand it. Many courses focus on the wrong things and dive too deep into theory. Or maybe the course is too much of an overview or introduction that leaves you unsure how to proceed on your own. I’ve said many times that programming is a journey. You don’t start out with a blank page and write an application from start to finish. To me, you shouldn’t learn everything from start to finish either. That would be like trying to learn how to speak a language by learning words in alphabetical order. Instead, focus on important topics that you need.
That doesn’t mean to ignore everything except the current function. Remember that I recommend starting each project with a quick look around to see if there are any better tools, technologies, or ways to do things than what you might already know.
But what you don’t need is to spend years in college before ever trying to write your first program. Take action and start.
My advice is to find something simple that you currently do manually. Something you understand well and that would benefit you if it could be automated. Don’t start out thinking you’ll create the next office word processing software or the next blockbuster game.
Listen to the full episode for more guidance including a short introduction to agile development. You can also read the full transcript of the episode below.
Transcript
Programming can help you no matter what goals you have. If you’re planning to become a manager, you can use programming to help you keep track of inventory, hours, scheduling, tasks, or money. If you’re planning to become a master salesperson, a better understanding of programming will help you make better use of technology resulting in an advantage that a lot of other salespeople will overlook. Even if your goal is to write the next best-selling novel, learning more about programming will add realism that will be noticed.
While there’s many ways to apply programming outside of getting computers to do what you want, it’s even more important if you’re dealing with software. If you’re a manager in a software company, then your insight will enable you to hire better programmers. If you’re selling software, then you’ll really have an advantage. And if you’re writing a high-tech thriller, then it’s likely that one of the main characters will need some coding skills.
I want to keep this episode focused on how you can apply programming as a programmer though.
I don’t blame you if you’ve taken a programming course before and either didn’t like it or didn’t understand it. Many courses focus on the wrong things and dive too deep into theory. Or maybe the course is too much of an overview or introduction that leaves you unsure how to proceed on your own. I’ve said many times that programming is a journey. You don’t start out with a blank page and write an application from start to finish. To me, you shouldn’t learn everything from start to finish either. That would be like trying to learn how to speak a language by learning words in alphabetical order. Instead, focus on important topics that you need.
That doesn’t mean to ignore everything except the current function. Remember that I recommend starting each project with a quick look around to see if there are any better tools, technologies, or ways to do things than what you might already know.
But what you don’t need is to spend years in college before ever trying to write your first program. Take action and start.
My advice is to find something simple that you currently do manually. Something you understand well and that would benefit you if it could be automated. Don’t start out thinking you’ll create the next office word processing software or the next blockbuster game.
Instead maybe pick a board game you like to play that needs players to keep track of the score. Think about how you might be able to write an application that could help you track scores instead of using a pencil and a calculator.
You can start simple with just text. Have the program ask you for basic information such as how many players and their names. Think about how the game works. Is it turn based? Or can players score points at anytime?
What you’re doing here applies to any programming language and platform. You’re starting to think in terms of algorithms and sub-problems. In other words, you’re thinking about how to do things and how to divide those things into smaller and simpler things.
An application like this is within your reach after just a few hours even if you’ve never written a line of computer code ever. I know this because I’ve taught many students how to write their first programs with just a single weekend of training.
Take it a step at a time. And always remember to keep adding value to your application. Don’t write anything unless you have a definite outcome in mind that you want to accomplish. I’m talking something tangible that provides a benefit.
In a game scoring system, this could be as simple as keeping a running score for each player. Once you have this in place, build on it. Maybe the game ends when a player reaches a certain score. As a second definite and specific outcome, add the ability to ask for this final score at the beginning of the program and then check each player’s score to detect a winner. Each little feature that you add like this makes your application more and more useful. But the real benefit is that your running program is always useful. You don’t have to wait while you learn a new technology with no visible signs of progress.
If you lose track of this, I can almost guarantee that you’ll also lose interest and give up.
What I’m proposing is called agile in the software world. Agile programming can take many specific forms but in essence it comes down to this. Start with a specific problem that you can solve for yourself or some customer. Make the problem as small as you can by identifying something that would help the customer right away. Even if this is not the full application. This is called a minimum viable product. In other words, what’s the smallest thing you could provide that would still be useful?
Then get that part working and get it in the hands of the customer right away. Or use it yourself. The point is to gather actual feedback that you can use to plan the next feature that will benefit the customer.
This is a good way to avoid working on software that customers don’t need and will never use. The process is agile because it lets you adapt as you go. And you may find that what you end up with is nothing like what you initially thought about.
Your goal is to provide working software at each step that solves a need. You don’t write a bunch of documents that describe the entire system and then try to get feedback. Get something working and let the customer guide you along the way.
If you’re following my advice from the previous episode, then you’ll also be writing tests before you write any new code and you’ll have a version control system in place to keep track of all your work. This is super important for agile software development because you may often find that adding that next new feature means you have to change other things that you worked on before.
Anytime you make changes, you take the risk that those changes will introduce bugs. Usually bugs are classified as either new bugs or regressions. New bugs are bad enough, but regressions are worse because a regression takes something that used to work and that the customer might already be relying on and breaks it. If you have good tests, then they should catch any regressions right away. And source code control allows you to go back to the way things used to be and try again.
If a bug slips through your testing, then you need to ask yourself what test should be added that would detect the bug. Go ahead and add the test and then fix the bug. Run your tests again until they all pass.