In the last Azimo Labs article, Wioletta Kurek shared her tips for starting a career in software engineering. This time it’s Liubov Fedorchuk’s turn. Both Wioletta and Liubov became full-time engineers at Azimo after graduating from our mobile engineering internship program.
How to succeed in your first software engineering job
So, you’ve done the hard part and won your dream job as a software engineer. What now?
Building confidence in your first software engineering job takes time. At the start, everything seems complex — there are new processes to learn, requirements to understand and relationships to manage. Thankfully, the job gets easier over time. In this article, I’ll share some tips that will give you a head start.
Plan, diagnose, troubleshoot
A good software engineer needs structure to plan their work. At Azimo we manage our work using JIRA, though there are several similar tools on the market.
JIRA work at Azimo is divided into different subtypes:
Bugs are defined as coding errors that result in unexpected or undefined behaviour by the software. When I started at Azimo, I was asked to fix bugs in my first week. Why? Because fixing bugs is a great way to acquaint yourself with software and what users expect of it.
Dealing with bugs teaches you another essential skill — diagnosing issues. You can’t fix something unless you know exactly what’s wrong. Sometimes it takes two minutes to diagnose an issue, in other cases it can take a whole day — so make sure you’re ready for that.
When you have successfully understood the problem, it’s time to find it and fix it. This is called troubleshooting. I’ve identified a few simple steps that help me to troubleshoot successfully:
Try to identify that most important keywords in your JIRA ticket. Often these are in the title: “Glitch in the UINavigationBar display”.
Use these keywords (in our case, UINavigationBar) to search for a project. Here are a couple of Xcode shortcuts that I use for searching:
- Global search with keywords by project — command+shift+F (⌘+⇧+F)
- Search for a file name in project / “open quickly” box — command+shift+O (⌘+⇧+O)
- Search in file by keyword — command+F (⌘+F)
When you find several places in the project where these keywords are used, try to look at the module as a whole and understand what task it performs. It’s easy to understand from the name of the class or protocol that is used there.
When you understand that the functionality of this module/block of code is the same as described in the task/Jira ticket, you can start to solve the problem.
- Take a look at unit tests that cover this class. Check what functionality they are testing and what results are expected. This will help to understand the mission of this class / module / block of code.
- It is obvious, but still — try to debug a project. Put a breakpoint and try to reproduce the bug. Keep track of the results while in the process of debugging.
Finally, and most importantly, ask for help if you get stuck. A good team member won’t refuse to help you solve the problem, a great one will show you how to solve the problem yourself. You aren’t expected to know everything from day one, so don’t suffer in silence 😊.
Don’t focus only on the specific lines of code in which you think the problem lies. Try to look at the project as a whole, because often the root of your problem will be elsewhere, or will be revealed by a more holistic approach. After all, if a person goes to the doctor with severe pain in their left arm, the doctor will probably check their heart as a precaution, because we know that left arm pain is a key indicator of a heart attack.
When you have “fixed” the bug, you need to be sure that it really is fixed, or that your fix doesn’t cause new bugs elsewhere in the software. Writing tests will help you with this.
Perhaps the biggest thing I learned during my Azimo internship was the importance of tests. Before my internship, I had no experience of writing tests, now I write them almost every day, because you can’t build working software without them. Tests simplify development, help to identify inaccuracies, show mistakes in logic and ultimately ensure a great user experience.
Automated testing will set your engineering team free
“Automation frees engineers to focus on the things that matter and unleash their creativity”
If you haven’t written tests before, and many of you fresh out of school or university will not have, it’s not so scary and it gets easier and faster with practice. Here are a few practical tips that took me from “tests are difficult, I hate them” to “tests will save humanity from damnation, I love them.”
- Unit tests should be independent of one another
- Tests should run quickly
- It’s better to avoid using real objects in unit testing. Instead of real objects it is better to use fake objects with configurable behaviour
- Avoid any ambiguity in the tests: the test result should only be pass or fail, and the test name should be self-descriptive.
Our team also has one simple rule — all tests in the project must pass (and there are a lot of them). This is the only way that we can determine our application is stable. And if something fails, we don’t fix the test, we fix the problem 😉.
Stand-ups and meetings
Meetings and stand-ups are an integral part of team work and cannot be skipped by any team member.
The first and most important meeting of the day is the daily standup with the entire mobile team. During the stand-up, we stand in a circle and throw a stuffed pig toy (thanks, Angry Birds) to each other.
When the pig lands in your hands, you share what you worked on yesterday and what your plans are for the day ahead. This helps to collect your thoughts, plan your day and understand what others are trying to achieve. It may be that you have a solution you can share with them, or vice versa.
We also gather for a longer meeting on Mondays for a short retrospective on the previous week’s work — what worked well, what was challenging. We then share knowledge to ensure that challenges are easier to meet and successes can be repeated.
Among other meetings, we also have sprint planning, task evaluation sessions, sprint retrospectives and sprint demos at which we share the working software from our previous sprint.
The first week of my internship was full of meetings and my advice to any new starter at a company is to embrace them all. Those early meetings give you a chance to get to know key people — product managers, designers, data scientists — and processes. Later on, meetings will become more routine as you acclimatise to the company. Make the most of them while they are fresh and new.
A good software engineer needs goals and a good leader helps to provide them. When I first joined Azimo as an intern, I had a one-to-one with the mobile tech lead in which we identified my goals for the internship. Here they are:
- Own one product feature.
- Complete three technical/maintenance tickets.
- Fix five bugs.
- Learn how to use the crash analytics tools.
- Be familiar with unit testing and write tests that meet quality and coverage expectations.
- Contribute actively to code reviews.
- Contribute actively in grooming and estimation sessions.
- Write this blog post.
It was great to have regular one-to-ones with the mobile tech lead. Every few weeks we met and I had the opportunity to tell him what was going well and what I’d found challenging since. I shared and received feedback and I always felt heard.
If you don’t have the chance to sit down one-to-one with your team lead, try to at least agree by email on a list of goals. It’s essential that you know what is expected of you and to share what you want to achieve. This approach will help to determine your career growth and it will make you feel like a real part of the team, actively contributing to projects.
Building a good relationship with your team is perhaps the most important thing you can do as a software engineer. No person is an island, we need the wisdom and company of others to flourish.
I’ll let you in on a secret. When I started my internship at Azimo in Kraków, I didn’t speak a word of Polish. Thankfully, everyone at the office speaks English (also not my first language), and it was heart-warming when colleagues discovered that I didn’t speak Polish and, without exception, switched to speaking in English to help me.
Besides, without understanding English I would not have been able to speak to our product and design team in London, none of whom speak Polish. So, one more important tip — English is as important a language as any programming language you will learn. It will unlock many more job opportunities for you. That said, I’m now conversant in Polish, even if my grammar isn’t always correct 😄.
If you focus on all the things mentioned above and bring enthusiasm to your new role, you will surely become a valued member of your team. After that, all you need to do is design, develop, maintain, test and evaluate all your software with love ❤️.