Why should you learn how to program? What is programming? What specific steps can you take? How can you apply programming?
This episode shares the following major aspects you can consider and it allows you to think about these from two different viewpoints – either starting a new project or joining an existing project that’s already established.
- Platform – have you considered the differences between a native application vs. a web application? Or maybe you just need a script or you can combine two or more existing solutions together.
- Configuration – how will you allow your application to adapt to environment differences, respond to administrative control, and allow users to provide their own preferences?
- Extensibility – will you allow your application to grow and change based on enhancements or new adaptations?
- Testing – how will you ensure that your code works as expected?
- Data storage – where and how will your application store information?
- Versioning – how will your application deal with different development versions and eventually different customer versions?
- Documentation – how will you deal with both documentation for internal development as well as for customers?
- Version control – what systems and tools will you use to keep track of your source code? How are changes reviewed and approved?
- Bug and issue tracking – how will you keep track of work items, customer requests, and bugs? How will you identify and troubleshoot bugs when they do happen?
- Requirements – how will you keep track of what the customer actually requires and map that back to individual features and changes?
- Communications – How will the various components send and receive messages.
Listen to the full episode or you can also read the full transcript below.
Transcript
There’s different ways I could go with this episode and my first thought is to encourage you to be consistent, curious, and to experiment with specific goals. In other words, take action right away and get started and then don’t stop. Maintain a steady pace with your learning and even if you spend just an hour a week, you’ll be surprised at how far you’ll progress after three to four months. It also helps if you get involved with others learning how to program because you’re sure to face resistance from friends and even family. It’s hard to change and we naturally resist change within ourselves and in the people we know.
I’ll be starting the live weekend classes again once things settle down a bit more from the move to New York. Right now, my weekends are still occupied arranging things. This is a great way for you to get the support you need to begin programming or take your skills to a new level.
I’ve already went over these topics in early episodes. And while I’ll surely discuss them again in the future, for today, I want to explain some different specific steps you can take.
Let’s divide this episode into two halves. In the first half, I’ll share steps you can take to help you program a new project. One you haven’t started yet but already have an idea. In the second half, I’ll share some steps that will help you be more productive when starting on a project that’s already quite far along. You can use recommendations from either of these extremes to fit your specific needs.
Both of these halves could be further divided based on your current skill level and experience and even by the expected size of the project when completed. I’m not going to go into all of that and will instead focus on what a more experienced programmer might consider. Don’t worry, if you’re just starting out, I’ll also recommend a couple places to start.
Okay, you have an idea. I’m going to assume this is something you can at least get started on by yourself. It’s a whole different story if you need a team of programmers right from the very beginning. You might be surprised what you can accomplish by just starting out yourself. I remember one very large and successful project at Microsoft that started out with just me initially programming and another person working on the requirements and specification. You have the opportunity at this point to set the initial structure of the project, figure out the big pieces, and select the tools and technologies that will be used. It’s very difficult to change these things once the project has begun.
This is why it’s important to know more than one programming language. You’ll have a better chance of succeeding if you pick the right tools. It goes beyond just the language and tools though. Technology changes so fast that I recommend you start out by looking for new ideas, tools, languages, algorithms, and similar problems. I’ve discovered completely new ways to think about and solve problems by just looking around before starting a new project.
When you’re researching and planning, try to avoid going too deep. You’re goal should be to understand relative strengths and weaknesses and not to learn each thing in detail. If you expect your project to be big, then it might be worthwhile to pick two or three options and spend more time getting to know each one. This should give you enough understanding to make a selection.
Do this for each major component of your project. I’m talking about things like the platform; have you considered the differences between a native application vs. a web application? Or maybe you just need a script or you can combine two or more existing solutions together. Maybe your project is too big for any one machine or you need to handle machine failures. The point is to really take the time to understand what the customer of your application needs. If you just start writing code, you’ll get so involved with one small piece that it’ll lead to another and before you know it, your project will be leading you instead of the other way around.
Other examples of big pieces include:
◦ Configuration – how will you allow your application to adapt to environment differences, respond to administrative control, and allow users to provide their own preferences?
◦ Extensibility – will you allow your application to grow and change based on enhancements or new adaptations?
◦ Testing – how will you ensure that your code works as expected?
◦ Data storage – where and how will your application store information?
◦ Versioning – how will your application deal with different development versions and eventually different customer versions?
◦ Documentation – how will you deal with both documentation for internal development as well as for customers?
◦ Version control – what systems and tools will you use to keep track of your source code? How are changes reviewed and approved?
◦ Bug and issue tracking – how will you keep track of work items, customer requests, and bugs? How will you identify and troubleshoot bugs when they do happen?
◦ Requirements – how will you keep track of what the customer actually requires and map that back to individual features and changes?
◦ Communications – How will the various components send and receive messages.
I could keep going. This is by no means a complete list and at the same time could easily be way more than you need. It’ll take some experience for you to get a feel for how much is necessary.
There’s no way to implement all of this on your first project unless you’re joining an existing team that already has these things in place. If you’re new to programming, this can seem overwhelming.
I recommend that you start small and focus on testing and version control.
Write your tests first before writing the code. This is called test-driven-development and has several benefits. I’ll discuss this topic more in a future episode. The main benefit you’ll get right away is that your code will be designed from the beginning to accomplish something useful. This helps avoid a bunch of code that while maybe interesting, serves no real purpose.
And becoming proficient with a version control system will allow you to keep track of your progress and try new ideas without worrying about how to go back to the way things were when the application last worked.
Let’s say instead of a new project, you’re joining a team of software engineers working on the second or third version of an application. My advice here is to take that list of big pieces and try to identify them. What approaches did the team already take?
Then identify the requirements. What’s the application trying to accomplish and how does it meet those needs? Learn to use the application and play around with it by experimenting. Look for confusing or strange behavior that you don’t understand. Then ask questions.
Contribute what you learn back to the team. You only get one chance to experience something for the first time and anything you can do to record your journey will help others who join the team later.
It helps if you can work on fixing bugs. Even with all my experience, when I join a new team, I find that fixing some bugs allows me to explore the software design with a specific purpose in mind.
Imagine you find yourself in a strange city and want something to eat. There are too many choices. Well, having a bug to fix is like already knowing the exact restaurant you want to eat at. Then it’s just a matter of following a map. You can explore but it’s a lot easier now because you have a definite destination in mind.