Where are the Developers?

The amazing recruiting team at Vend have hired a few awesome software developers to add to our already incredible team. But it is hard work. Really, really bloody hard. So hard that I sometimes wonder what we’re doing wrong. Are we looking for the right people? Are we sending the right messages to attract those people? I’ve been thinking hard about what we’re looking for, and what we have to offer, and wondering if those things match up.

I think back to classic hiring articles like Joel Spolsky’s Smart and Gets Things Done for example. Are we asking the right questions in interviews? I’m pretty sure we are, but we could do better. I think about the concept of the 10x developer. Are we looking for unattainable unicorns instead of incredibly good racehorses? Maybe, but our current unicorns would get pretty lonely if we didn’t hire more.

What about our tooling? Should we be looking for a direct match there? There are plenty of opinions on PHP, but that’s only one part of our stack, and a part that we do as well as any modern dev shop, with unit tests, dependency injection, MVC, and – quite seriously – the most robust code review and continuous delivery culture I’ve ever been involved in. I could mumble about HHVM and PHPNG, but that’s just noise. Of course we’re looking at those: we continually evolve our platform just as we also include other tools where it makes sense. I’d list all the bits but honestly you’re better off coming in for a coffee to chat through it all with our crazy-talented devops crew.

It’s particularly interesting to me, coming from a Microsoft dev background, that your average PHP developer has less in common with what we build than does a high-end C# or Java dev. Emphasis on the average in that last sentence, because we all know VB6 caused the Microsoft world just as much pain as PHP; but you could argue .NET and Java have supported good, testable OO coding for longer than PHP has.

Coming back to Spolsky’s post, there’s a quote that highlights my point on tooling:

In software, things change so often and so rapidly that you need people that can succeed at just about any programming task that you throw at them. If for some reason you find an idiot savant that is really, really, really good at SQL but completely incapable of ever learning any other topic, No Hire. You’ll solve some short term pain in exchange for a lot of long term pain.

If I’m brutally honest, I think we’ve boxed ourselves in a little by advertising hard for PHP developers, when what we really need are great developers. 10x developers. Smart and Gets Things Done developers. Developers who thrive on massive growth and solving crunchy problems in a supportive team environment built on Trust and Focus.

Maybe those developers know a bit of PHP, but it’s more likely that they’re dabbling in Node or Go or some godforsaken JVM variant. All I care is that they’re passionate and intelligent, and want to share those talents with a team of like-minded individuals.

Is that so hard? In the famous words of Delia Smith: Where are you? Let’s be avvin’ you! I’d love to chat over this stuff with anyone. Or just.. you know.

/cries

Politics and Social Media

I’m hoping for a change of government in New Zealand come September, but not for the reason you may assume.

Back in 2008 when John Key came to power, Twitter was barely kicking off and Granny Herald had about 40 or 50 thousand more subscribers than today. I genuinely can’t remember being involved in any real-time online conversations about Helen Clark’s Labour government, whereas I now read multiple personal opinions on a daily basis about the latest thing that Key or Brownlee or Cunliffe or Norman has done.

I guess it’s obvious that Trevor Mallard is just as bad as Judith Collins on Twitter, but what about Chris Carter, Cullen and Goff? What would their time in power look like through the lens of personal jibes and dumb hashtag jokes? Did they get a relatively free ride?

When National put through not one, nor two or three, but four laws that appear dodgy in respect of the Human Rights act, I paused before flipping my lid online: surely it can’t be this bad? Surely other governments have done similar things and it’s just my pinko-liberal world-view to blame. Chill out. Right?

Is the Fifth National Government truly a cesspool of dimwitted decision making, or do I only think that because the Twitter echo chamber tells me to do so? I like to think I’m equally critical of Cunliffe’s gaffes and lack of policy, but worry that I’m just suffering confirmation bias. Does John Key truly disagree more with scientific, statistical, and economic consensus than Helen Clark did, or do I just think that because there are more immediate howls of anger from the e-left (iLeft? cyber-left?) when he comes up with another pearler about his “advice” saying otherwise?

To me it looks like no politicians are getting an easy ride online right now, when any fact or opinion can be rapidly fisked by the pyjama army ranks on both the left and right. If anything, it appears that investment in polling and carefully researched talking points is many times more valuable now than it was in the time of controllable media. Just take a look at the nutty “infographics” and crappily crafted motivational posters coming thick and fast from all sides lately: any time a politician says something vaguely quotable it’s turned into a Facebook-shaped meme before bedtime. Most of these are pointless crap, but I guess the plan is if just one of them turns “viral”, then yay votes!

The question I’m asking is this: what does social media look like when your favourite team ends up winning all the time instead of losing? I’m a Greens voter, but I like to think I’ll still be calling bullshit on dumb policy if they’re ever in power. Will they turn out to look just as idiotic as the current bunch? Will Trevor Mallard be an appalling speaker, biased toward the left instead of driving for genuine answers at Question Time?

Basically: bring on a change of government so I can check my bias by trolling left-wing politicians. Also: you’re on notice left-wing echo chamber. I’ll be watching.

Sphero 2: Not just a toy

I saw my first Sphero at Microsoft’s BUILD conference in 2013. Sphero wasn’t new at the time, but after seeing it in action I just had to have one. Who wouldn’t want a silly robotic ball that you can control with your smartphone?

Fast-forward 12 months and the revised Sphero 2 is on my desk. It’s faster, brighter and apparently more agile than the original. The 10 year-old and I had a blast putting the new Sphero through its paces, bumping down the hallway and occasionally hitting the ramps. Yup – it’s still pretty hard to get Sphero heading in the direction you want, but it sure is fun while you try.

Out of the box (which includes two jump ramps), Sphero 2 is quite a bit more fun than the original. A new career mode has been added to the basic smartphone app, encouraging users to play with Sphero to unlock new tricks and develop their control skills. There are of course a bunch of other apps to play with too.

But to me, just playing with Sphero using the provided apps is only the start.

Programming Sphero

Orbotix have obviously had a lot of feedback from people like me: coders and parents of curious 10 year olds. Their Sphero MacroLab and more advanced orbBasic apps provide a great way for kids (and adults) to experiment with basic programming techniques. I’m not sure how many institutes have taken up Orbotix’s education discount, but it looks like a great idea.

For those with more experience in coding, Orbotix provides a full Sphero SDK for most platforms, and a bunch of documentation and information via their official developer portal. Orbotix’s GitHub profile is a quick way to to see some of the available samples.

Perhaps one of the more zany things about Sphero is that you can use its location and orientation sensors as input devices, rather than just telling the robot where to go. There are a few examples of Sphero as an input device for gaming and 3D input, but perhaps the coolest one is using Sphero to control a drone:

The demo above uses the AR-Drone Sphero SDK. Perhaps you could take it to the next level by using the spheroSMS package to control the AR-Drone via Sphero via SMS?

In conclusion, Sphero is totally nuts, both as a simple toy and as a tool for education and software development. It’s just plain fun, and I can’t wait to play with the new Ollie, which promises to be like Sphero on steroids.

Trust

Those following along at home will know that I recently wrote about the place of responsibility and ownership in software development. While valid throughout software engineering, ownership is especially important in the context of a rapidly scaling software business – we need to be able to rely on developers to get things done without a massive layer of management whom we neither have the time to recruit, nor the culture to support.

The seminal Netflix culture slide deck (yeah it’s a doozy – I’ll wait while you read it), illustrates this wonderfully as the point where the growth rate of the business out-paces the density of high-performing individuals. This is traditionally the point where layers of management and process are introduced to deal with the ensuing chaos.

The clue to solving this is imbued throughout that Netflix deck too: trust. Without trust we can’t expect responsibility to flourish. Without trust we sit on the shoulders of developers, imposing restrictions and demanding feedback. Proponents of Agile would call this an impediment.

So what does trust look like in a rapidly growing engineering team?

Solving the right problems

Newly minted development managers coming from a technical background (and there’s an argument they should only be from a technical background), often feel to manage developers one needs to prove one’s technical prowess. I’ll admit to falling into this trap myself, especially when working with a new team. If they don’t respect me as a coder, how can I have any authority?

Here’s the thing: the problems you need to solve as a technical manager are by definition non-technical. You need to create an environment in which the engineering team can execute to their potential, and otherwise just get out of their way. The last thing you need is technical authority. I suggest you get your technical jollies forking MEAN at home, and use your fading technical knowledge when liaising with the business, but otherwise close Sublime Text or Visual Studio and walk away.

Do you trust your team to choose the right libraries, architect solutions, solve loosely-defined technical problems, and code to their best abilities? How about do you trust the team to deliver a solution that is the best mix of JFDI and polish for a given timeframe? If you don’t, then you have a problem infinitely larger than your technical abilities could ever solve.

So, what problems should you be solving in order to build responsibility and ownership in your engineering team, and build a self-propelling engine of international awesome?

Focus

Work with the business to make sure the engineering team are working on the right thing, right now. Help them understand how to build the right way. The right thing of course means the number one (or two or three) thing that must be built to bring delight to your customers (new or old).

Here’s one I prepared earlier.

Clarity

You are undoubtedly right to abhor a 50-page technical specification, but you do need to demand enough information so that engineers can understand the scope of the task at hand, and ensure they can connect to the right people to get the detailed answers as they build. This might be Product Management, or perhaps direct customers. Facilitate and engage, then leave them to it; don’t dictate.

You need to be a navigation buoy in the flow between engineering and their stakeholders, rather than an hourglass through which all information must travel.

Foundations

Provide space and time for the team to lay their foundations. Documentation, tooling, code reviews, training, recruiting, onboarding, communication, experimentation. All of those things that are “invisible” to customers but oh so incredibly important to the smooth operation of a dev team and the production of world-class software.

You need to be the advocate for this behaviour, explaining to the business why it is essential. But trust, trust that the team can execute this foundation work themselves.

Growth

If you’re getting a lot of the above right, then your team will be a fecund swamp of talent. Engineers will be popping up and seeking out challenges. It can be super tricky to find opportunities for growth in a small team and company, but one simple way to promote growth is to delegate ownership as much as you can, because this supports the growth of both the team and the individual – things you need to be happening as the team size grows.

You can also facilitate internal presentation sessions to foster talent within the team, then support your engineers if they want to present externally.

Use your gut feel and previous technical experience to pinpoint areas for improvement and work with each engineer individually to help them improve those areas. We’ve found some benefit in plotting a modified Urban Airship Tech Ladder across four axes, which can show where an engineer perhaps excels in some areas but can improve in others. Great food for growth!

Output will flow

I imagine some readers are having heart palpitations because I haven’t mentioned delivery, or deadlines, or output. My assertion is that if you get the above right – especially focus and clarity – output will flow. Sure you can tweak the dials on time spent on foundation vs delivery work, but only for short periods of time.

Trust the team. They will deliver.

TL;DR version: Are your engineering managers solving the right problems, or are they an impediment?

Responsibility

It’s pretty obvious why you would pay an experienced (and skilled) software developer more than a fresh graduate. Beyond that, if you’re working for a company with a great hiring ethos, differentiating engineers by relative ability becomes murky remarkably rapidly. I remember working with a particularly gifted graduate in a large company that used a fixed 3 year pay scale for graduates, and wondering why she should be restricted to a graduate salary when she was obviously outperforming many others.

Like it or not, there is value in having a concrete way to rank software developers. It serves as a checkpoint for salary bands, and also helps developers to understand what they need to do to be “better” (aka paid more).

There are a number of pre-canned “software developer maturity models” around the place. Urban Airship published their tech ladder, which is well written and has the bonus of mapping technical roles onto equivalent management roles – this really speaks to me because I’m a huge fan of the non-managerial technical career. Jin linked me to another great article about “mature” engineers (as opposed to gifted, but inexperienced engineers), which also pushed my “nod nod” button.

I’ve had this nagging feeling that there was something missing from all of these models. It’s taken me a while to put a finger on what it is.

Making Smiles

Having spent a fair bit of time as a manager of developers, there’s one really simple sign (for me personally) that developers are growing: smiles. Those little smiles that I get when I’m hopping in my car after a day at work, or reading an email, or watching an interaction. Those little “wow, yeah, that’s the behaviour I’m looking for” moments.

It’s not that I don’t smile at other times. I love hearing about how someone used throatwhistle.js* to solve a tricky problem, or how they Capistranoed the Puppet onto the SSH. But the thing is: coders be coding. Getting better at technical tasks is simply how you do your job, not how you become a better software developer.

If I think back on those private smiles, there is one common factor behind them: responsibility. They are the moments where I’ve seen a developer moving from one level of responsibility to another. Perhaps a developer has said “hey, I’ll deal with that customer query, don’t worry about it”, or maybe they are pre-empting my thoughts by emailing another developer about an impending dependency that has an unclear delivery date. Fantastic!

These are the times when I’ve become positive that there’s one less thing I need to think about when planning that developer’s workload. One more hour of my week available to think strategically. That sounds selfish on a second reading, but bear with me for a bit.

Towards a Responsibility-based Developer Maturity Model

You may be the most incredible coder, but if you don’t take responsibility for what you are building right from design to delivery, you’re leaving holes in your work for others to deal with. It really is that simple.

This is a straw-man, but I think a responsibility-based developer maturity model is what I’m looking for. Here’s how it might look:

Code Responsibility

A freshly minted graduate understands how to code. Depending on their degree, they might know a bit about software delivery models, but even then they will take time to learn how delivery works at your company. As such, the level of responsibility you might expect from a fresh developer is limited to the code they have created. They need to be told what to build, and often how to build it, but once built they should be able to own it.

Personal Responsibility

“What should I be working on now/next” defines this level of maturity. You’ve moved away from being fed work to do, and are actively seeking out the next piece of work. For a dev manager, this is the first sign of a great developer in the making. Curiosity, drive, and work ethic are all apparent in this level of responsibility.

Functional Responsibility

“Talk to Jane about XML tax updates, she really understands that function”, or more particularly, Jane might email and say “If anyone needs to know about XML tax updates, come and see me, I’ve grokked it”. This sort of behaviour shows that a developer has come out of their shell. They’re confident in their technical ability, they have some respect in the team, and they’re now putting their hand up to take on responsibility outside of their own personal sphere.

Platform Responsibility

“Dave is the Javascript guy”. You’ve proved your technical ability, you have the respect of your peers, and you’re being asked to make decisions about libraries and tools. But it’s not just about your technical skills – your peers know that you’ll take everything into account when making platform decisions, including developer happiness, so they trust you (and in fact rely on you) to help make these decisions.

Delivery Responsibility

“You can really rely on Sally to keep you up to date on where she is at and when her team will be finished”. From a management point of view, this is the ultimate level of responsibility. Developers working at this level will rally their team, manage their time, and deliver on their promises (or let you know when they can’t). There’s really not much more I could ask for than this, because it encompasses everything – including technical ability. A developer like Sally will tell you when there are holes in the spec or a technical gap in the team.

With Great Responsibility…

Reflecting on the above, it’s interesting that responsibility maps reasonably well to respect, and respect (in developer circles) can be an approximation for seniority. Want more respect from your peers? Take more responsibility for your work. The other thing to consider is just as no one bestows respect, no one is going to just give you responsibility (in fact, you’ve probably all worked with poor managers who have been given responsibility without the requisite ability).

Care about your work, take ownership of problems and delivery, look after your team members, communicate with your customers. This is what responsibility looks like.

Does this work as a maturity model? I think we might end up with those responsibility categories mixed in with Urban Airship’s tech ladder. I’d love to hear other opinions on whether responsibility is the missing link when we think about software developer maturity.

*Someone once told me about a drinking game, where you drink if [randomNoun].js exists.