Photo from unsplash
Thriving as a Multi-Project Engineer
June 3, 2019
One of my favorite aspects of my job is the variety. I get to work on a WordPress site on one day, then a React component the next.
One of the most challenging aspects of my job is the variety. My projects do different things and work in different ways.
Managing all those different projects in different languages and frameworks is challenging, particularly because my background includes very little formal software training. (Experience goes a long way.)
How do I thrive in my job? Here are some tips:
There is no such thing as self-documenting code.
Well-written code is clear about how it does what it does, but when you come back a year later, that’s not always the important part. Many, many times I’ve looked at code that’s barely a month old and asked myself another question: “Why did I do it this way?”
So when you write code, make it clear. Clever programming tricks are difficult to follow down the line. Even if it takes a few extra lines of code to accomplish, limit your trickiness. Compilers and optimizers are better than they’ve ever been.
Use descriptive (but not crazy) variable names.
And, most of all, when it’s taken a few tries to make something work, leave yourself a comment as to why you did it that way. Version control is great for looking through the history of a file, but it takes time. It’s even better to have those decisions right there.
Don’t keep it in your head.
As a tech lead, I tell my team, “It’s not official till it’s Jira official.” When there’s a decision made or a question asked about something not related to the code, have the discussion in person or on your chat app, but record the decision and reasoning in your ticketing system. Then, since your commit messages are linked to the tickets (they are, right?), you can understand the why better.
Keep a single source of truth.
And I mean this both for people and for code.
The decisions and the explanations that I was just talking about should exist in exactly one place, and that place should be easily discoverable. Code explanations go into the code, product explanations go into the ticket, and process explanations go into your well-groomed wiki.
In your code, magic numbers are A Bad Thing. Keep them as constants that you can refer to down the line so when you need to change something, you don’t have to hunt down all of the uses of that number.
Know the basics.
Learn some of the core concepts of each language you work in. PHP is stateless: every single request starts from scratch and rebuilds the whole stack. Node is not: you can initialize slow things when you boot the server, and then have small tasks for each request. Client-side JavaScript — well, the details of your project define many of its basics.
When you approach a task, figure out the broad strokes of how to do it in whatever language you need to do it in. Once you have the broad strokes down, start coding. And remember…
Your search engine is your friend.
No two languages have the same syntax. Even more so, sometimes the same language is inconsistent. Don’t be afraid to pull up the docs as a reminder, or see how StackOverflow users solved a problem. But…
StackOverflow is not a code library.
A good engineer sees what people on StackOverflow have done to solve a problem. A great engineer understands each line of that code. Especially with older languages like JavaScript and PHP, answers can easily get outdated and hard to maintain. And, well, if you had to check StackOverflow for a solution, you’ll probably need to document the why.
Reach out.
Nobody knows everything, and everybody knows something. If there’s something you just can’t get your head around, ask a colleague. The time they spend helping you is going to be less than the time you’d spend spinning your wheels, and to a team, that’s a net win.
Understand the code you review.
Peer reviews take time, but done right they can help you keep your code maintainable. So take the time to do them right. Make sure you understand the how and the why. Push back if something’s not clear. Hold your colleagues responsible to keep a maintainable codebase, and have them do the same. And when you get a question back, think about answering it as a comment, not just in your review tool.
Build in “Scotty time.”
Time estimates are a necessary evil in most software shops. Build in some extra time in your tickets for getting yourself back into the project, for the unforeseen problems that will come up, and for QA and code review. That’ll help your bosses’ expectations stay realistic.
Build in “me time.”
You’re a biological being. (Probably human, but as a sci-fi writer on the side, I want to be inclusive.) Keep your biological processes healthy: take breaks to eat, get some water, don’t overdo the caffeine or alcohol, and make sure to get a good night’s sleep.
You’re a psychological being. Keep your mind healthy: when it’s time to pack up, pack up. If you need to work overtime regularly, the problem is not with you. It means the higher-ups expect more than you can reliably deliver, and it’s just not going to be sustainable down the road. Burnout’s a real thing, and if you find yourself getting there, raise a flag. If they have a problem, remind them that overwork hurts code quality. When you’re tired, you write bugs.
Have a fun side project.
Inevitably, there comes a time in software engineering when you're focused on bug fixes and grinding tasks. Some people thrive in that, but I know I don't. So have a side project you're just doing for fun, so you can inoculate yourself against the grind.
Know that, once in a while, you’ll fail. And that’s a good thing.
In many ways, failure is a form of success. It could mean that the problem isn’t clear, or that there’s something else that’s interfering. As a manager, I know that when my team fails at something, we just need to pull back a little bit and try something else. While many failures are caused by one person, I take the attitude that it’s a team effort to fix it, and when I describe the problem I’ll leave the person’s name out of it. It’s extremely important to me to maintain a supportive atmosphere.
When you succeed, take pride in it.
For every amazing feature you work on, you’ll work on ten bug fixes or small tweaks. Every time you finish anything, take a look at the product and say to yourself, “That’s something I did.” Bug fixes can be a grind, but that doesn’t mean they’re not worth small celebrations.
Love your product.
In the end, I work for the paycheck, like most people do. But it’s nice to think about the impact I’m making. No matter the product, even if it’s just a small piece of a big machine, I take a look at it and know that I’m helping people do X. You can help entertain or keep people informed. You can help small businesses succeed. Find the person you like whose life you’re making just a little bit better.