Engineer Career Traps

When I mentor other engineers, soft skills are the trickiest. Hard skills such as performance or security are most sought after, while situations requiring soft skills are overlooked.

Here are situations that are avoided, but should not be!

Fighting Battles that matter

As a software engineer, there are moments that define your career. Maybe the codebase reeks. Maybe the team is overworked. Maybe there are security gaps. Someone says, “It’s fine”. Everyone, except you, nods because it is easier.

It is akward. You might make enemies if you speak up. Would anyone even care? What if you get rebuked? Would you be able to to turn away the ship, or is it already sinking?

First, know that not every hill is worth dying on. Some battles are distractions, and some problems are immovable. Learn to pick your fights. If the issue won’t matter in six months or if you know the culture won’t change, let it go. Focus on what you can influence, and save your energy for battles that matter. Knowing when to speak is just as important as speaking at all.

Experience and expert knowledge let you know which battle is worth fighting for.

In a project, I approved an implementation that was mediocre. It fulfilled product requirements but I knew it would double or triple the mean response time of the endpoint for large datasets. But the product team pushed for release. I hesitated and let it go. Three months later, we had major performance issues that impacted the whole team. This means overtime, frustration, finger-pointing and more.

Approving mediocrity wins in the short term, but you lose in the long term!

One hill that is not worth dying on for me is code styling. Who cares if you used collect instead of map? I’ve never seen a project fail because of code styling or rubocop issues. Other team members will tell you it is not elegant, and spent hours and hours working on a new rubocop rule. I am sure you can think of other examples of issues that are not worth fighting for.

Once you know there is a real issue, ask questions.

Is there really a problem?

Is it temporary or permanent?

Who approves?

Do the higher ups encourage or discourage this?

Those important questions will make the situation clearer and perhaps lead you to solutions.

Now it is time to speak up.

Here, being convinced of your cause if half the battle. “Maybes”, sighs, hushed voices will not lead anywhere. So remember that if you hesitate, mediocrity wins. Speak with your head high and voice heard. Be ready to come with clear, documented examples if there are disagreements.

If you must, leave, but don’t leave quietly. If the toxic culture won’t change, at least you will.

Build a Tribe

It is important to be present and committed to your team.

However your manager is not your lifeline. Coworkers come and go. You are your own map and compass. Conferences, meetups, open source projects – those are your trade routes. Travel them. Learn from strangers. Show your work. Write a blog. Contribute to a public repo. Shake hands at a meetup. The network you build outside the office will let you go further, faster and sometimes will be your escape hatch.

When your coworkers are stuck, you will think of a novel architecture seen at a conference. When the company needs to hire more engineers, you already have a list of programmers you met at local meetups.

Lead Without Permission

Tech and non-tech companies make a clear difference between juniors, seniors, leads, managers and executives. Each level comes with defined lists of responsabilities and tasks. Staff Engineers own architecture design. Managers solve tricky deadlines. Junior do not deploy on production etc.

I will go against the grain but I believe true software engineers do not need a title to lead.

See the gap? Fill it. Spot the problem? Solve it. See a junior dev struggling? Help them. Leadership isn’t bestowed — it’s claimed. Act as if every day was a new day and an opportunity to make things happen. So make things happen. If a test suite is broken, fix it. If there’s a new security fix, update dependencies. The team’s office is dirty? Clean it. Your team can’t make the friday deadline? Why not pick up a ticket or two.

A bold adventurer and crasftman

Programming is not for the passive. It’s for the bold. The curious. The ones who treat their career like an adventure. A lot of programmers think of themselves as introverts, quiet, passive. That’s a lie. You’re not a statue. You’re a bold adventurer and craftsman. Speak, lead, move.

Because if you don’t fend for yourself, who will? Silence is safe, but silence doesn’t win wars, and it doesn’t write the future.

Comments: