As promised, this is the fifth part of a short series to provide some quick guidance for people who would like to reach out feelers into a possible software development career. As I mentioned in the first post, a lot of this material is recycled from some of my old Quora answers, updated for current times and the tone of the blog. More of it turns out to be new, the longer this goes on.

Mapping things out

This time through, we’ll talk about starting a project. I suspect that—if you have been reading along—you either have learned the basics of some technology stack or are in the process of doing so (or maybe you’re just a programmer who wants some extra ideas; it happens!), and (either way) are looking to get accustomed to actually programming.

Diving into the Deep End with a Project

The easiest way that I’ve found to learn programming is to just learn by doing. While (as mentioned) there’s some minimum amount of experience you should probably have so that you’re not completely lost, but otherwise, your best bet is to just move forward. You’ll struggle and make a lot of mistakes, of course, but it’s much more productive and…well, more fun than studying seven different ways that you might repeat some code without any context of what kind of code you might be repeating.

What to Look for in a Project

In the case of learning to program, the project should have a handful of qualities.

  • It should do something that interests you. If you’re not interested in seeing it working, you’re less likely to stick with it. If it’s something you’re going to actually use, that’s even better, because you’ll be motivated to get it right.

  • The concept should be simple. If it takes more than one breath to describe everything you want, then there are probably too many moving parts that might interact in bad ways.

  • If any of your features involves verbs like “figure out,” “predict,” or “organize,” it might not be a bad project, but the features you want most are probably going to need to wait until later. Honestly, because there are many problems that aren’t computable, it’s even possible that what you want could be impossible. So, just keep that in mind.

    • In fact, if you can phrase all of your features in CRUD terms—create, retrieve, update, and delete—you’ll probably find yourself much happier as you work.

    • The exception is if you can find someone else to do that work for you, like a free web service that allows you to make requests. You can find many examples of such services in this GitHub repository.

  • While it sounds like it contradicts the idea that the project should be simple, it should also be significant enough to require sustained work over (at least) a few weeks, to make sure you learn to do more than just a single thing.

In other words, you want something that’s significant, but not going to take forever, and challenging, but not discouraging.

Example Projects

If you have trouble coming up with a project that fits the bill, here are some possibilities that might spark a decent idea. Most of them are probably going to use public APIs (“application programming interfaces”) from the aforementioned GitHub repository.

  • Maybe the oldest standby project in the industry, but also one that nobody enjoys writing or using, is a book/music/video database. Users create a page for every book/album/movie they own, with a title, author/artist, year of release, and so forth. When that works, you can add user accounts to keep everybody’s collections separate, notify users of other users who own the same material, use one of the media-based APIs to try to auto-fill information for the user, and so forth.

  • A website to check the weather. There are already millions of these, of course, but imagine a site that takes the current weather and forecast from one or more weather API. Once you have that running, you can add the ability to create an account where each user might set their location and create a list of weather conditions they would like to be notified about. You might also save the weather information over time for the user’s location, to supply a historical view, and adding air quality data may also be interesting.

  • Combine multiple news APIs into a single “front page” of headlines for a given day on specific topics. When that’s done, add accounts where users can change those topics and rate the articles.

  • Use the APIs at the Open Trivia Database, UI Names, and This Person Does Not Exist (or one of the other ways of getting a random name and face, like the avatar creators) to create a game that plays like Hollywood Squares: Two players play Tic-Tac-Toe, but to mark a square, a “celebrity” (the random name/face) is “asked” a question (from the Open Trivia Database) and “responds” with one of the four answers for the question, chosen randomly. The player can then “agree” or “disagree” with the fake celebrity. When that works, it can be extended to have the fake celebrities quip about why they know the answer and user accounts can allow players to compete remotely and track how many games each player has won.

  • Use recipe APIs to let a user plan what they would like to cook for a week. Allow the user to download a shopping list (combine the common ingredients from each recipe), a schedule, and the recipes as separate items. Allow users with accounts to save recipes, making it easy to add to another week’s plan.

  • Create a chat system, where people can create an account and get involved in a conversation, storing the history over time. The world doesn’t need another chat system, but you have probably used enough of them to know what features you like and which you would like to fix, so I don’t need to list them, here.

Ideally, that gives you some guidance of what projects are probably the right size and complexity to start out. Of course, if you get it wrong, nobody is going to make fun of you for giving up on a project or coming back to it later.

Getting Started

So, assuming that you now have a project, where do you go from here?

The easy parts are setting up the project. The web application framework you chose (assuming you’ve gone with web programming) almost certainly has a “create a new project” command that you found at the start of the documentation. You’ll need to give the project a name, and I can only recommend keeping your names functional and describing what the project is supposed to do. Personally, I’m pro-pun and against using the names of any technologies (language, framework, API, whatever) in the names of projects. You might have a different preference.

Next, you’ll need to set up version control for the project’s folder. Once you’ve done that, if you’re using git, head over to gitignore.io to get an “ignore file” that makes sense for your project. Download it to the project folder and call it .gitignore (yes, it starts with a period), so that the version control system doesn’t strain itself keeping track of files you shouldn’t care about. Then, add all files and commit them. Now, if you do something absolutely terrible, you can always “reset” the project to this starting point; every time you commit, that’s another point in history that you can return to.

That’s all important, but administrative work. Now, it’s time to get to work.

Planning

Take a few minutes (literally just a few minutes) to sketch out your plans for the application. Specifically, what pages does your application need? What will the user see on each page?

Then, for each of the pages, think about that Model-View-Controller pattern. What information do you need to have in your page’s Model? Are you accounting for the input and output? What information will you display and request on the View? What actions does the Controller need to take to get the information the View needs?

Programming

Once you have answers to those questions (and, if we’re being honest, sometimes you don’t actually need all of those answers, if you’re willing to bumble your way through…), it’s time to start programming.

Personally, I would recommend starting with writing the simplest View, since the HTML will probably be easy to write and you can immediately see your progress. In other words, it’s an easy win and it helps you know whether you’re moving in the right direction with the Model and Controller.

Once you have your View, work on the different aspects of Model that I went into in the post about learning the bare minimum. You’ll probably need a database table or two, plus a “class” that represents what the View needs to see.

And then you have your Controller to work on, taking the user input and using it to update and prepare the Model for the View to show you. The application framework’s documentation probably has a list of methods (actions) you need to implement for a given Model—usually similar to Create, Retrieve, Update, and Delete, under different names—each of which works with a separate View.

In many web application frameworks, you can often short-cut some of this work by generating a “scaffold” for your model. A scaffold is an automatically generated Model-View-Controller set that creates the Model based on specified fields, a set of Views for each of the CRUD actions, and a Controller with empty versions of each of the CRUD actions ready for you to fill them in. It doesn’t save you any thinking, but it will usually save you from doing the boring, repetitive work.

Continuing Administration

Whenever you get something working, commit your changes to version control and move on to the next piece. In addition, run your static analysis tools frequently, so that you don’t find yourself dealing with hundreds of warnings that might be an important sign that you’re about to break a lot of pieces…but also might be entirely benign stylistic issues. If you can keep everything compartmentalized, you’ll be much happier as you continue.

If you realize that there’s a significant task to take care of—for example, connecting to someone’s API or combining data in interesting ways—check to see if there’s a library that someone has written to do the job for you. Most modern programming languages have a registry, where you can go to the website and search for the kinds of features you need. After all, a good rule of thumb is that every line of code that you’re not responsible for writing and testing is more time you can spend on something you care more about.

Finally—speaking of testing code—whenever you write or update some code, take a moment and ask yourself what might go wrong. If the user is supposed to give you a phone number, how many ways can that user give you a bad phone number, and what happens if they do? What happens if a book title is a thousand words long? Written in Chinese? Is it all emoji? Was it not typed in at all? More importantly, what can your code do to make sure that the user can correct the mistake before it’s a problem?

As you get more experience, you might want to consider putting the testing first, in fact. Almost every modern programming language can take advantage of an automated testing system and test-driven development, where you write a series of tests (small programs) that you know will fail, then write the code that makes them pass.

Keep at It

One of the nice things about the Model-View-Controller approach is that you always have a place to go. No matter what feature you need, you can quickly decide whether it’s part of the View, Model, and/or Controller. It’s also easy to decide whether it’s a Create, Retrieve, Update, or Delete action. You’re not always going to be right about that decision, but you can always fix it later. And if you can always fix your problems later, that means you can always just plow forward now, even if it’s not the best result.

As a quick tip, when you learn something, write it down. It’s useful to occasionally go back and see how far you’ve come and have a record where you can look things up. Heck, consider starting a blog and writing it there, so that the next person who decides to start programming can learn it from someone who had it fresh on their mind and still understands the confusion. My Monday-morning posts have been an overview of what I worked on from week to week (plus any small tidbits I picked up along the way), and I think it has helped my focus, preventing me from making changes without thinking about what they mean in English.

And, of course, ask for help! As I’ve mentioned before, programming is hard work that stresses some people out, and there is no reason you should shoulder it all alone when there are so many experienced developers looking at Q&A sites for a chance to make somebody else’s project easier. Just be aware that some people are…a bit aggressive in their attempts to help, and may try to turn it into a lecture on how you shouldn’t be trying to do anything that you think you need to do. When you find someone like that, it’s your call whether to listen to them, probably depending on how well you know the person, but most of us find it easiest to just thank them for their time and ask someone else.

Keep chipping away at the project, feature by feature, and eventually, you have what you envisioned at the beginning.

Next

This should put you on the path to getting experience programming. With any luck and some persistence, you’ll have a working project in a couple of weeks, gotten to know your way around your technology stack, and maybe even made some contacts of people willing to help out.

Your next steps should be to continue down this path. When you have one project “done,” move on to another project. Make your project available someplace public, if you don’t absolutely hate it. Document how to run the projects. Look for other people’s projects that you would be willing to help with. With each of those, you’ll gain some confidence and experience.

Meanwhile, for next Sunday’s post, we’ll take a look at the non-technical issues involved in transitioning to a software career. As much as nobody wants to use the phrase, you’ll need to “sell yourself” to credibly look like the sort of person a hiring manager needs for their team.

Credits: The header image is Untitled by Richard Tilney-Bassett, made available under the CC0 1.0 Universal Public Domain Dedication.