Conquering Network Resentment

“One of the symptoms of an approaching nervous breakdown is the belief that one’s work is terribly important.”

Bertrand Russell

One commonly-discussed habit of successful people is having successful friends. Indeed, having a network of people who are all kicking ass is a very effective way of realizing that most limits are self-imposed and can be a consistent source of inspiration.

However, there are times where I’ve found this influence to be of more harm than good; Sometimes knowing that my friends or colleagues are (seemingly) miles ahead of me can be a source of anxiety. And I’m not just talking about common jealousy either — I’m referring more to an overwhelming feeling that I am falling further and further behind.

I find this happens to me when:

  1. I’m in between “next big things” and considering what to do next. (i.e. I do not currently have a mission.)
  2. Ironically, after a minor success of my own — it’s all too easy to look at the successes of others and feel like what I’m doing is insignificant.

This is one of the stupidest and most counterproductive habits that I’ve encountered in myself, but I still often fall prey to it. Between the influence of my friends’ own success stories, the constant bombardment of “dream big” messages feeding in from Facebook and Twitter, and the media deluge of startups going gangbusters, it’s very easy to feel like I’m marching to the frenzied beat of someone else’s drum.

In an ideal world, one would always be inspired and happy that one’s peers are doing so well. However, we are all human, and fear and jealousy have been hot topics since the very dawn of literature. (Go back and read the Epic of Gilgamesh sometime — compare him to your average startup CEO and you’ll probably find they have very similar neuroses.)

The thing is, I don’t want to feel this way. So, like with any other negative habit, I’ve practiced some ways of training myself out of it. Here are some techniques I’ve found to be effective:

  • Disconnect. Pick a strategic hour (or longer) and detach yourself from the internet. In the absence of other signals, my own to come through a lot stronger.
  • Live in the present. Go outside, go for a walk, just focus on what is happening around you. Look at the trees, watch what other people are doing, imagine what their lives are like. Immerse yourself in the everyday details of life. If you find your mind racing to other people, the future, the past, anything that’s not your immediate environment — smile, take a deep breath, and refocus on the present moment.
  • Think of the origin of the universe. (Seriously.) Think about the fact that, many billions of years ago, the universe exploded outwards for some reason we cannot fathom (or perhaps no reason at all), and that it somehow evolved to the point that your life is now possible. Remember how small you are. Remember that, if your mission fails, it’s not going to alter the course of the universe for the worse. You are doing what you’re doing for your own edification. Detach your self-worth from your list of accomplishments, and see your work instead as a vehicle for self-fulfillment — not guilt.
  • Try to reframe your feelings of inadequacy into feelings of friendly competition. If you know you have a friend who is making 3x more money than you or has a greater influence than you do and it’s bothering you, think to yourself “I’m totally going to beat her at this, and then we’ll share a laugh when I do.” Maybe even call the person up and tell them so in a joking manner.
  • Do something unusual. If you have a television show or a favorite band or a workout or something that you always lean on in times of stress, do something else instead. Listen to some acid jazz, read some gothic pagan literature, go out and swim or play football or do some other physical activity that you never do. The initial feeling of discomfort and then the subsequent buzz of learning a new thing can really help bring your positive focus back.
  • Be honest. If you catch yourself in a moment of weakness and your reaction is to go post something inanely inspiring on Facebook (“Life is amazing and the universe is made of pink sparkles that turn into money trees when they hit the ground!”), think about how much value that message is actually adding to the lives of people who are possibly feeling the same way as you. Go have a quick, in-person conversation with a friend about something totally unrelated to your immediate feelings of inadequacy. Talk about something abstractly interesting or just catch up on life.
  • Remember that all of your friends are probably feeling the same way. Think about stupid that is. Commit yourself to not adding to the stupidity by breaking the cycle yourself.

I consider myself very lucky to have so many ambitious and admirable people in my universe; I don’t want feelings of negativity to detract from even one moment of my relationships with them. These are some of the techniques I’ve found that have helped me meet that goal, and I hope they’ll help you too.

Review of “Service Design Patterns” by Robert Daigneau

I’ve recently been reading through Martin Fowler’s Signature Series of books, published through Addison-Wesley. I like curated collections like these because they save me the work of assembling high-level curricula on my own, and it sounds like Fowler actually read these books before recommending them, which is a definite plus.

I just finished tackling the first book in the series, “Service Design Patterns,” by Robert Daigneau. (They should have prepended the word ‘Web’ to the title, in my opinion, as ‘service’ is a very general term.)

I enjoyed the book, but the signal-to-noise ratio was a bit low for my taste. I found the most useful contribution to be the classification of web service endpoint design “styles” into three major types:

RPC API: A remote interface that is designed as a procedure which takes multiple typed arguments. (e.g. GetInvoiceList(customerID, startDate, endDate, phaseOfTheMoon)).

This one is easy for newbies to understand, and amenable to implementation via code generation. Tends to produce very flat, grab-baggy APIs and service contracts are easily broken if you have to e.g. change the parameter list to a call.

Message API: Similar to RPC API, except that each endpoint receives a single typed parameter that encapsulates all of the parameters to the call in a “message” or “document”. This gives you a bit more flexibility in how the service contract evolves, because the message classes themselves can be versioned and routed to the correct handler by the endpoint based on this version. (Google’s protocol buffers are used as the primary example of this.)

For example:

service Invoice(InvoiceRequest)

message InvoiceRequest {
	version = 1.0
	startDate  = ...

Resource API: This is what most newbies to the field will encounter as their first example of a web service API these days, which is potentially unfortunate because it is the most complex. The resources (nouns) of your system are exposed via dedicated urls, and you retrieve or manipulate these nouns via verbs that are represented by HTTP methods like GET, PUT, DELETE, etc.

I found this classification (and the short history in chapter 1 that motivates it) to be very clarifying, and I lived through the evolutionary process that created each of these styles. If you are early in your software engineering career and a RESTful API is the first example you ever see of a web service API, I don’t think it will be obvious to you why the rest of the world decided this was a good engineering practice (pun intended). The historical discussion and subsequent classification of web service style APIs gives one a clear list of general possibilities to consider when consuming or creating a web service API, and is thus good reading in my opinion.

The rest of the book is devoted to enumerating specific design patterns that can be used in the implementation of each service API “style”, and then shows how to implement it in a common Java or .NET framework.

The thing is, the implementation of these patterns is really quite simple. I think it would have been much better to discuss a concrete example of a requirement that would motivate the use of the pattern instead, since that discussion would be much more resistant to change than boilerplate code.

Slightly “advanced” topics like service registration and discovery are discussed here as well, but I don’t think I’ve ever met anyone who was confused (or thrilled) by the idea of a service registry.

My conclusion: I’m definitely glad I read the first two chapters. The rest of it was educational in parts but had a very low signal-to-noise ratio. If you see a copy on someone’s shelf, do yourself a favor and read the first ~50 pages or so — or even better, recommend it to a new CS grad or junior dev.

Toronto Global Day of Coderetreat 2012

My first coderetreat experience was in 2009. I became involved in the Software Craftsmanship community through an effort called the Wandering Book, in which a little Moleskine journal was physically mailed from member to member so that we could write out our ideas about the current state of maturity in the field, and where we were headed in the future. (I often wonder what happened to that book.)

At the time, there was a crazy fellow named Corey Haines on the mailing list who was traveling from city to city, from software company to software company, never staying in one place for very long. He called himself a “software journeyman”, and was on a quest to improve his own skills by working with as many people and organizations as he could.

Early in 2009, J.B. Rainsberger posted to the newsgroup stating that he and Corey would be coming to Toronto, and asking if anyone would be interested in organizing a Coderetreat for them to facilitate. Not having any idea what a Coderetreat was, I thought it would be a good idea to immediately agree to organize one. For the sake of brevity, I’ll say that it went off without a hitch, and I was a convert.

By 2011, Coderetreat had become a global phenomenon. In celebration of this, over 1800 developers worldwide held 94 Coderetreats on the same day, which was appropriately titled the Global Day of Coderetreat. Corey himself defied the constraints of time and space to facilitate_two_ Coderetreats on the Global Day, starting out in Sydney Australia and then flying to Honolulu, Hawaii to wrap up the day.

I was absent for most of this growth period, being knee-deep in startup-land from 2010 onwards. In 2012, however, I decided to get back into the Coderetreat habit. I organized a couple of events in Waterloo, and discovered the Toronto Coderetreat Meetup organized by Taz Singh and Kyle Hodgson. I was reading up on all the recent happenings on when I discovered that the Global Day of Coderetreat was being held again, and I knew that I had to get involved.

Thus did ~70 Toronto developers converge on the Polar Mobile offices on Saturday, December 8th to practice their craft at GDCR 2012. The basic structure of coderetreat is simple: the day is split into several 45 minute sessions. In each session, participants select a partner and work together on a single problem, which is usually Conway’s Game of Life. The focus, however, is not on solving the problem; rather, the goal is to promote learning by attempting the problem using a variety of different techniques or constraints.

Since developers tend to be very goal-focused individuals, there is an additional technique we use to ensure that everyone is starting afresh every session: At the end of each 45-minute segment, you must throw away the code you have just written.

This simple structure — working in 45-minute sessions, in pairs, and throwing away the code each time — opens up all sorts of interesting possibilties for learning. I saw one pair attempt to solve the problem using Excel, for example. Several other pairs worked under some suggested constraints, such as “don’t use conditionals,” or “no getters and setters”. Our entire group attempted the “evil mute” constraint in the fourth session of the day, where you aren’t allowed to talk to your partner at all.

It was inspiring (and hilarious) to read the tweets throughout the day from coderetreats running all over the globe. However, while the global aspect of GDCR is exciting, it is the local effect on our community that I find the most exciting. Several of our attendees left GDCR 2012 saying that they were going to organize coderetreats internally at their own organizations as soon as they got to the office on Monday, and that to me is the very best part of all of this.

Of course, none of this would have been possible without the support of our facilitators and sponsors. We had a couple of very experienced facilitators as well as a few newbies, and they did a fantastic job in challenging participants to work outside of their comfort zone and learn new things:

You can’t host this many developers for a whole day without some financial support, and we couldn’t have asked for better sponsors than Guidewire and Polar Mobile. Guidewire provided the funding for coffee and lunch, and Polar Mobile gave us access to their incredible office space. We had almost 70 people in there and it felt like we could have easily fit twice that number!

My favorite thing about our sponors is that they didn’t just get involved financially — they both had developers there on the ground participating in the event! Guidewire developers have been attending coderetreat since the very early days, while Polar is new and enthusiastic arrival to the coderetreat scene. I am looking forward to seeing more of both of them at future events!

As it stands so far, it looks like we were one head short of being the biggest code retreat in the world at GDCR 2012 (edged out slightly by our inexhaustible Romanian comrades). Let’s see if we claim that honor at GDCR 2013, shall we?


A few weeks ago — in the midst of PyCon Canada planning no less — my girlfriend complained about the Toronto Public Library’s policy of only emailing you after your books are overdue. Having experienced this anguish firsthand before, I threw together a something to fix it.

I really like attacking random problems like these because I never know what I’m going to learn by doing it. In this project, I specifically took myself out of my comfort zone by abandoning my usual way of doing things. Normally, I’ll take a domain-driven design approach to things, where I try my best to seperate infrastructure from core domain logic.

In cases like this one where there isn’t much of a “domain” to speak of, though, this has the potential to be overkill. That’s why I decided to experiment with going entirely in the opposite direction. I used the framework (specifically the ORM) as if it were some ubiquitous thing, ready to be used anywhere. (Which it is, of course; and therein lies its power and its greatest threat.) If I was in a view function and I needed to pull some data, I just did it right there instead of pushing that functionality behind a service layer.

I actually made it all the way to the end by doing things this way before I started to feel really uncomfortable and confused with the whole thing, even for a project this small. One of the benefits of practicing a technique over and over again is that you establish an Everything In Its Right Place habit where you never really have to think about where something should go. When you abandon that recipe or method, it sort of simulates the feeling you get when multiple people are working on the system without sharing a consistent metaphor of how it works. That is, you’re constantly confused. So, right near the end, I caved and pushed a bunch of stuff behind a service layer, using a hacky barebones dependency injection trick I like to play in Django.

The one concession I made to the framework was to keep some infrastructure-specific stuff in behaviors on the domain objects themselves. I did this because I find in invasive frameworks like Django, there is a tendency to want to give an object a responsibility (e.g. “tell me what your absolute url is”) that should really be behind a service layer by virtue of that behaviour relying on the infrastructure (in the case, calling Django’s url reverse function, for example). I wanted to see how it felt to give into this tendency, given that you’re already binding your model objects to the framework in Django through inheritance anyways. It certainly made things a bit more convenient. I learned that there are middle grounds of abstraction you can take that will make the organization of a framework-reliant project a bit easier, without going for the whole hog and allowing you to swap things out at will.

For the non-programmers in the audience, I hope you find this thing useful. But even if you don’t, I still had fun building it.