In school, engineers and scientists learn to prioritize aspects of their work in a particular way. While hard deadlines are never “ideal” (and are often set arbitrarily), they are at least adjustable by the instructor. Bad instructors make a mess of things, but good instructors (I’m sure we can all remember a few) are masters at balancing due dates and project work loads so that their students have the time to adequately build essential skills.
The focus is all on the work — what to build, how to design it, how to build it, how to allot your time, and so on. In many ways it’s like learning how to operate in a vacuum; without a host of problems beating down your door on a day to day basis, you can learn how to balance design, time spent researching pre-existing tools, time spent coding, time spent automating one’s processes, et cetera.
If you go to work for a startup, kiss all of this goodbye.
From an engineer’s perspective, a startup’s priorities seem to put the cart before the horse. This can be frustrating at first, but it helps to realize that this is a good thing. If most engineers or scientists were at the helm, the team would spend its entire runway building and building. Sales is meant to pull engineering along at a clip; this is not ideal from the viewpoint of the engineer, who often has learned to work in the university environment described above, but it is real.
Step one is acceptance. Step two is learning how, on a daily basis, to ask the right questions about your work. Asking the right questions and making small adjustments as one goes keeps building momentum, and nothing is more important than keeping things moving.
Informed stoicism in the workplace
“I was stoic before being a Stoic was even a thing.”
Step one is to not fret. You’re going to have to pull the trigger on things you feel are half-baked or require more time. However, you have to realize that on some level this is distorted thinking. Piecemeal solutions are required, and often an engineer or scientist’s drive is to build the most elaborate, detailed, complete system possible. The problem with this (common knowledge among tech managers and graduate student advisors) is that researchers/developers tend to dig themselves a deep hole. To switch metaphors, they tend to spend a lot of time putting a spoiler onto a hoopty.
The important thing to remember as a developer, scientist, or engineer at a company is that your skills are intended to fit into the overall goals of the organization. Removed from the vacuum of pure work, what was once sterile, controlled surgery becomes field-medic work with a tourniquet and a handsaw. This can be hard to balance emotionally; people are rushed, and there’s always a cofinite amount of work remaining, no matter how much is done. When you’ve learned to approach projects from a “from scratch to full completion” mindset, it can be frustrating to move toward doing what one can, laying one brick at a time here and there.
Step two is to realize your own mind’s place in the machine you’re building. Startups can be viewed as a big machine, part computational, part psychological / biological. We aren’t simply charged with optimizing our code, we are charged with optimizing ourselves, our work routines, our practices. There’s a balance to be struck here as well; clearly we can’t spend all day automating our tasks, all day reflecting on method, as day-to-day things must be done.
What it boils down to is asking the right questions and doing what one can when one can. This might sound obvious, but it’s a matter of practical mindstate. The focus should not be on making things ideal, this will never happen. Rather, it should be on maintaining forward momentum however one can. If you realize you’re typing the same things over and over again, hack up a quick script to speed yourself up. Once you’ve done this with a few tasks (and if you rely on this quick tools enough), you have a good set of candidates for inclusion into a more comprehensive tool. This can be done piecemeal alongside more pressing daily goals. Doing it piecemeal also means that you don’t waste time building out functionality that ends up being not that useful.
Optimization is a lifestyle choice
It won’t do to simply sit down every few weeks or months and say “what could I do to improve my daily practices?” It’s something to think about on a daily basis, bringing awareness to every task. What do I spend my time on? Am I typing the same things over and over? Would it simplify my code if these various functions were phrased more generally, or in a module?
While we can’t stop to address the answers to these questions whenever we want, simply asking them and keeping them in mind is useful. It helps orient us toward what needs to be done when the time comes. This helps us reach a more ideal situation through small, doable steps.
About the AuthorMore Content by Mike Freenor