Categories
development

When the old guard are not heroes

When I started programming, there were some key figures identified as the experts. They wrote the books that laid out how my code should look, how I should behave, and what the purpose of a software developer was. And there’s a new guard, also steeped in that mythos, publishing their hot takes and simple books.

I looked to my peers and seniors for guidance, and they looked to the agile manifesto, the gang of four and others. Those who packaged up existing ideas and best practices, set against a growing trend of Taylorism, and wrapped themselves in a punk ethos fighting the power, wielding keyboards like axes.

And there was value in what they were selling, small pieces that fed my hunger for “something better”.

But for all the bravado, the facade of Woody Guthrie and Bruce Springsteen they presented, deep down they were the establishment, tweaking the system slightly for their own benefit, re-engaging the bro culture of the “frontier spirit” of the early internet. Rules and processes are dictated by “the man” to restrict our freedom to innovate, and to work in the best way.

Companies formed and rose on the counter-culture ethic, buoyed by the vacuum left as union power fell, blinding us all that tech was the new utopia, and it brought a meritocracy that would bring equality.

And the gods saw agile, and it was good.

We moved fast and broke stuff, re-wrote the rules. The industry didn’t take time to consider why those rules existed, just that they were roadblocks.

So when women and people of colour, and anyone else who wasn’t a bro, stepped into the arena, they were vulnerable. Because there were still rules, just no process. And the rules aren’t made for them. And the gatekeepers, clear in their self-image that they weren’t racist, or sexist, and only discriminated on merit, could not comprehend that processes and written rules exist to limit privilege, because equality means nothing without equity.

They asked all of us, the squirrels, the rhinos, the fish, and the peacocks, to climb trees and collect nuts to demonstrate our worthiness to join their club, without regard for our skills or our backgrounds. They bully, they fight, they protect their own, because rules weigh us down, man.


  • People over process, so long as the people are the right people.
  • Working software, so long as it works for me. Anything else is externalities and not my problem.
  • Collaboration over contracts, we’re all on the same team, so forgive me as I forgive you.
  • Respond to change over following a plan, but is there a vision that informs what changes are acceptable?

Agile still has its place, but what would it look like if the manifesto and the guiding principles had been laid out by a more representative group? The antecedents, stretching right back through NASA, Bletchly Park and The Difference Engine, remain the same, and the key lessons are independent of those teachers, but what did we miss by not having others at the table?

  • What does process that protects people look like? Process that keeps people safe and secure to deliver the best solution?
  • What does software that works for everyone look like? Beyond documentation on accessibility and anti-discrimination.
  • What does proper, honest, compassionate collaboration look like? Within teams, between teams and across disciplines?
  • What does meaningful, people-centered change look like?

Software is too important to be left to the swamp that is this libertarian mess. The current ways are driving great developers out of tech, and users are not fairly represented. Some of the old guard recognise this, but many don’t, and they have plenty of followers who still believe the meritocracy myth.

There is no level playing field in tech.

Not everyone has spare time for technical exams outside work hours. Not everyone is comfortable pair programming. Not everyone can follow a spoken stand-up. Not everyone feels safe to bring their full self to work. Everyone is not treated the same. Not everyone can have alcohol and pizza. Not everyone has the experience of standing up to authority figures. Not everyone can be themselves without being judged or mocked by the cis straight white male gatekeepers, and their supporters.

There’s precious few unions and the biggest tech companies are all struggling with human rights, fair employment and treating their users fairly. And it’s not just them.

Unlike the 20th century, it’s not a battle between management and worker. Agile has cast management and worker in the same side, but some workers are far more equal than others.

People are not supported by the process. Software doesn’t work for everyone. Collaboration is limited because contracts don’t protect and promote safety. The plan for meritocracy to end discrimination isn’t working. How are you going to change it?

Advertisement
Categories
development

Ddd.scot, diversity, and your career

I had a great day at DDD Scotland, thanks to everyone who came along for the discussions. Apart from the panel sessions I chaired and participated in, Joe Wright ran a great mob programming session, Gary Fleming led a lean coffee session, and we had a couple of great lightning talks about recruitment at Skyscanner and Becoming a Technical Lead From Tugberk Ugurlu of Redgrave.

There were a few recurring themes that I want to highlight.

Diversity

This was a strong recurrent theme throughout the sessions in the community room. Whilst the focus was on gender due mostly to the makeup of the attendees, a few people pointed out the need to respect diversity for LGBT, age (graduates don’t have 5 years experience), family circumstances (single parents and others don’t have time in the evenings to do coding interviews), dyslexia and autism. To which I’d also add physical disabilities, skin colour, religion, any of which can and have been used intentionally or otherwise to limit the pool of candidates brought to interview, or created a hostile environment once in the job.

If you want to hire on merit, don’t just give the job to the white guy because he’s “a culture fit” and recognise that your recruitment may be biased. When I put an ad on Stackoverflow, all the replies were men, but working with a couple of recruiters we found a better mix of candidates, including the woman who we ended up hiring.

Job hunting and moving on in your career

There was a scary graph that suggests that computer scientists are less employable that other graduates, and yet of all the STEM subjects, there are more vacancies in software (where the stem jobs are ).

The job market is broken. There’s a lot of smart people out there, and for my last 2 jobs I had no experience in one of the key technologies they were advertising for, so the job adverts in many ways are meaningless. I want to work with people who have the skills to evaluate the next JavaScript framework, not 10 years experience in Vue. Nothing I work on today existed when I graduated. No ASP.NET MVC, no REST, JavaScript was for image rollovers, no Swift, no Xamarin. But job adverts don’t care about ability to learn. They’re a checklist.

I know recruitment agents get a bad reputation, and for some it’s well deserved, but a good one will help you get past the keyword gate, because they can sell you on your potential. If a company isn’t interested in your potential, choose another one. If you don’t want to deal with an agent, you need to be bold, demonstrate what you can for the requirements, and find examples to help them see that you can learn the rest quickly.

But have examples. You don’t want to be the clueless braggard who can’t even FizzBuzz.

Culture of learning, and mentorship

If you want to continue to be successful, you need to learn. Some of it you can do on your own, some you’ll need help with. If you’re working for the right company, they’ll provide you with a mentor, but even if they do, it’s worth finding others to help, whether it’s a formal process, or just someone to discuss if all companies make you deal with that stressful thing that’s getting you down.

Write a blog, volunteer for projects outside your comfort zone that help you improve those skills you’re lacking. Seek feedback. Accept that you won’t know everything and the learning experience is littered with failures. Learn by doing. Pair, mob, spike ideas.

When you’re tired of learning, find a new job.

Categories
development

Ddd.scot panel sessions and lightening talks

I’ve been selected for 2 sessions at DDD Scotland this year. There’s no presentation from me, but I’ll be chairing a panel, and appearing on another, so plenty of opportunities to answer questions. This is a new thing for ddd.scot, as well as the lightening talks stream to help you practice public speaking, or just share something cool. Please come along and provide your feedback.

If you’re coming, please submit a question to the Your Career in Software Development panel so we can answer the questions you have on your career. Submit your question anonymously here

Hope to see you there.

Categories
Blogroll

My 2017 in review

After the whirlwind of 2016, 2017 looked like a quieter year. Fewer talks, some interesting and rewarding challenges bringing a new product to market, and a chance to build and reflect on what it means to be a technical leader, to move jobs, and to be productively lazy. Although I notice there’s still a lot of interest in obscure bugs thanks to Chrome’s URL limit, and the User Experience when 2 factor authentication needs to be reset.

I’ve not had quite as many blog views as last year, but I’ve accepted I’m not here to be a blogging superstar. This is my scratchpad for the talks I want to give, and a place to share useful reminders and signposts for future me, and others. Thanks to all of you who have helped shape and refine these thoughts here, on twitter and via other channels.

I wasn’t planning a new job in 2017, but more on that next week (and many, many thanks to my twitter and LinkedIn connections on that front – I’ve been humbled), which means I have some more thoughts on the product life vs the consultancy life that I hope to share this year.

I got a few opportunities to think about applying Conway’s Law to build teams that make the right software, most notably in the Architecting Teams guided conversation I led for CodeCraft.

Looking to 2018

I’d love to keep up 2 blogs a week, playing with styles and topics, as I’ve started to do last year. I’ve got enough topics on my Trello board for a few years at that pace (including one describing the Trello board). I’ve got a new adventure, and some experiments in productivity that I’ll hopefully get more time to explore, as well as reflecting on design and the next generation.

I don’t do New Year resolutions. It’s always a bad day to start something. Always reflect, always refine. And if you leave it to New Year, you’re only giving yourself 70-odd chances to change. Why limit yourself?

Sláinte

Categories
code leadership

CodeCraft – Architecting Teams Notes and follow-up

Thanks to everyone who came to the CodeCraft guided conversation last week. I’ve added some notes to the questions below to carry on the discussion, and there’s a few topics I want to revisit in this blog, and in DDD Scotland if my talk is accepted.

The code craft team did a great job of reviewing and improving the questions so thanks to them, but I think in the very busy session itself, some of the questions were too ambiguous. For example, when I was thinking about goals, I was thinking about project goals and strategy goals rather than just “Make more money”, but I suspect that’s as much to do with the ambiguity many people have about their company strategy and culture in general.

It was also interesting to me to hear how agile is interpreted. The agile manifesto is clear that people take priority over procedures, and software over documentation, but explicitly the authors “still value the things on the right”. So it’s not about no procedures, and no documentation (please tell me you have coding standards), it’s about the right ones to support the people, the delivery of working software, etc. rather than documentation in its own right. Indeed, there are a number of explicit rules that an agile team needs in order to function. Is there a framework? What is the lifecycle of a unit of work? What language are we using? Not all of it needs to be documented, but some of it absolutely does, especially if you want to understand and improve it, and remove the rules you no longer need.

Be wary of anything that interrupts transparency, whether it’s Chinese walls, secret tasks, hidden agendas or ninja developers who work in the shadows and surprise everyone when they’re least expecting it.

And it’s never just enough to say who you are and what you do. Promote, encourage, and challenge. Be proud to be a diverse employer, to be wheelchair accessible, to have staff with more than 2 years real world experience, and welcoming to fresh faces with new ideas.

Trust. Respect. Communicate.


As a general point, I’m thinking of a team as “the people you work regularly with, usually daily”.

  1. How do you keep track of your team and the company goals?
  2. How does your team manage risk to and changes to those goals?
    • Pre-mortem
    • Chaos monkey
    • Agile “threw away risk register and other important documents”
  3. What makes a great team?
    • People
    • Feel comfortable
    • Trust
    • Communication
    • Balance
    • Good Leader
    • Sustainable development
    • Transparency
    • Healthy Debate
    • Growth and change
    • Common Goals
    • Motivation tailored to each person
    • Rules
      • Raise concerns
      • Feedback should be timely and structured
      • Coding standards
      • Process rules (e.g. how do we report a story can’t be implemented, what’s the weekly schedule)
  4. What would you change about your current team?
    • Management
      • Decisions made outside the team, not taking input from the team
      • Coaching developers to talk to management
      • Wrong person promoted to lead
    • Too many rules
      • “Because we’ve always done that”
      • Needs the context of why that rule exists
    • Clear roles
    • Respect for decisions the team has made
    • No secret tasks
    • Co-located, or remote, not mixed.
    • No “them and us”
      • Manager vs developer
      • Techie vs non-techie
  5. What makes you feel unsafe in a team?
    • Lack of:
      • Support
      • Communication
      • Respect
      • Goals
    • Secret genius / hero developer who does their own thing
    • Decisions made without buy-in
    • Teams without source control
    • No tests
    • Secrets
    • Success at the expense of others
    • Developers are not “resources”
      • And managers are not “overhead”
    • Fear
    • Stagnation
  6. How well would your current team survive a conflict?
    • To survive, have Strong Opinions, Weakly Held
    • Have a “naughty step” project for someone who doesn’t follow the rules, or doesn’t respect the team
    • Avoid imbalance in workloads that lead to loading stress onto key individuals
  7. Should teams change when projects change?
    • Teams should be mixed to avoid stagnation, but not completely break them up
    • Good teams can inspire others
    • Every good team cares about the product they produce
  8. How does the culture of a team change as it grows?
    • Negatively. Easily leads to “Us vs Them” (e.g. backend vs frontend vs DBAs, developers vs testers)
    • Lines of communication fail, especially as distance increases.
    • Old vs new – “I prefered the company when it was smaller”
    • T-shaped individuals are better collaborators
    • Tribe structures can help by allowing multiple communication lines
  9. What kinds of diversity should we seek in the teams we work in?
    • Diverse teams build diverse products
  10. Should we recruit to enforce the current culture or diversify it?
    • Put accessibility positively on ad when true (wheelchair accessible, BSL-friendly)
    • Do you know the current culture?
    • What is “culture fit”?
    • Does anyone know your company values? (not just the 5 Apprentice team names on the posters around the office)
    • Get job adverts reviewed by as diverse a team as possible
    • Diversify where the jobs are advertised
    • Not every candidate has 20 hours for a coding exercise, or wants to give up 2 holidays to pair with you
    • Coding review should be blind
  11. What one thing can a leader do to make a team great?
    • Trust
    • Delegate authority and empower the team
    • Protect the team
    • “Reading the room” understand what’s not being said so you can investigate
    • Push everyone to improve (including yourself)
    • Empathy
    • Happy people
    • Communicate
  12. Are effective teams a democracy or a dictatorship?

codecraftuk-sessions/architecting-teams.md at master · craignicol/codecraftuk-sessions · GitHub

Categories
development

The first rule of dog training

(EDIT : whilst the below line is an old joke, part of putting information out in public is making sure your facts are correct. So, for the dog trainers out there, as Christiaan Baes  🇧🇪 @chrissie1 points out, the first rule is Be Consistent, which means I can’t break this URL, but I will leave this note in place.)

The first rule of dog training is : know more than the dog.

If you pass that level, you’re ready to give a talk. Have you used node.js on a real project, or evaluated it properly against another framework? Have you failed badly on a project that would serve as a warning to others? Did you learn something important from your mentor or boss that they’re happy for you to share? What do you know now that you wish someone had told you last year?

When I first gave a talk in public, I was very nervous. I still get that way.

My first talk wasn’t an original idea. At the first DDD Scotland, I saw Ben Hall talking about Red, Green, Refactor and took the ideas away to try it properly, without fully understanding it (sorry, Ben). The following year, at the next DDD Scotland, I did a live coding session entitled “TDD? I don’t have time” that revisited the highlights of that talk, then filled in some of the lessons I learned from applying it. There was a bigger audience, and lots of fresh faces who found the idea interesting, but I didn’t plan it enough and it was very rough.

I started giving talks as a way to improve my communication skills. And on my first attempt, I failed badly. And I had to make the choice. Do I write it off, and retreat, or do I keep doing it so I can learn to do it better? It was a talk about agile principles, so I had to take the latter route.

So I did some user group talks, 20 minutes, instead of an hour. Some pikka machu talks, 6 minutes. I’ve since done workshops and guided conversations, where I let other people talk. I’ve paired with others to talk. I’ve talked about technology, people, other talks I’ve seen and the near future. I learned some tricks along the way, but Scott Hanselman (check out the related links too) and Christos Matskas summarise them much better than I could.

There are good reasons to speak at user group events, or conferences, or in your office. Don’t be afraid of being noticed. And if you want any more advice or encouragement, leave a comment or find me on Twitter or LinkedIn.

And don’t forget, DDD Scotland is back. Submit.

Categories
code leadership

CodeCraft – Architecting Teams

Thanks to everyone who came to the CodeCraft guided conversation yesterday. If you want to reconsider any of the questions yourself, you’ll find them below.


As a general point, I’m thinking of a team as “the people you work regularly with, usually daily”.

  1. How do you keep track of your team and the company goals?
  2. How does your team manage risk to and changes to those goals?
  3. What makes a great team?
  4. What would you change about your current team?
  5. What makes you feel unsafe in a team?
  6. How well would your current team survive a conflict?
  7. Should teams change when projects change?
  8. How does the culture of a team change as it grows?
  9. What kinds of diversity should we seek in the teams we work in?
  10. Should we recruit to enforce the current culture or diversify it?
  11. What one thing can a leader do to make a team great?
  12. Are effective teams a democracy or a dictatorship?

codecraftuk-sessions/architecting-teams.md at master · craignicol/codecraftuk-sessions · GitHub

Categories
development leadership

How to run a stand-up meeting

  • These tend to run smoother face-to-face (or video-to-video) since part of their benefit is ensuring everyone is working as a team.
  • Run them at the same time every morning so that they become a heartbeat of the project
  • Keep it short
    • If it takes longer than 10 minutes, take discussions out of the meeting
    • If there’s too many people for the time, split up the team
  • Format is very important, everyone should say the following:
    • What they achieved yesterday
    • What they plan to do today
    • Any blockers or impediments to their progress
    • (Other formats are acceptable, so long as it is agreed and followed)
  • As the team lead, use your achieved and plan time to provide feedback on any outstanding or resolved blockers.
Categories
development programming

Working exactly to spec

Is there a problem?

  • The work was completed to spec.
  • Any additional work was likely to break the time and cost estimates.
  • The work meets the current standards. To bring the remaining paintwork up to standard would require removing and re-implementing the solution, further risking budgets and blocking higher priority work.
  • The only available colours do not provide the legacy appearance required to match the existing lines.
  • The blue lines were not part of the original specification and therefore no knowledge is available on their purpose and whether they should be extended or removed.
  • The disjointed yellow line on the right-hand side would require straightening, which would cause confusion to existing users. There are multiple consistent configurations and the workers have no means to evaluate which of these minimises confusion.
  • The user who raised the bug report is unaware of the timetable detailing the repainting plan and the agreed extent of the lines.
  • The user who raised the bug report is unaware of future proposed fixes that will require additional upheaval. Any attempt to fix other line issues now will result in unnecessary rework.
  • The existing pattern does not cover the required scope (see the far side), and any additional work would lead to scope creep to correct this error.
Categories
development

The Father Dougal trap

Every day we work with a codebase we get smarter, we learn more, we have more context, we refactor, we compromise and we understand.

Every day we work with a codebase, our estimates improve.

But some days we get asked to estimate “everything on the backlog”, with a large dose of yesterdays weather, and a divination ceremony that uses numbers and maybe spreadsheets to make it look like engineering.

And the tasks we tackle the following day or the next sprint, or the sprint thereafter are mostly going to match the estimates, except for the knotty ones that don’t. And the ones further away will match less because by then we’ll know more. And we know we’ll no more, and we chose, or are advised, not to do them yet.

Those are the indistinct shapes in the fog. The ones that look bigger than what you’re doing now but definitely a lot smaller than those big problems we’ve tackled in the past.

Or are you fooling yourself? Do they only look small because they’re far away?

When you get close, will you find that even your best tools aren’t up to tackling this monster, and you’ll need to invent some new ones? And that will take time, and rework.

How far ahead are you estimating, how soon will you get there, and how confident are you that size isn’t an illusion?