Finding Time to Code

3 Dec 2016

Does this story sound familiar? You get to work, grab a coffee, and sit at your desk. You start looking through your uncommitted files to remember where you left off yesterday. You remember you have a project backlog grooming meeting with your team at 10 AM, and out of nowhere, a PM walks up to your desk to see if you can join another meeting to discuss the amount of effort it will take to complete a new project. It starts in ten minutes. Oh, and don’t forget you have yet another Scrum meeting at 9 AM to touch base and a client coming into the office at 3 PM to discuss revisions to the work you’ve been doing. Before you know it, you only have 30 minutes in your entire work day to write code.

A lot of us have multiple projects at work, including non-development responsibilities (e.g. scoping out projects, interviewing other developers, company meetings, etc.), and multiple projects we want to complete at home in our free time. This can make it difficult to effectively focus on a single development task. It likely comes at no surprise that meetings can be one of the biggest productivity killers for developers. Switching context between communicating with people and communicating with a machine can quickly eat up all of the time in a day, yet it is critical to your organizational success as a developer. Changing gears between working with people and writing code is always going to cause some amount of overhead time in order to prepare yourself for the situation.

You mumble and grumble about having meetings all day because you were hired to be a developer… you know, to develop things. Not to sit in meetings all day. Not to sit on calls with clients. Not to be interrupted every five minutes.

My word of advice here is: Stop grumbling. Start owning.

Stop Grumbling

We, as developers, have it easy. Aside from the very few meetings we have each day, we get to build stuff most of the time. Chances are there are other people at your company who are jealous of you being able to do just that. Building cool stuff. While they sit in meetings back-to-back-to-back all day, every day, five days a week, looking at the little pieces of “free time” you have each day with envy. So the next time you want to complain about the number of meetings you’re attending, take a look at your project manager’s or your QA lead’s work calendar.

Start Owning

Now that we have gotten the complainer-bashing out of the way, I want to share some tips I’ve learned. The hopes are that I help you hone in on your abilities to effectively manage your day so that you can find more time to develop.

The more you listen, focus, and respond with confident feedback during meetings, the quicker you may be able to get out of that meeting. Don’t go into a meeting and read email and other messages while others expect your attention. Don’t continue to write code that you were writing right before the meeting (I know how badly this one sucks. I’m the type of person who hates pausing on work until it’s completed). Go into the meeting ON TIME, listen to your colleagues, write as many notes as you can when it pertains to your actual work, and be prepared to respond to questions or concerns with precise answers and conclusions. If anyone has to repeat themselves, or if you have no helpful feedback to provide during the entire meeting, then the meeting has failed at its goal. And you get less time to code.

Here are some tips I’ve picked up that might help you get the most out of meetings.

Prepare for Meetings

• First, make sure there’s one or two crystal-clear goals for the meeting. If you can’t think of any, ask the attendees if it would be better to communicate about your meeting’s topic via Slack or Skype. In fact, many problems can be solved through a two minute conversation in person. So walk to your colleague’s desk or pick up the phone and cancel that unnecessary meeting altogether.
• If a meeting is in fact the best option, email the goals to all of the attendees at least 24 hours before so everyone can prepare.
• If you know you have a meeting coming up, plan ahead so you’re wrapping up the feature or bug you’re working on ten minutes before the start of the meeting.
• Try to spend ten or fifteen minutes before the meeting reading any documentation or communication that was last shared with the people who are attending. Or, at the very least, have it open on your computer when going into the meeting. This will help save time from someone having to sift through email or Slack messages to find out what was last said.
• This may go without saying, but charge your devices before the meeting! It wastes everyone’s time if you’re forcing the conversation to pause while you run back to your desk to grab your computer charger or to grab the test device you needed for demoing.
• Check the meeting invite and make sure you have the tools for calling into the meeting. If your PM is using GoToMeeting or WebEx, make sure you have their software or plugin installed so you can join. That said, if your PM decided to use Oldy McOldFace’s super archaic meeting software built on Silverlight or Flash, flip some tables. All the tables. (╯°□°)╯︵ ┻━┻
• If the meeting is for troubleshooting with a client, ask your manager or your PM if the client has run through steps to ensure the issue isn’t user error or that it can’t be fixed with commonly known steps. Also, provide your manager or PM with a list of steps the client needs to run through in order to prepare for the meeting. Nothing is more annoying than getting on a call with a customer who is aggravated with you about a bug with the application you built, but who is not willing to prepare themselves to help you help them. We’re not magicians. We can’t always fix issues without the client’s help. So make sure they have your application ready for a walk through and that they can reproduce the issue before you jump on the call with them. Otherwise, your time will be wasted. And you can use that point for leverage! Being unprepared diminishes what the client is paying for, which is you having time to actually fix the issue or even build more features.

Own the Meeting

• If the meeting is running off track, ask if the tangential conversation can be taken offline between the people who it directly impacts.
• Keep the goals in mind throughout the entirety of the meeting. Remember that the meeting will have failed if you walk out with the goals unachieved. This will only lead to follow-up meetings, which could have been avoided. Again, make sure the purpose is clear upfront. If your PM doesn’t communicate the goals of the meeting upfront, then do it yourself. Tell everyone in the meeting, “Let’s make sure we figure out what to do about issue #P127 today and let’s also talk about how we can accomplish this feature request for company XYZ.”
• If you have to, force people into feeling like they are responsible for the success of those goals rather than you. Most people like to shovel responsibility off to anyone but themselves. It’s easier to just not talk about a problem, if you know someone else is ultimately going to be held accountable for it. In these cases, you need to make sure the responsibility is shared among the team. Tell them, “I won’t be able to fix issue #P127 until we get on a quick call with the client. After this meeting, I will look into what we can do on the client call to troubleshoot the issue, but ultimately I’m blocked until we meet with them. Would you mind setting something up with them? Also, could you ask them this set of questions to make sure the call is necessary and that they’re prepared?… “.
• If a colleague is giving other attendees misleading information, speak up! Try to resolve confusion as quickly as possible. Otherwise, it may manifest its ugly head later by causing your team to have more meetings on the same topic tomorrow. Again, avoid unnecessary meetings at all costs.
• If the meeting involves a demo, be prepared. Demos almost never go according to plan. I’ve been in meetings where there were attendees on three different continents with different network speeds, different firewall rules, and different software permissions. In those meetings, it wasn’t abnormal that the end user would share their screen via one piece of software and then our client’s project leads would share the end user’s screen-share through a different screen-sharing software… Screenception.
• If you have the opportunity to show off some new functionality or to show off how your team has fixed a fair amount of bugs (and your PM is ok with it), do it! It only makes the client more happy, which can actually result in less communication. I’ve, on many occasions, found out if I showed the client how “far ahead” we were with other work, they would tend to be less aggravated with a particular issue. This often led to the client telling us that it’s ok to skip our daily meeting for the day because they were impressed with our efforts and felt confident that we would meet our deadlines. Everyone is happy! And ultimately, you get to return to coding.

Don’t Attend the Pointless Meetings

Further, sometimes it’s actually good to raise concerns about the number of meetings you’re having to attend. Can the meeting be resolved with a quick chat on Slack or Skype? If you’re attending a recurring meeting and you’re never asked to give input during the conversation, then maybe you shouldn’t be there. Tell your manager why you don’t think it’s beneficial to you and give them a cost-benefit analysis of why this time would be better spent with you sitting at your desk writing code. Tell them how the project can be improved by you having that extra hour to complete bug fixes. The PM on the project can instead send you a simple recap email afterward.

Final Word of Advice

Don’t use these tips to ask to be excluded from every meeting. We, as developers, have a responsibility to show up and help the rest of the team be the best they can be at what they do. If you want others to help you put your best efforts towards the product or service that you’re developing, then give your best efforts to helping the rest of the team.

---

What are some helpful tricks you use to find more development time during the day? Share yours in the comment section below.