View From The Booth
I’ve created a new category of blog posts called “View From The Booth” where I will share my observations and thoughts that result from experiences working with students and new hires. Much like a coach watching football practice from the top of the stadium, I see quite a bit in my role at Nebraska Global and Don’t Panic Labs. What I will be sharing will run the gamut from mere observations to more direct “guidance” that I feel should be taken to heart. I will also point out some behaviors and patterns that should be avoided in order for one to be the most effective member possible on a software development team.
To start off this new category, I’d like to share three “anti-patterns” that should be avoided for the sake of yourself, your team, and your project.
“I can figure this out”
If you knew someone could help you figure out an API or some particularly tricky implementation, you would seek out their help, right? Me too. However, I often see folks hunker down and bury themselves in trying to figure something out without considering the possibility of reaching out for help. I am not sure why this is the case, but I can guess that it results from a high level of confidence in themselves (which is a good thing) or a concern over being seen as incapable (i.e., insecurity). Probably more concerning is that I also suspect that their lack of experience results in their inability to recognize that it is far less effective for them to spend four hours themselves on something when they could pair up with a colleague to work through the problem in an hour (see the math here?). Moral of the story: You are a far more effective and productive team member when you leverage the help and knowledge of your teammates.
“I will just fill in the blanks”
There are, and will always be, holes in the requirements. This is particularly true with agile methodologies, which rely on disciplined software developers to build software from user stories in lieu of exhaustive requirements documents. However, there is a major trap here that has to be avoided and I see this mistake with both junior and more experienced developers. When ambiguous requirements cause uncertainty as to how a feature is implemented, you should always seek out the opinion of your teammates and the product owners to validate your decision prior to moving on (call it a “pre”-code review). This is non-negotiable when the result affects the user experience. Failure to do so almost always results in re-work. Moral of the story: Ambiguity in the requirements does not mean that decisions you make are arbitrary.
“I would rather not speak up”
Our success is built on the strength of a highly collaborative environment where the best ideas win. If only one or two people are expressing opinions then I just don’t see how the best idea is going to be identified. I often feel like people are unwilling to speak out until they have completely thought through their position on a particular topic and I think that is a mistake. I firmly believe that the best idea will emerge out of the discourse and exchange that happens when people verbalize less-than-wholly-formed ideas and opinions. As long as everyone is keeping an open mind and not digging in their heels when someone else expresses a different opinion, any debate or conversation that happens can and should advance the team towards the best idea. Moral of the story: The best idea will not happen unless everyone on the team engages in the debate.
