Recently, we had our first Hackathon at ToolTime. It was really exciting and gave birth to a large number of ideas that can potentially help ToolTime grow even more. But an idea is worth nothing without the implementation. And as a Software Engineer I was part of that implementation.
So, it's Wednesday noon and I start, together with my colleague Maja, writing some code on the backend and later on the frontend. A couple of hours later we realised we were applying proper architecture, we were even writing tests, for a Hackathon. And this was yet another moment that made me realise how much a Software Engineer can grow at ToolTime.
Being open minded and compromise
Everybody is biased. We have different experiences and ways of working. We have worked in different environments and projects. Bringing people together in order to work on a product is not easy.
However, at ToolTime we see our personal success through the team's success. That's why we try our best to be inclusive and listen to what each one of us has to say. Everybody has something to contribute.
Whenever we have conflicting opinions we come to a conclusion that is in the best interest of the team. This can mean that we create a mix of what was proposed or we choose only one while at the same time we encourage people to keep being innovative and keep trying to contribute.
Good code architecture leads to a better product
Ok, we all know that. Books have been written about it and design patterns have been created. But it's different to have it as part of your every day life. Many teams talk about architecture in theory and as a goal but at ToolTime it is our compass.
Everything revolves around it. Every little decision we make is part of a living organism that needs a strategic approach in order to maintain it and help it grow the best way.
A great example is described by my colleague Yves in this post.
But how to support an architecture?
Here comes the tricky but exciting part.
Use the architecture that makes sense, not what the community wants
Most of the time technologies or tools with a big audience (e.g. React) have what we call common or best practices. These usually make sense and they are the result of a lot of trial and error. The problem is that best practices are proposed by a handful of people. Some teams tried something, worked for them and demo it to the community. Eventually, software engineers around the world start following and at the end it becomes a trend.
However, we often ignore that different teams and projects have different problems to solve. For example, one of the things we wanted to improve in our web application was the big number of bugs we had a year ago. Therefore, our whole strategy was focused to eliminate this issue. And that's why we aimed for code isolation instead of code (React components) reusability.
Let people talk
First of all, we educate our team members about the need of following code architectures and agreed guidelines. At the end of the day, if a team doesn't buy in a concept, then what's the point of it.
We never take architectural decisions without bringing them to the table for discussion. Everyone has time and space to propose, experiment and demo an idea. This usually happens via our three Forums (Frontend, Backend, Mobile) where we suggest topics to discuss. There we can express our ideas and the team can decide whether to make it part of our guidelines or not. Alignment is gold for ToolTime.
I always look forward to the next Forum to see what is the next step towards our engineering goals.
Tooling
Another essential part is tooling. Since architecture defines how code should be split and distributed around the app, patterns start to arise. And patterns mean standardisation.
With tooling we can apply the patterns our team defines and secure faster development together with alignment.
Apart from common tools like linters we have created our code generators that create all the necessary files pre-filled with code for:
- Creating models on the Frontend
- Creating React components accompanied with tests and hooks
- Creating microservices
Experimentation and staying curious
At ToolTime we have a variety of domains and languages we use:
- Frontend (TypeScript, React, Redux, GraphQL)
- Backend (Kotlin, PostgreSQL)
- Mobile (React Native, Redux, GraphQL)
- Infrastructure (AWS, Terraform, Kubernetes, GitOps)
Even though usually people have different levels of skills in different domains, we highly encourage our team members to have a hands-on experience in any of the mentioned areas.
Maybe you will be just like me, that I mainly copy paste code on the Backend but still, seeing a different approach and technologies can only be a benefit.
Being pragmatic
Here we always try to pick the most balanced solution to a problem. Working on software doesn't only involve Software Engineers. Product Managers, Designers, Customer Success are also part of the team and have their expectations as well. Hence, coding having in mind only how to fulfil your own technical goals doesn't sound fair. Being pragmatic is an essential part of our job and at ToolTime we value it highly.
This means we aim for an implementation that follows our software guidelines but avoids over-engineering and pre-optimisation.
But how all the above made me a better Software Engineer?
All the above are things that most of us have thought about one way or another. The same applies to myself.
The difference is that at ToolTime they really became part of my core mindset. I used to try to convince myself to apply them. Now, they just come naturally and seem really obvious and reasonable.
That's the reason why following code architecture and writing tests lead to a faster implementation for the Hackathon rather than writing something the hacky way.
And now here I am, being so passionate about it that I want to share it with you.
