Empathy – the 4th most popular word in 2017, according to Merriam-Webster. It’s interesting that this word has risen up in its popularity this year. Mirriam-Webster also points out the connection between politics in the USA, and the increase usage and searches for empathy.
Here’s Google’s take on how empathy is doing 2017. This is a trend graph compared to sympathy and compassion:
The career of being a software developer can be a bumpy one. From the very start you are challenged by technical challenges you have no idea how to solve. Some grasp the concepts and principles easily, while others struggle. It’s an uphill climb of continuous learning. Constant failure, and success just a semi-colon away.
One of the biggest challenges during this process isn’t technical, but rather social. Around each turn you uncover new wonders, and new challenges. When you start a new job or position, publish a blog post, submit a pull request or even make a product. There will be people lined up to tell you how wrong you are and as a result; how you’re not good enough. I’m here to tell you, that you are!
Using tools like GitHub or BitBucket allow developers to able to submit their changes through pull requests. One of the challenges with pull requests is that they often contain very little information, apart from the change itself and perhaps the issue or case in question. Bad pull requests make the lives of reviewers a lot harder, and mean they need to spend a lot of time understanding the context. Instead of focusing on the change itself.
So, how can you improve your pull requests? Continue Reading
We’re coming upon the end of another year. An eventful year that may have left you with a mix of feelings. Some people wish for 2016 to just get over with and hope for a more positive 2017. I won’t dwell on those aspects. Let’s let the years events be and do what we must to improve and make it better.
On a personal note, I’ve come a long way in the past year and as a result, so has this blog. It’s hard to imagine I was just coming out of a period of burnout, struggle and depression. My recovery manifested itself into the journey that is this blog and everything that’s spawned out of it. I’ve made some wonderful connections along the way, and what better way to celebrate the end of the year than to celebrate these connections? Continue Reading
I’ve been fortunate enough to be interviewed on the Legacy Code Rocks podcast. We had the chance to dive into empathy in software development and cover quite a few topics. I feel it was a really good conversation and I learned a lot. Hope you enjoy it! Continue Reading
When working in a team trying to deliver software things don’t always go right. Quite often they actually go wrong. Sometimes though they go so wrong that there are consequences for others. And when things go wrong, someone is to blame.
It’s natural to protect yourself and make sure all attention is on the next person by blaming and pointing. Perhaps you just sit idly and let others deal out blame and this helps you get by on a day-to-day basis. If you and the people around you are dealing out blame, you aren’t only making it bad for those around you, but for yourself.
The 2016 Empathy Global Index was originally published in the Harvard Business Review. The source of this global index is from The Empathy Business, a UK-based firm “Committed to bringing empathy to business”. This is the 3rd year they have published the Empathy Global Index. Continue Reading
As a technical team lead, you are in a unique position to facilitate the growth of your team or watch it spin out of control. You can run it with an iron fist or meekly get overrun by strong forces. You can encourage psychological safety or allow watch things fall apart in a toxic environment.
What makes or breaks a team? How can you bring out the best in the people around you? What can you do as a technical team lead to ensure the success of your team, and as an extension your product? Continue Reading
Many software development teams have a process including retrospective meetings. An opportunity for the team to look back at a period of time and assess how it has functioned. It’s often connected to the Scrum, but you don’t need to be adhering to any process / approach to see the value of having retrospective meetings. The goal of the retrospective is learning. What worked? What didn’t work? How can we improve something that’s broken? Should we continue with something that’s working?
Another aspect of the retrospective is that it’s meant to be a safe place for team members to speak their minds. The idea being that given a safe place, a team can figure out its own problems and possibly even solutions.
To create that safe place there needs to be trust. Enough trust so that team members can be candid with each other about issues that arise while working together. Enough trust that allows the team members to be vulnerable, and know that they won’t be judged. Where blame isn’t handed out, but rather bonds created and learnings are formed.
But how do we create a space in the busy life of a software development team, where deadlines and bugs are commonplace and there’s often a pressure to deliver something that will create value? Continue Reading
I recently wrote about candor as a better way to achieve truly open and honest communication. Candor Inc created the framework of “Radical Candor” as a way to categorize your feedback and communication.
What I didn’t do in my previous post, is dive into how the different ways of communicating actually would sound like. In this post I’ll explore the framework more deeply and also look at an example.