I have been working professionally as a Software Developer for about 9 months now and in that time I've had many opportunities to evaluate my processes and whether I was working as well as I could have been.
Oftentimes, the answer was no, simply because I did not yet know any better. I have missed deadlines on tasks or projects due to gaps in knowledge and lack of a solid development and time management process. At this point there's still tons of problems I've never encountered before, but I am learning how to better approach them and manage my time so I don't continue to make the same mistakes.
Mistakes and falling short are learning opportunities though, and I wanted to share some of the methods and tools I've learned over these months. I hope that they may provide you similar benefits in meeting your own deadlines and optimizing workplace productivity.
I would like to note that I don't use all of these tools and methods for all situations; I'm learning to adapt my method to each unique situation as it seems to fit. With that said, let's talk productivity!
Scrum/Kanban-Style Planning Board
One of my favorite productivity tools is keeping a Story Board. I maintain a separate board for each of my epic stories and share it with the rest of my team, including the Product Owner if applicable. For those who are unfamiliar, an epic is a major task or project that is broken down into a number of smaller ones due to its size and scope.
A Story Board can be kept on a whiteboard or wall using sticky notes, or electronically using many software or online tools such as Trello, Atlassian Jira, Microsoft Planner, and many others. My preference is Jira, but my manager prefers to collaborate over MS Planner. The important part is to have this easily available to the full team.
Typically my Story Board has four columns:
ToDo: New tasks start here and remain until they've been picked up to be worked on
In Progress: Tasks that have been picked up by a developer are moved here until they are completed. There should never be more than one or two cards in this column for each developer to keep the flow moving.
In Test/QA: This column can be used in two different ways -
1. In a team with a designated tester, the developer finishes development and tests their own work before moving the card into this column. The tester will work through the cards in this column.
2. In a team with no designated tester, the developer finishes development on a card and moves it into this column to signal their change in "hats." Once the card is in the Test column, they take off their "developer hat" and only think in testing mode. Often I will close most of my development tools to get my mind in the right place.
Complete: Once the development on a card has been finished and work has been thoroughly tested, it is moved to this column where it awaits check off by the Product Owner or release into Production.
Pomodoro Timer
The Pomodoro Technique is a pretty old time management method, but has recently had a resurgence in popularity... especially among programmers. To put it simply, one works in 25 minute intervals with 5 minute breaks. Every four interval sets is rewarded with a longer 15-30 minute break. Many people use apps on their phones, but egg timers work just as well (and don't have the temptation of social media!)
There are six steps to the original technique:
1. Dedicate the Pomodoro period to a specific task - write it down.
2. Set your timer for the working period.
3. Work on the specified task.
4. When the timer goes off, stop working and mark a check on a piece of paper.
5. If the checkmarks are fewer than four, take a 3-5 minute break. Go back to Step 2.
6. If this is your fourth checkmark, take a 15-30 minute break. Reset your checkmark count to zero and go back to Step 1.
Time-Boxing
This is another method used by many Scrum teams to keep the flow moving. This method works very well for me, especially in cases where I find myself unsure of the solution to a problem right away. I allocate a certain amount of time to research (perhaps 1-2 hours), then if I am completely stuck after this period I will seek out assistance from a more senior developer or my manager.
Oftentimes this working period can provide me with enough well thought out questions that I can help the person I reach out to guide me in the right direction to make further progress.
Time boxing also gives me a definite stopping point, keeping me from falling into the trap of thinking I'm just on the verge of the solution "if I only read one more article."
Minimizing Distractions
Oftentimes distractions are inevitable, but chatty coworkers, noisy cubicle neighbors, and constant meetings are a detriment to productivity - especially for software developers. It's impossible to put a complete halt to these attention parasites, but there are techniques you can use to minimize the harm they deal to your productivity.
Noise-canceling headphones are one major deterrent I use; even if I don't have music playing I tend to keep them on my head to keep the chatty coworkers and excess neighbor noise away. Another technique I use is a firm but friendly reminder that I'm working on an issue for X,Y,Z Application and it needs to be released [soon-in-the-future-day], so it needs my full focus.
Constant meetings are a little harder to manage if your manager doesn't understand how developers work and focus. Having a one-on-one with them might be the best bet. I have also heard of developers who block out chunks of their day as "Working Hours" on their calendar, making themselves unavailable so others must consider scheduling around this availability. Keeping meetings together and in the morning seems to work best for me. I'm happy when all of that's out of the way by 10 or 11am so I can get some solid development hours in before the day's done.
Commute Time
This won't apply to everyone, but many people commute to work via bus, train, or by foot or bicycle. In my case, my commute is about 90 minutes each way and I've come to love every minute of it.
My morning commute is spent doing language studies, either using Pimsleur, Duolingo, or reading. My mind seems to be fresher and more apt to absorbing new words and languages in the early morning, so I am trying to take full advantage of this. My evening commute is dedicated to reading technical and self-improvement books to increase my skills in the workplace and in life.
Those who commute on foot or by bike probably won't be able to use apps or read print books, but podcasts and audio books are readily available and a wonderful way to make good use of time where you're otherwise simply sitting or walking (or pedaling) and not using the "thinking" part of your brain.
I'm sure there are tons of other techniques that work well for other people - please do me a favor and share them in the comments! I'm always looking for more ways to increase my output and productivity at work (and just in daily life).
Top comments (6)
It isn't so bad when you use the time for things you wouldn't otherwise make time for. Once I get home I'm dealing with all the things I do there and at work I try to stay on task, so my long commute has actually become a serene little chunk of "me time" that I've grown to love. :)
It's also temporary, thankfully, because I do also miss having the extra time to do other things (and not get up so early!) When I moved to my new state and got this job, it all happened so quickly and we found the apartment before I was offered the job, so the location didn't end up being optimal. Once the lease is up I'll be moving closer to work so the commute will be much less.
Maybe ask about working from home one day a week. Some people enjoy the lack of distractions and no commute, but others like to physically go to work to get out the house and get in the right mindset for work.
It may be an option one day, but for now I need to be physically in-office everyday. My company has a policy that requires one year of employment with them before an employee is able to do any remote work.
I struggled for years with the kanban structures at tech companies. There's a basic problem: the unit of the board is not of fixed size. If it's a doable task, then where to the projects and ends that it's part of get tracked? If it's projects and ends, then where is my actual todo list? And then you realize that some projects have lots of subparts and some have three actions to be done.
I've also been running a Getting Things Done system for a couple decades as well, and I've basically gone back to a hierarchical todo list that I work down.
The funny thing is that actual kanban in industrial settings doesn't work this way at all. It was completely misunderstood when brought over to software. In manufacturing, you have a series of work stations with different machines. You want to optimize for producing the right things in the shortest amount of time (which is not the same as optimizing keeping all the work stations busy). So if you need a finished product X, you write out a card for X and hand it to the last workstation to produce X...if they don't have too many cards already (to limit work in progress). They write a kanban card for each upstream step and pass them to the upstream stations, who keep going back until you get a kanban card for parts or raw materials to be ordered or fetched from storage. Then the cards are attached to the output of each stage as it moves back down. Since each stage can only take a certain number of cards, you intrinsically limit the amount of unfinished inventory.
Great read, thanks for sharing!
Brilliant tips! Will look to try The Pomodoro Technique :D