On March 22nd I gave a presentation to ASU's Software Developers Association which I called "What My Professors Didn't Teach Me - Developer Skills: What They Are, Why They're Important and What You Should Know About Them". The presentation provided an overview on seven different "developer skills" that I believe are necessary to succeed as a professional software developer. I define "developer skills" as those aptitudes between the "hard" technical skills of programming / hacking and the "soft" interpersonal skills of teamwork and communication. They are the things that a developer needs to know to succeed at his job outside of actually building software.

Over the next several weeks I will be writing a post on each of these proficiencies; each post will describe what the developer skill is, why I consider it to be necessary knowledge for the workplace, and what specific things you should learn. I plan to have links to tutorials or other websites that you can use to follow up.

The previous post focused on how you keep track of your changes to your code using a version control system. Today's topic focuses on another issue related to changes - how do we keep track of change requests? In other words, instead of looking at managing changes from a technical perspective, we need a way to manage changes from a business perspective.

When working on a team, work is generally divided up into separate units before being assigned. There are a few reasons for this:

It helps define exactly what needs to be done by going from a general functional specification to a series of more specific descriptions

It allows work to be assigned out to multiple developers in chunks small enough for one person to work on

It helps project managers figure which work can be done in parallel, and which work must be done sequentially - or, put another way, it helps managers see which work units are dependent on one another, and which are independent.

Ticketing software assists you in creating these units of work, allows you to create relations between tickets to show dependencies, and allows you to assign the tickets to other people.

After actually creating the tickets, ticketing software often allows people to comment on each ticket. This can be used to document work done, or to discuss specifics or requirements on the ticket.

Finally, ticketing software allows you to move tickets through a "workflow", usually from a "created" state to a "finished" state. Doing this allows project managers to glance at a "board" grouping the tickets into their different states, thereby seeing the status of the project as a whole.

This is a sample workflow for a ticket, showing how it can move from the start state ("Open") to the end state ("Closed")

Why Is This Important?

We've discussed above why knowing how to use ticketing software is important for project managers and for businesses, but what about for developers? As you might expect, I consider it just as important for devs to have at least a familiarity with how ticketing software works.

There are two reasons for this:

Even if you're not creating the tickets, you'll still be expected to participate in them. If you work in a professional dev shop, you will likely have your work assigned to you via tickets. You'll need to know how to comment on tickets, how to change the ticket state, and so on. As you grow as a developer, you will likely start creating tickets of your own - a common use case for this is creating a ticket upon finding a bug during development. Since your work will be tracked using the tickets, you'll need to know how to keep things up to date. Often, your reports in the tickets will be used to judge your productivity.

All of these things, hopefully, show the importance of knowing how to work with these systems.

There's another reason that it's good for you to know how to use tickets properly - it will allow you to better keep a record of the work you've done. One of the most important functions of tickets are the historical function they serve - when used properly, they will show which business decisions were made, which problems were experienced, and which steps were taken, in which order. You'll also get specific timestamps for each of these things. You'll quickly learn to appreciate this the first time you get a request to reopen an issue from six months ago - or when something breaks, and you need to figure out why functionality was implemented the way it was. Version control can only show you what was changed - the tickets, when used properly, will tell you why.

To summarize, a significant amount of your productivity outside of actually coding will be determined by how well you work with your ticketing software.

Things You Should Know

A lot of the ticketing software functionality you need to know can be sussed out with a bit of common sense - for example, it's pretty easy to figure out how to use the comments appropriately. This said, there are a few specific points of knowledge I would recommend:

First, I would recommend taking a tutorial or a class in using JIRA. JIRA is a widely used ticketing software in the real world, and much as how Git is representative of version control software, so JIRA is representative of ticketing software. Knowing JIRA will save you a lot of time in training if your future job uses it (and there's a good chance it will), but even if they don't, you'll still have the benefit of knowing one system, and all the concepts and heuristics that come with it.

Beyond learning how to work with the software itself, I also recommend you have a good grasp of two concepts:

Know the general lifecycle of a ticket. Usually, these correspond to your development workflow, a topic I'll get more into later. Every shop has a slightly different way of moving tickets (and some companies even have different flows between different projects), but most have a core similarity.

The standard workflow is usually: Open > In Progress > Ready for QA > In QA > Ready for Production > Migrated > Closed.

Know the general "scope" of a ticket, and be able to determine whether a ticket is growing out of that scope. One of the most common problems in software development is scope creep; this often starts at the ticket level. I have seen many tickets whose comment chains have grown to 100 comments or more due to off-topic conversations working their way in.

You should definitely know what conversation is appropriate within a ticket's comments - discussion related specifically to the execution of the functionality that the ticket embodies. Anything outside of this - planning (should always be done before the ticket is created), discussion of another ticket, or general off-topic discussion - should be called out and stopped.

In my experience, these two topics are where developers most often make mistakes with their tickets. If you have an strong understanding of these concepts, you'll be a credit to your team.

Conclusion

This concludes my discussion of the second of the seven developer skills. So far, we've discussed version control - a way to track and manage code changes - and ticketing software - a way to track and manage business requirements.

The next topic - the multi-branch development workflow - will tie these together in a third topic: how do my code changes implementing my business requirements move from development into production? As we'll see, most companies use a specific system to ensure that this is done in a smooth, safe manner. Stay tuned to find out more.