The Productive Desktop
After spending the past month dealing with personal things – new niece, nephew’s birthday, Easter, and my son’s 1st birthday, I’m back. I’ve transitioned off of a client, and I’m now working from home on another client’s project. I’ve found what it takes for me to get into the productivity zone, and I’m curious to learn what works for you.
Typically, I find myself most productive at home. I can work in my home office and stay focused on a project with Pandora as background noise. I find it hard to work at a coffee shop or elsewhere because I run the risk of running into someone I know and getting way too distracted. However, if I’m working with a partner on a project, then I’m at a coffee shop or elsewhere, as it’s nice to get away from my house and if I’m working with someone, there’s a lesser chance of someone distracting me if I’m engaged in working.
I have to take breaks every now and then just to keep myself from burning out. Breaks usually translate into writing a blog post – like now, working on laundry, going outside for a walk, eating lunch, or tending to phone calls.
I work best with dual monitors or at least 1 monitor and a laptop. Today’s configuration is a monitor hooked up to my Lenovo IdeaPad Yoga 13. I have my Balsamiq mockup of my client’s work – that I created yesterday – on the right. On the left, I’m alternating between SQL Server Management Studio and Visual Studio 2012. The client’s project is greenfield, which means I’m building my database off of my mockups and then building the code once the data is in place.
When I’m working on any project – greenfield or otherwise, I like having my mockups in one screen and my tools in the other. For me, I’m a very visual developer – I like seeing where I’m going and then developing towards that vision. If you’ve worked with me in the past, you know that I like to draw app concepts out – I’m known to draw my forms out on paper first. Balsamiq on a touchscreen will probably help phase me out of the “paper and pencil method” since it has a lot of what I need. But I still draw out my apps.
On a greenfield project, I mock up the UI first. I’m more of a front end developer than a service layer monkey (and I mean that lovingly). And while I like Super Mario Brothers, I don’t like plumbing, so you won’t see me getting excited about projects with a lot of back end development. Once I get my UI done, then I build my database. Because I see the world in patterns and data, it’s easy for me to build my database tables and relationships based off of UI mockups. Once I’m certain of how the data needs to be stored and how it’ll get in there, then I build the guts of the system, making the mockup come to life.
On brownfield projects, when I’m working on my own, I try to get UI screenshots so that I understand what I’m working with. At that point, once I have that understanding, then I look at the database and hope that it’s somewhat near what I had envisioned. However, if it’s like some projects I’ve encountered, the database may be a lot worse than I envisioned, which then causes me to come up with a new way of working with the existing database or a plan to migrate the old data into a new database. Once the data situation is checked out, then I get into the code.
This turns out to be the recipe for me to be the most productive. However, different people find different approaches work for them. So I have to wonder… do you have a different approach to things? Care to share your approach? Blog about it and leave a link here in the comments! I look forward to hearing about your approach!