Last week, I attended an LSCC (London Software Craftsmanship Community) open space, hosted in the Codurance offices for the first time! We celebrated LSCC’s 6th birthday (so there was cake – my kinda meetup!) and a very decent vegetarian pizza. But, this isn’t a food blog so let’s move swiftly on…
It started out with some interesting lightning talks, we had someone talking about communities and how the culture of a community defines that community; we had another talk introducing the some of the concepts of DDD; some people describing their company’s transition from horizontally aligned teams (one in charge of the database, one in charge of the UI, etc) to more feature aligned teams (where every team had the expertise to deliver a whole feature, front to back); just to name a few!
We then broke out into smaller discussion groups after voting for the topic that we wanted to chat about. I wanted to clone myself a few times during the vote – there were plenty of topics I cared about and would’ve wanted to discuss. However, after deliberating a bit I joined a group discussing two different but related topics – “How to create a work environment to attract the best developers”, and “How to build a Software Craftsmanship Community in your workplace”.
Unfortunately, we were so involved in the discussion on the first point we lost track of time and didn’t get to discuss the second in any level of detail during the formal discussion! However, a few of us stayed behind afterwards to exchange ideas and experiences, and Shane has already very eloquently summarised what we talked about in his blog post here.
I found it very interesting speaking to people about culture in the workplace, and what they value – it’s something I’ve been thinking a lot about lately. We had a very wide variety of people, some from very small technology companies, and a few who, like me, worked in much larger companies where tech was just one aspect of their operations, and the difference certainly showed!
Over the course of the discussion, a few common themes kept cropping up:
We spoke about trust a LOT. We said that developers are experts in what they do, and as such they want their opinion on all things development to be listened to, valued, and trusted.
- If a team of developers wants to use a new technology, as they feel it is more suited to what they are trying to achieve, then (to an extent) they should be able to do so. This was one of the areas where the difference between smaller and larger organisations presented itself – those working in larger companies are used to these sorts of decisions being completely dictated by management!
This brought about further discussion where we put ourselves into the shoes of managers, and understood that it is not always wise to have several different technologies at play as this could lead to pockets of knowledge, where individuals or teams are the only ones who can make changes to particular parts of an app simply because most people don’t have the expertise to be able to do so.
We also agreed that while a developer values trust, s/he understands that a decision like this is a team decision. We cannot have individual developers deciding that they’d like to use some new shiny technology that no one else understands.
- Similarly, the developers should be trusted with being able to implement a story as they see fit. They do not need non-developers breathing down their necks telling them where and how to make changes to the application. They know and understand the code better than anyone else!
Developers, or good developers, enjoy working with other people who care about their craft as much as they do themselves. They like to know that the other people who have access to the same codebase have the same vision, and want the outcome to be beautiful. It can be very demotivating when you see code you’ve taken such care to write, degenerating into chaotic legacy code simply because someone else didn’t have the same vision for the code as you did. Developers also (generally) like discussing the code, why they did things in a certain way – and being able to learn from peers and have others understand your approach or give feedback on your code is a priceless learning opportunity.
Working With Management, Not Against Them
Over the course of the discussion, we addressed the fact that part of the problem we have is an “Us vs Them” mindset when it comes to management. This tied in with the trust point above, but essentially what came up was that ideally, developers and management have to work together to come up with a solution both are happy with, and recognise that ultimately their goal is the same – to give the users what they want. Too often, it becomes a battle between the two, and perhaps because they don’t understand each other’s aims and objectives.
On this point, there is a fantastic talk given by Ted Neward at DevoxxUK 2016, called “Managers are from Mars, Developers are from Venus” which I’d recommend everyone watch! Perhaps there’s a market for management/developer relationship counselling 🙂
Finally, if possible, it’s an amazing feeling of satisfaction when a developer can actually see their work being used, and working! Too often, especially with a large application, the code is released and we never hear about it again until it breaks. For a developer to sit with a user and actually see their work in action, providing value to people, makes the whole thing worth it :). This point has also been raised to me by friends who are working on applications which they see and use outside of work.
During the discussion, multiple people recommended the book “Peopleware” by Tom Demarco and Tim Lister. I’ve not read it myself but it’s definitely on my list of books to read!
Are you a developer? Or do you manage developers? What are the most important things to you when it comes to the culture of your workplace? Do you agree/disagree with anything above? Comment below or tweet me @fdayamani!