On moving from manual work careers to software engineering
Last updated: Nov 3, 2021
For people who are coming into software engineering from a previous manual-work (“MW”) career, software engineering feels VERY different. A lot of this difference comes from the fact that software engineering is knowledge work (“KW”).
In KW many things are different. Here are a few differences that come to mind.
- In MW, you work on materials. In KW, you work on information.
- In MW, your work is tangible and visible. In KW, it is intangible and invisible.
- In MW, supervision of the worker is critical. In KW, it is often counter-productive.
- In MW, work is linear and predictable. In KW, it is non-linear and varied.
- In MW, adding team members helps projects finish faster. In KW, it often slows things down.
- In MW, experimentation is often discouraged. In KW, it is often essential.
- In MW, punctuality is expected. In many KW workplaces it is only a nice to have.
- In MW, your work is obviously visible. In KW, you have to spend effort to make your work visible.
- In MW, others set your standards for you. In KW, you are the one setting your standards.
- In MW, the nature of work shifts slowly. In KW, it often changes at a breakneck pace.
Here are a few gotchas that manual-work professionals encounter in the software engineering workplace:
Knowledge work is almost entirely problem-solving, and so you’ll be given a lot of responsibility in a very short period of time. You might be asked to build the front page of the company in your first week on the job. As you progress, you’ll build critical components of your company’s software infrastructure. You might even be given access to production databases, where any mistake could possibly sink the company.
There is no way to avoid this responsibility – responsibility is at the heart of KW itself. Coming from an MW environment, KW will feel like you’re a high-powered individual. That’s because you are. If you feel nervous at your first job, I would suggest getting plenty of sleep, having a good breakfast, and finding ways to manage your emotions until you get accustomed to it.
No two engineers are alike
Every software engineer has their own unique mix of skills, strengths, blindspots and weaknesses. There is no easy way to compare two software engineers that I know of. If you look around your office (if you aren’t there yet, you will be one day), you’ll see that what I’m saying is true. A good software team feels like a band of superheroes: you might all be working together to fight the big bad bug, but you’ll all do things differently.
For the aspiring engineer, this means that your interests are as important as your skills. In fact, for the best engineers, their interests will end up determining their skills. If a particular technology interests you, you should follow that interest. In software engineering, following your passion works very well, which is actually the opposite of what works/doesn’t work in many MW workplaces.
There are no set rules
At some point, usually once you’re past your first year, software engineering starts feeling very subjective. This is because software engineering IS subjective. Developers are usually making things up as they go along. All the time. In fact, even “best practices” are just rules of thumb. I have no doubt that, as a profession, we have not created a universal set of architectural principles that will always work, nor can we possibly do so. There’s an idiom for this: “Silver bullets don’t exist.”
But this doesn’t mean that there are no consequences to your decisions. You still have to reap what you sow, and best practices will keep you safe from bad decisions. That’s why they persist in software engineering culture. The way you learn best practices is to read. Read a lot. Read blogs, books and articles. Videos are okay, but they tend to be focused on beginners more often than not, and when you’re on video it’s easy to get away with less-than-useful content. Immerse yourself in the rich history and literature of software engineering. It’s a great subculture, and there are lots of useful and fun things to learn and discover here. By doing this, you’ll gain many different perspectives which will help you triangulate a “good enough” solution to any given problem. Not a “best” solution – remember, that doesn’t exist, because there are no silver bullets. Keep doing this for long enough and maybe one day, you’ll make YOUR OWN best practices and form YOUR OWN opinions.
Estimates always have healthy risk buffers
A famous book called The Mythical Man Month points out that software engineering is non-linear. You don’t know how much time a task will take to complete because you don’t always know what deeper, unknown issues or concerns will make your work lengthier. The only way to find out how long a task will take is to actually do the task. What this means is that estimation is a crapshoot. It’s all random. Google #NoEstimates.
In other words, unlike making cars on a factory floor, it is IMPOSSIBLE to know for certain how long it will take to build a piece of software. And so, deadlines are negotiable. You will probably still be asked for an estimate because the business still needs to know how long things will take, so they can plan. A good rule of thumb is to think about how long you THINK a task will take, then double it. Or, better yet, triple it, because the truth is, you DON’T know how long a task will take. All good engineers build a healthy risk buffer into their estimates so that any surprises can be handled.
Your mental state will have a larger effect on your performance than in MW
Sleep is important in all work. But in KW, especially in software engineering, the thing doing all the work isn’t your muscles – it’s your brain. And you can’t function at anywhere close to peak performance if your brain is tired, overworked, stressed, or otherwise emotionally compromised.
Get sleep and take care of your mental health. As a software engineer, your performance depends on it.
You will often be unsupervised and will be expected to manage your own time
This one is a big one for many people. In many MW workplaces, you punch in and punch out at a set time of day. Not so in software engineering. Many workplaces will give you a VERY long leash when it comes to managing your own time. Asynchronous work is quite common, and I’ve seen my friends travel the world while holding down a corporate job. The truth is that managing time and supervising people takes a lot of effort, and in a KW workplace, it’s seen as micromanagement.
Instead, you can expect to be almost totally unsupervised on a day-to-day basis. You’ll manage your own time. Pickign up time management skills is a bonus; picking up distraction management skills is CRUCIAL. You’ll be measured based on your impact, not on your efforts or your time spent.
Disqus comments are disabled.