Know Thyself

One thing I’ve always been guilty of is honesty.

That might sound a bit weird, but essentially I am alway happy to be clear at what I’m not good at.  This is often interpreted as imposter syndrome, or typical scots self deprecation, but its not.  I’m also pretty clear on what I am good at.

I’ve been trying to find a nice clear way of summing it up, but I can’t really do better than “I’m a coach, not a manager” and like so much of the XP/Agile terminology, that can really confuse or irritate people, so I’ll try and explain.  This will certainly be rambly.  As Ron Jeffries has said “how do I know what I think until I hear what I say?

In the much maligned Myers-Briggs Type Indicator I come out consistently as INFP/ENFP, which is quite different from a lot of programmers who are often ISTJ/ESTJ.  I am intuitive.  I make a lot of leaps and guesses and many of them turn out right.  To quote Mr Jeffries again “I’m not smarter than other people, I just make mistakes faster“.  I try things.  I talk about how I feel about things, rather than how I think about them.  I worry about people.  The intangible is very important.

I like a tutorial rather than lecture setting when I’m teaching.  I’d prefer people to ask questions and see where the discussion goes, adjusting my answers to the same questions for different people.  Looking them in the eye and seeing if I’m making sense.  This jibes with using XP to build software.  Small steps, feedback informing the next steps.  Lectures feel too much like Waterfall and I suck at that.  If I have no immediate feedback I will overthink and worry and panic and never get anything concrete done.  There will be no software because I’m trying to make sure I get the design just right before I start,  There will be no lecture because I’ll rewrite and revisit the content over and over, aware I have to get it right before I start, rather than adjusting as I go.

I like short or multiple choice exams rather than essay questions, because I get bored planning an essay out and want to just write all the things I know and move on.

In many of my consulting engagements I have been glue, helping to bring disparate parts of an organisation together to share a single vision.  In others, I have been oil, providing a layer to ease the interface between parts that rub up against each other.

I’m a starter, not a finisher.

I don’t mean that I just want to have crazy ideas and not see them through, I mean that I enjoy being one of the guys running along behind your car, pushing, shouting, telling you whats worked on other cars, helping you get started on whatever journey you want to go on, then move on to the next car.  I like building teams that build software.

I feel naturally entrepreneurial, but my family responsibilities override that and keep me (rightly or wrongly) essentially risk-averse.

As a programmer I work best alone when in the early stages of a codebase.  I like to get something working in a hacky, spiky way, then refactor until its good enough to share.  I think thats a good model for the exploration phase of a project. Let individuals own a piece they’re playing with.   On more mature projects, during the expansion phase, safety is paramount and lots of pair programming and testing is a good way to spread that knowledge around.  (phase names courtesy of Kent Beck’s 3X theory)

The most productive I have ever felt is using IntelliJ to build Java code.  It perfectly fit my “just code it up till it works, then do the actual work of extracting and renaming and parameterising” mode.  Once you have the guts of the thing, thats the best time to start designing.  What makes sense here or there, is this thing a new object, how could these two similar bits be merged to eliminate duplication?  All these  questions are better answered once you have working software.  Then you’re making exactly the right design for the software you have.  Proper, reliable, natural refactoring tools entirely change the way you can write software.

I suck when I’m bored.

My first manager at Panasonic, Don Grant, once had me in a performance appraisal and said “I wish I could give you two marks for everything.  When you’re interested, you’re amazing.  When you’re not interested, you’re terrible“.  I was fresh out of college and horrified.  “Well“, he said, “its not necessarily a problem.  The question is are you only interested in doing things you’re good at?  Or are you only good at doing things that interest you?  If its the former, thats an issue for you.  If its the latter it’s just my job to keep giving you things that are interesting“.   Its definitely the latter.  I’ll have a go at anything as long as its caught my interest.  I might suck initially, but I’m good at figuring stuff out with limited information because of the aforementioned making mistakes fast.

I was the third independent signatory on the Agile Manifesto.  I was knee deep in XP for ObjectMentor when Agile became a thing, back in 2001 and as soon as Ward allowed people to sign up, I did.

My favourite thing I have ever achieved is bringing Zoe Keating to play at the Scottish Ruby Conference.  Twice.

I have nothing concrete to point to.  No big open source projects, no books written. My name is in a couple of the original XP books as a reviewer, but my one attempt to write a book for the prags failed because I’m an overthinker.

I’ve organised six Scottish Ruby Conferences and 4 NSScotland conference but I’ve only ever given two conference talks (one of them twice).  My entire career is based almost entirely on word of mouth recommendations.  “I worked with him and he added value”.

From one perspective I feel like thats what I’m proudest of.  It should count for the most.  From another it makes it hard in situations like now where I’m considering “cold calling” for something new.  If you don’t know me, or know someone who does, how can I convince you I’m a good hire?”.

I got into the ThoughtWorks interview because I put Kent Beck and Martin Fowler on my CV as references.  At one stage I listed a reference for every single job.  These days my CV is too full of jobs, so I just say “references available on request” and wonder who I’ll call if I get a request.

I don’t really have an ending to this.  I’ve just kind of run out of things to say.  I did mention I suck at planning and finishing.


Where do we go from here?

I will soon be made redundant from a job I’ve held for 6 years.  Thats the longest I’ve ever been anywhere.

The last time I found myself without a job, I was terrified.  How will I keep a roof over my family’s head?  What if I couldn’t ever find another job?  The fear of the unknown was enormous, mostly because the financial pressure felt crushing and imposter syndrome loomed large.  No-one will hire me because I have no idea what I’m doing.  Perhaps I should go talk to McDonalds.

This time round however, I find myself in the enviable position of having enough of a redundancy package to keep me afloat for 6-8 months.  If I find a job right away, thats a nice lump sum that I could do something useful with, either personally or socially, but if not, 6 months should be plenty of time to find something.  Anything.  So thats the financial fear taken care of.

And so we come, as we inevitably do, to imposter syndrome.  What am I worth?  The last time I did anything other than iOS development was about 10 years ago.  My Ruby/Rails skills are out of date, my Java is ancient history and my work consulting and training with XP/Agile process is almost certainly too old school.  I have, in 10 years buried in Apple tools and technologies, failed to keep up with pretty much anything else. The changes in web technologies, in process, in buzzwords and frameworks seem all too massive.

When I did C++ for money, I did Java for fun.  When I did Java for money, I did Ruby for fun.  When I did Ruby for money I did iOS for fun, and then I kind of stopped.  Family life meant there was little time for programming outside of work, so I stopped having an eye on the new things, and which of them might be interesting as a future direction.  Back then, each transition seemed obvious.  I knew what I was interested in before I had to look for a job doing it, and each time, because I was interested and made friends in that space, I didn’t have to look hard to find a place to do it for money.

This time though I find myself a little lost.

How can I find a job with skills so out of date and irrelevant ?  I don’t know any of this stuff?  I need to buy books on Elixir and Go and a 10 volume set of Javascript frameworks.

But wait, I know how to build good software.

I know how to build good software and I’ve done it in FORTRAN and C and C++ and Java and Ruby and Lotus Notes for goodness sake and C# and ObjectiveC and Swift.

I know how to build good software and I’ve done it with UML and XP and DDD and Scrum and using Jira and Pivotal Tracker and Rational Rose and index cards.

I know how to build good software and I’ve done it for banks and startups and research labs and electrical retailers and power stations and Coca Cola and telecoms.

I know how to build good software in anything.

So.  The imposter syndrome is kicked into touch this time too.

I feel strong.  I feel ready.  I have no idea where I’m going or what I’m going to do next, but thats a blessing, not a curse.

It might, as I’ve said, be lovely to spend the next 6 months as a junior Mac developer or Project Manager or devops engineer and be the worst guy in the band.  To focus on the small and the specific.  It might also be lovely to finally take a step up into technical leadership across a small organisation.  To think bigger and work harder out of my comfort zone.

Its a magical world, Hobbes ol’ buddy.  Let’s go exploring.



The Worst Guy in the Band

In Chad Fowler’s wonderful Passionate Programmer book (which you should buy), theres a chapter called “Be the Worst”.

Legendary jazz guitarist Pat Metheny has a stock piece of advice for young musicians, which is “Always be the worst guy in every band you’re in”

Chad spins this musical advice into advice for programmers.

Being the worst person on the team has the same effect as being the worst person  in the band.  You find that you’re unexplainably smarter.  You even speak and write more intelligent.  Your code and designs get more elegant, and you find that you’re able to solve hard problems with increasingly creative solutions.

I’ve tried to make a habit of this, and so far I think I’ve succeeded.  You’d need to speak to my co-workers to confirm.  I’m looking for a change in work right now, and its got me thinking.

The advice above is essentially saying be around people who are better than you, so you’re always learning.  But there are a couple of issues with this.

Firstly, you’re good enough to be in the band at all.  Chad talks a little about this in context.  You want to be the worst guy in the first division, rather than the best guy in the second, but that assumes you have the requisite skills to be in the first division.  Secondly, it assumes some relevance or connection between you and the others.

You can become a better saxophonist by playing regular jazz with a really good pianist, drummer and bassist, assuming they let you in to their band, but what if you really want to play drums.  You can’t be the worst drummer in that band.  They already have a drummer who’s good.

Maybe you go join a drumming group.

You’re surrounded by drummers who are better than you.  You are the worst drummer and every day you work with better drummers and get better at drumming.  But now you’re a junior drummer, and you’re getting paid as a junior drummer, and you’re playing basic stuff all the time, which is improving you as s drummer, but not really stretching you as a musician.  Your expert saxophone status does not buy you recognition in that drumming group. You’re a beginner.

What you want is a bigger band.  A band that already has a great drummer, but can hire you for your saxophone skills 6 days a week and indulge your desire to be a junior drummer 1 day a week.

A couple of times in my career I’ve wanted to change direction, and both times I’ve been lucky.  My first proper Ruby job, my Java experience and Agile consulting work was enough to pay my way while I was a junior Ruby engineer working with a team of experts.  My first proper iOS job, that Ruby (and the Agile work again) was enough to justify a senior engineers position and salary while allowing me to essentially be a junior iOS guy and learn the ropes.

I’m feeling like its time again.  I’d like to be a junior something.  Maybe Mac development, maybe project management, maybe something else entirely, but I have to find the right band.  Someone that’ll happily hire my saxophone while I learn my crash from my splash.


My pencils are sharp enough

Its time I started blogging again.

I’ve had several over the years and usually end up deleting them after a while.  I used MovableType, and Ghost and Blosxom and Jekyll and all sorts of other tools.  Twitter really killed it for me.  It made it easier to throw out a thought than to sit down a craft a post. This is a wordpress site because it was quick to get working and typing.

I pulled across 3 or 4 older things I still liked, though they’re ten years old and maybe not relevant any more, it meant I wasn’t starting with the pressure of a blank slate.  Back then I was doing Java and Ruby.  These days its ObjectiveC and Swift.

So I guess I’ll see where this goes.

Smalltalk Best Practice Patterns

unknown-1In the 1990s the “patterns” movement in software was in full flight. The poster child, and many peoples introduction to patterns was the so-called Gang of Four book Design Patterns, published in 1994. Design Patterns catalogued a series of blueprints, strategies for combining classes to solve a problem, and the idea spread through the industry quickly, to point where Design Patterns become a buzzword and to some extent lost a lot of its original meaning.

But software patterns come in all different shapes and sizes and one of the people instrumental in the movement towards utilising the notion of describing software with patterns was Kent Beck. Kent is involved with many of the most important (IMO) ideas in software over the last 20 years, including object-orientation through Smalltalk, Test-Driven Development, Refactoring and our subject here – Patterns,.

unknownSmalltalk Best Practice Patterns is a collection of tiny, very specific patterns describing how Kent wrote Smalltalk. I’ve heard Kent describe how the book was written once, and I’ve tried and failed to find a reference.

In essence, when he start to write a line of code, he looked to see if he had a pattern describing what he was about to do. If yes, he used it, if no, he amended an existing one or wrote a new one. The result is a reasonably complete specification describing the choices available to him in writing each and every line of code in a program, from variable naming to inheritance hierarchies.

The power of this method was obvious to me, despite never having really seen Smalltalk before, so in order to properly read the book, I wrote to Wilf LaLonde’s JOOP column asking him for a beginners guide to Smalltalk.  He wrote one for me, and doubtless other Java programmers keen to understand how a “pure” Object-Oriented language worked

Smalltalk Best Practice Patterns is, without doubt, the best programming book I’ve ever read. Despite never having written a line of production Smalltalk in my career, it fundamentally altered how I write code in any language, forever.