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.
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
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
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.
Working in any team environment will involve communication between its members. To really bring the best out in others and yourself, having a culture of where honesty is important. It’s also something almost anybody will verbally agree to. Yet being open and honest in a good way is extremely hard. How often do you refrain from saying something completely honestly because you don’t want to embarrass someone. Or what about the time somebody called you out on something in front of the team? Sure you may have needed that feedback, but what happens to your relationship with that person? What about the team dynamics?
Blunt honesty can not only be harsh, but downright devastating to hear. How then are we meant to move beyond the complications of honest communication and get to a place where our being honest actually provides room for everyone to grow? Continue Reading
Just from reading from the title, you may have already made up your mind about what this article is all about (and you’re probably right). I’d also wager that if I’d said this directly to you, you’d be ready with a response just as I was uttering the last word. But do you really know what I mean? Why did I use those words? The need I’m trying to express? Which assumptions do you have when interpreting my words that lead to the immediate response or feeling you have now? The thing is, you suck at listening, and I do too.
Developers often find themselves in situations where we need to make decisions, weigh in our opinions and persuade others of our views. We often fail miserably by oversimplifying, jumping to conclusions or arguing. Our responses and thoughts are based on our experiences and assumptions. Which is great since it reduces the cognitive overhead of actually listening to each spoken word. Communication isn’t easy, but we can improve drastically by talking less and listening more. Continue Reading
Most developers can master the skill of listening to spoken words quite well. It’s easy to grasp words, run them through the compiler in our mind and spit out instructions. The compiler is based on sub-routines created through our life experiences, ready to give an output based on any input. These sub-routines remove the cognitive burden of weighing and considering each and every spoken word.
We spend our careers learning how to understand communication with compilers, yet struggle to effectively communicate with the people around us. Can we shift our built-in compiler to interpret words and actions in a way that opens us up to more empathic communication? Continue Reading