As a community, or at-least on my twitter feed echo-chamber, we do love a good moan about broken hiring processes. Often for good reason and to hilarious effect. I’m not saying we should stop doing it, although once I’ve finally worked out how many golf balls you can fit in a Boeing 747 maybe I’ll change my mind.
But forget all that - I want to turn the tables. I want to discuss what it’s like to be the interviewer, or more specifically, some of the biggest mistakes I’ve made when it comes to hiring people... or attempting to.
As more grey hairs start to appear on my head, more contentious opinions on the art of programming start to develop inside it. And I've noticed three of those opinions that just keep getting stronger. Either I'm completely wrong (did happen once), or you should be taking more notice of these good habits, too.
And please tell me, which 3 beliefs have you come to hold so dearly that you wish everyone else did, too?
I love my type system like a big, cuddly teddy bear
Having spent over a year working in the UK government as part of large scale digital transformations, I wanted to show people lot's of the amazing things that are happening there. I wanted to give recognition to all of the hard-working people in government who have achieved incredible things, and I wanted to inspire other people to work in government IT, too. I also wanted to highlight some of the problems that are preventing government agencies from being agile and how they can be fixed.
Since making the mistake of writing a DDD book, I now get lots of people asking me how they can sell the benefits of DDD to management, how they can teach it to their teams, and even how they can make sense of it themselves.
I know that feeling too well. The first time I read Eric Evans big blue book, I felt like I'd learned a huge amount, but my brain was stuck thinking: "Ok, I've read the book. What on earth do I do now?".
But I'm pleased to announce that there is now an easy way to sell, teach and explain DDD - with "The Anatomy of Domain-Driven Design" Infographic. You can grab as many digital copies as you like, free on Leanpub.
Programmers are on-par with politicians when it comes to fiercely debating and rarely reaching agreement - we argue about everything. Getting programmers to agree and be productive together is probably the hardest problem in software development.
Which programming language shall we use? Is SQL or NoSQL best? What is the one true version control strategy we must use? Should the name of this class be a noun or verb? Or should that class actually be 3 smaller classes?!
Two developers politely discussing whether to use MongoDB or Postgres
Debate is fine. A range of opinions is healthy. Even a bit of friction now and then can be productive. But, too often, for developers, decision making brings out the worst in us. We refuse to accept that our opinion is not the right one, and we won’t let it go.
With each of us having a diverse wealth of experiences, preferences and opinions on the subjective art of software development, is it even realistic to expect healthy debate and unanimously-accepted decision making in a team?
Yes it is. It is possible to have a passionate team of developers, with a diverse range of strongly-held opinions, and absolutely it is possible for them to work harmoniously and productively. But how?
Tech is overflowing with organisations wildly proclaiming how much more digital they will become, how much more agile they will become and how much more customer-driven they will become. But beyond the hype and sensationalism, many transformations fail. And for some strange reason, people are less keen to talk and blog about their embarrassing failures.
Transformation requires a strategic long-term vision, based on an understanding of continuous delivery and matched with an unrelenting commitment to organisational change. And that is hard. Changing people’s beliefs and how they work is hard.
What I see and hear, over and over and over, is organisations doing what they always have but giving things funky agile names and making cosmetic changes. Project managers? They’re called Scrum Masters now. We don’t do waterfall anymore, but we’ve planned out the next 27 sprints in minute detail. Empowering our teams? Of course we let them put sticky notes on the wall!
But the mistakes I see. Always the same. The same fundamental problems that aren’t easy to solve, but do have tried and tested solutions.
Most software developers thrive in environments where they have freedom and flexibility to put their creative minds to work and solve challenging business problems. The organisations they work for benefit too, through a motivated workforce, and a reduction in people management.
Freedom necessitates judicious boundaries, though. Team boundaries and technical boundaries. If teams are constantly relying on each other, or constantly having to coordinate themselves around shared resources such as code or databases, freedom diminishes and the overheads of people management increase.
But what tools do we have for carving out these judicious boundaries for productivity, autonomy and freedom? Are microservices the answer? What about bounded contexts? Or should we be understanding more about our problem domain first?