Efficiency and effectiveness. These two concepts are quite often mixed up. Each with their own strengths and weaknesses. Understanding these concepts will increase the impact of a software developers work. Continue Reading
You’re talking about a new feature that’s being planned and prioritized to the dev-team. It’s straight-forward enough, but you sense that it’s latching on yet another feature to an existing long chain of functionality. The team has some reservations to expanding the feature chain even more before doing some adjustments to how it’s been architected to keep this maintainable. That’s when you hear from the product owner: “Just add an if…”. Continue Reading
Let me introduce you to Malcolm. He’s my imaginary developer-friend currently working at Mega Enterprise Inc Ltd Corp. He’s been butting heads with the lead developer, Jack, for a while now. They don’t seem to be seeing eye to eye on a feature that Malcolm implemented. You see, Jack doesn’t like how Malcolm writes his code. Formatting is wrong and he uses way too long variable names, and he doesn’t write a single comment and…(list goes on)! Jack hates reviewing Malcolms code. Malcolm usually gets his code back from Jack, with a long list of TODOs. So Malcolm goes off to re-do most of his work just to give it back to Jack…When Jack’s finally happy with the code; It adheres to his preferred coding style and uses the correct enterprise patterns that have been decided upon. He allows it through the magic gates to master. Continue Reading
Working in a distributed team isn’t easy, especially when members are spread across 4 locations. I was recently part of a team that was doing pretty well, but wasn’t functioning as a cohesive unit. There seemed to be hesitance towards pair-programming sessions, even though doing quick Skype calls seemed to be fine. We were relatively open during retrospectives, but were missing out on the deep conversations.
I had a feeling this was a trust issue, and that spending more time together could help. Sitting in an online meeting doing team-building exercises didn’t seem like the best approach, which is when I stumbled over Mob Programming as a way to both get work done, and build up the team’s collective trust and understanding. 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
We’re sometimes placed in situations where we need to present our software to stakeholders, business owners or end users. These users may or may not be technical, but they will most likely be the other side of the user interface you are creating. They are the reason you create software and are genuinely interested in the end result. In recent years, with Agile and Scrum, these presentations tend to take place more often and you’re in the limelight presenting the latest and greatest. Many years of honing our skills as software developers have all but prepared us for this challenge, and we may end up getting a response from the attendees along the lines of this:
Too much uptight focus on technical details, digging deep into issues that nobody cares about, discussing the framework, library or platform chosen to solve a particular problem leaves you attendees bored, confused and sometimes feeling dumb since they haven’t got the faintest idea what you’re talking about. This leads to frustration, arguments, cold-fronts or just a general feeling of “meh”, where developers, stakeholders and users just don’t get the value out of this important meeting arena they could.
So what’s a developer to do? Here are some tips and thoughts for preparing for, presenting and participating in more technical presentations.