Pour some coffee, put on some relaxing music and join us for the ninth episode of The Hüb where Đorđe Madić shares the valuable experience he obtained while working as a Tech Lead at Zühlke.
"Welcome to the Hüb – a place where our experts share their frank opinions, ideas and expertise, their knowledge of the industry, its future and important trends"
What does the path to becoming a tech lead look like? What is the impact of bad tests? What are the values of a technological company?
Pour some coffee, put on some relaxing music and join us for the ninth episode of The Hüb where Đorđe Madić shares the valuable experience he obtained while working as a Tech Lead at Zühlke.
I recently stumbled upon a quote that can describe my experience as a Tech Lead quite well. The book "Fundamentals of Software Architecture" by Mark Richards and Neal Ford quotes Ralph Johnson, a Software Architect and author of several architecture books: "Architecture is about the important stuff…whatever that is."
I could say the same for being a Tech Lead.
"Tech Lead is about the important stuff, whatever that is".
What do I mean by that? Well, I’ve dealt with the analysis of business demands as well as the health of our system architecture – analysis aimed at looking towards the future. What awaits us in the days to come? How does that affect us?
But there are also certain processes that aren’t strictly technical but directed towards leading a team. Simply speaking, the optimization of teamwork. How to divide work? What should be taken as a priority? etc.
The transition to a tech-lead role is never clear. At first, I dealt a lot with technical aspects, which allowed me an insight into the broad perspective of the technical side of the job. Apart from the code, which I worked on, this included every task, through which I learned about the whole picture, the whole perspective. This brought a sense of responsibility, especially for the success of the entire team. What certainly changed there was the fact that I developed even closer cooperation with the members of my team. My work began to include less coding, more code reading and more conversations with colleagues from our business stakeholders. It all somehow became well-balanced. I didn’t miss anything.
A clear difference emerged: far more work with people and less work with code. But working with people is never that simple.
Software testing and I clicked early on in my career. The reason is simple - it gives me the confidence to change the code and gives my team confidence to frequently deploy to production.
Continuously analyzing the automated tests I worked with, I noticed some interesting things.
Tests are easy to add, but hard to remove.
My team had more than a few opportunities to take over an application codebase. This often means a new business domain, a new tech stack, new stakeholders.
Removing tests, even obviously bad ones generate a sense of uncertainty - maybe they exist for a reason we don't understand.
Tests know too much.
If the outcome is that the code does not change, a test should not fail. But they often do, and fixing them kills our productivity. What's missing here is the right level of abstraction. Do you sometimes split your screen to write unit tests for your new method? Code on the left, tests on the right? This might lead you to write tests that know too much.
Real data is good data.
How often do you hand-craft the test data your tests use? Does it look similar to production data?
If the test data is not realistic, then what is the value of the test report?
Bugs are detected later in the integration, making them more expensive.
False positives occur as the crafted test data may never appear in that form in production.
Realistic test data also helps me understand the domain behind the code, especially in large codebases.
CDC tests require formal education.
We, developers, are used to writing functional tests. CDC tests have a different purpose, requiring a different mindset in the design. If developers are not educated on the topic, the CDC tests will look more like awkward functional integration tests.
Don’t take it personally.
There’s no need for that, and in most situations, it can only hinder our work. But be careful and always try to understand where people are coming from, try to keep your focus on the problem at hand. Push your emotions aside.
Go "back to basics" from time to time.
With this as your starting point, you can do anything. For example, if you have been focused for some time on a specific framework, go back and remind yourself of the basics of JavaScript. Get comfortable with the basics because they are very helpful when it comes to understanding high-level tasks, framework, library, etc.
Be yourself.
If you have the technical skills required, just relax and be who you are.
If you act naturally, you will look great in the eyes of others – colleagues or clients. Be yourself, be relaxed. That will also help create a natural working atmosphere, which is great for the team. You might be afraid to admit that you don’t know something, but that is no big deal. We all have something that we don’t know or simply forget at a particular moment.
The essential value to learn is the culture of open feedback.
You need to practice this skill and get comfortable with receiving and giving feedback to both colleagues and strangers. I also went through formal feedback training. Practice and work with your colleagues make that exchange easier, although in some situations it can still get challenging, especially when we’re dealing with a case of critical feedback. That is why you should focus on mapping your intentions and make sure that neither you nor the other side takes the feedback emotionally.
One of the most valuable things I learned about feedback was that a short feedback loop (how fast we get to our feedback) greatly affects the success of our work, and that of our team and our organization.
That is why when your team finishes a high-quality piece of work, it is beneficial to create a process of feedback with the client. Sometimes, even organizing a meeting – in person or via Skype – is a good way of hearing whether or not the client was satisfied with the process and whether there is room for improvement on future projects.
Đorđe has been working at Zühlke since November 2016. Most of his experience is in enterprise projects in the domain of telecommunications, where he worked as a full-stack software engineer and technical team lead. He is also a career coach at Zühlke.
