Often Be Coding
It’s the most succinct and probably the best advice I’ve ever heard for developers — both aspiring and experienced: Always Be Coding. I recently read David Byttow’s article, ABC: Always Be Coding. How to land an Engineering Job. It is thoughtful and full of the kind of gems that I know will draw me back time and again as I continue to nurture my own coding skills. But in the end, much as I’d like to follow Byttow’s advice, I cannot. I can, however, strive to Often Be Coding.
The issue: I’m a “Lead.” For many years I’ve often been the Lead or Only developer/sysadmin/analyst on the teams I worked on, having deliberately cultivated my skills as a broad technology generalist. I worked almost exclusively in non-technical domains with non-technical professionals who required guidance, education and enough freedom from technology to focus on their own areas of expertise. I believe that I represent the majority of developers who must juggle coding obligations with many competing demands upon our time.
The simple fact is that the smaller your team, the more collateral responsibilities you are going to have. Similarly, the more complex your problem domain, the more non-coding work you have to do. Until late 2012, I worked at a world-class research University on a childhood cancer study. Although we were small, our work was so complex as to merit one major technology corporation making our research group a case-study for data management complexity. As a result, I had a wild variety of responsibilities on top of coding, including…
- deciphering HIPAA, domestic & int’l PII regulations and ensuring compliance
- analyzing/auditing/cleaning legacy data
- designing new systems and writing specifications
- defining and writing computer & data security policies
- researching existing and emerging infrastructure vendors and options
- …coding
I now work as the Lead Engineer and Architect of a startup in San Francisco where my scope of responsibilities, although very different, is equally broad. So what does Often Be Coding look like for someone like me?
A part-time developer — that is, anyone who isn’t paid to code full time — has to develop a “Coding Practice” in the same way that an artist creates his own personal Art Practice. Too many distractions and many responsibilities mean it can be challenging to know how to stop everything else and focus on coding. Just as important, we must be able to switch our focus back to our other work when the time is right rather than fall into a hyperfocus rabbit hole.
Creating a “Coding Practice” provides the structure and tools we need to Often Be Coding. We need a defined space and time that we work, free from distractions. We need projects to work on. We need sources of inspiration. And we need creative collaboration or exchange of ideas with other coders. Because our work or workplace doesn’t provide us with those things, we must create them for ourselves.
Structure Your Practice
Setup your Environment
Your Space: Artists, musicians and craftsmen set up studios where they test ideas, push boundaries, examine failed experiments. You need the same. If you’re fortunate, it’s your desk at the office. But it can also be an extra room in the house, a desk in the corner of your bedroom or your favorite table at the local coffeehouse.
Identifying your work space isn’t just about being disciplined. When you have a defined place to code and a habit of using it, entering that space signals your subconscious that it’s time to get down to work. Visit the local hackerspace or try a new cafe, of course, but identify your default workplace and commit to use it several days a week to get that cognitive payoff.
Distractions: During “studio hours” shut your door if you have one. If you don’t, invest in a very good pair of noise-cancelling headphones. I am highly distractible and have found that my noise canceling headset allows me to work in a bustling hacker space and be completely focused. They’re an investment but the payoff in productivity more than compensates for their expense. A clever alternative: friends have purchased flight line style hearing protection like these 3M Hearing Protectors. They’re $22 or so and protect up to 30dB. I’m pretty sure a set of earbuds fit very comfortably underneath.
Music: Even the best noise canceling headphones don’t filter out all sound. A rowdy bunch of engineers can easily exceed 30db. One remedy: Music. If you don’t already have “coding music” open a Pandora account and experiment with different genres until you find a style that helps you work. If you want some ideas, check out the “best background music for programming” thread on Reddit.
One last thing to try if you’re adventuresome… Try coding to binaural beats and judge for yourself whether that helps with focus and creativity. I switch between binaural sound and music when I code.
Communications: Finally, close your email and its distracting alerts and for the love of all things holy put your phone on vibrate. Better yet, turn it off.
Code Every Day
Set a Schedule: Now that you have your environment setup, it’s time to define a fixed time every day to code. Factor in time for production coding and then add appointments throughout the week where you throw paint on a canvas and see what happens. That is, schedule several weekly time slots for doing tutorials, working on side projects, tackling new coding practices/languages/whatever. Try that new library that you’ve been curious about. Don’t be afraid to throw it all out and start again. That’s what this time is for. If staying focused is a challenge, create clear differentiation between production coding time and your creative experimentation hours.
Experiment with Timing: I’m a night owl. I always have been. So I have always assumed that my most productive time to code was later in the day and again late at night when I was curled up in a comfortable chair or propped up in bed free of distractions. I can work for hours that way.
A few years ago, however, my husband and I began commuting in to work together. He would drop me off at work at 6:45 and continued on from there to his office. I was surprised to learn during those several years that I am orders of magnitude more focused and more productive in those quiet, often dark hours first thing in the morning. The difference was so remarkable that even now, when I work largely from a home office, I still get up early and get cracking.
The moral of that story: experiment with timing. Mornings are often considered the best time of day to have uninterrupted time to work but that’s not always true. Switch it up until you notice 1) the time that you feel most comfortable working and 2) when you are the most productive. Determine where those two overlap and make that your default coding hour.
Notify Your Colleagues/Family: Once you’ve chosen the time that’s most productive for you to code, let your colleagues (family, if home) know what those hours are and that you are unavailable during that time. Post them where folks can reference them any time. Write them down in your calendar. Set the “Repeat” schedule so your appointments with yourself show up every day or every Monday, or… whatever. Set a reminder to alert you 30 minutes or so beforehand that it’s time to get coding and set another timer to let you know when it’s time to stop.
In addition to a small sheet of paper with my hours that I taped to the interior window of my office. I had an old Peanuts Cartoon that showed Lucy Van Pelt sitting at her makeshift Doctor’s Office-cum-lemonade stand with a hand written note tacked to the front saying “The Doctor is In.” I crossed out “In” and wrote “Out” and kept that cartoon taped to the back of my door. When it was time to work, I moved it to the face of my door and shut it. Folks came to understand that when they saw Lucy on my closed door it meant that, barring an emergency, I was to be left to work.
Timers: The smartphone app world is an embarrassment of productivity tool riches. I’ve recently started using a nifty iOS app called 30/30. I’ve defined a few standard task lists to keep my “Studio Time” structured. My early morning list has the things I do every day: “coffee,” “take care of the dog,” “check online orders” and “check email” with times set for each. When I wake up, I press “Play” and wait for the timer to chime to indicate that it’s time to get to the next item. I also have task lists for coding, for learning, for “Wednesday”, etc. and I’ll choose the right one for that day’s plan. If you’re challenged by distractions or can get hyper-focused on the task at hand, these kinds of tools are handy. Even better, many are free.
Create a Plan
Once you begin a work session, define your objective for that day. Are you going to explore D3.js, try using the code from that blog post on async Javascript, spend an hour on the new book on Angular.js?
This is the most important part of my toolkit. It addresses my greatest area of weakness. I’ve actively cultivated a (deep) generalist skillset. So everything interests me. I find myself skipping from trying out a new library, researching good architecture for my current framework, catching up on the state of WebRTC, etc. But I have some projects that require that I develop deeper mastery of a couple of my tools. Skipping in and out of those projects doesn’t help me achieve my goals.
This is where my 30/30 tool comes in handy. It’s useful because I have a plan. After my morning task list is done, I’ll switch to the task list that gets me closer to achieving my goal of diving deeper into my Framework-du-Jour. This is where I’ll refer you back to David Byttow’s article for ideas. He has great suggestions for how to spend your study time. Pick one or two ideas, make sure to set achievable goals (Google “SMART” for good info on goal setting) then put them on your schedule and stick to it.
Growing Yourself
Find Community
It used to be that the greatest challenge for me was identifying a project or a problem that I could tackle as a coding project. Work provided ample options but I wanted a more creative set of problems. The more interesting the project, the more likely I’ll commit time to working on it.
After I left the university, I threw myself into the local technology community. I listened to a Javascript Performance tuning presentation given entirely in Pirate (on Talk Like a Pirate Day, of course), helped edit CSS animation documentation for WebPlatform.org and mentored women who were learning to use open-source hardware at Hackbright Academy’s first Silicon Chef Hardware Hackathon for Women.
What I learned over time is that being a part of the community pays unexpected dividends on the project ideas front. The exchange of ideas, the tech demos, the people I have met have all left me with a list of compelling projects and ideas as long as my arm. I have potential mentors, collaborators and commiserators. I show up at a Meteor Devshop and lo-and-behold, there’s someone I know. I pull up a bowl of trail mix and a caffeinated beverage and we talk shop. Checkout Meetup for similar meetings in your area.
Test Yourself Under Pressure
There is a growing list of online resources where you can test your coding chops. I’ve only begun to examine them but a few have gamified coding in a way that makes my competitive nature kick in. Code Wars uses a martial arts metaphor to challenge coders to solve problems (kata). Solve them correctly and you move up the ranks. Project Euler is another site I’ve used to test my algorithm skills.
Another way to measure the state of your coding skills is by participating in Hackathons. Here in the SF Bay Area, there’s one nearly every weekend. Where you live they may be less frequent and be a bit harder to find but it’s worth looking. Hackathons are a great place to meet other developers, learn new vendor services and technologies and test your mettle. Attend a few. Visit the vendors’ desks and learn what their technologies do. Let them inspire you.
Best of all, a Hackathon is a great place to measure how effective your (Often Be) Coding Practice is and will highlight weaknesses that will be good to target for the following weeks’ Code Plans.
Some sources for info on Hackathons:
Make Peace with Your Circumstances
Finally, as a Lead you have a choice to make. Most software engineers in our current market do have options. If developing coding mastery is your main objective, then you may need to revisit your current work situation and consider finding a position where you can make coding your primary focus — one where you can “Always Be Coding.”
The alternative is to recognize that with success comes compromise. Your senior engineer position or your new startup requires more of your talent than just your coding skill. Create an (Often Be) Coding Practice. Experiment with various “tools” and approaches to create a plan that satisfies your personal goals. But recognize that while coding chops are an easy measure of worth in our industry, they are often easier to acquire and maintain than the skills that allow you to lead teams, disrupt industries, employ wizards and support your families. Give yourself the credit you deserve for having those skills. Then go ask your newest engineer what technologies they find most exciting right now and see where that leads you both.
