The Four Most Important Things I’ve Learned From 15 Years In Tech
Working in tech is hard. Independent on if you’ve spent time at the Uni or not, there are specific skills we don’t learn or easily forget. My goal with this article to fast forward you 15 years. I’m planning on doing this by exposing the four most important learnings I’ve collected during my time in the industry.
Before we start, a little about me, I work as an automation engineer, developing systems that make various processes more effective. I’ve worked on automation software running in robotised factories and, most recently, in AAA gaming studios.
I general, the mistakes I make have a significant impact. And I’ve made a lot of them. If I had followed these four principles, I estimate I would have avoided almost all of them. Here we go.
Listen to your gut feeling
Now and then, while working on a task, you might get the sensation that something isn’t how it should be. If you get a feeling telling you that you might not be on the right track, it’s tempting to push away those feelings just because they are uncomfortable. The thing is, if the belief turns out to describe the reality, it could mean more work for you upfront. It is admitting you should have made another decision earlier requires courage.
I’ve been in situations where I’ve spent a significant amount of time on a particular task while pushing away my gut feelings. I thought that if I started to listen to that voice, I might realise I’m on the wrong track. The outcome would be that the work I’ve produced so far would be useless. In the end, this was precisely the case, but this became clear to me much later. If I had dealt with the feeling earlier, I could have spent my time differently.
Your gut feeling won’t always tell the truth, but make sure you listen to it.
Test your changes
It’s not uncommon for anyone within tech to work under time pressure. As soon as the tasks are stacking up and deadlines are looming, strange things start to happen. You might resort to the reasoning you wouldn’t otherwise. The idea I would like to call “might work now” could be tempting. It means that at any point during the development, you might be done. By trying to finish off the task, there is a possibility you could move over to the next one. On the other hand, if you continue the development and testing, that chance is zero.
You realise you’re in a high risk, high reward situation, and you might choose to gamble. I would say it’s rarely worth it. By gambling, you will, in most cases, end up spending more time on the task by having to go back to it over and over again. Put that extra time in upfront to make sure what you’re working on is solid. Then you can safely move over to the next task.
I learned this the hard way by having to leave my home for work at 11 pm to deliver a code update. The reason behind this was that a change I’d made earlier that day, which I didn’t thoroughly test. As the night shift of the company using my software started, an operator discovered a bug that interfered with their work. I could easily have avoided that by running a few test cases earlier that day.
Question everything
If I ranked the differences between a junior and a senior engineer, the ability to question things would be on top of that list. With years in the craft comes confidence and with confidence the courage to question. Regardless if you’re a junior or senior engineer, I would say that you should get into the mindset of asking things right now.
Whatever position you’re in, you are there because you are you. What this means is that you are the expert in your field. Let’s look at how you can utilise that expertise. Whenever you get a task, ask yourself these three questions:
- Should we do this in this way?
- Should we do this right now?
- Should we do this at all?
In some cases, there is absolutely nothing wrong with the task. You might realise you didn’t get the whole picture or simply that you’ve misunderstood. In those cases, there is something wrong, though, and you want to the point that out.
Opposite of what you might think, by questioning your co-workers and even your boss, you are going to be the best team player you can. You will realise that the people around you might be wrong from time to time, and by allowing yourself to question, you can fill in those gaps. Who wouldn’t want a colleague who is there to catch you when you fall?
Is there another way around this problem?
There is a picture floating around online of a cat waiting to get out of her cage. The gate of the pen is there, but the roof or sides are not, so really she could get out, anywhere but where the entrance is. Being too focused on the problem and forgetting about the goal is a recipe for failure.
Example time. After spending several days trying to figure out how to get rid of some elusive compile errors, I gave up. Not knowing what to do, I resolved to re-installing the OS on my computer. By doing this, I was able to fix the issues. In this case, the goal was to get the project to compile. By focusing too much on trying to find errors in the code, I forgot about the other options at hand.
Engineers learn to find solutions and understand how things are working. It can be very frustrating to have to give up on a problem before you’ve gotten to the bottom of it. Some of us might even see it as failing at your job. That’s not the case at all. Sometimes the opposite might be right. By letting go and moving forward, we will be able to increase our productivity and ultimately become better at what we do.
To sum this up in one sentence; Don’t forget why you’re at work, to find solutions, not to solve problems.
Conclusion
There you have it. Next time you are going to make a decision, follow the principles of Listen to your gut feeling, Test your changes, Question everything, and Is there another way around this problem. By doing so, I promise you’ll make fewer mistakes than I’ve done.
