This piece of writing is a little different from what i usually post here. I’ll probably just talk about my experiences in 2022 that relate to my work or what i didn’t know before and what i’ve since learned, as well as what i experienced during that time up to now. So it’s kind of a personal retrospective. Naturally, there might be some mistakes in idioms or terminology, and of course, there are still many things i don’t know yet. Sorry about that!
So here’s what i’ve learned so far if looking back at 2022
Python
I’ve been writing in Python since around late 2015 or so, mainly because i just can’t stand Java or PHP. Back then, i needed a programming language that was easy to learn and quick to pick up. That’s why i started learning Python, and eventually, it became my ‘de-facto’ language for writing code: whether for work or just for fun projects. Fortunately, at my current workplace, Python has become the standard for writing automation tests (UI, integration, API) and for creating libraries or internal tools
The biggest change i’ve experienced in my Python journey is that now i can manipulate Python in different ways to solve problems. Back then, when i used libraries like requests for HTTP, database libraries like SQLite or MySQL, or web frameworks like Django, i only knew how to use their basic built-in APIs. But now, i can extend their methods, override them for my own use cases, or even rewrite parts of them to fit my needs
Since i started working at a new place, i’ve also learned a lot more about Python related things, like dunder (magic) methods, built-in collections, using C extensions and porting them to run in Python, I/O, threading, and other core Python concepts that are usually written in PEPs. I’ve also learned more about writing Pythonic code and avoiding anti-patterns. Of course, even with all this progress, there’s still so much i don’t know about Python
Design Patterns
I got into design patterns thanks to being assigned a major refactoring project for automating the website and app UIs. And yes, it was horrendous but at the same time, i felt i gained a huge amount of new knowledge about programming paradigms. During that refactoring work, i also learned about many design patterns things like Adapter, Decorator, Bridge, Composite over Inheritance, Interface (in Python only), Factory, Proxy, and many others.
Of course, i only implemented a few of them in practice. As the famous saying goes “If all you have is a hammer, everything looks like a nail”
Database
Somehow, from 2021 until the middle of this year, i often worked with databases. I didn’t really learn much about writing queries, but i did learn a lot about database clusters, connection pooling, and the federated database concept (i just found out that my company uses this). I also learned about database migration, strategies for testing it, and what i fondly remember the most, i created a wrapper that contained a set of methods for running query scripts to quickly retrieve data.
Why did i do that? The answer’s simple: at my workplace, there are various stakeholders such as key people from Operations/Support, Sales, Marketing, and so on who often ask us for data (ad hoc requests, if you prefer to call them that). Take for example:
- How many users dropped resumes on our platform?
- How many users applied to job A, B, or C?
- Or how many users interacted with banner A over a certain time period?
So, my co-workers and i took the initiative to make a wrapper (of course, written in Python) that could make our work much easier, so we wouldn’t have to write queries from scratch every time
Distributed Systems
Since 2018, i’ve been fascinated by the topic of distributed systems. Even now, i still think it’s one of the broadest and hardest areas of software engineering to truly understand. Especially if we haven’t applied it or experienced it firsthand. Luckily, when i joined my current company, i finally got to experience the challenge of managing so many services that are all distributed connected to each other
Kubernetes is still a hot topic for me, and i’ve also started to understand a bit more about resiliency and how to troubleshoot issues related to distributed systems. I also wrote about one of my experiences handling failed requests, which was just one of many issues i’ve faced, but it was a particularly interesting and challenging one, and i learned a lot from it
Software Testing
Apart from distributed systems, software testing is one of the hardest topics to learn. I’m not talking about implementing or designing a test automation framework, but about the underlying concepts themselves: they’re broad, complex, and often causes a lot of different opinions
When i switched my career to this role1, hell, i’m not exaggerating that i really struggled with the transition and adaptation to the work. Even after two years, i still find it difficult to do manual testing or to find the root cause of an issue because my mindset is naturally constructive, which is the exact opposite of a tester’s mindset with a destructive one
Before that, when i was a software or backend engineer, i used to think QA was annoying because they always found the weirdest, most unexpected bugs hahaha. But as time went on, i realized that people who work in this role are the unsung heroes of software development. They’re super duper underrated and honestly, only a handful of people can truly fill them well
- Want to understand the flow of a feature from the user’s perspective? Ask QA
- Want to understand it from the business side? Ask QA
- Want to know which part of the code caused the bug? Seriously, just ask QA
So, i really think QA deserves more appreciation and deeper attention
Mobile Apps Migration
Out of all the moments i experienced throughout 2022–2023, this one definitely takes first place in terms of how much i learned. This was the time when i was given huge responsibility for managing the quality, reliability, release process, and overall migration of our mobile apps. We underwent major migration from Swift and Kotlin to Flutter, which is still ongoing even now
Honestly, it was one of the most exhausting things i’ve done since i started working at this company two years ago. It was a painful experience (seriously, this was the first time i truly understood the meaning of berangkat-kerja-pulang-tidur). Not to mention, i also had to monitor the existing native apps. Even though i’d already become familiar with our features, things were far from easy: definitely not a quick “sat set sat set” and done kind of situation
We prepared everything thoroughly, yet we still ran into issues every new sprint: errors, discrepancies, and unexpected bugs. The most astonishing thing was when i checked the issue tracker, to date, the mobile apps team has closed +360 issues during this Flutter migration. And honestly, i’m sure that number will keep increasing once we release at a larger scale
Just thinking about it sometimes makes me nervous, especially knowing how massive our user base is. Based on Firebase and our internal tracking, our monthly active users range from about 120 to 180k. I guess at some point, i’ll write a longer post just about this whole experience
Agile-board management things or whatever relate with these
It’s still a mystery to me and honestly, i still don’t really understand what kind of best practices can truly be applied. That being said, i think after a few years of working and having experienced different environments, cultures, and people, i’ve learned that what we consider a “best practice” in one place and what we try to apply in a new one, should be something that makes us comfortable and makes our daily work easier
This year, i’ve learned a lot about that. For example, it’s better to create a parent ticket that contains a list of issues for certain features. We can also integrate Git branch naming based on the related ticket. Besides that, i’ve done a lot of experiments with the YouTrack board (that’s what my company uses, so perhaps that’s primary reasons why i’m talking about this), like calculating and distributing story points based on man-hours, prioritizing P0/P1 issues instead of having too many P2/P3s and plenty of other things that are still new to me, even after all these years
Hiring
For the first time, i was finally given the opportunity to take part in the applicant recruitment process. And you know what? This was honestly one of the most unforgettable moments for me so far. I think the process of interviewing candidates, checking technical tests, and screening resumes is not only a task, but also one of the first real steps toward becoming an experienced professional in a company (perhaps? or is just for me?). So yeah, the feeling i got was both embarrassing and fun — because during my first interview, the nervous one wasn’t the candidate, but me! 😅
Eventually, i started to understand how a company actually recruits the best candidates. For example, in my workplace (especially when hiring an SDET or QA Engineer), there are about seven stages a candidate needs to go through:
- Resume screening — done by HR
- HR interview — if the candidate’s background meets the basic requirements, HR conducts an initial interview
- Technical test — if they pass the HR round, the candidate gets an assignment (the deadline is usually 5–7 days). The questions depend on their experience. Some tests are purely coding; others combine test-case design and coding. I usually take part in reviewing the technical test and give the “green light” if the candidate can move forward
- First technical interview — focused more on technical matters, conducted by two people: me and a senior engineer
- Second technical interview — this one’s the most crucial stage. The candidate is interviewed directly by our lead QA and head of engineering (or sometimes our principal engineer). The questions usually dig deeper into fundamentals, critical concepts, and how the candidate’s experience aligns with our company
- Interview with the Head of People & Culture — focuses more on work style, values, and personal vision (we work across 3-4 countries with different cultures, so yeah this is a big deal)
- Final interview — with HR again and someone from operations (i forgot the position title 😅). Here, the candidate receives the offer letter, salary discussion and finally, the end of the process
The most interesting part is the final decision-making. Everyone involved in the interviews gathers to discuss each candidate’s strengths and weaknesses from their own perspective, and then we vote. That collective process really taught me that hiring: whether it turns out great or not, can’t be blamed on just one person because it’s a shared responsibility
Besides that, i also learned how to manage my time between interviews, reviewing technical tests, and doing my main tasks. Like it or not, this recruitment work often happens at the end of the day, but still, i learned so many things from the candidates: from their technical answers, their stories, to how they handled tricky questions
Others Things That I’ve Missed?
Actually, i’ve learned a lot of things this year, though i’ve also forgotten quite a few 😅. But there are some highlights that i particularly remember, mostly because those “things” were tough to work on, like dealing with the event emitter in TypeScript (or in a Node.js environment), handling Redis crashes on its instances, and learning some useful commands for debugging with bash scripts or even some wacky Linux commands
Footnotes
-
Technically speaking, I’m not purely QA, i work as a Software Engineer in Test (let’s just call it that for the fancy term haha) ↩