The Biggest Barrier to Doing Good Work

hands-on-keyboardFor me, the biggest barrier preventing me from doing good work is the strange notion that I should be producing my best work all the time. It is simply not possible.

This self-imposed expectation and lofty standard is what creates the feeling that, if I do some work now, it won’t be good enough or I won’t be sufficiently productive. So I beat myself up and I don’t get started, when getting started  is the only thing that’s actually required.

I’ve learned that when ideas and work are tough — as anything worth doing surely is — all that is required is spending time with those ideas and with that work. Going back to it repeatedly, developing it a little more, lifting it a little closer  to where it needs to be. It won’t always be productive, but doing this frequently is necessary. Without spending regular time in that work, it won’t magically become what it is potentially capable of becoming: My greatest work, or simply the next ball of screwed up paper to hit the waste paper bin. And it really doesn’t matter which.

What matters most, and the real urgency, is progressing this piece of work towards its logical conclusion. There can be no urgency to have a great idea, because that just won’t produce one.

Knowing that I’m engaged in the right process, and that this is all that’s required, helps me to get started and stay engaged. The rest will come.

Remembering To Dream Big, Again

S025-bwFrom the age when I could first put the pieces together, I built impractical things in Lego, and sometimes in Meccano. I used to dream of having enough Lego to build a castle, or a Meccano crane as tall as the house. There were no limits to my dreams, other than the size of my Lego set.

When I got into Computing I realised that, in a virtual world, there was no limit to what I could build to improve, serve and augment the real world outside. It was the ultimate toolkit. That’s how I found my passion, and my career. I count myself as immensely lucky.

Sometimes though, I wonder if I am honouring those early dreams, or whether I let them fade along the way. Have a Zone 1-3 travel card, a monthly pay slip and someone else’s dreams made me forget that being alive necessitates an element of impracticality, of thinking big… no, bigger!  Of planning things that might initially seem beyond me, then stretching to reach them. Not everything worth pursuing can be neatly described in a career plan, a yearly goal or an appraisal.

It doesn’t matter how many hundreds of thousands of lines of great Java code I’ve written, if I’ve not yet written the thing that reignites those early dreams.

I feel privileged to know some immensely passionate and brave people — entrepreneurs, artists and professionals —  some of whom are pursuing their dreams and making them real seven days a week, not just in “spare” moments snatched from a busy work schedule. I think it’s no coincidence that I’ve stayed in touch with these people. Like them, I also pursued my own projects full-time for a 2-year period recently, got a real taste of what’s possible when I focus, and realised how tantalisingly few steps there are between a software engineer like me and viable, commercial ideas.

I have, in Computing, the ultimate Meccano kit, the biggest box of Lego. It’s no wonder I regularly think, “Am I dreaming big enough?”

 

 

Making “Impossible” Post-Launch Product Changes Possible

Image: (c) 2014 Ian Cackett

Image: (c) 2014 Ian Cackett

Before launching a software product or app, any tech change is possible.

One day, you might change the database (MySQL seemed a bad choice anyway, right?). Another day the architecture. Perhaps the front-end templating language turned out to be clunky, so you switch to a better one. Maybe you even rewrite the whole thing in an entirely different programming language (because your mate down the pub said the one you picked originally sucked… and other fine reasons!)

During these pre-launch days, anything seems — and indeed is — possible. If something breaks, you just fix it and move on. No-one gets hurt.

But these heady days come to an end… After launch, certain changes become tough, scary or downright “impossible”. With existing users, data and promises of uptime / availability, it no longer seems possible to make certain changes. You are locked in by the burden of live usage. Or so it seems.

You see, I believe that it is always possible to make brave, far-reaching and deep tech / software changes, despite having already launched the product, but it requires three somewhat uncommon things: A reason, a plan and the willingness to execute that plan to completion. Miss one of these things out, and chaos is almost guaranteed.

Reasons – Before even starting, is there a reason for this change? Pre-launch, changes can be made on a whim. But as the product is now live and this will take some considerable effort, reasons are important.

Does the change improve the product in some way? Perhaps its performance or even just its maintainability going forward? Perhaps it allows the business, or users, to do something with the product that they can’t currently do? Perhaps it opens up the possibility for other desirable change down the line?

If there aren’t tangible reasons for a change, don’t do it or schedule it for another time… or for your next product, if this is just a personal preference for a change or a desire to follow a trend. After all, the product and its users matter more than how you personally feel about the code.

Plan the Destination – Ask yourself whether the proposed change would work, both trivially and at scale. This is the time to try the change in a test environment, but as-yet with no eye for how  you’ll get there and absolutely no code committed that will affect production.

Does the new database improve performance? Does the new templating language actually make things simpler? Does it work under current production load? (Folks usually forget that last one, but it matters and you may need to build an environment that closely mimics production to figure this out).

In short, would the change justify the reasons for making it and actually work in production? If not, you can ditch the whole plan right now. If it does… move on and plan it further.

Plan the Journey – How would you migrate? Usually, this means existing data, but it also means dependencies between services and components.

If components depend upon one another, plan a step-by-step migration such that all components have what they need (data and other services) at each stage. If the system will be in use as the plan proceeds, how do you ensure that no data is lost? Perhaps users need to be prevented from certain actions or use of particular features at key times to ensure this? Perhaps they need locking out completely during a published maintenance window?

The plan needs to be rehearse-able and repeatable, so write scripts for data migration and other tasks that can be automated. The plan also needs to be written down and reviewed. This isn’t the time for napkins or the back of an envelope.

If the plan seems to work, rehearse it again once more. Sometimes you do unexpected things on a first run through that invalidate the plan in unforeseen ways, so run through it again cleanly one last time.

Drawing out a plan at this stage allows you to see whether there is a path to the destination. Can you get there with everything intact and no outages?

Aside from planning how this will take place in production, how will you do it in development and test environments? When does the code get committed? When do other developers need to make the change? When does that get promoted to various test and staging environments? This may all need to be over a protracted period, so making a code change that breaks another developer’s ability to support (and release to) production isn’t allowable.

Be willing to think about all of these in your plan, or don’t attempt such a change… you’re simply not methodical enough.

Plan the Timing – When would the production switch-over occur? When is data going to be migrated? (You wrote and rehearsed a script for this already, right?) Does it need to take place during a quiet time in production, a planned maintenance window, or can it proceed seamlessly at any time?

Plan for Failures – What are the contingency plans, and could you revert if the unthinkable happened and the journey became unfinishable at any stage? You might discover way too late the reasons that make the change impossible. What happens if you lose some data? What happens if customers can’t use the app for a period?

Plan the Impact – Does this program of change affect any others? Any parallel development? Any business users?

Whilst you’re planning this  program of change, think about other  activities also going on… the timing of the change may affect them too. Is someone else developing code on a branch that needs merging with yours? Is someone else planning a brave change that clashes with yours? Can you align them both, or perhaps combine them?

Plan for Stability – After the change occurs in production you can just forget it, right? Wrong! What you now have is a radically changed product in production. There needs to be a planned period, post-change, in which you are on-guard for unforeseen problems. Memory leaks, race conditions that didn’t become apparent in load testing, etc.

This is a reason why there should be a pause before other sweeping changes are layered on top. You need to see the system working for a period once everything is complete, and leave a window in which critical fixes can easily be rolled out without clashing with other changes. You need to see stability, after the change.

Execution – This is probably the one everyone forgets. Having planned the change, executing it requires one more uncommon thing: Rigour. You need to stick to the plan, at all stages, and ask regularly “Where are we on the plan?”

If the data migration will take place over 4 stages, make sure everyone remains aware which stage you’re at. If the upgrade takes place overnight, keep everyone informed of its progress and outcome. Did it work? Did you revert? Are there issues that people need to be aware of?

This isn’t the time to change the plan unless unforeseen circumstances dictate that. Whilst execution may seem boring, failure to be rigorous will undo all of the planning that went before, and could lead you into a mess of production problems.

With a willingness to plan and execute, and some rigour in both, I suspect that most “impossible” post-launch changes with clear benefits are in fact quite achievable. Their cost and risk is greater than pre-launch, but I would argue that sometimes these brave changes are worth the effort, and that entertaining them can help to avoid product stagnation or bigger problems long-term.

I think this is a more mature version of Facebook’s “move fast and break things”. Perhaps “plan, and don’t break things”. All change is possible, even post-launch.

The Importance of Risking being Mediocre

averagelYesterday, one of my oldest school friends, an artist, said something that made me pause and think about what we risk by pursuing our own projects, startups, goals or art.

Far worse than the often talked about risk of failure, or the similarly discussed and dreamed of success, is the middle ground.

“What if I’m mediocre?!”, she said.

Rather than being something that most people fear openly, I suspect this may still be the reason why a great many people never get started and never produce their own work. Meaning, work which we publish as our own, to which we 100% attribute our own name, not that of an employer, a course or a group. Work for which we own all success, failure or other outcome.

It’s a myth that we can somehow learn enough to avoid being mediocre at some point, during a safe preparatory period, and then go out into the world and pursue success directly. And yet, I suspect most never get beyond the preparation stage, because mediocrity is always a risk.

In “Clarity”, Jamie Smart says “Discover your path by walking it”. I think we actually need to begin and learn en-route. Create and publish or share our work. Naturally, this means going through any mediocre stage in full view of people who may criticise us, but I suspect it’s the only way; through mediocrity and beyond. There is no way to avoid it, and perhaps it’s better to embrace it as an essential aspect of success.

This is why I began blogging and, as a software engineer, why I launched two apps of my own: They are learning experiences and, each time, I get better. The only way to something bigger and better is by doing real work and putting it out there.

It is also work realising that, by putting our work out there… we are already well ahead of the pack, because most never will.

I hope you enjoyed this mediocre blog post 😉

7 Limiting Things Software Developers Need to Stop Saying to Ourselves

Going it alone

(c) 1993 Ian Cackett

As a software developer for the past 20+ years, I know that I have at times restricted my own view of what’s possible in my career. These were my own personal limiting beliefs  and things I was telling myself, but I believe most of them are quite common.

I’ve listed them here in order, smallest to largest. I suspect most people reading this will have conquered them to a point, and the remainder probably define where progress might be productive and possible. I am by no means done with this list myself, and my current focus is the last two.

How many of the following are familiar to you?

“I am just a language X developer” – We all start off with, or predominantly use, a specific skill set. Over time, it defines us within a company and in the wider recruitment market. Switching to other skills seems impossible, but it is entirely within our control.

If I hear another person say “But I need training”, or ask me how I learned Java or JavaScript as if I was somehow handed the opportunity on a plate, I will scream. Order books online, read tutorials, do programming exercises, teach yourself, build a working prototype of something in that new language, in your own time. You  drive your career progression, not your employer.

This doesn’t just apply to programming languages either. We are all capable of become a more well-rounded software engineer. If you didn’t study Computer Science or Software Engineering, read a few books or blogs and figure out a reading list to round out your knowledge. Learn about good design, architecture and listen to how others built systems that work well and scale. There is no hidden magic here, and anyone with a will to learn can reproduce the same great results as others.

“I only build the product” – Product direction and input tends to come from non-tech departments: Sales, Marketing, Product Management. It can feel like we have no input when, in-fact, we have a great deal to offer.

Listen and contribute to the business. Learn how to describe technical problems in non-tech language, and to translate business problems back into technical solutions. An engineer with these abilities has a great deal to offer the wider company. Beyond being a full-stack developer, extend that stack to some include business knowledge.

“X isn’t possible in this company” – Courageous programs of technical and business change can be accomplished, and you can lead them. If you learn to act as the rock around which they are planned and executed, they are possible.

Migrating a data centre to a new architecture, removing old redundant database tables, standardising the non-standard and even redeveloping the product from scratch, if justified, are all possible. I see so many of these remaining as long-term obstacles, and yet these are just the kinds of challenges that allow an engineer to prove themselves to a business.

The secret is to propose a plan that will actually work  — perhaps test it in a staging environment to prove this — and then act as the rock around which that plan executes. Split it into multiple stages, and define what must happen at each stage before moving on to the next. How will you ensure no data is lost? How will you be sure the business has moved along with the technical aspects correctly? What are the contingency and reversion plans? Think of the impact on the whole business, not just the bits that are relevant to you. Write it up as a proposal, in both business and technical language… but then expect to be asked to deliver it.

“I have nothing to teach others” – Stand up and teach the things you know. Risk being seen as audacious. But also listen and learn.

If you fear giving presentations, get over that fear. This has often been described as the single most limiting factor in most people’s careers. If you learned a new skill, be willing to discuss and teach it. Not willing to do that? Then don’t kid yourself that anything but fear is the reason. Fear is a self-imposed career obstacle.

This all comes with an expectation of pragmatism  though too: Don’t become the techie who always evangelises about the new language or framework, without an eye on practicality and the actual value to the business. If Scala will really benefit the business, learn it, propose it and be willing to teach it to people. If it’s just your latest favourite language, or the 12th one you’ve proposed this year, then keep it to your spare time instead. At least for now, anyway.

“I can’t talk to clients” – There is a stereotypical image of the techie whom business folks fear putting in front of a client. Don’t be that guy.

Learn to talk in the client’s own language, and to listen. The only thing that matters is translating their requirements into technical implementations, and demonstrating to them (again, in their language) what a product can, or could, do for them. Talking on their terms is key.

It won’t take much client exposure before you learn what to say, and what not to say. If you aren’t getting that exposure, ask for it. Sit in on a Sales call, ask to go on a client visit with someone… and then listen. You may be amazed by how many questions come up that you’re the perfect person to answer. And that’s your intro. You will most likely be asked to contribute again.

“I couldn’t build my own commercial product” – You already build some or all of a product for your employer, so what’s the difference in building it for yourself?

What we tend to mean is that we need someone else to constrain and shape the commercial context. But really, what is more potent than someone with both business and technical knowledge? Someone who can figure out that a client wants, and then build it or lead a technical team in doing that? You can, and should, add that commercial awareness.

I’ve begun reading “The Personal MBA” (Josh Kaufman), in an attempt to round out my own business and non-tech skills. It is my assertion that every technical person is a tantalisingly-small number of steps away from being sufficiently commercially aware that they can not only build a product, but figure out what to build too.

“I couldn’t run my own company” – If you can build a commercial product, what’s to stop you starting a company of your own to sell it? After all, a startup is simply a bunch of folks (or even one) who realised that they could do just that.

Again, the Personal MBA helps here, and an awareness of which areas you don’t currently know much about (your blind spots), plus a willingness to go and learn enough about each of those areas. Don’t deny the need for some marketing, sales, financial knowledge; They are all  crucial. Just admit what you don’t know, plan to learn some, and then realise you’ll need to wear each of those hats periodically to build (or at least kick-start) a well-rounded venture.

For me, awareness of what makes a product commercial, and how to run a company, are the two aspects that I’m still trying to learn. They have been pivotal in my own limiting beliefs in the past, and I’m beginning to see possibilities where once I only saw barriers and obstacles to my career.

 

The Hidden Message in Product Flaws

flawI’ve noticed that I tend to seek out the flaws in other peoples’ products, particularly software products and apps. But probably not for the reasons you’d expect.

I don’t go hunting for glitches, problems and the “chink in their armour” as a way to feel better about myself or to mock their imperfections, or to gloat.

Instead, I take them on board privately as signs that the person or company isn’t quite as unreachable  as I perhaps once assumed. That their goals aren’t quite as unattainable  or as perfectly-executed  as I usually believe. That they are, in-fact, within my reach.

Seeing well-known brands, companies or people we’ve idolised as being fallible  and accessible  means something startling…

Any of us can do what they did… and more.

 

Handling Product Feedback: Listening in Detail, Acting in Aggregate

I’m inherently a pleaser. I think anyone who develops, builds or sells a product is, to some degree, a pleaser.

When I hear product feedback, I want to act on it. I want to to fix everything  and to please everyone. As it turns out, this can be a somewhat counterproductive trait.

Handling product feedback requires the maturity to aggregate it over time, before acting. Only in aggregate does it make sense. Here’s why.

Different Strokes – One person’s “must have”  feature, their preferred default value or their request to expose / hide certain controls will invoke the exact opposite reaction in another person. The new feature might even annoy them. The preferred default could be wrong. They will want the hidden feature exposed, or the exposed feature hidden again, just because it gets in their way.

Not every change or product decision will divide a crowd in this manner, but there is always a trade off between pleasing one person and displeasing another, which you can only see by aggregating feedback.

Groan or Gripe? – Is the request for something that matters, or is this just window dressing? Realising that some people will give feedback with the same insistence and intensity, whether or not the request is pivotal or trivial for them, helps me greatly when assessing the true priority. The trick is not to tell them the priority I’ve assigned in my head, or on my plan. Hearing that their niggle is “trivial” is a great way to lose them. Likewise, telling them I’m going to act with great urgency when I really intend to shelve the request can be as damaging.

It is also worth remembering that, in aggregate, the trivial thing that annoys a large number of people might be worth doing, whereas the major gripe for one customer in a thousand could be worth ignoring and losing that customer over. But I realise I’ll only ever see this in aggregate, and perhaps not as feedback comes in.

Is It Worth It? – Is the request one that will bring in or retain a significant number of users? Pleasing existing customers is crucial but, at some point, I know I have to weigh up whether that investment in time and effort is bringing in money and helping to keep the product going. If it isn’t, we’re just a day closer to the point at which the product no-longer exists.

Is it a Distraction? – Are there more pressing things that should be worked on first? This is obvious if there are higher priority items, but sometimes any feedback can be a distraction from building new features, or too many requests in one area can lead to neglect of another. Maintaining the product versus building the product out, will always be a balancing act. Again, seeing feedback in aggregate, versus new features and product development, can help.

It it on the map? – Does the request align with where I intend the product to go? Alternatively, does it suggest a new potential roadmap or feature? Sometimes, features requested even by a minority — occasionally a minority of one — can be worth exploring. Other users may not have thought of them and may respond favourably when we experiment in that direction.

Alternatively, if the request is not aligned with the product roadmap and doesn’t suggest a sensible detour, this may be a sign that a portion of users no-longer find the product a good fit, and there is a financial and functional decision to be made there: Who are we trying to please, and can we really please all of them or do we pick a subset so we can focus on them more effectively? This may even change the market  the product is aimed at.

How to act in aggregate – Other than bug reports, it should be rare that feedback from a single client or user turns directly into a task to be implemented.

More often, requests should feed into regular decision making about tasks, priorities and releases. Piling each request straight into the development backlog isn’t aggregation, it’s reaction. Collating feedback separately from the backlog, reviewing it regularly and then adding tasks to the backlog appropriately is more effective. Some requests will never reach the backlog at all, or they may only reach it once a volume of similar feedback is achieved and opposing reactions considered.

I’ve learned to realise that feedback points — but no more than points– at things I could, and sometimes should, act on. And I can still be a pleaser, albeit a slightly more mature one.

Why Asking “Friends & Family” About Your New Product May Be A Mistake

Friends & Family

(c) 2014 Ian Cackett

They call it your “warm market” — The people you already know and the ones that common wisdom suggests we should show our product / app / offering to for early feedback. Friends, family, perhaps former colleagues.

I’d like to suggest that perhaps these are the absolute worst  people to get early feedback from.

Your warm market probably doesn’t consist of genuine customers: People who feel your product answers a need for them, at a price they are willing to pay.

Family in-particular may feel obliged  to give you good feedback which could be misleading, or to offer harsh feedback in a misguided attempt to protect you from potential failure. They may subconsciously hold back genuine favourable / unfavourable reactions, giving you an unrealistic belief about whether your product has a market.

Conversely, because they aren’t genuine customers, they may over-think  their feedback. In the pub / bar world, I’ve often heard friends give scathing feedback on new bars run by people we know, and yet the same people give gushing reviews of established bars owned by other friends that exhibit the very same flaws and problems, just because they are established and others have already gone on the record saying they love the  place. To some, the very request for feedback on a new product opens up a tide of irrelevant over-thought “helpful” feedback. Genuine customers, who don’t know you, are more likely to state what they actually think of the product, and only that.

Friends and family are probably unfamiliar with what a promising early-stage product in your intended market might look like. They may not have seen early rough-and-ready versions of Facebook, Twitter or other apps like yours. As such, they may see the “newness” of your offering as a problem, rather than seeing beyond it to what it might be capable of becoming.

Asking someone that you don’t know to buy the very thing you’re offering is a great way to get genuine feedback. Not a reduced-price early version, not a freebie, but an actual MVP of the product you intend to offer, at the price you intended to offer it at. Ask anyone else about anything else, and you’ve changed an unknown number of variables.

It’s my assertion that perhaps if we resist showing an early product to this “warm market”, whilst finding out if a lean version of the product can be a success with genuine customers first, we may discover subsequently that feedback from friends and family would have misled us in those early stages.