By: Oren Cohen
Two years ago, I found myself arriving at an interview inside a renovated “chicken roost” in a village.
My first impression of Edgybees at the time was, ‘I love the idea! I hope we get seriously funded.’
I started as a Software Development Engineer In Test, which is a fancy title for the person responsible for Automation and also for building the QA process from zero.
I spent countless hours drafting test documents, flying drones, finding bugs, verifying the developers fixed them, and drinking lots of coffee. I loved it. I never flew a drone prior to working at Edgybees. I did, however, have experience and recommendations for doing an excellent job in QA and was also in my last year of Computer Science studies. Everything fell into place, and life threw challenges at me day in, day out.
Fast forward to 2020. I’m a Backend and Platform Engineer. Responsible for some modules in our backend suite, actively supporting live events, creating internal courses for the company’s staff, and still drinking lots of coffee.
During this journey, I had the privilege of working on software that is meant to help first responders save lives. I’ve always considered myself as the type of developer that creates video games. I’m grateful for the enlightening experience that taught me hard, but valuable lessons, for any developer.
Before we begin, here’s lesson number 0: The amount of knowledge I gained over two years of being a part of a start- up is impossible to learn in any large high-tech organization with bigger teams.
Now, let’s dig in!
1. Leave Your Ego Aside
This point is first for a reason. How do you react to team members criticizing your work? Are you generally curious about what you could have done better? Are you seeking to learn from the more experienced people in your team? Or are you sulking for the rest of the day, thinking to yourself they don’t know what they’re saying?
If you are doing the first, congratulations, you are in for a whole lot of learning and a skill sharpening ride. That attitude will take you far and up, while your skill set will continue to grow every day.
However, if you’re not taking that road, it’s going to be challenging to learn anything new – especially when you’re always right, and everyone else is always wrong or doesn’t understand your reasoning. Don’t you think?
Leave your ego where it won’t interfere in your daily office activities, and watch your knowledge grow. Your peers will respect you for the willingness to learn and ability to see their perspective as well.
2. Don’t Wait For Tasks To Come In
The business of saving lives isn’t laid-back. Usually, windows of opportunity are short, and the opportunities themselves are stretching the team’s capacity. That’s why it is super important to be proactive. Do you see a critical bug? Fix it. Don’t wait to be assigned a task to do it.
I know how sometimes there are tasks we don’t want to fall into our plate. “Could someone else do it?” was a recurring thought for me at the beginning of 2018, when I just started writing business code instead of QA Automation.
As we grow and experience crisis and hardship at work, we understand these lessons. If I had just fixed it when I found it, I wouldn’t be working on it at 1 AM.
Don’t give up on doing the right thing because of laziness or procrastination. Let’s face it — we both know that you know when a bug is under your jurisdiction.
When saving lives is on the line, we don’t waste precious time.
But, the flip side of this is not to take on something you’re not familiar with that will take even more time to solve.For example, at Edgybees, we deal with Augmented Reality. But, I wouldn’t know the first thing about fixing a bug in any related algorithm. I deal with the backend and platform. That’s where my power is. I don’t stretch it into territories that will waste our time.
Know your strengths and responsibilities and act on those without permission. If you’re independent, you can keep growing on your own.
3. Don’t Think About Saving Lives
When saving lives becomes your responsibility, it’s stressful.
Everything you do becomes ladled with meaning. Will the change to the Platform structure affect our Computer Vision modules? Will a change in the backend break the front-end? When is this coming out to Production? Will QA have enough time to test?
Endless questions! You can’t stop thinking about what it means if you break anything.
So don’t.
It doesn’t lead anywhere, believe me. I do have a suggestion, instead.
Trust the structure.
Whichever code you want to merge into the project will be reviewed by a team member. That code should also pass unit and integration tests. After clearing those, it should also get a green light from QA.
Only then, your code will be on its way to actual customers.
So why worry? Do your best work. Make sure that the reviewer is familiar with the project you’re working on, and there are tests to validate that work.
And what to do when that structure is partial or non-existent? That takes us back to our previous point — invent it. Don’t wait to be tasked with creating unit tests for your code. I will even go as far as saying that if you’re building something completely new, budget the time for writing these tests within the task estimation.
Just don’t think about the critical what-ifs. They won’t help your progress in any way.
4. Get Excited and Celebrate Small Wins
There’s nothing I love more than shouting “YES!” in the office when something I worked on — small as it may seem — works as I intended.
It might seem childish to some, but it keeps me motivated.
Another way to get excited and motivated is to break down a big task into smaller tasks and then start to chip away at them.
Here’s a short example:
Big task:
• Write a new Module for the Kubernetes cluster that does X.
Small tasks:
• Write Handler 1 of the module.
• Write Handler 2 of the module.
• … Write Handler N.
• Dockerize the module.
• Integrate with DB.
• Integrate with Kubernetes.
• Drink a glass of Hot Chocolate and marvel at your work.
Do you see it? Now, instead of one foreboding task, you have many small ones that are a lot easier to accomplish.
When you cross off these tasks, celebrate this fact. Acknowledge the progress you made.
If you don’t do it, you’ll be bored. You’ll lose interest quickly and start falling into the “what am I doing with my life?” adage.
You’re not a librarian at an empty library. You’re a software engineer, and you learn something new every single day. Your work is going to affect many people. No matter if dozens, hundreds, or even millions. Your work will change lives. Act like it. Be willing to celebrate the process.
You’ll thank yourself later (and me).
5. Being a Team Player glues everything together
Being a Team Player is probably the most crucial point in this entire story. We already talked about structure. Your team members help keep your work in a pipeline before it reaches customers. But, that’s not all being a team player means.
You see these people every day for more hours than your own family. If a family is defined by the amount of time spent with someone, your team is your family.
Don’t you think it’s important to know a thing or two about these people? To know you can rely on them? Or perhaps to let them know they can depend on you as well.
It doesn’t matter what your business is. The software can range from casino software to first responders — You’ll always have someone who did the research, or has much more experience than you in the field. You should feel comfortable asking them questions and learning from them.
Being a team player doesn’t put full responsibility on them. Yes, they do need to be courteous and answer your questions or refer you to helpful resources. But, what many inexperienced developers take for granted is that a team player should also feel comfortable asking questions and saying the three magic words: “I don’t know.”
In my business, if you need help, you ask for help. We don’t have time to deal with personal insecurity that will lead to much more time consumed than a knowledgeable team member will present.
Don’t feel comfortable asking for help? That’s when it’s time to challenge the structure. Talk to your boss about changing the work environment in a way that promotes healthy communication between team members.
A business without healthy team communication is not going to last long. Make sure to be proactive about improving that communication in the companies that employ you.
After all, a strong team is a win-win for everybody.
