jr conlin's ink stained banana

It’s absolutely true that your work will never love you back. This is proven by the recent rash of tech layoffs alongside quarterly reports of increased revenue. For most employers, you are a resource, just like the coffee makers and copy machines. You just cost more and want to take weekends off for some reason.

That doesn’t necessarily reflect how your co-workers may feel, though.

For all the discussion of Big Tech, it’s actually composed of a number of fairly small factions. There are clusters of folk that tend to bump into each other at various jobs, which makes sense, because those jobs tend to look for the same sort of skills. If you write game code, you tend to work for gaming companies. If you write Java, you tend to work for B2B sorts of companies. i work on large data backends for websites, so i tend to bump into a lot of folk that i’ve met at other jobs. Colleagues float between companies because, frankly, that’s the only way to get a raise that’s actually above inflation rate.

What’s more, we all talk to each other. Probably a lot more than the companies we work for would prefer. There are whisper networks about how some companies are worse than others about certain things, and how some companies absolutely nail the right approaches to other things. No company is perfect. No industry is either. We all have our scars and habits grown from the weary battles and share stories at conferences and meetups.

i mean, tech folk aren’t special. We’re no different than any other professional group. Lawyers will talk with other lawyers about their craft, as will plumbers, pizza delivery folk, brain surgeons and rocket scientists.

This is one of the reasons that i can’t believe that the state of mentoring in our industry is so, damn, awful. Mentoring is a key way to foster a network of folk you can rely on. They’re the web of trust you have to check your assumptions, and are the first to reach out a hand when you need it. What’s more, for the same reason you don’t put all your servers in one colo or region, smart folk are ALWAYS looking to grow their network to include more people. Mentoring (and being mentored) is an absolutely fabulous way to do that.

The Lone Coder valiantly hacking away and building something from scratch is a myth made up by the same folk that thought having two people type on a keyboard was a good idea. Don’t believe it. Great Coders have a strong network of people they rely on.

A while ago, i had a discussion with a coworker about their boss. My coworker was venting a bit about a number of patterns that i recognized from my experience with various managers.

First off, let me say that i’m not a manager. i was a manager for a while and was terrible at it, so not being one to want to repeat mistakes, i haven’t pursued being one since. Being a good manager is incredibly difficult and requires a number of talents that are not included in WSJ Productive Resource Engagement books or whatever the current trend is.

What i do have a lot of experience in is managing my manager. Each manager has their own quirks, but there are certain types of managers that i’ve learned how to train and deal with.

Let me talk a bit about Process Managers.

Process Managers are folk that are in love with the process of management. These are folks smitten by things like JIRA, AGILE, SCRUM, and all the other things that either add or remove things from various checklists that they fetish over. These are people who “want to see progress” and expect their reports to have complete, analytical breakdowns of tasks done within minutes of being assigned. These folk do not do well with things like “discussion” or “revision”, since that requires them to alter the carefully crafted charts and diagrams that they spent all week putting together to impress their own manager.

Some folk might feel that these sorts of managers like to micro-manage, and a number do, but mostly, they’re looking for the dopamine hit of “number goes up” (or down, but basically not “stayed the same” so that they can show “the process works!”).

As a software engineer, we know full well that Life Does Not Work That Way. Asking how long a given task might take is like asking “how long will it take to carve this statue?” You have a rough idea, and can show progress, but as an artist, you have no idea what’s actually in the stone and if you it something unexpected, you have to deal with that. Sometimes you need to alter the design a bit. Sometimes you have to start over. It’s the nature of the art, and that is completely incomprehensible to the Process Manager.

So, how do you manage a Process Manager? You feed them the dopamine they’re looking for. Give them short updates where you specify the work that’s been done and the very short scale work that lies ahead. Give them little things that they can check off of a list. If you need to alter a design or the scale of something changed, give them a new checklist of things to tick off. Track Everything via the ticketing system of choice (Jira, bugzilla, Postit notes on the cube wall, whatever). They’ll grouse, but you gave them delicious mental candy, so they won’t stay mad for long.

Play the game they want to play and they stay happy.

On the other side, realize that they are not invested in your growth and career unless it maps to some form of progress they can chart. So, if you want to go to a conference or learn about something, you need to absolutely qualify it with all the bells and whistles they want to see. Put together an Impact Assessment that highlights what percentage points of improvement you expect to deliver or whatever.

(bit of a side note: Process managers tend to think of reports as ‘resources’. You know, like the copy machine or coffee maker. Mind you, when the coffee maker has a bad day, i replace it, because coffee makers very seldomly self correct. A coffee machine doesn’t perform poorly because it’s kid was up until 3 AM, or because a parent just got a cancer diagnosis. People do, and they’re not going to tell their manager or coworker about that for lots of reasons. People have off days and weeks, and a good manager knows and works with that. The coffee machine also doesn’t angle to get the copy machine’s job, but that’s a different matter.)

i kinda spelled all that out for my co-worker, with the added point that “all of this is temporary”, none of it is actually personal, particularly since the senior engineer on the project has zero complaints, and frankly the stuff the Process Manager is complaining about is stuff like “too much discussion in PRs”. Uhm, you want discussion in PRs. That’s documentation. It also means that folk aren’t just rubber-stamping future bugs into the code. i’d rather there be good conversation in a PR than a bunch of issues being re-opened.

i also gave a bunch of other tips for how to deal with a Process Manager, and maybe i’ll write those up sometime.

A key aspect of a good engineer’s life is dealing with non-technical issues like these. A key aspect of a senior engineer’s life is giving junior folk the insights needed to become a good engineer. Dealing with iffy managers definitely falls into that category.

Maybe it’s the end of the year and hearing one too many bad versions of “Auld Lang Syne”. Maybe it’s the fact that i’m on day 6 of COVID. But for some reason i was thinking about Mr. Scott on the Enterprise from Star Trek.

i started thinking about what a massively complex system a 400 person capable interstellar space ship, complete with armaments and transportation systems, fueled by carefully exploding matter and antimatter, which produces pure energy at an unfathomable scale must be. And yet, you’ve got basically one guy who somehow knows and can repair all of it.

i mean to micro-geek me sitting on my bed trying to hold the UHF antenna just right on the black and white so i can watch reruns after-school, sure. And for a bunch of writers on a fairly low-budget TV show focused on telling stories about societal ills dressed up as “Wagon-train in the Stars”, you bet! But for grown up me who’d be about the right age myself? Oh, hell no.

One of the hallmarks of being a Senior Engineer anywhere is having a firm and complete understanding of what you do not know. It should spread out before you like the vast, endless plain that it is. You might recognize features like distant mountains or far off towers, but that’s probably about it. You should also know who to ask or rely on to navigate those particular bits when you need to, and also recognize that unless you’re working with that stuff frequently, you’re not going to instantly become a domain expert.

So, yeah, having one guy who basically is responsible for keeping a multi trillion dollar machine flight and fight ready at all times, as well as will be on call to unplug the Command Head after the replicators finish Taco Tuesday? Yeah, nope.

For work, i do what’s become called “DevOps”. My company defines that as building scale-ready back end services that can be deployed and maintained for extended periods. This differs from our SRE (Systems Reliability Engineers) who’s job it is to make sure that the systems we built are deployed and operational. i’ve sometimes said that they’re the “Check Engine” lights of our org. They’re critical players that monitor and understand our running systems and how they relate far better than anyone else. i could not do their jobs and i’m always exceptionally nice to them. For anything that’s truly broken, their job is to file a ticket or call me and make it my problem to fix.

Same with our Test Engineering folk. Their job is to make sure that the things we build and operate run consistently, validly, and efficiently. They are our highly skilled, trained chaos monkeys who actually help fill out reports. They look to make sure that we’re not just doing “happy path” testing, but introduce appropriate noise and hostile behaviors that we miss because we just want this crap to work (dag-nabbit).

Each group knows their skills and shortcoming. Each group happily works with the others to get a fantastic final result. i would no more dismiss these groups as “useless” than i would dismiss a surgeon because “My G.P. knows how to medicine. How hard could it be?”

i suppose this also gets into the whole myth of the 10x engineer, (Note: a 10x engineer is someone who does a job that is only .1% defined.) but that’s a different discussion.

All i can think is that if Mr. Scott has to do some sort of repair or fix on something, someone else is dead or incapacitated and that a third person may be needed to spend a day or two repairing the “fix”. i mean, yeah, i can deploy a system on a set of servers that could run for some period, and have in the past, but i’m not dumb enough to think that it could handle several times the population of the United States without me personally funding the next trip Jeff takes to the stratosphere. i’m sure that there are whole catalogs of “Scotty Fixes” pictures at Star Bases around the Federation showcasing plasma conduits wrapped in chicken wire and silicon tape.

Mr. Scott was my favorite character on Star Trek for a slew of good reasons, but the further i get in my career, the more i appreciate the unseen folk who made it their jobs to make sure that Mr. Scott barely knew the systems they worked on.

i should probably spend a few minutes outlining what i think mentoring is.

Mentoring is the long term sharing knowledge and experience with the goal of making life easier for the recipient.

If you’re only doing it once, you’re not mentoring. That’s a lecture.
If you’re not invested in the improvements of the folks you’re helping, you’re not mentoring. You’re preaching.
If you’re just pointing out flaws or trying to make someone change, that’s not mentoring. That’s coaching.

Mentoring is work. Being mentored is also work. For what it’s worth, i consider mentoring to be a bit holistic. If someone is struggling, it’s important to recognize why they might be struggling. Perhaps it’s a language or context issue (not everyone has the same background or experiences, so it might require doing some research to find the right way to express an idea so that it’s understood). Perhaps it’s a non-technical issue (perhaps they’re stressed about a personal issue. These can be tricky, and you should never delve into those uninvited, but letting someone know what you can do to help can be a huge relief).

When i mentor someone my goal is to make their life better. i teach technical approaches because i’m an engineer, but i also advise things about career growth, office politics, and other hard lessons i suffered through. The last thing i want is for anyone i’m mentoring to hit the same walls and fall into the same traps as i did. Likewise, i’m actually interested in their experiences and thoughts. Everyone has a different background and expertise. i want to learn about it because it’s different and there might be valuable things i can learn.

Honestly, if i’m not learning as much as i’m teaching, there’s a problem.

So, how does one set up a mentoring relationship?

A colleague pointed out that a good relationship starts with a mutual objective. So, a senior engineer would want to mentor a junior one if they’re both working on a given project. This makes good sense, purely from a practical point of view. The faster you can turn someone into a peer, the less work you have on your plate. Likewise, you now have someone you’re comfortable reviewing your code so you can work faster. If you’re afraid that someone is “going to steal your job”, you’re thinking too small. Instead, you’re building your own tiny army of folk that will support each other.

That’s actually a really important side benefit to good mentorship, the trust relationship you establish via mentorship can easily outlast your immediate employment. One of you might get a better job, or get laid off, or any number of other things. Maintaining that relationship means that you will have a personal network that will be looking out for each other, and possibly lining up folks for good jobs (and future hiring bonuses). Likewise, you’ll have third party folk that can give you honest answer to “Hey, so i’ve been asked to XYZ, and i’m not sure it’s a good idea.” It’s a lot easier to be ethical if you’re not as worried about having food and shelter.

It’s also worth noting that having a good mentor can sometimes help correct bad management. A manager may be temporary and a mentor may well outlive a managers role. To that end, a mentor may be able to guide an employee in ways that a manager never would. A mentor may point out other, better opportunities, which might mean that the mentee leaves their current team. A mentor may pass along crucial information that a manager may not feel is important, or may be damaging to the manager’s ego.

A good mentoring relationship may continue for quite some time, spanning teams, divisions, or even companies. Honestly, one of the most damaging things i’ve seen in tech is treating other company employees as “The Enemy”. Sorry, no, they’re not. You may be competing against them, and there may be good reasons to be guarded about speaking with them about your work, but in a week, you might be working with them or they with you. In sports a player may be traded from one team to the next. That never diminishes the athletic prowess of a given player, just what clothes he has to regularly wear.

Your employer will never love you back. However, you can still build lasting networks among the people you worked with. Mentoring can be part of that. Ideally, every one i mentor eventually grows into becoming a mentor themselves.

And that’s part of my Evil Plan on how to make the tech industry better.

Tech people: Mentoring sucks, it’s sucked for a while, and will probably continue to suck.

First off, let me start with a little story.

i generally start my day early. Back when offices were a thing, i’d often show up early enough that the folk who keep things running would still be there. One morning i’m working away while someone was on a ladder repairing an air-conditioning duct. He’s up there a while, comes down, and walks away. A few minutes later, he comes back with someone who is definitely his senior. Senior goes up the ladder checks a few things and comes down. Senior tells Junior that he did a good job, but there was one tricky thing that he missed, then explained what it was. Junior starts peppering Senior with all sorts of questions like “how do you check for that?” and “is there a tool or technique i can use to spot for that in the future?”. The back and forth go on for a while, before Junior and Senior collect the tools and head off.

Why, yes, that should sound familiar. Basically it was the HVAC equivalent of a code review. It wasn’t judgemental. Nobody yelled or complained. It was clear, focused and deliberate because it was something that industry has built in for decades. Heck, you could argue that it’s something that the other trade industries have had for centuries. It’s also something that Tech just recently figured out was a good idea, and we are still generally terrible at it.

In my professional life of close to 35 years i think i’ve only really had one real mentor. Everywhere else i went through the usual horrible interview process, balanced a binary tree moving at some fraction of the speed of light on a whiteboard, got hired, and was then left to either sink or swim. That’s an absolutely terrible work environment. It’s like being proud of the fact that you work in squalor and know just how to sleep so the rats don’t bite anything critical. i’ve not had a whole lot of great mentoring role models to pick from. Chances are, neither have you.

Granted, i have a theory about that. Companies don’t care. Think about how many engineering managers you know that got to that position because they’d either been around longer than most or because the company was hoping that they would some how magically make mini versions of themselves. Then, either the new manager burns out and leaves, or the people under them burn out and leave. The company doesn’t care because they’ll just repeat the cycle and back-fill with (preferably) cheaper folk. (i also have a theory that companies love Imposter Syndrome because it’s a lovely boat anchor that makes you put up with crap you wouldn’t otherwise, but i’ll leave that for another screed.)

And we engineers put up with it because we have no idea how to change it or that things could be better. Surprise! You can change it. Things could be better.

Your boss doesn’t have to be your mentor. Honestly, your boss probably shouldn’t be your mentor. They sign your paycheck and are judged on your performance. They have a bias and it’s probably not in your favor.

A good mentor not only provides good technical insight, but also improves you, the holistic you. Hell, it’s why i’m writing this up. If you’re a better person, i don’t have to clean up the damage you did to the person i hire which lets me spend more time on things that matter, like making that new hire more effective and productive so that we can get more done. Likewise, i can start learning new things from that person since mentoring is a two way thing.

Awesome! So what’s the solution? Hell if i know.

i just told you that i’m a product of terrible or non-existent mentoring. i have spent the past year or so trying to work out what might work. i plan on sharing what works and what doesn’t here because this is also my mental dumping ground.

i will say that not everyone is cut out to be a mentor, but that just means that you’re missing a required skill. Senior+ devs need to be mentoring younger devs. This means having regular discussions with them where your compassionate and empathetic. You were also dumb and ignorant, so it’s not their fault. If you struggled with something, it’s not a badge of honor, it’s a system failure. Fix it. Part of your job is making junior devs into peers. If you’re not doing that, you’re a crap engineer. You’re basically a glorified calculator and can be replaced just as easily.

But, yeah, if y’all have ideas, the comments are open.