This is your brain. This is your brain on computers.

5 Ways to Stay Organized as a Software Engineer

Coordination and organization is a tricky thing. For some people, there’s never enough cleanliness, nothing is ever in quite the right place, and everything is in a constant struggle to achieve its optimal configuration. For others, although outsiders see their style as chaotic, they may insist that everything is exactly where it should be, that there is a special method to the madness, and that ultimately they thrive on what they claim to be organized chaos. Whatever your personal style is, this article hopes to show you some great ways to stay organized as a software engineer.

Most careers in software engineering require interacting with others and engaging in a team based development project. Yes, there are times when you may be working on your own projects (perhaps those that you’ve used to build up your GitHub portfolio), but those should be the exception rather than the rule. Regardless, these tips can apply to those smaller projects as well. Striving to settle on some personally good organizational habits and participating in a team norm building process will improve your and your team’s productivity.

In the heat of the moment, when the executives on high are blasting demands down from above, it’s easy to get into crunch mode wherein you fix the issues but ultimately leave things in a longer term worse state. Maybe you’ve bypassed the normal ticket tracking system or didn’t follow the normal code review process. And it’s entirely possible that no communication was sent out to let other teams know of what was happening at lightning speed. Such disorganization can lead to botched releases, unmaintainable code, forgetful developers, and mistrust between teams.

The good news is that, like most problems in life, we are able to build tools and establish processes that suppress our inner demons and force us into habits of coordination and control regardless of how chaotic we are by default. Human vices can be difficult to overcome and knowing that we have the ability to automate away many of our habits is slightly comforting.

So, what’s your method the control the madness?

Use Source Control

First up, source control. This is one of the few suggestions that we consider to be non-negotiable. This is especially true when we consider how easy it is for files, folders, and code specifically to get disorganized and scattered across our hard drives. Applications and the code that makes them work are living documents. The phrase “etched in stone” absolutely does not apply. As such, we need to employ tactics that allow us to keep track of anything that happens to those files for our own sanity and for the health of the application.

Think about any school assignment you’ve ever had to complete that involved using a computer. Maybe it was an essay, or a PowerPoint presentation, or a spreadsheet. One of the first things people learn when working on critical tasks is that you should constantly save your work. Pressing ctrl + s should be encoded into your muscle memory right next to breathing. Miss a breath? That’s fine. Miss a save? Unacceptable.

Let’s take this example further. If your assignment requires contributions from a team, you’ve got more complications. You could pass the files back and forth as each person works on it, or you could designate specific sections of the assignment to each person so that conflicts are reduced. But at the end of the day, someone is going to have to reconcile all those changes into a single master document so that you can turn in the assignment. Your teacher isn’t going to accept five different files that partially make up a whole.

Fortunately, we have the technology to solve this problem.

With a source control system (aka version control), you can effectively track all changes to your work including:

  • When a change was committed
  • Who committed the change
  • What was included in the committed changes

In addition, source control systems provide some critical functions that can be performed on these changes like:

  • Revert to a previous version if a mistake occurs
  • View the full history of changes to files
  • See who changed specific lines in files
  • Work in parallel and merge changes together from different people

There is a lot more provided by popular source control systems, but those are the basics.

Take a look at the diagram below. This is an extremely high level view of how a source control tool like Git handles files and versions. For further reading on how Git works and what the fundamental commands are, check out our Git Essentials Guide.

High level version control diagram.

Developers work on a single checked out version of a file which is linked to a history of versions in the source control database. When changes are committed from the checked out files, a new version is included in the database. Each version is assigned a unique identifier, a date/time stamp, an author, and an optional message. This allows developers to reach back in time to get the full contextual picture of how a file got to its current state.

Want to know when an awful code smell was introduced? No problem, go through the Git history with something like the git diff command or applications such as SourceTree or Visual Studio for those of you that prefer a nice visual interface.

What about a situation in which you merge in changes from your coworker and now nothing works as expected? Git allows you to revert to previous commits or check out older versions of the code to trace your way through to where the breakdown occurred. Again, using something like Visual Studio to visualize your Git repo is a huge help here.

At the very least, you must take advantage of local source control repositories as described above. But you shouldn’t stop there. Oh no, that’s just the beginning of the organization adventure.

Why limit yourself to just local repositories? You will eventually need to collaborate with other team members and rest assured that your repository is backed up somewhere other than your local machine.

Read on for tips about using remote repositories.

Create Repositories in GitHub

After you learn the basics of using Git locally, you can start to use cloud hosted providers by opening your GitHub or BitBucket account (they’re free). GitHub is a distributed service that allows for remote Git repositories. This enables you to host your repositories in an environment that allows you to share your code with the public and allows others to contribute to your project in parallel.

To get started, read through our huge guide to using GitHub to build a public portfolio. After you’ve mastered those steps, you should be in a great place to start organizing!

Not only do you get the benefits of collaboration, public access to your code, and crowd sharing of your knowledge, but you also get a nice user interface to organize and keep track of your repositories. After you create your GitHub account, your profile can be used to organize and view your repositories, followers, packages, and activity.

Keeping a tidy profile helps you remember what you worked on in the past, where you want to go in the future, and what improvements you can make to existing repositories. Other users can look at your code, provide critical feedback, and request their own changes to be merged in to the code in an effort to build and ultimately better product.

Collaboration? Check. Coordination? Check. Organized? Check. There’s literally no downside to taking advantage of this.

GitHub profile screen.

Beyond your profile, you can make your repositories descriptive, searchable, and helpful by using good repository descriptions, tags, and README files.

Take a second to realize exactly why this helps with your organization. Instead of being chained to limitations of your local machine, you are now free to delete files, rename files, restructure folders and architectures, or completely replace your computer without negatively impacting the remote versions of your repositories. This protects you from yourself and effectively forces you into a process and flow that may make you a better software citizen.

GitHub repository example with best practices

It’s important to note that GitHub isn’t magic. It won’t cure you of your ills nor will it magically make you a more organized person. This says less about you specifically and more about the combined problems inherent to being a human and the complex processes required of a software engineer.

First, as humans, we’re just messy creatures. We’ve evolved to prioritize breathing, eating, drinking, and sleeping. Natural survival didn’t require anyone to understand the intricate details of organizing folders on a computer for maximum efficiency and productivity. So don’t be afraid to excuse yourself just a little.

Second, as software engineers, it’s understandable that we don’t want to spend our precious time being a librarian. Don’t take that as a shot against librarians! The point is that software engineers went into the profession because they enjoy problem solving, deep thought experiments, and telling computers what to do. Organization just so happens to be a necessary evil part of the profession (especially if teams are involved).

That said, use GitHub as much as you can to organize your projects but always be mindful that tools are only as useful as their owners.

Build Code Libraries

If you’ve read any articles on best programming practices, you’ve probably heard about the principle of “Don’t Repeat Yourself” or “DRY” for short. In a nutshell, you should attempt to reduce redundancy by reusing as many automated processes and code as possible for similar solutions.

Some examples of this in action are:

  • Liberal use of functions and methods to compartmentalize functionality into reusable chunks
  • Creating logically accurate and consistent classes
  • Building automated build and release processes by following good CI/CD practices
  • Maintaining a large set of unit tests that are integrated into the CI/CD pipelines

More specifically, let’s say you want to write a quick algorithm that calculates someones age. Easy enough:

var today = DateTime.Today;
var age = today.Year - birthDate.Year;
if (birthDate.AddYears(age) > today) age--;

But I don’t want to have to copy and paste this anywhere I need it. So I create a function.

function int CalculateAge(DateTime birthDate)
  var today = DateTime.Today;
  var age = today.Year - birthDate.Year;
  if (birthDate.AddYears(age) > today) age--;
  return age;

Yes, yes. We can hear you now. This is so fundamental. We know about functions and why they’re used! Well, read on then!

That solves the problem of repetition within a single application or assembly, but what if we want to use that function in other applications? Calculating a person’s age is a very generic operation, after all. We shouldn’t require anyone that wants to calculate it to have to solve and implement the same solution again. It’s a solved problem, so let’s reuse it.

So let’s come to the point of this section then: libraries. Just like a library for books, a library for applications offers an organized, compartmentalized interface into common routines. Notice we said organized? Yes, libraries help with organization, too!

Try to think about some common libraries that you might interact with regularly.

  • File systems to interact with disks
  • Device drivers to interact with hardware like printers, webcams, keyboards, and mic
  • Networking libraries to send HTTP, TCP, or UDP traffic
  • Graphics drivers to render colors and images to a monitor

The list goes on, but you probably get the point. You should immediately notice that these are complex functions that you don’t have to implement in your applications. They’re packaged nicely in a library with a (hopefully) well documented interface. All you have to do is make sure you meet the requirements of the library, import it, and then properly use it based on the interface specifications.

How you organize and bundle your functions and libraries is really up to you, but try to package things together that make sense and are related. You obviously don’t want to add a function which calculates a person’s age to a library that primarily helps with video encoding. Not only would it be confusing, but it requires someone that wants to calculate an age to take on a ton of video encoding related dependencies.

Here are some more detailed examples of libraries created in an enterprise environment:

  • Service abstraction libraries to interact microservices so that consumers don’t need to implement HTTP or TCP
  • Shared contractual classes to interact with service abstractions. For example, adding a person to a system that specializes in managing people might require constructing a Person object and passing it to the API. We could reuse that object in a common library.
  • Caching abstracting libraries so that consumers don’t need to understand if the cache is on disk, in memory, or in a distributed system like a database or Redis.

Utilize Kanban With Trello

This is the first section that isn’t specific to coding, though we will speak to it from a software engineering perspective. However, if you want to apply these organizational tools and techniques to your workflow as a product owner, project manager, tester, author, or really anyone that needs to accomplish tasks, they will directly apply.

Personal projects, learning experiments, and small business applications can typically be managed and tracked through simple either by a single person’s memory or something like a spreadsheet. Where project and product management becomes important is when multiple people are involved, changes cross product boundaries, or feature sets are large and complex to implement.

You may have heard of popular project management strategies like waterfall, agile, kanban, or scrum. Each has its own purpose and should be considered yet another tool in your management toolbox. Any sufficiently complex project will require the employment of one of these methodologies in order to avoid confusion between employees and teams. Remember, the keyword here is organization.

For this guide, we want to focus on a strategy of using kanban specifically with a tool like Trello.

So just what is kanban and how is it helpful to organize work and tasks?

“Kanban” is the Japanese word for “visual signal.” If you work in services or technology, your work is often times invisible and intangible. A kanban board helps make your work visible so you can show it to others and keep everyone on the same page.


The words “invisible and intangible” are important here. In other professions like construction, industrial engineering, architecture, health services, or really anything that has a physical progression, it’s easy (or, at least, easier) to keep track of progress. But in software, there’s nothing you can really touch to get a sense of progress. There’s no giant building or bridge that is built over time in a visible manner.

Instead, you may need to track tasks like creating guidelines, designing graphics and styles, coming up with a social media strategy, analyzing data, or sending out marketing surveys. Knowing the current status of these tasks, where they are in the grand scheme of things, and how they interact or depend on other parts of the project is critical to success.

Kanban via Trello.

As seen in the image above, Trello is a free to use (paid versions have more features) digital task management system that can be configured to used with kanban boards. You can set up multiple columns that represent state transitions such as To Do, In Progress, Needs Work, Testing, Done, or more. Each column can contain multiple cards to represent a task or use story with details of the requirements and comments about that task. Coloring each card gives a nice visual indicator (remember kanban means visual signal) to quickly determine the context of a card. And finally, interacting with the cards by adding comments, graphics, or dragging cards between column is fluid and intuitive.

We suggest signing up for Trello just to start playing around. Whether you’re using this tool for your personal projects or your team has normalized around its use, you’ll find that the organization and structure provided by the kanban flow is a productivity booster. You might even realize how convenient it is for tracking simple to-do lists around the house.

Always Keep Tickets Updated

This is tangentially related to the previous section. Cards in a kanban board typically represent a single user story. That is, a single feature or bug fix that needs to occur based on a user requirement. Another term that is used in the industry is a “ticket”. We’ve heard the ticketing expression used more commonly in teams that are used to working in customer support or DevOps. For example, a ticket would be created in a customer support tracking system like Salesforce which is then translated into something more technical for the product or DevOps teams to start tackling.

As time progresses, products mature, projects spin up and down, people enter and exit teams, it’s easy for backlogs and boards to get messy and disorganized. Imagine you’re working at a company that uses physical kanban boards. You know, those big paper grids on a wall with hundreds of sticky notes scattered all over the place (see below). Can you understand how easily this could go haywire? Without proper maintenance, the board rapidly becomes as useless as having nothing. Misinformation or information overload is as harmful as no information.

If the board becomes a mess, guess who is accountable? Everyone! You and everyone else is a stakeholder in the board and product success.

Physical kanbard board.

The point here is that you should always update your tickets, stories, cards, or whatever you want to call them. Update what specifically you might be asking.

  • Update the current status. Is the ticket done? Does it need testing? Are you blocked? Update it so everyone knows what is happening.
  • Leave important comments. Are you blocked and need help? Did you learn something interesting? Do you want to ask someone a question? Write a quick comment to leave a “paper” trail.
  • Assign the ticket to someone. Are you the owner of the current status? If not, who should be? Don’t just let the ticket linger on the wrong person’s queue.
  • Keep the ticket tags or categories correct. Is the ticket tagged correctly? If not, what should it be? Ask!
  • Check the title and description. Are there errors in the title or description of the ticket? Do they make sense? If not, what should they be?

Are you seeing a pattern here? Take an active interest in the ticket and its health. Don’t be a passive player in the dance of development. Instead, become actively involved in the health of the backlog, sprints, and boards so that everyone is on the same page and working from the same set of facts.

Too many developers assume that product owners and project managers are solely responsible for the accuracy of the boards. While it is their primary responsibility, the product from top to bottom should be thought of as everyone’s responsibility. If you see any inaccuracies, don’t just sit around waiting for someone to notice and fix it. You just noticed it, so you should either fix it yourself or contact someone that has the authority.

Justin Skiles

Justin Skiles

Justin has been developing enterprise application software for over 10 years primarily using Microsoft stacks, Azure, and various open source tools. He has most recently been trying his best as a Manager and Director of Software Engineering in the health care industry.

Share the Knowledge

Share on facebook
Share on twitter
Share on linkedin
Share on pinterest
Share on facebook
Share on twitter
Share on linkedin
Share on pinterest

Follow our updates



Keep Exploring. Choose Your Path.