Category: Technical Leadership

Let’s Stop Making People Feel Stupid.

Let’s Stop Making People Feel Stupid.

(Image / comic by xkcd: https://xkcd.com/1053/)

“I know nothing.”

“I know less than nothing.”

“I am an impostor.”

“The more I learn, the more I realise how little I know.”

These are sentences that will be familiar to the vast majority of IT professionals. But how about these?

“They know nothing about X.”

“They have no relevant experience.”

“Wow, I just discovered my colleague doesn’t understand Y. I’m shocked.”

“Can you believe, I just interviewed this dev, and they didn’t even know what a Z was?”

Over my 18-year software career, those last two have been said to me countless times. They are said derisively, scornfully, impatiently. And every time those words are said, we lose both existing and potential members of our profession. We lose them because they feel stupid; because they believe they can’t keep up; because they have given up on ever really knowing what they’re doing; because they’re terrified that people are saying the same things about them.

We work in an industry where knowledge is highly valued, and where every time we look for a new job we have to prove how much we know. We find ways of posturing to one another, of proving how well-informed we are. Sometimes we join in when others’ knowledge is criticised – relieved that we are not the target ourselves.

And yet, we know that everybody has gaps. There are a million different paths through software development, touching a million different combinations of technologies and skills. On a day-to-day level we have to specialise on one task at a time. The skills we don’t need right now are necessarily forgotten, or delegated to someone else. And that’s fine.

Let’s stop putting pressure on individuals to know everything, and focus instead on how teams can work together to build and provide the unique combination of skills required to deliver their current project – in the certain knowledge that whatever that combination was today, it will be different tomorrow.

Instead of knowledge, let’s focus on aptitude. Instead of judging people about what they don’t know, let’s help them to feel excited about all the new things they’re going to discover.

Instead of saying “For God’s sake, do you really not know about X?” let’s say “Fantastic, you don’t know about X! Lucky you. That means you get to learn it. What can I do to help?”

(I’m hoping to do talks on this topic at events in 2018 – let me know if you have an event you’d like me to talk at).

Fighting Procrastination (in solidarity with all teachers everywhere)

Fighting Procrastination (in solidarity with all teachers everywhere)

I used to be a high school maths teacher. It didn’t go well. I miss the energy and creativity of the young people I worked with, but apart from that I have no regrets about leaving that profession behind me.

A friend of mine has just completed his first term of teacher training, and it’s HARD. You would think that now the Christmas holiday period has started, he’d be able to have a rest. Nuh-uh. Too much work to do.

Coincidentally I’ve also been facing a giant to-do list this week, and with the festive season fast approaching I’ve struggled to stay focused. But I have various coping mechanisms, which I just shared with my teaching friend and I thought were worth preserving for my own benefit too. And if they can help anyone else (particularly teachers), so much the better:

“What you have to remember is that you’ve been working flat out for months without even the option of slowing down. Whether you like it or not, your mind and body need a rest and what’s happening right now is that your subconscious is forcing that rest on you whether you like it or not. Sadly your conscious mind knows that there isn’t really time for that rest, and that’s preventing you from enjoying it – which is a shame.

So…

1) Accept right now that the workload is impossible. Therefore it’s either not all going to get done, or some of it will have to be done to a poor standard. There’s no point lying to yourself about that. You can’t bend time. You and thousands of other teachers are in the same position and you just have to accept it.

2) Given that you’re not going to get all of it done anyway, just pick TWO OR THREE SMALL THINGS and do those. Be unambitious. Don’t tell yourself “today I’m going to do the top 50 things on my to-do list,” because that’s a lie. You’re not going to achieve that, no matter how much you hope. And you already feel shit about that, and the whole thing is so depressing that it’s preventing you from doing anything.

Instead, aim low. Tell yourself you’re going to do a small number of things. Then do them, and feel good about having achieved your goals for the day. If that glow of success gives you the energy to do a little more, fantastic. But don’t plan for that, otherwise you’re back to square one.

Baby steps. You need to get back into a rhythm. If somebody gives you a mountain to climb when you’ve just eaten ten mince pies, you’re going to tell them to sod off. But a flight of stairs? Yeah. That’s a possibility.”

POSTSCRIPT:

I just did something which I realised I often do, and may also be good advice:

I scrolled down my to-do list until I found something I could easily do. The thing in question is pretty pointless and not at all urgent. It can easily wait til after Xmas and the world wouldn’t end if I never got round to it at all. But it’s a gateway drug. It’s not only easy, it’s vaguely enjoyable. And I know that it represents an “in”, ie once I’ve done that, I’ll be in the swing of Getting Things Done and I’ll find it easier to tackle a more worthwhile item from the list.

I know from experience that if I don’t do this, I’ll just arse around on the internet and do nothing from my to-do list. So it’s better to do something slightly pointless, but knowing I’ll find it much easier to follow it with something pointful… than to do nothing at all.

Want to learn Git / improve your Git knowledge?

Want to learn Git / improve your Git knowledge?

This list is culled from a thread where people were asking for useful resources when learning Git. A lot of useful recommendations were made, so I’m summarising them here (for my own benefit as much as anything):

I ran a git workshop for some devs earlier this year – I created a repo, a bunch of exercises and some top tips. Everything you need to find your way around should be in the readme: https://github.com/claresudbery/Git-Playground

I find it very helpful to understand what the definition of a branch is: it’s just a commit, which defines the current head of the branch …and that allows you to explain the concept of “detached head”.

I would also encourage people to dig a little into the gitconfig folder and understand what diffs and commit IDs are all about.

Criteria to Apply to Third Party Vendors

When assessing third-party products to purchase their software products:

  • Products need to be cloud native, extensible, and use open standards for integration.
  • How quickly do updates move from development to production? Do they use CI?
  • What do their processes look like?
  • What sort of extensions do they provide?
  • Do they allow you to customise a product without going off the upgrade path?
  • How will you migrate your existing data to the CRM solution?
  • Is data security guaranteed?
  • Does the solution have regulatory compliance?
  • Can you have a single central identifier for each customer, that can be used across systems?
  • How will communication happen between systems?
  • Does the vendor give good support?
  • Are their APIs fit for purpose?
  • Will they give you all the access you need?
  • Will they respond quickly to attempts to communicate / collaborate?

The Tech Lead’s New Project Checklist

These are my notes from a session on what a tech lead needs to do and know when arriving on a new project. The wisdom came from @JimBarritt at Thoughtworks – I am just the conduit.

Note that this list applies both to projects that existed before the tech lead arrived, and those where the whole team / product is new.

The first two are apparently “the two most likely causes of death or injury”:

1) Infrastructure

  • Where’s the production environment? It’s the most important one! What does it look like? When will it be ready? (Development environments are an afterthought after prod)
  • How are we going to go live? What’s the plan?
  • Load balancers
  • Firewalls
  • Certificates

2) Third parties

  • Integration!
  • If environments beyond your control are chaotic, it’s even more important to make sure your own environment is super-organised and disciplined, smooth, automated, with good scope planning, etc

3) Find the movers and shakers

  • Find all the people who can say No, and the people who hold the purse-strings/can sign off budgets, and the people who can say “Yeah, you did a good job” and get to know them
  • Eg:
    • Architects
    • The person who has control over data protection (Beware “organisational scar tissue”)
    • In the public sector, the SIRO (Senior Information Risk Officer)

4) Find any top-level documentation of your team’s work, read it and understand it

5) What’s the budget and the value proposition?

  • How well defined is it? Why are you doing the work? What’s the vision? Do people understand it?
  • Once you find this info, be really repetitive about it
  • If there are assumptions which are crucial to the whole success, keep repeating them at the start of every showcase

6) Try to have a one-to-one with each person in the team

  • Try to understand what their goals are, particularly on the project – and be transparent about your own goals. For instance if you have areas you want to move away from, find people who are keen to move INTO those areas
  • What are their main pain points and blockers?

7) Befriend a project manager and get to understand how they manage budgets

8) If there are multiple teams, find and get to know the other tech leads

9) Understand the importance of the Trinity of delivery: Delivery manager, product owner, tech lead

  • There is often a tension between these three areas
  • Build relationships with these people
  • All three should be present for all decisions, otherwise it’s likely to be skewed
  • Tech leads can sometimes get a bit side-lined in these relationships

10) Backlog: make sure the scope is clearly structured

  • Use story trees and backlog hierarchies
  • People can struggle with higher levels of grouping / scale
  • You need to get into the helicopter, go up and look down on the thing you’re building

11) Code:

  • Make sure you have access to it
  • Remain connected to it
  • Get a couple of the devs to give you a guided tour
    • Can be particularly illuminating to get newer team members to do this
  • You need to be able to visualise the entire code base (overall architecture)
  • How easy is it to run it from scratch for the first time?

12) What are the pain points and blockers?

  • Project manager is good person to talk to about that

13) Cross Functional Requirements

  • Resilience & scalability
    • Is it going to fall over with the load
  • Security
    • Is someone going to break into it?
  • Automation
    • Although automation is awesome, don’t fall for the trap of thinking you have to set everything up at the start
    • Don’t necessarily prioritise automation – but do prioritise what you need to actually deliver something
    • Once you have something up and running and iterating, it’s all good – but how do you break that initial blank sheet of paper?
    • You want pipelines etc, but as a principle, maybe there are different laws of physics right at the start of a project
    • Don’t spend six weeks building a pipeline with no actual deliverable – make sure you have something iterative
    • Imagine this product that you’re building… imagine you’re doing it with no software at all. Then bring the computer into it, and ask why – what is it going to give you? Where can it give you the most value? Don’t add stuff you don’t need
    • Imagine a walking skeleton in business terms – for instance, delivering whisky by physically posting it*. Your deployment walking skeleton can be over the top – only automate something when you need it
    • It’s a subtle art though – you don’t want to end up with tons of tech debt
    • You can spend a bunch of time working out the concept without having the capability.
    • Could have a simultaneous technical alpha – looking at cross-functional requirements etc
    • Try a walking skeleton of the architecture – a “scale model”

14) As a tech lead, what things are scaring you most about this project?

  • Do a futurespective graph with time on the x axis and clouds of uncertainty. If the cloud is really close and has a lot of lightning coming out of it… pay attention to it!
  • This is partly about risk management

* Whisky idea inspired by JK Werner.