There’s a thin tightrope you walk every time you work on a software project that has two or more people involved. If you’re on a team of more than a handful of developers, you know that being able to clearly communicate your ideas and understand other teammate’s ideas is really important to the success of your project. You started your project, and it may have been just you and one other person. As the project grows in importance, and gains more visibility in the company, more developers might get added to it. Soon you find your calendar starts to fill up with meeting requests, most of your working hours disappearing into the dark void of conference rooms. The urge to just slap your headphones on and crank out some code might start looming large in your head.
But this is a modern software project you’re working on, right? You’re not writing code in your basement just for you; you’re writing it for a real business. It’s the real deal now man. This isn’t code that just you will have to deal with, this is code that will impact every other person that you work with every day. It’s not just about you anymore dude.
So where is the balance? I’ve been thinking about this a lot lately. A talented software developer is someone who can craft beautiful code, and also communicate effectively. We work in integrated environments that demand this of us. We know that spending all day in meetings is toxic to our creativity, but on the other end of the spectrum, we know that coding in a walled off garden on any team project only leads to problems. How much of a software project is spent in communication and collaboration, and how much is spent flying solo? What proportion of each will yield the best results, and make for the happiest developers? Where does creativity blossom in this continuum?
There’s one emotion that reaches into both of these platitudes.
fear
As a developer, when you get the fear, you might do one of two things:
fear and meetings
Fear breeds meetings. When we don’t know how to execute or where to proceed next, how might we handle it? We might hold a meeting. It’s crippling to not know what’s next on the path you’re on. When we’re dealing with uncertainty and a dimly lit plan (often symptoms found in software projects), some people find reassurance in other teammates. We don’t like to not know what’s going on, and so holding a meeting can feel like the right course of action. But meetings are almost always the most unproductive way to resolve the fear. Do you really want to break up your entire teams workflow because you need reassurance about a new feature? Incidentally, this is usually the lever a manager who’s not tuned in to the problems and needs of their team will reach for. These don’t even have to be formalized meetings that live on your calendar, they might be ad-hoc desk fly-bys and frequent interruptive check-ins. When there’s uncertainty and ambiguity in the project, it’s really easy to find yourself stuck in too many meetings.
fear and flying solo
To other developers, fear breeds hiding. If you’re stuck on a tough problem, sometimes it’s easy to wall yourself off. I’ve done this one many times: too embarrassed to speak up and admit that I need help, I might waste half a day spinning my wheels on a problem that could have been solved in two minutes if I had humbled myself and been willing to ask a teammate for help. It’s that little voice in the back of my head saying, “They’ll laugh at you if you admit you don’t know the answer.” This is not a good mindset to be writing code in. You’re already stuck in a strange state of doubt, and your code is going to reflect these insecurities. Don’t hide from the fear.
finding the balance
I realized that for my growth as a developer, it’s important to understand what fear-coping behavior I fall back on when I’m face with it. Do I tend to fly solo or do I try to drag other people into my problems with destructive ad-hoc communication? I’m someone who leans closer to seeking others, sometimes at a disadvantage to my teammates and to my growth. How does leaning on others too much affect my problem solving skills for future endeavors? On the flip side, how does trying to figure everything out on my own lead to patterns and code that is destructive to the productivity of the rest of my team?
In the end, it’s all about shipping good software. It’s a team effort, so finding that balance always depends on who you’re working with. There is no silver bullet here. The important thing is to always be asking yourself these questions. When faced with the insurmountable problem, and fear starts creeping in, how is your team best adapted to deal with it (and can you find a way to keep doing it better?).