Pour some coffee, put on some relaxing music and join us for the first episode of The Hüb series where Veljko Zrnić shares the valuable experience he obtained while working as a Lead Engineer at Zühlke.
We welcome you to The Hüb - a place where professionals generously share their expertise and knowledge. Keep up with the next big trends as we bring you our take on the industry and do our part in moving it forward.
How does work in large software development teams function? What are the advantages of keeping up with new technologies? How important is personal development in this line of work?
Pour some coffee, put on some relaxing music and join us for the first episode of The Hüb series where Veljko Zrnić shares the valuable experience he obtained while working as a Lead Engineer at Zühlke.
I’ve been working in the field for around fifteen years. The interest and love of IT typically develops early on. For me it began in high school with first computers and Visual Basic. My first project I was proud of was a star field simulation, and then everything went on from there, C++, Pascal… What drew me to this line of work the most was freedom and creativity, the feeling that you’re creating something that’s helping users, either by being entertaining or useful.
I believe the essence of the work of a software engineer hasn’t changed over the time I’ve been working. You need a universal knack for programming, no matter what you are working on. Talent is needed when it comes to mastering the basics. Everything else is a matter of choice, whether you will use Java, .NET, DevOps tools or whatever. The tools have been evolving, new languages emerging, but programmers’ universal sense for making use of them is still the same.
It's a matter of preference. Do you want to be a specialist in a few areas, or you prefer to know a bit of everything? Every approach has its drawbacks, and it’s important for you to realize what they are. If you’re a specialist, you have to be aware that technologies move at a very fast pace, and your specialty needs to follow as well – just remember what nodeJS looked like 5 years ago, and where it is now. If you’re preferring the generalist approach, then you might encounter weird stuff as you work because your knowledge doesn’t cover the intricacies of the chosen technologies for example.
But of course, no one can put a line between the two approaches, and for me I believe the mix is the best – specialize in one, but always be on the lookout, try to see things from another perspective, use another tool, another language, even for a short while. This will give you a broader perspective when it comes to apps, API’s and anything in between. Leaving your comfort zone creates room for personal growth and expansion of your ideas.
Once you start working on a project, that is simply where your focus needs to be. You are bound to spend eight hours working on it, and if you have a family like me, you don’t get a lot of time for additional reading and research. When I do find the time, I read the news about the current developments in the industry, but I don’t have a lot of room to try these new things out. The bottom line is that self-development is at its peak whilst solving problems on a project. The more problems a project has - the more experience you gain. It’s as simple as that. So, don’t shy away from them, embrace them and do your best to solve them.
Things change fast when you work in large teams. The technical aspects such as task delegation, context of work, and individual responsibilities are important. Communication is key, the project suffers when there is a lack of it. If the team members are not cooperating, precious time is wasted.
For example, when you work remotely, the correspondence between members can cause misunderstandings. Something that is supposed to be funny can be taken wrong or literally, and someone gets offended. It takes time for the team members to get to know each other better, learn the way their minds work and how to accept comments the right way.
I learned communication from my mistakes. You shouldn’t refrain from communication with people or asking questions. Always ask questions because that is how you find solutions – even if the feedback is negative. It just means you will do better next time.
I’m currently working on a large and dynamic project along with 50 members in six different teams. That’s a lot of people for one product, which just adds to complexity. We’ve been working on it for three years at similar capacity, and it’s leaning on a legacy project which lasted for six years.
To illustrate how difficult a change would be let’s look at one example – introduction of messaging solution. Many developers would just jump at the opportunity to make changes in the communication layer to solve the persistent issues you get there, myself included. But those are the changes you would make only when it comes to the early phases of a project. Even if it seems like that would solve a lot of problems, it would actually introduce many others, especially with involving legacy systems.
It’s important to remember not to rush to design changes as one solution is actually just a tradeoff for another problem.
Our decisions are made by an architectural team. We have a person from each team who is in charge of the architecture and assigned context. All the architects meet once a week and discuss how each context fits into the whole of the project. I believe it’s an excellent approach. The only thing I would change there is finding a more inviting way for developers to suggest insights and ideas to architects, involve them on a regular basis. Some of the best ideas come from the most unexpected places, and you should always keep the door open.
When it comes to the product, you have to think about the people who will be using it. You can create the most functional product in the world, but If you haven’t optimized it to suit the user’s needs - it has no real value.
When you think in terms of functionality and problem solving, you need to do so from the perspective of a user. Software in time got into a bad habit of not always working as expected, and users just went with it. Imagine if technology were a door, the users wouldn’t be ok with not being able to open them completely or fail to open them from time to time. We should make the software reliable, as most of the other things are. This shift in perspective takes time.
Service based development on the other hand isn’t about perfection – there you’re presented with problems, you solve them as fast as you can, and you carry on. Some people are eager to make the switch from product-based to service-based development because the work is more dynamic. Others want to focus on one thing – no one can say one is better than the other, it’s a matter of a personal choice.
It’s a no brainer. You always go with new technologies because the older ones will become obsolete sooner. New technologies give way to use modern solutions for modern problems.
These days, I’m looking into cloud technologies and providers, both private and public (GCP, AWS, Azure). I find their way of problem-solving interesting, and there is an added value in how easily they allow you to create an architecture for a solution. You can spin-up a complicated setup really fast - messaging, queuing, dynamic infrastructure, automatic scaling, you name it. Every one of those cloud providers will get you there, but they all use slightly different philosophy. There is no silver bullet, you have to map problems you’re trying to solve to the most optimal provider. It’s no longer a question whether the cloud will become primary destination for developing and running solutions, it’s just a matter of time.
What we could do is prepare ourselves to make the best pick when designing solutions, as all of the vendors are betting on vendor lock-in – once you’re in, you’re probably never getting out, or be switching to another one. Just to mention that also Cloud can be more expensive than in-house solutions - you must consume it right to make your money worth it.
On the other hand, I believe AI will be applied more and more in the future. The question is how the educational systems will respond to these changes because these are very different people profiles at demand. You will need the persons with talent for understanding data, as well as programming. It is a field which will be more prominent in the future, and the lack of it can already be seen in the job ads, as well as paychecks offered.
I have noticed the trend when it comes to the lack of interest in personal development in young engineers. They often do the bare minimum and view everything else as overtime, or “not-strictly-needed", instead of an opportunity. I cannot stress enough that growth is achieved on tasks which are outside of your comfort zone. Do your task, and then think about how you could do it better, then do it better. This practice would make you stand out and become a better engineer over time. You’re not improving yourself to suit the employer, you improve yourself for your own sake.
It is important to find yourself within an environment which lets you develop and try new things out. My advice is: If you wish to grow, do things which you haven’t done so far, that’s how your brain learns, that’s how you develop.
The other thing, which is often forgotten, is that developing your soft-skills is equally important as technical skills – what good is your technical knowledge if you can’t function as a team member? Considerable amount of time in team is spent in doing reviews, helping people out or seeking help from others, etc. All of these must not be neglected if you want to develop yourself as an engineer.
We want to make a series of challenges where the employees will perform tasks to help them get out of their comfort zone.
We have several developers that are working on a platform where people will be encouraged to take initiative and learn something new through personal and group challenges. That way, we allow for personal growth and experience exchange through short presentations and teamwork. This is just a teaser; I don’t want to reveal too much. The key is for the employees to feel accomplishment through the process of self-development.
I believe Zühlke is the right place for this because people here always look for that extra skill, they are all about constant improvement and getting better, all the while having fun and enjoying the process.
Veljko Zrnic is .NET Lead Engineer and since May 2018 at Zühlke. He is BSc in Computer Engineering. His main area of expertise includes working in .NET, databases, and all things that come with software engineering. He worked in many domains, including government sector, banking and health. His passion is delivering efficient solutions with most optimal end-users experience.
