Tag: organization

Staying Productive

Staying Productive


I wrote a post a long while back about how I started to use Google Keep to get myself organized. Google Keep has been a go-to app for me on my phone for a long time now. I love using it to make lists of things, and I find it much more convenient than a paper notebook.

Don’t get me wrong–I think a paper notebook still has plenty of uses! I love my notebook for long running meetings with open-ended discussions or brain storming sessions. It’s great to be able to take a pen/pencil and doodle down any idea that comes to mind. When I’m having a free-form conversation, I need a free-form way to take notes.

However, my phone is something I almost always have with me–and my paper notebook isn’t. My phone allows me to take my Google Keep notes and email them to myself. It allows me to have a reminder right on my homescreen every time I unlock my phone. It’s just more convenient.

But something happened since the last time I wrote about using Google Keep. I use it more and more, and at some point I felt like I was getting less and less done. This is less about in the office and more about how productive I feel at home. So how can I be getting less done (or at least feeling that way) if I’m taking my own advice and using Google Keep to hack my TODO list?

I have tons of lists and no actions.

I think that’s the big take away. I list all the things I’m thinking about, and I keep making more lists. There’s no time frame around actioning things with the lists I’m making! So, in the spirit of continuous improvement, I set out to make some changes.


I know I wanted to make some changes with this part of my life because it was starting to weigh down on me; I didn’t feel productive. But I knew this wasn’t going to be something I’d answer over night. I kept my eyes and ears open for ideas for a little while before I thought up some tweaks.

The first thing I came across while living my alter ego was an Instagram post by Big J. Big J is this guy that’s incredibly big and incredibly strong. He’s lived the bodybuilding life and has a lot to show for it… And because being successful in the bodybuilding and strength world means being extremely motivated and hardworking, it’s no surprise I picked up this little bit from Big J:

Simple idea, right? Put some time into planning your schedule for the upcoming days. It almost seems to obvious to not be doing. I mean, don’t I do this already? I have meeting invites and stuff in my calendar for work… But, that’s right! I don’t have anything in my calendar for my own personal things that I like to do outside of work. Hmmm…

The next little tip to push me along was after a conversation with a teammate of mine at work. Our conversation was mostly about work-life balance, but my colleague was telling me about something he was trying out around forming habits. Essentially, over a period of time he’s been recording his success at keeping on top of good habits and identifying reasons why he’s sometimes missing them. Definitely right up the continuous improvement alley! Another great point he brought up was that good habits need to be introduced one at a time and only once you’ve been consistent with your other habits. By adding too much at once, you can derail the whole good habit process.

The “Staying Productive” Hack

This is the hack I’ve been implementing for a bit over a week now, and it’s helped tremendously with feeling productive!

Every night when I’m laying in bed, I spend about 5-15 minutes with my phone and I schedule personal activities in my calendar for the following day.

There it is. It’s not rocket science or something Earth shattering, but it’s definitely helping. Taking a page out of Big J’s book and a tip from my colleague, I’ve modified my schedule to introduce a very brief planning period every day. And it’s just one change that I think is helping introduce a good habit into my life.

This has helped me:

  • Stay on top of prepping food (which is a big part of the lifestyle I try to live)
  • Schedule time to relax (yes, I even schedule time for things like video games!)
  • Schedule time to blog (I run three blogs, and sometimes finding time to write feels like a chore)
  • Work on personal projects
  • … Feel like I’m being productive.

And no, I didn’t drop Google Keep–It actually helps feed into my scheduling! It’s great to look over my lists of things and try to create actions for them.

Next Steps

This simple hack is not only nothing particularly fancy, it’s also not bullet proof! But that’s okay when you’re always trying to continuously improve. Some snags I’ve run into or things I’ve thought about are:

  • How do I adjust my planned schedule when unexpected things come up? If someone drops in for a visit out of nowhere, or my car breaks down, or my dog decides to tear up the furniture, how do I make sure I can continue on with my planned schedule? Right now some things drop off the schedule or I push other things off to compensate. This hasn’t been too big of a problem so far, but sometimes this has a bit of a landslide effect and it makes the rest of the day feel unproductive. A little bit of dirt in the cogs seems to throw the whole thing off for me! This is something I’ll be thinking about as I encounter it and I’ll try to thing of some easy solutions.
  • How can I be more like Big J?! Aside from being bigger and stronger, how can I plan for more days? Big J plans every Sunday but I plan every night for the next day. Is there a happy medium? Planning every Sunday would potentially amplify the landslide effect I previously mentioned, but it would be a convenient single planning session for the whole week. Perhaps I’ll continue with the advice of my colleague and modify one part of my new habit at a time and look at planning for an extra day at a time and see how that goes!

If you’ve been making checklists and find that you’re unable to action items, try this approach! It takes only a few minutes every day, and so far I’ve been having great success in feeling productive. It’s not difficult, so it’s worth a try!

It’s Our Code


I’m sure what I’m about to talk about here doesn’t just relate to programming–it relates to any team-based project where everyone works on a small portion of the big picture. My experiences are primarily geared toward writing code in teams, so try to find parallels in your own work/experiences if you’re not a programmer. Anyway, enough of that.

When someone puts a lot of effort into something, they’ll often take great pride in the finished product. Of course, it’s great that they do! They’ve slaved away at something at work for days, weeks, or months, and it’s finally working/implemented. Other people are using it and it’s doing its job as expected. Awesome!

What kinds of things could possibly go sour here? If you have experience working in teams to complete a project, you might have some ideas.


You don’t own anything. You don’t own a single sentence or character you type and share with your team. You don’t own the title you came up with for the document, the name of a class or interface in your code, the conventions for indenting your variable declarations, the overall file & folder structure of your code, or even the Powerpoint you want to show to the sales and marketing department. If you’re on a team, you’re creating content for your team and your team assumes ownership of it (technically, I guess your company owns everything you do… but… stick with me on this one for a bit).

Ownership becomes a big problem in team environments. Person A worked on Item X, so Person A is assumed to be the owner of Item X. Now every time someone wants to use Item X, they need Person A. Simple? Yeah, that’s a simple system, but it’s absurd. Why don’t I just work on the most important part of the project, encrypt it, and secure my job for the rest of eternity? It’s hard to swallow sometimes, especially after pouring a lot of time and effort into something, but when you’re part of a team you should always be working in order to create things for your team. This has two major benefits:

  • You’ll adjust your perspective to be that of your entire team when you’re making something. (i.e. Am I working to their standards? Am I using their conventions? Can someone else understand what I’m writing here? Will this be easy for them to use? Can someone easily come along and modify my work to improve it in the future? etc…)
  • You remove the people bottleneck.

Ask the Experts

Instead of ownership, people should be considering “expertise”. What’s the difference? Well, someone who owns something is entirely responsible for it. If you want to use it, you ask the one owner. If you want to change it, you ask the one owner. If someone asks you about it, you better direct them to the one owner. The one owner becomes the bottleneck for whatever they own.

An expert is someone who has extensive knowledge in the area and there can be more than one. If you want to use something, you consult one of the experts for proper usage. If you want to modify it, you consult the experts. If someone asks you about it, you can direct them to any of the experts. See the difference? You widen (or eliminate?!) the bottleneck. You increase how robust your team is in terms of responsibilities.

What happens if Bob is sick for a week and he’s the only one who knows how to use the data layer when a big customer bug comes in? What happens when your co-op student who wrote your patented fizz-buzz algorithm leaves to go back to school and no other developer knows how to maintain the code? If there’s only one owner in each of these situations, you’re in a bad spot. If there are several experts who are knowledgeable in the area of code in question, you’re laughing.

Keep in mind, there aren’t only changes in your development staff–your code base is dynamic too.

Code Changes

One huge benefit that software has over almost any other product is that it’s dynamic. You can build something now that works, that may not work next week, that can be fixed the week after, and then later completely rewritten the week after that… and… well… you get the idea. Sure. I know you’re capable of thinking of situations where this doesn’t work with software or products that can somehow get the same benefit, but I’m not contesting that. The point is that software is (usually) flexible and dynamic and you need to treat it like that.

When a group of people has control over software, they can guide the direction it grows in. You get multiple people who are knowledgeable in the direction that the software can take and you leverage the group’s knowledge and experience collectively. Obviously consulting every single person on the team to change a single line of code is overkill, but at least you can find a happy medium in terms of architectural and API changes.

Your code changes because unless you executed the waterfall approach to programming 100% perfectly, your architecture is likely going to change. It’s just a fact of life. But there’s absolutely no reason to freak out. Embrace it. You’ve written unit tests for a reason, right? You’ve used interfaces and designed a nice clean API to decouple your code and make such changes easy. Duh! So don’t worry! You have a couple experts in the area of code that needs to change, so either they can tackle the changes or guide one of your more junior developers.

The same thing should hold true for any process or on-going project that is dynamic. Take measures to ensure that changes in the project or workflow can be done by anyone and don’t jeopardize the whole operation.


Here’s an assortment of tips (and hopefully some parallels for the non-programming types):

  • Use some sort of revision control. When something bad happens with your work, you always want the ability to press a figurative undo button. Look into something like Git, Subversion, or Mercurial. There are others out there too! Source control software isn’t just great for programmers… If you’re collaborating on a document of any kind, you can leverage source control to manage the revisions of the document.
  • Use tools that allow working on things in parallel. Again, source control helps here for programmers… but find solutions that mirror this. Look at Google Docs! You can literally work with people at the exact same time!
  • Practice and embrace the fact that you don’t own anything… It all belongs to your team, collectively. Keep that in mind or your team may start finding better team players! You want everyone to feel like what they are working on is for the team.
  • When you have something that’s dynamic and changes (like code), take the necessary steps to facilitate and embrace changes. Take precautions to ensure changes don’t mess everything up (unit test & code review!)


When you’re working in a team, you need to be thinking about your team. What you’re working on belongs to your team and shouldn’t be treated as your personal pet project that you control. This works best when you have multiple “experts” that have knowledge in a given area that can make changes or guide others to make the required changes. If you’re working on something that is dynamic or changes often, you can ease some pains by planning for change. Don’t resist it and fall apart when changes finally happen.

  • Copyright © 1996-2010 Dev Leader. All rights reserved.
    Jarrah theme by Templates Next | Powered by WordPress