Personal Development – What William Said

Finishing

November has been a crazy month for me. Despite the fact that I’ve been out of the state for eight days this month (and, of course, all the craziness surrounding the holidays) I’ve been doing NaNoWriMo.

In NaNoWriMo, National Novel Writer’s Month, you commit to writing a novel during the month of November, where a novel is defined to be a story consisting of at least 50,000 words. You aren’t allowed to start until 12am on Nov 1 and must finish by 11:59pm on Nov 30. I’ve taken a stab at it twice in the past, but have never actually finished. This year, with five evenings left to work, I’m about 14,000 words away from the goal. I fully intend to reach it.

Why keep doing this? As happened the previous two times that I tried participating, my motivation started off strong and quickly waned. But I kept at it, staying pretty close to the required daily average word count up until my travel started. This week, I’ll have to average close to 3,000 words per day (as compared to the 1,667 required if you’re consistent for the entire 30 days). I’m under no illusions that I’m turning out the Great American Novel. Nor do I expect to sell a million copies; indeed, the smarter move would have been to spend the month continuing to revise my computer science textbook, which I actually do hope will sell quite well. There are certainly ways I could have spent all these hours that would result in a much better return on my investment. So why bother? I gain two things by finishing:

1) I’ll have written a novel! Tons of people want to have written a novel, but actually finishing one is quite a bit less common. It’s another item off the bucket list.

2) I’ll have met the goal. 50k words is challenging, arbitrary, and (for those of us who don’t write full time) pretty difficult to get done in a month. Many days this month I haven’t wanted to write at all – in fact, I’m pretty burned out on it right now – but I force myself to sit down at the computer each day (when I’m sure my wife would rather I come upstairs and watch House of Cards) and bang out the words. NaNoWriMo is a commitment, if only to yourself; once you set a goal, will you keep doing whatever it takes until you reach it? Are you a person who gets things done?

Applying leverage

I was reading a finance thread recently where the concept of leverage came up. Simply put, this is asking what activities get you the best “bang for your buck”.

If you’re a minimum wage worker, then activities that save you money are a good use of time because the return is high compared to your hourly rate. If you’re making eight bucks an hour and can save $2 by spending ten minutes making your own lunch, or $10 by spending an hour sorting through coupons, then those activities essentially pay better than working. On the other hand, if you make six figures, those activities aren’t a good use of time (unless you like making your own lunch). In fact, it’s even financially sensible to pay others to do chores you might not enjoy, such as yard work, if it frees up time that you then apply to higher-paying projects.

This applies at the business level as well. If task X takes a senior developer making $100 2 hours and a junior developer making $50k 3 hours, it makes more sense to assign it to the junior developer even though it will take longer. This has two benefits: the total cost of the task is lower, and it frees up the senior developer to work on projects that require his or her expertise.

At a personal level, this also explains why it makes sense to focus on your strengths. Suppose that on a scale of 1-10, I’m at skill level 1 on skill B and skill level 7 on skill C. I’m most likely going to work primarily on projects involving skill C, since that’s what I’m good at. Unless there’s some reason I really need to use skill B, increasing it to level 2 is less useful than increasing my skill C to level 8, which makes me even more valuable for projects that require skill C. (This is a long-winded way of saying that it’s good to specialize)

Would you rather be good at several things, or great at one thing? Would you rather spend an hour saving $10 or making $50? Where does investing your time return the best results?

Thoughts on That Conference 2018

For the last few years, the beginning of August has meant one thing for me: That Conference! The joke eventually starts getting old, but the conference is always worth the time. 2018 was my fourth year attending and second year speaking.

My favorite talks this year were the first two keynotes. When I saw the title of Jessica Kerr’s talk, “the Origin of Opera and the Future of Programming”, I assumed she meant the web browser. No – she actually meant Opera singing! This isn’t a topic that I have any interest in whatsoever…but Jessica’s enthusiasm actually made it interesting (and yes, she did relate it to programming). Then Cory House gave the keynote I was particularly looking forward to, on building a career; he talked about the tradeoffs he had to make to do what he does. Videos of both talks are available on the That Conference Facebook page.

When I’m writing or speaking, I like to choose a topic that’s more conceptual than language X or program Y. Last year my talks were on accessibility (at That Conference) and sorting algorithms (at MKE.NET); this year my talk at That Conference was about graph theory and I’ll be speaking on accessibility again at Cream City Code. Over the last few years I’ve noticed that there are a lot of software developers who don’t have computer science degrees and are interested in seeing what they’ve missed, which is why I’m giving talks on various topics that would normally be covered in the course of a CS degree (and am writing a book in the area as well). I was happy to see quite a few people turn out to hear what was essentially a math talk and stay engaged to the end. Graph theory isn’t something that most of us will use every day, but it definitely has a lot of practical applications in programming.

If you came to my talk, I appreciate it! See you next year for more waterpark and bacon :-)

Graph Theory slides for That Conference 2018

Setting Priorities

Assuming you get to set your own schedule, how do you choose what to work on next?

Do you pick the most important task? The one with the closest deadline? The one most likely to make your boss (or significant other) happy?

After I read about Kanban, I started trying to arrange my tasks such as to minimize the amount of work that I have in progress. My goal is to minimize the number of things that I am responsible for at any point in time.

Obviously, this doesn’t mean that the highest-priority tasks don’t still get done first – I can’t imagine my team leader would be happy if I told him I was going to put off responding to a critical bug report for a week because I have too many low-priority tasks on my plate – but it means that I’ll try to prioritize finishing something that’s already started over starting something new. This results in less time for tasks overall, because you’re more likely to get back to things while they’re still partially cached in your memory, rather than having to get up to speed again before you can start working. I actually prefer to tackle the tasks that can be knocked off quickly before anything else, and get them through the process and off my plate entirely so they’re not taking up any mental energy.

Plus, it sounds a lot better (at least to me) to say “I finished 5 tasks last week and I’m working on my big project” vs just “I spent last week working on my big project.” Particularly when progress on the larger project is difficult to measure, this shows you’re still getting work done.

On work, burnout, and recovery

A while back, I was asked what I would change about my job. My answer was that I would like to have more vacation time.

In other words…what I would like to have for my job…is less of it.

The funny thing is, I like my job. It’s consistently challenging. I have to do and learn new things all the time. The hours are semi-flexible, the dress code is practically non-existent, and the cafeteria is a major perk.

All that – and it’s still easy to get burned out. I’ve been in the same job for seven years, now. There have been a few title changes – software developer to software developer II to senior software developer – the people are different, the languages are mostly different..but I’m still programming. Now, I like programming – I like technology in general – but I’ve never done the same thing for so long. I get bored and want to move on to something else.

So why not move on from programming? A big part of it is the money, of course – being a software developer pays really well. I’m getting older and I have a family to support, which makes jumping around harder. On top of that, this is something that I CAN do long-term – there are new challenging all the time, which is what makes it interesting. And yet – I get burned out.

There are different ways of fighting it. Sometimes I go to programming conferences, which helps me get excited about coding again. Sometimes I work on my book – I love teaching, and my book (which I’ve been writing sporadically for a few years now) is one way to do that. But sometimes I feel like I just need a break. In 2016 my wife and I spent two weeks in Europe, and it was amazing; for two weeks I completely cut myself off from work, blocked email from my phone, and just relaxed. I needed that.

Little bits of vacation – a day here, a day there? It’s not enough. I end up answering work emails and don’t clear my mind. I need a real break, one where I focus on something that’s not work related. A week at BGGCon, focused on playing board games with my friends. A few weeks in Europe, focused on traveling with my family.

I like my job. Time away from it helps me to be better.

Goals for 2018

I’ve never been a believer in New Year’s resolutions; there’s a reason it’s a cliche to start a new exercise program in January and abandon it by February. Resolutions tend to be things that people would like to do…and by the end of the year, they become things that people would have liked to have done.

At the same time, goals can be worthwhile – especially if they’re SMART goals. A SMART goal is one that is specific, measurable, actionable, realistic, and time-bound.

SMART Goals
Specific: It is clear exactly what the goal is.
Measurable: It is clear whether the goal has been achieved.
Actionable: It’s clear what actions need to be taken to achieve the goal. “I will be a millionaire in a year” isn’t actionable; “I will spend at least two hours per week writing” is.
Realistic: The goal is something you can realistically achieve within the given time bound.
Time-bound: There is a deadline for when the goal will be accomplished.

For 2018, I’ve decided to set New Year’s commitments. Why commitments instead of resolutions or goals? Because I’m committing that these are things I will get done this year (and I’ve actually set up a penalty for if I fail to accomplish any of them). In 2018, I am committing that:

I will publish at least one book – this will probably be either my computer science textbook or my first novel.
I will apply to speak at [at least] two conferences – probably the two I spoke at in 2017 and any others that look good.
I will update my blog at least once per month.

None of these goals are based on things outside of my control; I’m not resolving to make six figures from my book (although it would be nice!), have my talks accepted, or write an outstandingly brilliant post; I’m simply committing to doing the work, and posting a public record of that commitment. When I’m running on way too little sleep because the baby was screaming all night long, I won’t have the option to say “oh, I guess I have a good excuse for not meeting my goals this month” – I have this commitment to hold myself accountable.

Are you setting goals for 2018?

Focused effort, faster results

Recently I read a post about productivity. The point of it was that you have a fixed amount of effort that you can put in every day, and you’ll get a lot further if you concentrate that effort on one task rather than dividing it between many tasks.

I’d actually like to think of this in terms of physics. Imagine that you have a number of heavy blocks you need to move; these represent all the work you have to get done. If you go up to each block and give it a little tap, you’re unlikely to overcome the block’s inertia; it will stay where it is, and you’ve gone all day without accomplishing anything. On the other hand, if you apply all of your effort to one block, you may be able to move it quite some distance. It may look like you’re doing less – you’ve only worked on one project, rather than many – but you’re actually getting more done.

We already know that multitasking doesn’t work, but even when we avoid it, how often do we engage in serial single-tasking – that is, doing one thing at a time, but jumping back and forth between different types of tasks? If each task only takes a few minutes, but comes from a different domain than the previous task, we still have to deal with the context switches that we’re trying to avoid by not multi-tasking.

On Monday, I spent my day focused entirely on doing fixes to a particular section of code. While I was doing a lot of different things, they all had the same basic context, which meant less for my brain to keep track of. I ended up having one of my most productive days ever, designing, developing, and checking in five discrete fixes. Last week I spent more time working on some larger fixes, but I let other work pile up while I focused on getting those big fixes done, so I didn’t have to take attention away from what was most important.

This isn’t a new concept – productivity gurus will speak of the importance of batching, where you save up related tasks (say, responding to emails) and tackle them all at once, also to avoid the context switches. How can you be more productive by doing less?

Stop Starting and Start Finishing

One thing that I’ve always struggled with is a short attention span; I tend to get bored pretty easily. One thing I like about my current job is that I get to work on a lot of different stuff, which helps keep me interested, but it’s still difficult to maintain focus, and I’ve been looking into different systems to help with that. Earlier this month my son was born, which is awesome but means I have less time and energy, more expenses, and less income (due to my wife staying home to take care of the baby), which adds that much more pressure to try to be really good at my job.

One of the things I tried last year was KanbanFlow, which is a free (and paid, though I haven’t felt the need for the paid features) tool for tracking your work; I liked the ease of use but didn’t really feel that I was getting that much out of it and more or less stopped using it. Recently, however, I’ve been reading the book Kanban in Action, which clarified for me what I should be doing, and I’ve started using my Kanban board again. I’m actually feeling more productive, so I thought I’d document what I’ve been doing.

My Kanban board is set up like this:

Screen shot of the top of my Kanban board — My Kanban board as of this morning.

One of the big things in Kanban is the Work in Progress (WIP) limit; the idea being that if you limit how much work you (or your team) can take on at any one time, then each piece of work flows through the process more quickly. This leads to less work overall, because any issues get found more quickly, before you have a chance to forget the details of what you’ve been working on. By limiting how many balls you have in the air at any given time, you also reduce the number of context switches you need to make, which helps you to be more efficient. In this case, you can see that my “In progress” column – the things that I’m actively working on – has a limit of three items; once that’s full, I can’t start working on anything else until I’ve moved something out of that column. Or as the book says – stop starting, start finishing!

My process here is to start the week by making all the decisions about what to work on and put those things on the to-do list in rough order of priority. At the start of the day, I can move a day’s worth of work over to the “Do today” column (under anything that might be left over from the day before); as things move off my “In progress” list, new items get pulled in from the top of “Do today”. Once I’m done with development that someone else needs to look at, it moves to “Waiting on someone else”; when it comes back it goes back into my “Do today” column. Any new tasks that come in can go into any of the first three columns or simply thrown on the backlog, depending on urgency; a customer issue will be worked on immediately but anything else needs to wait until the current task is complete.

Pretty straightforward so far, right? Even if I’m bored with working on something, it still needs to get done so I can move it out of the “In progress” column, and I need to stay on task to be able to clear out the “Do today” column. This brings us to the next part, the pomodoro timer:

Screenshot of the pomodoro timer

The pomodoro technique works with the understanding that it’s extremely difficult to stay focused for long periods of time, and that our brains need to rest every so often. Thus, you work for a timed 25 minutes and then get a 5 minute break to walk around, visit the restroom, check Facebook, whatever. The timer here lets you select the task you’re working on, so you can use it to keep track of how much time you’ve spent on each task. Meanwhile, it’s easier to stay focused because you know there’s a clock ticking down and you just have to stay on task for a little while longer before you can take a break. When the pomodoro ends, you’ll be asked if you stayed on task, if so, you get rewarded with FlowPoints. It’s a simple motivational system, but it seems to work.

Another technique is to break up those tasks that require the most decision making, so we’re not constantly making demands on the same part of the brain. Do the important development first, before spending time answering emails. Put in some mindless tasks, like filling out time cards and walking to meetings, in between heavy programming sessions.

Roles, titles, and growing into expectations

Last week, I found out that I’ve been promoted to senior developer. From a practical standpoint, this doesn’t actually affect me at all; the titles system was put into place to deal with immigration requirements, and the ‘promotion’ doesn’t signify a change in my responsibilities or compensation. In fact, this actually happened over a month ago; it’s just of so little import that nobody bothered to tell me about it!

Still, this seems as good a time as any to reflect on where my career has been going, where I’d like it to go in the future, and what I need to do in order to get there.

Over the last year I’ve spent less time working on code (although that’s still what I’m usually doing) and more time doing project management-type activities: setting priorities, writing designs, explaining things and providing feedback to other developers. I’ve said in the past that I’m not interested in become a team lead (partially because I want to focus on becoming a better developer and partially because I don’t want to spend all day in meetings) but I find that I actually do enjoy overseeing a project.

I’m now feeling that I’d like to move into more of a software architect role. I’ve seen this defined as the person who takes the blame for the quality of the software; he sets the overall direction for the project. For the project that I’ve been overseeing, I’ve worked to set standards that everyone working on the project follows, and the result is code that’s much easier to work with; I actually feel that my biggest contribution to the company will be how much easier it will be to make updates to my team’s part of the software in the future.

So what do I need to do for this?

On the interpersonal side, pretty much every job I’ve ever had has involved me being in a leadership role, one way or another, so I have no issues with that and I enjoy helping the other developers; my only real challenge in this area is that I’m hard of hearing and many of the other developers have accents, so face to face meetings are challenging for me. Unfortunately that’s not really anything I can change; all I can do is work around it.

On the technical side, I feel like my largest challenge is in testing; when I’m doing PQA (programmer quality assurance) on other people’s code (or even my own) I don’t feel that I’m catching as many issues as I would like. So that’s something for me to focus on this year: improving my testing skills. Interestingly enough, this area is also one of my strengths; since I have a bit of an unusual background (teaching and editing) I do tend to catch different problems than the other developers. So my technical goal for this year is to improve my testing process. What I’m going to try to make time for is to go back and look at development I’ve touched where a bug got through, and see if that’s something I could have caught. If it is, maybe I can add something to my testing checklist so that kind of bug doesn’t get by me the next time.

In other words – I need to discover new steps I can take to improve my work and refine my processes to include those steps, playing architect on a small scale. The better the process – assuming it’s followed – the better the end result. What processes can you improve this year?

The daily accomplishment, or, did I get anything done today?

Today I installed a new faucet.

Not a big deal – I’ve done it before and it’s not that difficult, just a bit of a pain (and hard on my back). But I’m still counting it as my accomplishment for the day.

When I was a kid, I always planned to get stuff done over the summer – learn Java or whatever – but more often than not it didn’t happen. When your primary focus is on big projects, it’s easy to have days when you’re not seeing any progress, or worse, actually not making any progress. I had that problem with my dissertation – it was so involved that it was difficult to sit down and write out the next lemma. I have that problem still; I’m working on a new book, but it’s such a large project that it’s difficult to just work on a small part of it.

It’s no secret that the way to get a big thing done is to break it into a lot of little things; sometimes it’s just hard to work up the motivation to do the little things. What I’m trying this year is simple: at the end of every day, I want to be able to look back and say that I accomplished at least one thing. If it’s getting towards the end of the day and there’s no sense of accomplishment yet, well, that should be my kick to keep going until I have something.

Thursday it was finishing off a decent-sized piece of functionality I’ve been working on. Today it was replacing a faucet and writing a blog post. I don’t even remember what it was the other days, but I do remember that there was something – even if small – each day of the year thus far that made me feel that, that day, I had accomplished SOMETHING.

And when you keep accomplishing little things? Maybe it helps you find the motivation to get the big things done.

Now, about that book…