Writing Your 2.0 Resume

Over the last ten years, I’ve spent a lot of time reviewing resumes and hiring engineers.

If you’ve ever been a part of the process, you already know the importance of the resume and putting your best foot forward. As members of the hiring team, we very rarely know the candidate aside from what is shared on the resume. 

Looking for some specific tips, see Terry’s post on How to Write A Resume.

In a nutshell. Selling yourself is critically important, never just list off the tasks you were expected to perform. Communicate to us what was accomplished, and what your role was in achieving it.  

Polish. Your resume will likely be printed, make sure the font selection and layout are readable on an 8.5″ x 11″ piece of paper.

Three Ways to Make Your Agile Retrospective Relevant Again

It’s tough to affect positive change within a team (or even individually) without a frequent feedback loop, that’s the point of holding retrospectives in an agile environment.

All too often, retrospectives become yet another habitually boring meeting every two or three weeks.  It doesn’t have to go down like that, and I’ve included three tips below that I think will add life back into your retrospectives and provide new opportunities for continuous improvement.

Agree / disagree, feel free to comment here or continue the conversation on Twitter.

Choose a Focus (and plan ahead)

As Esther Derby has said previouslyEvery retrospective should be unique.  Never begin (or attend) a retrospective if you have no idea as to what the primary focus will be, you’ll waste time and wasting time is the root of all evil.  

When you know the topic, don’t be afraid to plan ahead of time as individuals. Bring evidence, data points, situations, behaviours and impacts to the retrospective.  Doing so will help make the meeting itself far more productive.

As the individual running the retrospective (Scrum master or not), keep the ball moving. Avoid long periods of awkward silence waiting for group feedback or consensus.

If you find yourself with multiple focuses needing attention simultaneously, consider having another retrospective.  For example, you might see need for a session at the end of week 1 that focuses specifically on the difficulties surrounding your sprint kick-offs. It makes sense to have the discussion when the situation is still fresh rather than waiting until the end of a sprint.

Track Outcomes

As part of closing the retrospective and after everything has been discussed and prioritized, record two copies of each action item.  

One goes to the individual tasked with it, the other to the scrum master / team lead.  

Make sure that the action items / takeaways (2-4 each sprintDO NOT just end up on a wiki page that no one looks at until the next retrospective. If something is important enough to warrant becoming an action item, it should be made visible to each team member every day.

Record each on their own piece of paper and place them on your physical sprint board

Which brings me to the final suggestion…

Record Incremental Progress

Throughout your sprint, whenever progress is made on an action item, put a check mark, dot or explanatory sticky on it.  Doing so will help establish a positive feedback loop and demonstrate that improvement is being made throughout the sprint.

Review each sheet of paper at the start of the next sprint. A bare sheet of paper is evidence of a poorly chosen action item (but it sounded good to the team at the time, how did that happen?). 

Celebrate not only the work (software, documents, hardware, etc) delivered in a sprint but also the progress made against your action items.  The former is what the team is expected to do, the later is what the team wants to do

What’s more important?

Building Monolithic Apps (Django?), Not So Fast.

Over the past few years (in my personal life) I’ve built a handful and launched a handful of web applications, predominately built using Django.  

Professionally, I’m a JVM developer who’s witnessed the shift from Java to alternative JVM languages like Groovy (I’m a big time fan), and a growing disfavour with full stack frameworks like Spring and Hibernate.  

Don’t get me wrong, both Spring and Hibernate have massive developer communities, but there’s a subset of the population looking for simplicity and less magic.

TL;DR – Django is nice, monolithic is bad.  I used to love Spring and Hibernate, but nowadays I feel like they’ve run their course and are no longer the defacto choice like they were in 2005-2010. Currently, my preferred stack includes Dropwizard (micro web service development) + AngularJS, but could just as well include Flask or a combination of both.  Be aware of behind-the-scenes framework magic (such as in Grails, Hibernate, Django, etc.), if you cannot easily reason around what it’s doing, someone will end up in debug / maintenance hell eventually.

In the end, do what feels right to you, be agile and put the effort in to build applications that you’re proud of.

Hit me @ajordens to continue this conversation.

What’s my definition of an application?

An application consists of services, data and user interface.  

Furthermore, most applications I’ve seen can be sliced into one or more verticals, each slice delivering one or more services and a user interface.

This slicing provides implementation flexibility, a small team of engineers (or perhaps even just one) can easily own an entire vertical soup to nuts. Verticals are integrated by way of APIs and previously agreed upon URI semantics.  

Deployment flexibility is achieved using a tried and true web proxy like Apache or Nginx that fronts your vertical stacks deployed across a fleet of internal servers (or elastic load balancers in AWS).


Contrast the previous definition of an application with the typical monolithic deployment.  

In the monolithic world, we’d typically build one artifact and deploy it to a number of servers.  A team of engineers would be responsible for the application and must all work in conjunction to ensure successful deployments and uptime.  

The introduction of an error or critical bug by a team member has the potential to wreck a deployment and force a rollback.  This issue is not completely solved by moving to more service-oriented verticals, but is perhaps a little more palatable.  If an issue is discovered in one of the verticals, simply roll that individual slice back and hope that you don’t have too much coupling between services.

What’s my beef with Django?

Don’t get me wrong, Django is nice. It’s got a great community and is relatively easy to jump in to.

Probably the biggest issue I had with it, coming from the perspective of a JVM developer, was the lacklustre API frameworks at the time. 

I started off with django-piston, and in hindsight, the resulting code was a little ugly (aka. not very pythonic — blame it on me, the developer if you will).  Subsequently, I moved on to django-tastypie to much more success.  I’m not sure if there have been improvements this past year on either framework (piston looks dead, tastypie is still somewhat active), but IMO both frameworks pale in comparison to what’s available w/ JAX-RS on the JVM.

Templating in Django is passable, although Jinja2 is much better than the default django templates IMO.

The admin interface is great, and was a good tool to expose a couple management interfaces to non-developers. 

The out-of-the-box CRUD stuff worked well.  Some of the more complicated admin operations may have been better served as a dedicated admin service with a hand cranked JS interface.

This blog post does a reasonable job of outlining a few other areas where Django is lacklustre when compared to Flask.

It’s not all bad.

Truthfully, there is no silver bullet architecture that will guarantee a successful business.  

There are millions of applications out there using Spring, Hibernate, Django, etc.  

They run, make money, and require maintenance just as any application would.  

Do what feels right to you, be agile and put the effort in to build applications that you’re proud of.