Incoming Perspectives

Get context on prior decisions before offering new solutions.
Friday, July 29, 2016

I am just starting the first proper job search I have conducted in a decade, and I’ll most likely end up joining an established team with an established product. And that brings with it an established code base, with established cruft, mistakes, poor decisions, etc. I know, because I’ve written that cruft and made those mistakes and poor decisions.

People have joined teams I have been on for years prior to their start, and you know what inevitably happens? They come in and shit on your prior work. They don’t to it with malice (probably), but they do it, and it can hurt. Because I’ve had that experience, being on the receiving side of the insults and accusations, I plan to be particularly aware of whether I fall into the same trap. I plan to be mindful of my attitude and tone as I discover code, architecture, database designs that are, in my view, wrong. And when I do come upon those, I hope I will remember to pause, ask questions to gain context, and offer constructive suggestions for change.

Probably the most egregious example I can recall involved an ornery operations guy. He joined and immediately declared our logging system a pile of shit, claiming that the log4j format was inscrutable and it all needed to be replaced. As it turns out, the format was inscrutable because he hadn’t taken any time to look at it, learn it, and make sense of it. It just wasn’t familiar to him, so he called it crap. It is particularly hard to work with someone who brings that attitude to a job, and I never worked well with him.

Another more sane interaction started with a question I received from a new product manager while I was tending bar at one of our happy hours (yes, a couple times a year, a colleague and I would make cocktails for the office, mostly so that we could get to know the new people joining during the fastest growth of the company). This PM was hired to work on a brand new mobile app, and as I handed her a cocktail and introduced myself, she asked me, “Why didn’t you build services from the start?” First, let’s think about her perspective: she is going to be responsible for a mobile app that integrates with the data and features we have built into our web app, which is a monolith. Services would be incredibly helpful to her team so they can just make the API calls they need and ship product fast. I get that. She wants services. At this point in the company’s trajectory, so do I. But let’s look at my perspective: four years prior, when I first started building the application, we weren’t even building a web app – just a big batch processing system – and we were focused on building what we needed to solve client needs. Designing services before we knew what we were building, and handling the complexity of running those services, would have prevented us from getting the company off the ground. While she was not rude or insulting, she hadn’t considered that at all in her question. I explained it to her, and we carried on enjoying cocktails.

So, my lesson is to take these experiences and remember them when I join a new team and my gut reaction is to hurl insults either at technology or at people. Nope – pause, get context, offer constructive suggestions, and help make the changes needed for success.