It inspired me to create my Technical Excellence Manifesto, using the same style "this over that" to share the vision of an ideal Tech Org with people I work with.
I've always strived for collaboration without understanding the difference to cooperation at first. The book "Coaching Agile Teams" by Lyssa Adkins reavealed it to me:
Cooperation means dividing work into separate parts that everyone can work on idenpently. Thus, the result of cooperation is the sum of its partial contributions and needs handover.
Colloboration means working together at the same time on the same task. Thus, the result of collaboration is the product of its partial contributions and it is no longer possible to distinguish the individuals' achievements.
It's not always possible to collaborate on everything. But especially for in-depth knowledge work it yields far more better results than cooperation because in collaboration we leverage everyone's skills, knowledge and experience.
Pairing is a specific form of collaboration and you cannot only pair on coding (pair programming) but also on creating a vision, strategy, requirements and much more. Pairing is powerful because you yield instant feedback. It originated from Extreme Programming.
Parallelising on the other hand creates more work in progress which at first might look like optimal utisation of the team. Kanban teaches us however, that utilisation is not what we should optimise a system for but flow. By optimising for utilisation, we create more waiting states in a system and thus work is stuck and not completed timely. We see this effect when Code Reviews are used as a quality gateway and Software Engineers parallelise on building features: they often wait for each other for days to review each others code.
Some people still think Pairing is wasting time as two people are utilised on the same problem. My own experience is that when working alone on a complex problem I more often get stuck or walk into a dead end. Pairing enables me to keep momentum and avoid time-intense rework.
The Agile Manifesto states "Working software over comprehensive documentation" and yes, it's not helpful to have everything documented but nothing working.
Nevertheless, good documentation enables onboarding. It also uncovers misunderstandings within a team.
When Tech Orgs grow and change, there's a constant need for onboarding new people. So having no documentation at all - which is not what the Agile Manifesto suggests - is a major risk.
But we all know that documentation gets outdated as soon as it's written and that's why I'd recommend using "living documentation" whenever possible.
When I started learning Ruby on Rails, I was awed by the simplicity of coding in this framework. I came from a Java background where I was used to write a lot of boilerplate code and configure the usual things over and over again.
"Convention over configuration" is so deeply embedded into Rails that you can start working immediately on the business specific problems. This principle is not limited to Rails however.
I recommend using it also when creating code, APIs, systems: for the default case, just use the default configuration and spare the user this complexity.
When working with software, it's very common that people assume that a certain change needs to be big and cannot be cut into smaller pieces.
I've argued both with Software Engineers ("This refactoring cannot be done incrementally! It's all a big ball of mud and we need a complete rewrite") as well as with Product Owners ("This epic will only create business value if we implement all the features! We can't just release a few of them!") and whenever I was allowed to, I proved them wrong.
Big bang changes come at a high cost. Errors in big bang changes are hard to find. There might be a lot of work done in big bang changes that was either wrong or not necessary and reverting it creates even more work.
Incremental change helps us to get something done and out of our heads. We don't need to keep two different models in our head: how the system is now and how it will be. This reduction in mental load frees us to focus on the next small change.
Continuous Integration, Delivery and Deployment are practices that apply the principle "incremental change over big bangs" when writing code.
Years ago, I discovered corgybites, a company specialising in refactoring legacy code. Their articles helped me to understand that incremental refactoring is more risk and cost sensitive than big bang rewrites.
It's important though that Product also understands this principle and creates User Stories that are independently deployable and as small as possible. The exercise Elephant Carpaccio - now rephrased as "Software Carpaccio" - has helped me to understand and teach how to create small User Stories.
When transitioning into leadership in 2019, "incremental change over big bangs" became even more important to me. As leaders we are often change agents and actively drive reorganisations. This is also something that is better approached incrementally than with a big bang as small changes will create less resistance and make it easier to integrate feedback.
I've shared this experience in a blog post and a talk.
In Software Engineering there is always more work to do than we can ever accomplish. Realising and embracing this logically leads to finding more effective and efficient ways of working. This is at the core of working agile: "Inspect and Adapt".
About 7 years into my career as a Software Engineer, I started to reduce my working hours because I realised that I was too exhausted on Fridays to get anything meaningful done and was also compromising my health and fitness.
I ended up with a 4-day workweek and then transitioned into leadership. Not wanting to compromise on my health and fitness again, I kept the 4-day workweek and optimised for working smart in order to keep up with the new requirements of my leadership role.
Working smart to me means making sure I understand what is important and what is urgent. That I balance both and work proactively on important stuff so that I don’t get overwhelmed and driven by urgent stuff. Take preventive quality measures as an example for important work and bugfixing as an example for urgent work. Working smart also means taking ample time to educate myself and my colleagues and that we continuously improve our way of working.
Working hard on the other hand is something that especially start-ups demand often from their staff and often just means putting on extra hours. While there might be phases in which working hard is necessary (weeks not months), asking knowledge workers to always work hard will result in less or even no learning which is absolutely required to work smart. Without adaquate rest, people make more errors and poorer decisions. And at some point they just fall sick.
----------
To get a deeper understanding of my reasoning, check out this video of the CO.DE interview series in which I share my personal software engineering journey and the Technical Excellence Manifesto: