As promised, this is the fourth 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.

Head to head

This time through, we need to talk about certain kinds of tools you’ll want to use on any project. Honestly, even if you have no interest in being a developer, you should have some sense of how these tools are able to help, because they’re not always limited to just software.

We’re clocking in at about twice as long as I really want these posts, so I apologize for that in advance.

Issue Tracking

You’ll see a lot of terms for this tool. They might “track” or “manage.” They might deal with bugs, defects, issues, troubles, support requests, incidents, or any number of other terms that all mean approximately the same thing. But the basic premise is that you have a database of tasks to accomplish, the deadlines (if any) associated with those tasks, who has been assigned to work on those tasks, and (ideally) what work has been done.

It’s a lot like a to-do list, if you want to think of it that way, but designed more for multiple people to work in parallel and to be able to help each other. For example, if I’m done with my current work (which may happen when tickets are allocated to people in batches instead of left as a pool for everybody to draw from), some issue trackers will let me look for people on my team who still have tasks to do, look them over to see what’s involved, and ask the colleague falling behind most if I can help them.

You’ll generally find two kinds of issue tracking systems, with some crossover in many products, to make them more appealing to another audience.

The traditional approach is to have each issue represented by a web page with a form. Any time you need to update the ticket, you make the change on that form, whether that means adding a comment, uploading a file, assigning the task to a worker, or announcing that you have worked for three hours on it.

For a quick example of what that looks like, you might compare an old Firefox issue with an old Minetest issue. Those are on two different systems, but you can see that the structure and process behind both tickets are basically the same.

  • Somebody announces a problem or a thing they want to happen.
  • Somebody (possibly the same somebody) categorizes that work as a bug, a feature, a change, something impossible, or another category.
    • That categorization may involve pointing out that the issue is related to other issues.
  • People discuss the idea in comments and attach files that support or illustrate their ideas.
  • Somebody takes or is given responsibility for the ticket.
  • That person works on the ticket, ideally posting updates as they work.
  • When the work is done, the ticket is marked as done.

The notes and updates are important, because they let someone else pick up the work, if the original developer isn’t available.

Of course, some people believe that a traditional system like that is too much work for the benefit, and so you’ll also see issue tracking systems that are built as kanban boards.

Kanban board

As a process, kanban comes out of manufacturing at Toyota, where physical cards were originally moved around on a wall to track the progress of the tasks they represented. The premise was to make it easier for the departments supplying parts to see when a worker would soon need more parts to consume.

As an issue tracking system, kanban becomes a system where tasks are grouped by state: Usually, blocked (can’t be completed unless something else happens), available (“backlog”), in progress, in review and/or test, and complete. Workers drag their card (on a web page, generally) from one column to the next as circumstances change.

Ideally, you should be able to work with either style. When you start a project, which we’ll talk about next week, you should also strongly consider using an issue tracker to make sure you don’t forget anything you want to do, leave yourself notes on ideas you have for those tasks, and be able to look back on your progress when it feels like you’re running in circles. In addition, if your project grows large enough to involve other people and support outside users, everybody can take and work on issues as they have time and interest, rather than having long conversations about what everybody plans to do.

Revision Control

One of the most powerful tools that most of us just ignore is version/revision/change/source control/management software, a kind of database that you use for keeping track of how your project has changed over time. That may not sound like a big deal, but it becomes much more helpful on projects that have been around for a while, for a few reasons.

First, it manages contributions from multiple users, so that two programmers can’t accidentally change the same code without warning. When the revision control system sees that happening, it asks one of the users to “merge” the changes so that they fit together.

Second, because every significant change is stored separately, it’s easier to undo a change that seems to be causing problems, even if that change is old.

Third, because every significant change is stored with a “commit message” that (with any luck) explains the change, it’s easier to learn—or refresh your memory about—code you haven’t looked at recently. If every developer adds an issue number to their commit messages, that provides even more information.

Fourth, most revision control systems allow a developer to create a “branch,” a version of the product that isn’t ready to go, where you can commit code that isn’t finished or isn’t yet working without interfering with anybody else’s work.

While there’s an unpleasantly large number of version control systems, you’re most likely to run across people using git, so that’s what I would recommend learning. If you have decided that you want to work with Microsoft technologies (C♯, ASP.NET, etc.), you’ll probably also want to get familiar with Azure DevOps.

Regardless of which system you choose, here are some quick tips to using revision control in a way that makes everybody’s life easier.

  • Create a branch whenever you start, if branches are available.
  • Avoid committing multiple changes at once, so that you don’t lose anything if you later need to undo (“roll back”) the change.
  • Especially if you have a separate branch that won’t affect anybody else, commit whenever you have finished a change you would be afraid to lose, even if it isn’t finished.
  • Since commit messages can usually be multiple lines, treat the first line like a headline, meaning that you should try to:
    • Keep the message short (under 80 characters),
    • Describe the change as if it was a command to the programmer to make the change (“add color to the background” or “fix the sort order,” rather than “connection has been activated”),
    • Include the issue number, and
    • Be clear about what changed, no matter how funny is seems to just write “Fix again” or curse.
  • If you must, put all your cursing, inside jokes, explanations, and long-term plans for the change into the subsequent lines of the message.
  • Merge your branch with the main (“master”) branch once you’re convinced that your work on the issue is complete, assuming that you created a branch to begin with.

If you work on a project that doesn’t follow all of these guidelines, try to blend in, instead; write like they write. The only non-negotiable item on the list is that you should always include the issue number, no matter what the rest of the team does, because there’s no other way to connect the changes with the issue.

Static Analyzers

With a few exceptions, over the long term, it’s a waste of time to spend time worrying about anything that you can automate. It’s silly to write a check and put a stamp on an envelope every month, for example, when you can just tell your bank to pay your bills. Similarly, if you can get the computer to teach you to write better code while you work, why would you do anything else?

Static analysis is a process where a tool investigates your code and highlights (and sometimes fixes) possible problems.

Sometimes, a limited amount of static analysis is a central part of the process of working in a particular language. For example, if you work in C♯, there are certain kinds of errors that you’ll be required to fix before you’re even allowed to test your code. But there are also static analyzers available for most major languages and for multiple kinds of mistakes.

As one example that I discussed while working on Bicker, Rubocop checks for ambiguities—the jargon-y term is “linting,” metaphorically picking pieces of lint off clothing—different kinds of bad practices (names, security issues, readability, and so forth), style, and formatting.

My Ruby code is better from using Rubocop, and I’m better at writing in Ruby, from getting familiar enough with the mistakes it finds to the point where I make them less often.

Browser Developer Tools

I saved this for last, because it’s the most unapologetically “techie” of the categories.

Right now, assuming that you’re reading this on a “traditional” computer (a desktop or laptop system), press the F12 key on your keyboard. On most web browsers, this should bring up the browser’s development tools. If that didn’t work, right-click something on this page (like this paragraph) with your mouse and then select Inspect Element (or the nearest equivalent) from the context menu that pops up.

The first tab probably says “Inspector” and, if you select it, you’ll see the structure of this web page. If you started learning HTML after last week’s post, you’ll probably recognize a lot of what you see. This is an easy way to learn how other developers structured their pages (assuming they were written as HTML), lets you make quick changes to a page for mock-ups, and gives you a way to figure out why the elements on your page aren’t showing up like you expect them to.

The Console and Debugger tabs deal with any JavaScript the page uses. The rest have rarer uses, but will be important when you need them.

Each web browser has a slightly different set of tools, but they’re all similar enough that it’s worth learning what you have available.

Next

As I mentioned at the top, even if you aren’t planning to ever write a line of code, many of these tools might still be useful to you. For example, everybody should probably try out a version control system, because version control makes it easy to collaborate on a project with a partner and gives you access to the entire history of the project so that you can fearlessly edit things, code or not. Similarly, I use a kanban board for any obligations I need to take care of in a given week—including reminders about any television shows I want to watch, but don’t want to watch so badly that I won’t forget about them. I also use a lot of static analyzers for various tasks, including Proselint for more recent writing.

While you look into those, be ready next week to look at choosing your first project.

Credits: The header image is Untitled by WOCinTech Chat, made available under the terms of the Creative Commons Attribution 2.0 Generic license. The Kanban board example is by Dr. Ian Mitchell and made available under the terms of the Creative Commons Attribution Share-Alike 2.5 Generic license.