Drupal

Some reflections on working with new-to-the-company Junior Developers

It all started the other day with a git pull from the development branch of one of our projects.


It all started the other day with a git pull from the development branch of one of our projects. I took a sip of my coffee, hit refresh on my browser, looked out the window at the sun over Portland's waterfront, and looked back at the screen.

Oh, crap.

Multiple large page header marquees I'd just finished building out were mostly broken, and page layout around them wasn't looking so great, either. My first thought was: did I have a merge conflict and somehow not notice?

A git log later and no unresolved conflict visible, I realized that I had pulled down some code from a coworker who is new to both Drupal and Metal Toad, and relatively new to front end dev in general. The 'oh, crap' feeling disappeared almost immediately, and I got excited about working with them towards a solution. Mind you, I was still a bit annoyed that the work I'd just felt great about wasn't complete anymore, but luckily Metal Toad's employees have a solid mindset about working with each other and I feel great about approaching coworkers with both questions and criticism.

Long story short, we worked out a solution to the Not-so-huge-after-all Marquee Fiasco of 2013. Afterward, and continuing into the next day, I kept thinking about it, analyzing my reactions/interaction and thinking about how I approached that situation, and I've come to some ideas/self critique.

Keep your cool.

Yep, your hours of hard work are suddenly hard to see because of what happened. Since version control is in place, you have the initial urge to just let them know that you're thinking about reverting their commit/s. Don't.

There is both a learning opportunity and a better coworker relationship to be had if you're willing and take time to work through a solution with them.

Put yourself in their shoes.

Remember that sweaty moment the first time you realized you had just borked the live production site? (We've all done it, at least to some extent. Don't pretend you haven't.)

Stop for a second before you talk to them and remember when you were at their experience level, or when you were suddenly on that first job and scrambling to both deliver on time and impress your team. Got that solidly in your head? Ok, now go talk to them.

Start by asking questions.

Once you've both sat down and taken an initial look at the problem, why not start by asking them to explain the goal? What were they trying to accomplish on the project? Does this match up with the current goals of the project? You might discover that their understanding of the current project goals/specification isn't complete. Great! Time to review the documentation and get everybody on the same page.

Step through the thought process.

Ask for a step-through of their thought process around the task. Ok, so once you understood the goal of the task, how did you approach it? How can we improve your approach? And, super important, what can I learn from your process?

Compare.

Step back & compare their thought process vs. the current state of things vs. that original goal.

Ask them to compare their thought process to the code they wrote, do they reflect each other? If not, did the implementation change due to perceived language/framework constraints? Are the constraints real, or caused by a knowledge gap? If there's a knowledge gap, you have a perfect opportunity to fill in some blanks in both of your understanding of the project's tools.

Head toward a solution.

I think that many people with a programmer mindset enjoy finding answers to complex questions, so why not take your understanding of their thought process and the comparison of their goal/implementation and ask the right questions? Try to lead with questions in the direction of a working solution.

Take a step away.

This is a hard one for me, and may not always be the right thing to do, but I've found that often it's best for everybody for you to put your headphones back on and step away. Let them implement the solution you've collaboratively created from the conversation you just had.

And again.

Ok, they've let you know that they fixed it all and you can pull the new code down. Great!
Keep your cool, and keep your head in that "in their shoes" mindset. Remember that the end game is learning for both of you. Take a deep breath & pull down the code.

Test.

Regression test, test, and test again. Did the implementation come out clean? We didn't break anything else in the process? Any reservations as to whether the solution is solid long-term?

Yes, things are back in working order? Time for a high five!

Finish up.

Take a minute and compare again, are we achieving the original goal? Is the current state reflecting that? Did the process follow our planning brainstorm? Are we aware of the exact changes that were made to produce the working solution?

Awesome. The codebase is back to a working state and we've both learned a few things along the way.

Part of my love for working in this field stems from the awesome mentors I've acquired along the way, and the industry as a whole's fascination with open source code and sharing advice and instruction. That being the macro, I think it's important to focus on the micro as well. The interactions I have with my fellow developers at work every day keep me motivated to learn more, dig deeper, and become more & more skilled in my field.

I think it's important as developers for us all to remember the lessons learned from our mentors, and if given the opportunity, give back to the folks who are just starting out. Speaking of starting out, Metal Toad is hiring Juniors right now, want to come work with us?

Similar posts

Get notified on new marketing insights

Be the first to know about new B2B SaaS Marketing insights to build or refine your marketing function with the tools and knowledge of today’s industry.