Let’s Think Differently About Collaboration
This blog post grew out of a presentation I made to Vena’s Product and Development team, during our Professional Development(PD) Days, in March 2022.
I have often struggled to think of things to present at PD Days or Lunch N’ Learns, partially due to my own Imposter Syndrome. Yes, I had been a professional developer for almost 20 years before transitioning to Development Manager. Yes, I know I have a lot of professional experience to share, and advice to give – but I felt more comfortable in a more private setting, given a particular person, problem, and situation. Who was I to say that the way I did something was “better” than the way you did it?
As I reflected over the past few years especially, I’d been asked many times, in many ways, “How can I become a better programmer?” or something approximating that. More specifically, how can I build myself up to the next level of expertise?
Everyone’s path is different, and everyone needs something different, but this desire to better oneself is something most of us share.
It got me thinking about how I work, and how it might differ from other people. Whether the perception of how I work (or other more-senior developers) might not be entirely representative of our truth.
As my responsibilities grew, the amount of heads-down-focus-time I had to code naturally decreased. So how was it that I was able to continue to deliver complicated, sometimes quite large, change sets in a responsible amount of time? While it’s true that expertise and some level of programming mastery certainly plays a part, I think working more efficiently is also a major factor.
Through some conversations with others, I began to understand that many people don’t realize how often very talented programmers, with high levels of expertise, actually collaborate with others!
What seemed obvious to me is apparently not so obvious.
I think there is a fairly common misconception that we are just so good, that we go off on our own, hide away in our caves, and come out with an awesome solution.
Let’s discuss…
Vena Developer Culture
A big part of our Developer Culture at Vena involves collaboration and psychological safety.
We ask you to not be afraid to ask for help.
But it’s not enough to simply say this is a big part of our culture – we have to prove it to you.
You have to put yourself out there, make yourself vulnerable – and then it’s everyone else’s job to prove that culture to you. Prove it’s not scary; that you’re not going to be made to feel dumb, that you shouldn’t have asked the question, or that you should have known something you didn’t. By making this kind of collaboration as painless as possible, we help build up that ‘ask’ muscle, making you more confident to ask in the future.
We’ve gotten quite good at asking very specific help-questions, like:
- I don’t understand what this code is doing…
- I can’t get this thing to work quite right…
- I’m having trouble writing this unit test…
- I keep getting this error…
- etc…
I think we do a great job asking and answering questions at Vena – it’s great to see how eager and willing our teammates are to jump on a quick Zoom call to help resolve an issue. We hear it time and again from our (especially new) developers – the overwhelming willingness of team members to help each other out. It’s great to hear, and very heartening.
But I think if we extend this mindset a little bit, we’d see some pretty great results.
Typical Workflow
Let’s consider the different stages of work a developer typically goes through when solving a programming problem.
The specific help-question-asking I referred to earlier usually takes place in Stage 4. It often goes something like,
“As part of my plan (I’ve got my plan, and it’s fine), I’m struggling with this one little thing…”.
Someone jumps on a call, or slides their chair over (in the before-times) and we figure out how to get you unblocked.
Most of the real collaboration tends to start after Stage 4, in the code-review process; once you’ve finished coding your solution. In essence, we say, “Hey, now that I’m done and it works, can you finally look over my whole solution and tell me what you think?”.
Several senior developers have said to me, in different ways, something amounting to, “Nothing is worse as a reviewer than starting a review and realizing there are major problems that will require rewriting a lot of code.”
This brings about the feel-bads all around. We empathize with the code-author, and we may have to start thinking about deadlines and dependencies. We’ve all been there, and it doesn’t feel good.
Um…Help…Differently?
It’s interesting to consider how changing our mindset around collaboration, and introducing it earlier in the process, might be helpful.
Most of us are really quite good at asking for help when we don’t understand something, or are stuck, but seem to be not as good at asking for help to confirm our plans and verify our assumptions.
Perhaps it’s a terminology thing? Maybe “help” and “stuck” are not the words we should be using in these cases? Possibly they have a more-negative connotation than is comfortable for some people.
What about the term consult?
It’s a term used a lot in the medical profession – you’ve probably seen on a TV show or movie, where one doctor asks another, “Hey, can I get a consult for my patient?”
Obviously, the healthcare industry is usually going to be a more-extreme example, when it’s someone’s life on the line. It will matter a lot more than (most?) Jira tickets.
But they do it. They ask for consults.
Very talented and smart professionals, asking for the advice of their peers before starting down a path. I’m not suggesting it’s always required – we shouldn’t be syncing up with teammates at each of the stages – that would obviously bog everything down.
But the earlier you discover you’re on the wrong path, the better for everyone.
Getting it wrong
Let’s look at the different stages again, and the implications of “getting it wrong” at each stage.
Once I have a plan, a quick chat to say, “I am thinking of doing it this way, what do you think?”
Maybe there are parts of my solution that already exist somewhere, or I should be solving something in a different way. This is the best place to get a consult in my opinion – once you have a plan, but before you start coding it.
Value of a Consult
So, let’s explore the value of asking for a consult before you start coding.
Higher self confidence in your solution. Having someone else confirm or help adjust your plan goes a long way towards improving your confidence and overall attitude while programming the solution.
Better organization of your thoughts. If you know you are likely going to ask for a consult, you’ll plan in a way that’s easier to understand and present to others. And in reviewing your own plan, you’ll often catch problems yourself.
Knowledge sharing. This is something we’re always striving for more of! More people on your team knowing about a thing is always better. And when someone on your team is familiar with your solution, not only is it easier to get help if you get stuck, but then can also more easily take over for you if you were to get pulled away or get sick.
And finally,
Faster delivery of better code. Your ticket will hopefully spend less time in code review, and will get done faster. When someone is already familiar with your solution and its logic, they will also probably make a good primary reviewer.
I think this last point can’t be overstated. If we can minimize the frequency of “big rewrites” needed at the code review stage of development, I think we’ll see the biggest impact of earlier consultation.
Think back…
I’m sure we can all think of times when we’ve spent several days working on a solution, pushing through some challenges, and finally producing code that works, is tested, and we are proud of. We feel pretty good about the potentially-very-large pull request we submitted for review. And then we open the review and see a lot of feedback, including some very valid reasons why some very fundamental changes are required.
As it dawns on us how much more work is now required for the ticket, we can’t help but feel dejected. We might start thinking in terms of negotiating what changes have to be made and what maybe could be put off until later. We start looking at the dependencies on our code getting merged (deadlines, other tickets, cross team work, etc), and make some cost/value decisions. It doesn’t feel good, and it’s easy to get demotivated.
Okay, but when should I ask?
How do you know when to ask for a consult on your plan? Certainly not every solution needs one, but it’s probably better to err on the side of asking if you’re not sure or can’t decide. In my experience, as the time I could dedicate to coding decreased, it became more important to ensure I was spending my time coding the correct solution. Almost anything non-trivial I would run by someone once I had a plan.
As a general rule of thumb, I like to consider:
- How algorithmically complex (or big) is my proposed solution?
- How disappointed will I be if a major rewrite is requested for it?
- Will I still be able to get the work done in a reasonable amount of time if
I do need to make fundamental changes? - How dependent are other people (or deadlines) on this code getting merged?
What do my consultations look like?
They don’t have to take very much time. Often a 5-10 minute face-to-face sync up, giving a quick walkthrough of my plan, is sufficient.
They also don’t have to be with an expert. It’s always nice if you can get a few minutes with someone who knows the code really well, but it’s not necessary. Just collaborating with someone else, having a second set of eyes on the plan, is incredibly helpful. It’s amazing what two non-expert brains can solve together!
I also recommend including the options you considered in arriving at your planned solution.
These were my options, and I’ve chosen this one for these reasons.
It helps get everyone on the same page, and putting all options on the table helps your consultant understand your reasons for making the decisions you did. They might even have a very good reason to suggest doing it one of the ways you had decided against.
I was thinking the same thing you had thought initially, but now I can see why you chose the way you did.
Or
No, I still think your first thought is better because X,Y, Z…
Everyone’s doing it…
It’s important to remember that this is a very common practice that even (especially!) very-senior developers do all the time. It’s nothing to be ashamed of, and is not just for junior developers or new-hires. Talk to your own Technical Leads, Staff Developers, Architects – I’m sure they’ll have some insights into how and when they do something similar.
Will this solve all my problems?
Is this a magic elixir that will get all your pull requests spotless reviews?
Of course not.
It’s not going to catch all of your bugs or solve all of your problems – and you’re still going to have some big rewrites from time to time too! But they will help catch some troubles early, and hopefully prevent some big rewrites.
And even if it doesn’t catch a problem, think about it as a psychological safety net. You can feel proud knowing that you didn’t just haphazardly start programming your solution. You did your due diligence to ensure your solution was sound. And someone else thought your approach was good!
Psychological safety of the team
From my perspective, the psychological safety of my team is a huge part of this, in addition to overall efficiency.
I feel very passionate about this.
Your state of mind during the time you are doing your work is more important to me than the speed and quality of the work you are completing right now.
To be very clear, it’s not the only thing that’s important to me.
Obviously, it’s very important to me that we meet deadlines, delivering good code in a timely manner. But if we’re meeting deadlines and the team is constantly feeling anxious, confused, or demotivated, that’s not a good work environment, and it’s not good for long term success or wellness.
At the end of the day, I would rather take things a little bit slower in the planning stages, to have higher confidence and more wellness overall. Slow is something we can improve on or deal with; your feelings about your work is a bigger deal. If your partner (or your pet!) asks how your day went and you say it was terrible, that’s something that has a much bigger long term impact on everyone than what time or day your code got merged.
Making the transition…
These are some of the things I’ve heard people say about collaboration, even after successfully completing their work:
It’s easy to read these things now, and think that people shouldn’t feel this way – but we all still do.
It is kind of silly when you really reflect on it though: can you actually recall a time when you felt this way about someone else after they asked for help or completed their work after collaborating with others?
For all those reasons (and probably more) I listed above as the Values of a Consult, working together is not wasting anyone’s time.
What am I signing on for?
No one should think that when you volunteer for (or are assigned) a work item, that it is a promise to go off on your own, put your head down, and emerge victorious with a solution.
That’s not what you’re saying.
You’re saying you will get the work done – no promise of solitude implied!
Work life is not an exam; it’s all a team effort (or it should be).
Everything we do is a team effort – we succeed together, and battle through our setbacks together.
As the O in Vena’s CORE Values says, we are ONE TEAM.
So…Let’s do it!
Getting a consult on your draft/idea is always helpful. The sanity check may not even give much feedback, it may just confirm what you already thought.
At the end of the day, you are reducing the overall risk we are taking as a team, and could be saving everyone a lot of time.
So, that’s my story, and this is my ask – consider the idea of a “consult” before you start coding your solution.
I would love it if the term “consult” became a part of our Developer Vocabulary (and yours!), and we all normalized the process of doing so, earlier in development.
Even if it doesn’t sweep through your engineering department like wild-fire, hopefully it might help a few people with their own process, helping them produce better code, faster.
