In a technical coaching context, modeling effective communication is my primary tactic. I try to model asking more than telling, asking only one question, saying more with fewer words, keeping my camera on, and not apologizing when my dogs invade my camera (I instead introduce them). Teams also benefit from learning to explicitly integrate “play” time, doing small entertaining activities and games together.
Read MoreIf you have heard of XP, you probably think of Test-Driven Development and Pair Programming, two of the most challenging XP practices both in ideology and in execution. You may not know it, but even if you have never even attempted these two contentious practices, your software team is probably already doing several of the other practices. Here are the top three I suspect you are already doing.
Read MoreScrum is not your process, evidenced primarily by the fact that it is devoid of any business domain. Additionally, it contains timed events within which your team can execute and refine your process, but does not instruct you how to execute that process. For example, the Daily Scrum is a 15-minute time-boxed event with only a couple generic directives: The Development Team inspects progress toward the Sprint Goal, and makes a plan for the next 24 hours. Though it offers an example, the Scrum Guide does not say how you should conduct this daily event, only the constraints and objectives of the event focused on inspecting and adapting the team's work.
Read MoreI do have some anxiety about the largely differing nature of the two roles I'm attempting to fulfill and the risk of having both at the same time. The Scrum Guide says the Scrum Master can be on the Development Team if they are executing the work of the sprint, so I'm not playing outside the rules of the game. Nevertheless, a mentor of mine has suggested that being a Developer means you have a list of deliverables that are easy to check off one at a time, but being a Scrum Master is far less task-oriented and involves a people-oriented set of skills such as mentoring, coaching, facilitating, and educating. As a result, it's easy to focus on the Developer's deliverable list and forget to prioritize the Scrum Master's duties.
Read MoreNaming is one of the most difficult tasks of development. My last team debated names of things because communication is crucial, but it is a challenge. Naming a paradigm, pattern, principle, namespace, class, variable, or whatever is an attempt to communicate with another engineer about a broader set of related ideas using a condensed term. Computers don't care what you name things in your code; It all becomes binary once it's compiled anyway.
Read MoreI carried this new found love of unit testing with me to each new workplace. I taught the passion and associated skill set to whichever colleagues would listen. At my last workplace, I declared myself the _Unit Test Evangelist_ and taught my team everything I knew, and together we improved on the knowledge and skills I brought with me. We had great philosophical discussions on how to think of approaching legacy code with tests, and what kind of tests were the most important to write in various situations.
Read MoreI have incredible respect for the individuals on my last team, so I became actively excited when the opportunity arose to disagree. I knew my teammates would listen to and try to clarify my ideas, and I would afford them the same dignity. The result of such a debate rarely ended in us agreeing on my or anyone's idea as it was originally presented. The process of clarification and debate would polish each idea until one was clearly the best idea given what we presently knew.
Read MoreA manager who, perhaps even unbeknownst to themselves, doesn't truly desire feedback but wants to appear as if they support a culture of feedback will set up a Feedback Theater, whether intentionally or not.
Read MoreThe spirit of the phrase, "Fail faster" is simple: In order to find success, you need to get through the necessary failures quickly. Getting stuck on a failure, or giving up after a failure means you've stopped actively failing, which means you can't ever hope to succeed.
Read MoreOne of the reasons I'm so attracted to this philosophy is that it applies to far more than just software engineering. This principle has been championed by the greatest social activists in history, and ultimately is the way forward in times of risk or threat.
Read MoreFrom a software engineer's perspective, these careless deadlines strike a tone of mistrust of the sort that feels like you can't be trusted to get the work done in a timely manner unless a fire is lit under you by your superior. These deadlines alone can undermine relationships and create hostility among colleagues who are otherwise working towards the same goal.
Read MoreSince my MockBridgeConsole exposes me ways to observe method call counts, I simply write an assertion that I've called the PressGreenButton() method once.
Read MoreThat team was the most high-performing team I’ve ever been on… We saw many other benefits, but the bottom line for the business is that we built valuable software much faster.
Read MoreThe idea of GAF, while seemingly originating as a way to identify passionate people, somehow became weaponized against folks with a busy family life, or with other non-technical interests.
Read MoreThe value of knowing how to get started testing cannot be understated. Once you build a little momentum, each successive test is a little easier to write.
Read MoreKnowing that empirically we can, in fact, increase our intelligence is a crucial first step to self-improvement. If you see a direction to go and believe there is ground you can cover to get there, you can target your weak areas with practice and feedback and make progress.
Read MoreIn those fleeting moments where engineers sit together to solve a problem collectively, we build trust, share wisdom, and debate ideas until they are better than any one of us could have come up with on our own.
Read MoreWhen a band performs on stage, the product is the music and the user is the audience. Some of the best performances I've had were because of the energy of the audience as they consumed the “product” and the band was able to feed off that energy and take the performance in the right direction.
Read MoreAfter several years in the software industry, I came to believe that one can live values through their work just as much as through their personal life, and the congruence of each was necessary. A dishonest person at the office is a dishonest person at home, but the corollary is true as well.
Read More