When the topic of “road maps” was brought up to me, I’ll be honest folks – I didn’t really know what to think. I wasn’t sure where I should take this post, and definitely needed a while to think about what I was going to cover. Because it’s such a broad topic, and I’ve been getting a lot of great feedback on the workflow-related posts I’ve done, I thought I’d jump back to that topic for a minute – specifically what my process is like from day to day to make sure that I get the most out of each day.
To start with, I have something to confess, and I’m mildly scared of the backlash that I’ll receive in the developer community: I, Simon Proudfoot, still use pencil and paper. I know, I know – I’m basically a dinosaur in the dev world in this way. And I’m okay with that.
In the beginning, there was the list
I’m a big, big fan of to-do lists. The topic has been covered extensively, probably most famously in the book The Checklist Manifesto by Atul Gawande. I make one checklist at the beginning of the week of all the things I want to get done during the course of the week, and another checklist each night for the things I want to get done the following day. I do this because I find that if I make the daily to-do list in the morning, my list seems more reactive as opposed to proactive, and I’m more likely to prioritize things that have come up recently, but are not necessarily the most pressing at that time.
I find that checklists help me for a number of reasons:
by putting what I have to do into words, I’m able to crystallize and get extremely granular as to what I have to do for any given task
they help me prioritize
they keep me out of various apps and services that I find it incredibly easy to get lost in (configuring settings and the like) while simultaneously convincing yourself that you’re being productive
To touch back on the pencil and paper note from earlier – I’m a big proponent of physically writing out lists. The reasons are several-fold. To begin with, I find that it’s very easy for me to be back and forth between being visual (which, as you can imagine, is pretty important for a front-end developer) and being pseudo-technical (e.g. writing out rough dimensions, pseudo-code, or just notes). Moreover, I find that physically writing things out has an immense benefit with respect to memory retention – so much so that some days I find myself not needing to revisit the to-do list after I’ve written it.
An additional benefit that I’ve found, which I had not initially accounted for, is I find lists incredibly gratifying to writing out plainly due to the fact that physically crossing items out of a to-do list is to my brain what working out a “knot” is to my muscles.
While there are a bunch of project management tools and apps out there that a lot of people have spent hours working very hard on, to me, there are few things that can beat the basics.
The pencil and paper is dead. Long live the pencil and paper.
There are few things in this world that people seem to simultaneously love, hate, and love to hate more than the email. For me, I find that it’s very easy to get lost in my inbox, and I figure that my inbox is everyone else’s to-do list (I mean, really, it’s seldom that you ever get the “hey, keep doing a great job!” email, right?). Not so good for keeping me productive so much as reactive, which is not so good for my workflow.
For these reasons, I tend to not check my email until I have at least one (sometimes two) of my daily to-do items done, which gives me some productivity momentum that I can carry forward through the day.
Once I get to my inbox, it’s a bit of a war zone trying to figure out what to prioritize, which is where the weekly to-do list comes back in. When going through the various tasks, I simply ask myself “will doing this help me get any of my weekly to-do items done and make any of my daily to-dos irrelevant?” If the answer is yes, it becomes a priority for the day. If not, I simply mark it as “unread” (so it stands out in my inbox, as unread items in my inbox denotes something that requires further attention) and get to it that day if I can squeeze it in after my other tasks are done, or work it into a to-do list on a following day. Simple, but effective.
When coding something, especially from scratch, I like to break writing markup and writing styles into two separate chunks of work – markup first (this seems like a no-brainer) and styles second. I’ve seen a lot of people attempt to do both at the same time, and it hardly ever makes things easier. I’ve actually found, for myself at least, that it works the opposite in that it slows me down. The reason I tend to break this up into to sections of labour is that to me they are two different (albeit related) processes.
When first tackling the styles, I like to try to get to what I call the minimum viable page. Borrowing from the idea of the “minimum viable product” famous in software development, the idea is to simply get the base placement/styles of the design on the page as quickly as possible. I do this by doing something that many people seem to crook their necks at when they see me do it – something I call “blitz coding” – where I write a huge smattering of CSS without looking at the browser until I think I have a section done. Once I’ve written a good portion of the CSS for one section, refresh the browser and see how I’ve done.
Sometimes I do well, sometimes… it needs some love. But that’s okay – that’s the point. The point, like I mentioned, is to get the base styles and structure up as soon as possible. It doesn’t have to be perfect, it just has to work. If there’s any point where you want to find huge structural areas to your code, it’s as early as possible, not when you’re halfway through the page – so be thankful if you find that certain elements of your code need to be revised.
Once you’ve got your blitz-coded page up there, you can start adding all the bells and whistles, but I think it’s important to have the base of the page up as early and easily as you can.
Use these Tips to Improve Your Workflow!
I’ll leave you folks with those actionable tips, which you can hopefully keep to good use. My workflow road map works for me and I’d be interesting to hear people’s take on it, so don’t be shy to comment below what works for you and suggestions on things I should try! Until next time – keep your stick on the ice.