Here are the top three that seem to jump out at me the most often:

Conforming to the average schedule of the team

I’m naturally a morning person; if I haven’t started on something productive by 6:30am, it’s going to be a bad day for me. As a general rule, I like to have my most important work done by 11am.

Some of the most unproductive times in my life have been when I let myself be dragged into the work schedule followed by the rest of my team. I definitely think it’s important to have 3-4 hours of overlap in working hours, but I often see people new to the game sitting around on their laptops “reading articles” way past when their brain has shut down and they don’t want to be the first to leave.

I learned to fight that urge. I still lose the battle once in a while, though, and I always pay for it the next day.

Refusing to set boundaries

When you first start on a new project or join a new team, there is a period of time where you’re learning what everyone else’s working habits are. It’s tempting to be “on call” all the time during this period. This can mean allowing interruptions at any time, or being connected to email / IM from the moment you wake up until the moment you go to sleep.

It’s also very easy for this “adjustment period” to stretch onwards into infinity.

This is another thing that has been disastrous for me in the past. I’ve actually found the inability to set “do not disturb” times during the day to be even worse for me than staying having to stay connected all night, since the former often necessitates the latter.

I’ve also found that certain personalities won’t ever respect these boundaries. It took me a while to accept that this is my problem, not theirs, in the sense that trying to change someone like that is going to be a fruitless battle. I’ve had this behaviour crop up in supervisors, clients, etc., and I’ve had to develop strategies in each case for dealing effectively with such people. This is a whole topic on its own, though, so I’ll leave this one for another time.

Trying to change things too drastically, too soon

Here’s a scenario I see pretty often: Let’s say you’re an engineer who has had the opportunity to learn the best engineering practices from your previous job experience at places like Facebook, Google, Twitter, etc. You decide to join a smaller company with maybe 10 engineers on the team where you can “make a greater contribution.”

So you sit down on the first day, check out the code, and build it… only to find that the build is a manual, 7 step process. All the “unit tests” are broken, but still take 16 minutes to run. You take a deep breath, go to your first scrum meeting… which drags on for over an hour.

And so on.

If you’re especially optimistic, your first instinct might be one of elation. “I have so much I can help them with!” you may think. And it’s true; there probably is a lot you can help them with.

But not right now.

Unless you’ve been specifically tasked with the job of “fixing things”, take your time with it. Get to know your teammates first. Go for coffee or lunch with them; learn about their lives as human beings first, and as coworkers second. My general rule of thumb is that I’ll know I’m in a position to tentatively suggest real changes to someone when I can first comfortably call them an asshat and not get in trouble for it.

I’m sure there have been exceptions to this rule in the past, but I personally haven’t witnessed any. Trust has to come before change. If only I’d learned this a decade ago, I could have my past teammates and myself a lot of unnecessary angst.

I know I’ve made these mistakes before, and I’ll probably make them again. But at least next time around, I’ll recognize when it’s happening.

Let’s say I’m knee-deep in that swampy mire known as Someone Else’s Code. I’m working on a search service that has this API:

class SearchService(object):
    def search(self, query):
    # Mega complicated stuff follows.

I need to change this method to be aware of the content-type of the media it returns.

OK, let’s go see how often this thing is used.

~$ ack search_service.search
<.. SPEW of 86 distinct invocations of this service method>

Awesome.

I pick one of those service calls and crack open open the relevant buffer:

def viewThatHasNoContentTypeInfoWhatsoever(request, query):
    context.search_service.search(query)

Even better — now I have to figure out how I’m going to get the content-type information I need to the service I’m calling here.

And there are 86 more of these to go.

So now I’m sitting here thinking that the job I initially thought was going to take 5 minutes is probably going to take much longer.

So what are my options?

1. Make content_type a required arg on the search method and just deal with the upstream changes.
2. Refactor the parameter list to search to take a SearchParams object that encapsulates the parameters that are required for a search.
3. Create a different, content-type-aware method on SearchService, since this is a conceptually different search, and use that instead.

1 and 2 both require changes to all 86 call sites, but at least 2 is a bit more future-proof. 3 just seems like it’s asking for an explosion in combinatorial complexity on that service interface.

This is generally the point where I begin to consider option 4, which is to make content_type a keyword arg with a reasonable default.

Great, right? This is a “minimally disruptive change” — I’m guaranteed not to break any client code, which is good because our test coverage is low and I’m not confident that I’ve even found all the relevant call sites.

The biggest problem I have with this is that it’s a terrible idea.

If this feature was being designed for the first time right now, I’d probably decide there there is no “reasonable default” for content_type at all, and I’m thus fragmenting the interface to the call at the intersection of version n-1 and version n.

New developers on the team aren’t necessarily going to be aware of the entire release history of the project, and so seeing media_type as an optional parameter will suggest to them that this is just a minor detail of the interface, where it is actually just as important as the querystring itself is.

I wonder — do you ever catch yourself being similarly lazy? I feel like this technique might actually be a good first step in getting hooks into legacy code for some preliminary unit testing before elevating the parameter to first-class status and making the upstream changes, but that’s only valid if you’re committed to making those changes in the first place.

In the meantime, I’ve forced myself to assess my motives carefully each time I add an optional kwarg to a function or method in Python. (Constant vigilance!)

In the first couple of chapters of the canonical DDD book, Eric Evans opines that developers are often very happy to tinker with a new technology, a new design pattern, or a new process, but they are usually unwilling to invest effort into the actual business of modelling the core concepts of the problem domain itself.

He continues by talking about how projects where even a few of the developers were not invested in this process meant that the effort was largely wasted, and that productivity stayed more or less constant despite the enormous effort poured into the modeling process by the rest of the folks there.

This isn’t particularly surprising to me; there are a variety of reasons I can see as to why your average developer would be more excited about adopting a new library to make cloud deployments easier, or adding a new code review process or the like to their dev teams repertoire of practices:

• There exists a lot of documentation and material that one can learn independently from.
• The effects are seen pretty much immediately (whether for good or for bad).
• Credit from the organization can generally be traced to the originator of
  the practice
• It’s a unit of work that can be done on e.g. lunch breaks, spare time, on
  the transit ride home, etc.

Building a rich domain model, on the other hand, bears very few of these favorable characteristics. Why not?

• Practicing it independently is not all that helpful, as a domain model is
  only provably robust when a variety of developers and domain experts can use it
  to improve communication and productivity in the team.
• You rarely see the payoff until the middle-to-late stages of the project,
  and it does generally slow things down at the beginning.
• Because buy-in from the team is required to make it effective, there is
  rarely going to be a single person who is going to get the credit for the
  initiative, and so the risk/reward is diluted across the team.
• It takes long, concerted bouts of practice to get good at it (preferably in
  the presence of people who have done it well before.)

As I was thinking about this in the context of Evans’ book, I realized that these difficulties prevent experience reports on DDD from being communicated effectively in the developer community at large. In addition to my involvement in PyCon Canada, I have also been involved in a variety of meetup groups in Toronto, San Francisco, and Vancouver that are focused on code quality and best practices (e.g. Code Retreat, Agile/XP groups, clean coding groups, etc.) And yet, I don’t think I’ve ever heard a talk on how a team switched from Approach X to development into a tight focus on creating a rich domain model, and what the subsequent consequences were.

Again, one can imagine a variety of reasons as to why this would be the case.

• There are probably relatively few developers who have even had this experience before. (Evans was possibly the first to write a book on it, and even he only had 3-4 examples to show off in the first few chapters. Half of them were failures.)
• Some prior experience with the domain itself is required to benefit from the discussion, which necessitates a significant introductory component (which has the potential to be boring.)
• Since the benefit of DDD is generally seen in the long run, the speaker would have to condense an enormous window of experience into a single talk.
• The amount of work it would take to address the topic properly (choosing the appropriate level of depth for each part of the discussion) is daunting.
• Many people with real-world experience in this space are prevented from talking about it due to NDAs, etc.

Nonetheless, this is the sort of talk that I would love to see attempted more
often at any general technical conference. The closest that I think we get are
focused refactoring sessions like this recent (awesome-sounding) talk from RubyConf AU.

I am going to play with creating some ‘artificial’ DDD scenarios that are in problem domains that are more likely to be familiar to developers, much like Vaughn Vernon did in his recent book.

In the interim, if anyone out there has seen an effective talk or presentation on a project that used (or better yet, was refactored to focus on) a rich domain model, I would love to see it!

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

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.

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.

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 http://coderetreat.org 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:

• Alistair McKinnell, who I met at my very first code retreat in 2009
• Taz Singh, co-organizer of the Toronto Coderetreat meetup
• Dann Toliver, of Bento Box and Bento Miso fame
• Siraj Berhan, XP coach and Agile champion
• Shradha Gaikwad, a budding entrepeneur and Pythonista

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?

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.

I’m swamped with co-organizing PyCon Canada right now, but I will be back in December with an article series I’ve been meaning to write for a long time.

I’ll see you all in a couple of weeks!