Resolutions for 2016

I’ve written up a list of career-related resolutions the past few years. I’ve been pretty successful meeting those goals, so I’m going to continue the tradition.

Coding

I want to increase the Open Source code I write this year. That’s basically everything I write that’s not directly related to work.

I took over maintenance of Virtus late last year, but haven’t done a good job at finding the time for that. That’s probably more responding to issues on GitHub and merging pull requests. But eventually, I’ll likely add some features and do some refactoring.

My goal is to work on 6 apps and libraries this year. That’s a pretty aggressive goal, but I want to focus on both learning new things and building some simple but useful things. Think MVP — focus on getting a lot of bang for not too much effort.

I want to work on a new Rails app, to familiarize myself with Rails 5. I want to get some experience with some more modern gems. I also want to see if I can use some new techniques with a Rails app, especially things that might help us get closer to a hexagonal architecture. I’m also hoping to work with some different web frameworks — maybe Lotus, Rodakase, Trailblazer, or Phoenix. Or maybe one of the Crystal web frameworks.

I also want to work on a couple Elm apps. I started the STL Elm group as an excuse to learn the language. I’d like to work on a Twitter client, that might eventually turn into a more general reading app. Beyond Twitter, it would keep track of things I want to read. The other Elm app I’d like to write is a game, based on the old Space Taxi game I loved to play on the Commodore 64.

I wrote a micro-ORM last year called Ruby Preserves. I’ve started converting that from working with raw SQL to sitting atop the awesome Sequel gem. The simplicity is still there so far, and basing it on Sequel has so far gone easier than I expected. But I haven’t figured out how to do relationships (JOINs) yet; that will be the real test.

Conferences

I’m pretty happy with my 2015 conference experience. I want to keep my conference level about the same. I don’t really want to commit to more talks than I gave last year. Conference presentations take a lot of time and energy to write and practice.

I’m planning to go to RailsConf, RubyConf, and Strange Loop. I’m hoping to give a talk at each of those, if I can. But I’ll probably attend all of them even if I’m not speaking. I’m also submitting a talk to Agile 2016. I’m unlikely to go to any other conferences, and even more unlikely to give more than 4 conference talks.

Writing

I really want to finish my Effective Agile book this year. I’m going to try to pull Amos in to pair with me on it occasionally, to move it forward. If I’m able to get it done, I’d also like to maybe write a book on Elm.

I actually want to do less blogging this year. Well, sort of. I want to put coding and book writing ahead of blogging. If that means less blogging, I’m okay with that. So my goal for blogging is more like every other week. And when I do write a blog article, I’d rather it be related to some code I’m working on, something that I could use in my book, or some more in-depth thoughts about programming language design.

Job Hunting

The contract I recently started at CenturyLink Cloud is open-ended, so I’ll likely be there for the entire year. I’m enjoying it so far; it’s a challenge, but I think I can make a significant impact. However, I’m really interested in moving to San Francisco in 2017. So I’m going to work on preparing for that in several ways.

I’m going to resurrect my LinkedIn account. I’ve neglected it for a few years now. I’ll make sure everything is up to date, and make some connections I’ve been putting off. I also want to reclaim my Stack Exchange and Hacker News accounts.

I’m going to pay a an expert to help me revamp my résumé. I think it’s pretty decent, but it could use some freshening up. I want it to stand out. I want to do a better job of explaining what I really do — which is to join a team to help them improve their processes and their technical skills.

I’ll also need to clean up all my web sites, so they look nice when people come to take a look at them. This includes my personal site, consulting business site, wiki, and blogs. I should also upgrade my server to the latest version of Debian, and use Ansible and some other tools to provision it using the principles of Infrastructure as Code.

Team Values

I held a retrospective with my new team last week. The team includes 2 senior developers, 2 junior developers, a product owner, and a product analyst. I’ve joined the team as an engineering manager, which I think of more as a team lead with an elevated title. Being new to this group, I wanted a way to understand their values. What motivates them? What common values do we share that we can leverage to move forward in the same direction?

I started out with a pretty simple question: “What do you value (in regards to what we’re building); what are you willing to fight for?” I asked them each to write down several values and then put them on the board before looking at everyone else’s answers. I also asked each person to rank their values in order of importance.

It turned out that my question was a little vague. Some people thought about the question in terms of the end result, and some in terms of the process of creating the software. In some ways that was a bit of a problem, because the different interpretations led people in different directions. But in other ways, not pushing them in any particular direction got more varied answers, exposing how they think about the project and the product.

My list (in order) was Effectiveness (doing the right thing), Quality (doing things right the first time), Happiness, Purpose, and Teamwork. In retrospect, I should have put Happiness first. If I’m not happy at work, I don’t really want to be there, and need to move on. (Sometimes I can trade some happiness at work for more happiness at home, but I’m definitely a person that needs to be happy at work.) The other values serve to improve my happiness, but the happiness is more important.

My own issue ranking my values turned out to be a problem with the ranking in general. Should they be ranked in importance of the necessity of the value as an outcome, or in importance of the necessity to focus on the value? I think the former is what I was looking for, but even I wasn’t clear on that when I began the exercise.

After everyone put their values up on the board, we read them off. Then I asked the team to choose several values that we share as a team. We pulled them off the individual members’ lists, and put them in the team list. Then I asked each person to come up and rank those values, then explain why they had ordered them that way, especially when they ordered them significantly different than the last person. I was hoping to come to some convergence of the rank over time, so we could document our values in rank order. That didn’t happen. But the discussion was illuminating to me and to everyone on the team.

I think the most interesting part about the lack of convergence was the difference between the developers and the product guys. The product guys definitely viewed the values more in terms of outcomes than the process. That makes sense — they’re not as intimately involved in the process of building the product.

We were able to converge on the top priority though: Will the user buy the product? This was a combination of a couple different values that we merged together. This included the end user experience as well as making sure the team would continue to have a reason for existing. The rest of the values we left unordered: Teamwork (cohesiveness), Data driven decisions, Team ownership, Simplicity, Effectiveness, Maintainability / Supportability, Quality, Automation, and Performance. I think that’s a pretty decent list.

As a couple teammates pointed out, those values are probably in part a reflection of this current point in time. If I asked the same question some other time, under different conditions and team dynamics, the answers would probably change a bit. And we’d probably come up with other answers if asked again, just due to randomness of the way we think about these things.

But I don’t think I’d do this activity a second time with the team. It was really about understanding our motivations — both our own, and those of our teammates. I found it effective in that way, and also in helping the team to think about our culture and how we can work to shape it to help us all push in the same direction.

There are a few caveats. When I asked for feedback on the exercise, one teammate pointed out that it wouldn’t work if people weren’t honest about their values, and they answered with what they thought management or their teammates wanted to hear. I don’t think that was an issue with this group, but it’s something to keep in mind.

The other major thing I’d do is to make it clear up front that I’m not looking for any action items from this activity; it’s more about understanding each other and ourselves. And next time, I’ll work to clarify how to rank the values.

I would recommend this activity for a new team, or when the makeup of the team is changing in some significant way. I wish there was a way to help a team converge on the ranking of their values, but I suppose I should be happy that agreeing on the set of important values went pretty quickly. And the diversity of ideas and opinions is probably a blessing that I should be embracing — the more ideas we have, the wider the variety of solutions we can imagine.