I like working. It tickles my brain, and I enjoy helping people through code. Sometimes I get stuck on stuff, but I can generally solve problems and make stuff easier. It's also good for long-term stuff.

I also like spending time with A- and learning from her. I'd pick A- over consulting because tasks generally keep and kiddos don't. I like snuggling with A-, and I like playing with her.

If I work late at night, I can generally do 1 to 2 hours of work between interruptions, so there's a bit of task switching. I can usually pick my stopping point for the night if I stay up a little later. My brain buzzes a bit afterwards, so it's hard to sleep. That sometimes affects my time with A- the next day.

If I get a babysitter and work in the afternoon, I can talk to people and focus better. I can generally do 2 hours of focused work, and sometimes more if A- is having fun. She strongly prefers playing with me, though.

If I wake up early, A- often insists on snuggling in bed. When she wakes up, I end up stopping work abruptly, so it's good to take notes along the way.

If I'm careful about the tasks I commit to, I give people a chance to develop their own skills while being able to squeeze in the occasional low effort, high reward thing. I can also get better at making my prototypes easier to turn over with comments and notes.

2-4 hours is a nice chunk of focused time that I can use to make decent progress. How can I arrange my life so that I can do that regularly? Monday night or Tuesday night might be a good time to stay up late working. Monday night is particularly good, since I can take A- to the drop-in centre on Tuesday for social interaction.

It's also good to use some focused time for personal projects: journaling, Emacs News, kaizen. As A- becomes more independent, I might start modeling 15 minutes of independent reading and taking notes.

So maybe a rhythm like this:

• S: W-
• Su: Emacs News
• M: Consulting
• T: Free choice
• W: Sleep
• Th: Kaizen
• F: Journal, review

On the flipside, more sleep makes everything even better. When I'm well-rested, it's easy to be playful and creative. So I won't push myself too hard, I'll keep commitments light and manageable, and I'll code with an eye to turning things over to other people who can run with stuff.

It might be good to experiment with babysitting monthly, to monitor her readiness for it.

I like learning the things that life with A- can teach me, even though they're harder and less externally validated than coding is. The important thing is to be where I am.

Eventually A- will be in school, or independent enough to want to go play by herself or with other people, or okay with playing with sitters or in daycare. That time will come quickly enough. No need to rush it.

I do a tiny bit of consulting to help a long-standing client with prototyping and data analysis. It lets them take advantage of the experience I’d built up with their tools and platform, and I get to keep my technical skills and professional network going.

Before we went on our trip, I was averaging about two hours a week, after A-‘s in bed. A- tends to nurse frequently at night, probably to make up for distractions during the day, and we’re okay with this. Sometimes I might be able to do an hour or two of uninterrupted work, and sometimes I clock in and out as I get interrupted by nursing. Fortunately, I built a pretty handy time tracking interface, so it takes only a few taps on my phone.

Because of my limited availability, I try to pick tasks that don’t require a lot of coordination with other people, that can bear with interruptions, and that aren’t risky when done with a fuzzy brain. So, no meetings, no big chunks of new things to learn, and no messing with write access to production data if I can help it. Despite this limited availability, I was able to prototype a few add-ons they wanted, yay!

IA- has been a bit more clingy lately (might be because of teething) so I’m not sure how much time I’ll have in the next little while. I’d like to have the brainspace to learn and build new things so that I can help out my main client, since he has moved up in terms of his role, but that can probably wait. In the meantime, we get decent ROI if I focus on quick answers and prototypes.

t’s important to me to manage expectations well and to turn over as much as I can. This means not committing to more than I can work on, and keeping people up to date on timelines and risks; making sure the team has access to my code and can take things over if they need to; and building in small steps so that I can deliver something of value as soon as possible. It’s fun to break an idea down into the minimum viable product, the intermediate steps to get there, and the incremental enhancements that would make it even better.

I’ve thought about expanding my available work time, but I chose not to. This is the last month and a half of W-‘s parental leave, but I’d rather spend the time enjoying parenting A- with him than squeezing in more computer things. He’s awesome with A- – better than I am. I’ve sometimes asked him to take care of her while I handled high-priority things that needed focused time (such as doing my business tax paperwork!), but I don’t want to commit more of that time than I need to.

At the moment, I’m not particularly keen on getting a babysitter after W- returns to work. I know the math could work out and that the socialization might even be an awesome thing for A-, but I’m curious about the things I might learn from going through this experience myself. I like the fun of problem-solving and the validation of helping a great team, but I can get that later, too. I also don’t quite trust my ability to pick a good person and build the kind of long-term relationship that would be good for A-, so there’s that too. In the meantime, I can learn from A- as she learns, and I can try to shape her world. We’ve got a rare opportunity to do this in a flexible way, and I want to take advantage of that.

So, how do I want consulting to fit into my life? I think the current arrangement is pretty good. I prioritize my self-care, A-, W-, and the general upkeep of the household; then my journal and Emacs News, since both are time-based; then more discretionary things, like consulting or personal coding. The clients seem happy. They’re not slowed down by me or kept hanging, and they get good value considering the time and money involved. I might be able to do more work if A-‘s sleep solidifies, but I’m in no rush. It might be that I’ll have limited work availability until she’s old enough for playdates or school, and that’s fine too.

I’ll think about this again after we settle into new routines, when W-‘s back at work. It’ll be interesting to see how things change.

It seems almost given that you should follow your passion, but what if you don’t know what that is? Or what if following your passion prematurely can lead to failure?

In So Good They Can’t Ignore You: Why Skills Trump Passion in the Quest for Work You Love (2012), Cal Newport gives more practical advice: Instead of jumping into a completely unknown field to follow a passion which might turn out to be imaginary, look for ways to translate or grow your existing capabilities. Develop a craftsman’s mindset so that you can improve through deliberate practice. Often it’s not a lack of courage that holds you back, but a lack of skill. As you build career capital, you can develop your appreciation of a field, possibly leading to a clear passion or a mission. You also can make little bets that help you move closer to the cutting edge so that you can make something remarkable. This qualifies you to do greater work that involves creativity, positive impact, and good control.

I’ve sketched the key points of the book below to make it easier to remember and share. Click on the image for a larger version that you can print if you want.

I agree with many of the ideas in the book, although I’m not entirely sure about the dichotomy that Newport sets up between passion and craftsmanship. Many of the passion-oriented books I’ve read encourage you to try out your ideas before making major changes to your life – for example, by working on your own business on weekends or by taking a second job. Very few people advocate leaping into the unknown, and if they do, they recommend having plenty of savings and a network of mentors, potential clients, and supporters. So the book comes down a little harshly on a caricature of the other side rather than the strongest form of the opposing side’s argument.

Amusingly enough, although the book describes What Color is Your Parachute as “the birth of the passion hypothesis”, I remember coming across the idea of gradually transitioning to a new field by first exploring something more related to your current one in What Color is Your Parachute, which recommends it as a way of lowering risk and clarifying what you want. I also remember the What Color is Your Parachute book to be less about impulsively following your whims and more about identifying and exploring the skills that gave you feelings of accomplishment.

Anyway, I think you start with curiosity. Then you develop a little skill. This makes you more curious, which helps you learn more, and so on. That–combined with feedback and appreciation–helps fan a spark of interest into a flame. So it’s not really that you start with passion or that you spend many years developing your craft before you can enjoy it, but rather that you gradually figure out both. (I have a feeling this somewhat agrees with what the book would’ve been if it weren’t trying so hard to distinguish itself from advice about passion.)

We just don’t normally express ourselves that way, I guess. It’s almost as if people are expected to either have strong convictions about their life’s work, or to be lost at sea. If you say, “I’m still figuring things out,” it’s like you’re a drifter. If you say, “I’m not passionate about my work right now,” it’s like you’re just going through the motions. I don’t agree with this, which is why I like the book’s emphasis on forming hypotheses about what you want to do, and testing that with little bets that also develop your skills. (This is particularly apropos, since J- will be choosing a university or college course soon.)

Anyway, after reading this book, the specific take-away I’m looking forward to following up on is that of exploring adjacent possibilities more systematically. How can I move closer to the edge of discovery in myself and in the fields I’m interested in, and what new areas have been opened up? I’ve been thinking about designing more focused projects that result in things I can measure and share. That’s similar to the middle layer of the pyramid that Newport suggests:

1. Tentative research mission – figuring out what you want
2. One-month exploratory projects with concrete results
3. Background results

On the whole, the book has a good message. You don’t have to love something to get good at it. Sometimes (often?) getting good at something will help you like it or even love it.

But the book feels a little… uneven, I guess? The anecdotes feel like they’re making too-similar points. The ones about failure feel unsympathetic and hand-picked for straw-man arguments. I imagine most businesses are not started out of the blue because of some grand passion. People prepare, they minimize risk, they work hard. Passion for something – either the work, the customers, or even just the life that’s afforded by the work – pulls them through the toughest parts and keeps them going. Sometimes they succeed for reasons unrelated to their skills; sometimes they fail for reasons unrelated to their passions. Sometimes things just happen. There are everyday businesses that don’t have the creativity, grand positive impact, or full control that are idealized in the book, but that still give people enjoyable lives. I think that the techniques and ingredients described by Newport in his book are good, but they are not essential to an awesome life.

On a somewhat related note, in the past few years, I’ve been learning to let go of the desire for either passion or mastery, Instead, I’m embracing uncertainty and beginner-ness, setting aside time for things I don’t quite love yet. It’s a challenging path, but it tickles my brain. =)

Anyway, if you’re looking for a counterpoint to the usual “Follow your passion!” advice and you want to check out So Good They Can’t Ignore You, you can check out this book.

Enjoy!

Don Maruska and Jay Perry’s Take Charge of Your Talent: Three Keys to Thriving in Your Career, Organization, and Life (2013) has plenty of tips for developing your skills and taking charge of your career. I’ve sketched the key points of the book below to make it easier to remember and share. Click on the image for a larger version that you can print if you want.

I liked the chapter on reflecting on your talents through a structured conversation with someone who can reflect back not only your words but also your feelings and hopes. Sometimes we don’t see the patterns in our thoughts until someone points it out to us. The questions are also good for personal reflection, and I’m looking forward to using them in my planning.

Sometimes people ask me to help them figure out what they want to do. Other books I’ve read about coaching tend to be pretty high-level, but this one gives concrete advice, including some notes anticipating potential responses or difficulties.

I also liked the chapters on creating tangible assets and sharing them with other people. That’s been a great learning- and career-booster for me, and I hope other people will try it out as well.

Among other things, the book also suggests listing at least one hundred resources (people, places, things, skills, …). Forced-length lists are great for creativity because you dig deeper than your surface answers, often coming across surprises. When you review your list, think about ways that you could make even better use of those resources. The book also suggests taking a look at your top 10 resources and working towards 100% use of them, which will be an interesting challenge. The third related exercise is to combine different resources so that you can break through obstacles or come up with interesting mash-ups – forced association, another great creativity technique. I like this reminder to apply creativity so that you can recognize and make the most of your resources, which allows you to MacGyver your way to growth.

Want the book? You can buy it from Amazon (affiliate link) or check out their website at .

Like this sketch? Check out sketchedbooks.com for more. Feel free to share – it’s under the Creative Commons Attribution License, like the rest of my blog.

Enjoy!

Now that we're (mostly) done with the conference and the major system upgrade, I could relax and go back to my old schedule of working a few days a week. But this consulting contract is winding down soon, so it also makes sense for me to spend the extra time helping team members learn, polishing up prototypes, and braindumping as many notes as I can into the internal social network. The more of my brain I can externalize, the more other people can build on, and the easier it will be to pick it up again even after some delay.

The next week or two won't have as much of a workload as we had during the conference. On a scale of 1 to 10, with 10 being super-intense (cutting into sleep), I'd say that the conference was probably around 8: I managed to do lots of work and get enough sleep, but I didn't do much else. These next few weeks will probably be around 5-7. I can still help out with things at home and with Hacklab and I'm totally okay with spending a little time playing video games (W- and I are currently playing Persona 3), but I'm holding off on personal projects until I have more brainspace.

Anyway, for the next time that I need to prepare for intense days (something like 8-10 on that scale), here's something I drew in mid-September. I've updated it with notes on how things actually worked out.

2014-09-15 Preparing for intense days

• Avoid long stretches of work. Coding is better when well-rested.
  • This worked out okay. I coded a lot, but I switched between coding different types of things.
• Go to bed early. Get 8.5-9 hours of sleep; more if you anticipate anxiety.
  • Yup! Managed to get plenty of sleep.
• Pick one thing. Focus on it.
  • Mostly managed this.
• Minimal computer or phone use in the evening. Draw instead, as a way of braindumping/thinking. Index cards can be useful for jotting down thoughts.
  • As you can see, I'm still processing the notes from then. =)
• Minimal socializing – use the time to recharge and prepare the foundation. Spend time with W- taking care of things. Guiltlessly reschedule other things.
  • Worked out well. Substituted money for time when it came to Hacklab.
• It's okay to take the subway instead of biking to work – minimize risk
  • I even took a few cabs! Boggle.
• Still go jogging with W- when weather and schedule permit; if not, do exercise ladder at home.
  • I want to reestablish this habit. Not ingrained yet.
• Eat freezer meals; get takeout if necessary. (Or frozen lunches from stores as stopgaps? They're not as nice, though.) Bulk-cook easy recipes (rice & lentils, congee, curry).
  • We ended up ordering pizza a few times. At work, people had food delivered too. It was nice to return to home-cooked meals, though!
• Keep the end in mind (reason and number of days).
  • That was helpful. =)

I don't often go on work sprints like that, but it's nice to know our lifestyle can handle it!

One of the things I realized from dealing with that programming issue is that I don't have a mature development workflow for front-end work yet. On previous projects, I focused mostly on back-end development. I had somewhat gotten the hang of test-driven development and code coverage when using Rails before, and I set up an issue tracker for my previous teams. For my main consulting engagement, I shifted to working on mostly HTML, Javascript, and CSS. I'd handled a bit of that before, but we usually worked with designers who did most of the heavy lifting (and the cross-browser fiddliness). Over the past two years,  I picked up more JQuery and Angular, fought with Internet Explorer 7 and then 8, and explored Chrome's developer tools a bit more.

I didn't have things quite set up the way I think other people have. I felt mildly guilty about installing programs that were not available from the client's internal software site, although Emacs was definitely worth the twinge of unease. Even the version control I used was ad-hoc, using Git on my computer to manage snippets for copying and pasting. I still haven't mastered the Javascript debugger in Google Chrome, much less the tools available for other browsers. (Hence all the grief Internet Explorer gave me.) I didn't have a test framework set up, so I often committed regression errors and other mistakes. I haven't yet internalized all the cool development tools in Emacs, like Smartparens and Magit. (I'm slowly getting the hang of multiple-cursors-mode, though!) In terms of workflow maturity, I felt more like someone a few years out of university (or maybe even someone in their final year of classes!), and definitely like someone cobbling things together instead of picking up practices from a well-running team.

My main consulting engagement is coming to a close, but I'm looking forward to learning more about the craft of software development. I have a few personal projects to practise on, and it might be easier to Do The Right Thing when you're less worried about potentially wasting the client's time. I'm looking forward to familiarizing myself with more of the nifty features in Emacs. I'm also looking forward to immersing myself in the right ways to do things with popular frameworks, including testing and deployment.

I'd like to become a good programmer someday. What would that be like? For the particular way that I work–a generalist pulling together different things quickly–a good programmer might be one who has a neatly organized library of snippets, and who writes modular code with simple tests that exercise different functionality. Using a debugger, the good programmer would be able to dig into other people's code, figuring out even things that aren't documented. That programmer would also be able to quickly prototype and build well-designed interfaces. Things don't have to win awards, but the interface shouldn't get in the way. An even better programmer would have the ability to coordinate other programmers, improving people's results by helping them work on both a tactical and strategic level.

Someday!

2014-09-15 Reflecting on my growth as a programmer

One of the things a good manager does is to recognize and reward people's achievements, especially if people exceeded expectations. A large corporation might have some standard ways to reward good work: a team lunch, movie tickets, gift certificates, days off, reward points, events, and so on. Startups and small businesses might be able to come up with even more creative ways of celebrating success.

In tech, I think good managers take extra care to recognize when people have gone beyond the normal call of duty. It makes sense. Many people earn salaries without overtime pay, might not get a bonus even if they've sacrificed time with family or other discretionary activities, and might not be able to take vacation time easily.

It got me thinking: Now that I'm on my own, how do I want to celebrate achievements–especially when they are a result of tilting the balance towards work?

When I'm freelancing, extra time is paid for, so some reward is there already. I like carving out part of those earnings for my opportunity fund, rewarding my decision-making by giving myself more room to explore.

During a sprint, the extra focus time sometimes comes from reducing my housework. When things relax, then, I like celebrating by cooking good meals, investing in our workflows at home, and picking up the slack.

I also like taking notes so that I can build on those successes. I might not be able to include a lot of details, but having a few memory-hooks is better than not having any.

Sometimes people are really happy with the team's performance, so there's extra good karma. Of the different non-monetary ways that people can show their appreciation within a corporate framework, which ones would I lean towards?

I definitely appreciate slowing down the pace after big deliverables. Sustained concentration is difficult, so it helps to be able to push back if there are too many things on the go.

At work, I like taking time to document lessons learned in more detail. I'd get even more of a kick out of it if other people picked up those notes and did something even cooler with the ideas. That ranks high on my warm-and-fuzzy feeling scale. It can take time for people to have the opportunity to do something similar, but that's okay. Sometimes I hear from people years later, and that's even awesomer.

A testimonial could come in handy, especially if it's on an attributed site like LinkedIn.

But really, it's more about long-term relationships and helping out good people, good teams, and good causes. Since I can choose how much to work and I know that my non-work activities are also valuable, the main reasons I would choose to work more instead of exploring those other interests are:

• I like the people I work with and what they're working on, and I want to support them,
• I'll learn interesting things along the way, and
• It's good to honour commitments and not disrupt plans unnecessarily.

So, theoretically, if we plunged right back into the thick of another project, I didn't get the time to write about stuff, I didn't feel right keeping personal notes (and thus I'll end up forgetting the important parts of the previous project), and no one's allowed to write testimonials, I'd still be okay with good karma – not the quid-pro-quo of transactional favour-swapping, but a general good feeling that might come in handy thirty years from now.

Hmm, this is somewhat related to my reflection on Fit for You – which I thought I'd updated within the last three years, but I guess I hadn't posted that to my blog. Should reflect on that again sometime… Anyway, it's good to put together a “care and feeding” guide for yourself! =)