From Rookie to Hero: Matijs' Webhooks Service Success.
In the fast-paced world of software development, companies are constantly on the lookout for new talent that can contribute to their success, Frontliners is no different. One such rising star in our organization is Matijs, a relatively new developer (who graduated in 2019) who joined our team a little over a year ago. Matijs has since taken the reins of the "webhooks service", a crucial component responsible for communication with third-party applications. In this blog, we'll take a closer look at Matijs' journey, highlighting how his fresh perspective and unwavering dedication enabled him to deliver a core functionality that has had a significant impact on our operations. We will also be diving a little deeper into Matijs' mind by reversing roles and asking him some questions in an inspiring, in-depth, interview featuring some architectural drawings and even some code!
The journey begins
Matijs started his journey with our company just over a year ago, fresh out of his previous job and brimming with enthusiasm. His background in computer science was solid, and his attitude was amazing but he did tell us during the interview that he had struggled with some advanced principles in his previous job that just so happen to form the core of Frontliners' software architecture. Nevertheless, his passion for software development was evident from the start, and he was eager to learn to overcome his past struggles.
With that we had found our newest diamond in the rough, our new shining star, we just had to polish him a bit and let him shine!
Embracing the learning curve
As previously mentioned Matijs knew, from the very start, that he didn't quite grasp some of the, admittedly hard, distributed software architecture used at Frontliners. Instead of being daunted by this steep learning curve Matijs threw himself into the challenge head first.
At Frontliners, we offer new employees a large "wiki" page where they can read up on the basics of our way of working and software architecture and Matijs made good use of that by combing through and experimenting with what he found.
Shortly after, presumably when he had enough of reading, Matijs started asking his peers some questions...
Asking questions fearlessly
Matijs has a remarkable talent for asking the right questions at the right time. Now, whether this is due to Matijs' ability to form the perfect questions or because one of Matijs' main strategies is to just burst-fire these questions onto the right person after finding said person is another matter entirely.
It didn't matter though... Whether it was during team meetings, one-on-one discussions, or in the midst of a challenging coding session, Matijs wasn't hesitant to seek guidance and clarification. His questions were thoughtful, revealing a deep understanding of the subject matter, and often well-prepared with code examples and relevant follow-up questions.
What stood out most was not just his curiosity but also his ability to turn these inquiries into a valuable learning experience for himself, which he then promptly used to ask more questions.
Regardless, it was clear that Matijs was growing rapidly and was able to quickly progress through the principles he had previously experienced to be difficult.
The early days, working in his team but yearning for a little extra
Within his team, Matijs was undoubtedly a valuable contributor, consistently exceeding expectations in his responsibilities. His dedication, passion, and ability to work harmoniously with the team were well-recognized. As he continued to shine in his role, it became evident that he had the potential, and desire, to do something a little more significant.
You see, at Frontliners we have generic "company-wide" development components and services, known as "architecture items", that are much more scrutinized than any other piece of development work. These components and services are meant to be used by multiple teams and, when done incorrectly, can be a massive pain in the journey of other teams.
In theory, all developers are free to take up or lead one of the components or services but in practice, we usually see developers who are quite comfortable with both their skill and their roles in the company pick up the leadership role of the larger ones. This is to be expected though, because being heavily scrutinized due to these services' importance also leads to more feedback.
Not for Matijs though, with a little bit of encouragement from the Frontliners' architects, Matijs decided to take up the leadership role of one of these larger architecture items.
Taking on the Webhooks Service
The webhooks service is a critical component in our event-driven landscape. This service is responsible for managing (push) communication to third-party applications, ensuring that data is delivered accurately and in near real-time. Setting up this service well will give consumers of our services much more flexibility whilst also leading them away from endlessly querying the same data over and over again. Setting this service up wrong though would surely lead to a lot of critical feedback from developers (and trust us, we know how critical we can be).
The challenge was not just about building a working system, but also optimizing it for scalability and reliability. Besides all the technical challenges Matijs also had to take point (and responsibility) on the entire project development cycle. This includes a fair few things:
Help with gathering requirements from stakeholders
Help with Drafting, proposing, and seeking approval for a solution design
Drafting, proposing, and seeking approval for a Software Architecture Document
Implementing, or overseeing the implementation of, the service.
Matijs has always been a part of these things for both his own team as well as other "architecture" items but has never been in the lead of them, usually deferring that task to his team's lead developer whilst he helped scrutinize the solutions.
Interview with Matijs
“What motivated you to join the company as a relatively new developer with a knowledge gap on some of the core architecture used at Frontliners?”
What motivated me the most were the opportunities for growth that Frontliners offers me. Before joining Frontliners my main goal has always been to "eventually" become a software architect. I even mentioned it in my interview. Frontliners gave me the impression that I would be able to grow towards my destination and would be supported along the way.
There were, of course, other things that attracted me to Frontliners. Let's run through a few:
The overall mindset and principles around the high quality of code is something I really liked.
You might even call it a relentless pursuit of quality in order to deliver the best product possible.
Apart from that I also liked the development stack. It is a stack that empowers the developers to deliver a scalable and reliable product in a relatively easy way. I did have some experience with the stack from prior jobs but there was always a fairly large gap in knowledge about the overall stack & architecture. It was immediately obvious to me that Frontliners has several highly intelligent and experienced people who know the ins and outs of this stack. This awoke my hunger for this knowledge and gave me lots of motivation to get started.
“How did you envision your role in the team when you started? ”
I knew of my own lack of knowledge surrounding not only the infrastructure but code standards (e.g. Domain Driven Design), which meant my goal was to start from the bottom as a developer and slowly but surely grow towards the architect role by gathering more knowledge and experience.
“Can you share some of the specific challenges you encountered when you initially began working on the webhooks service, and how did you approach overcoming them?”
The first challenge faced was, unsurprisingly, a difference in definition. Frontliners and I had a different interpretation of what "Technical Design" means. When people at Frontliners talk about a technical design they talk about the Software Architecture Document (SAD), whereas I was thinking of a different technical document which wound up restricting development because it was so detailed. Essentially losing out on the expertise of the developers.
My technical design went way further than anticipated. I even added my own, new, requirements such as: "Supporting the possibility of other mediums to send messages". This all led to a very generic implementation which supported way too much and was more complicated than desired.
I did not know that at the time though, so I went ahead and continued.
I began to realize that in order to create a working `class diagram` without coding the actual class structure was going to be difficult. This led to me creating proof of concept (below) whilst still in the design phases. The more I worked on it the more I saw limitations of my approach. Luckily this all sent me thinking so I consulted some colleagues with a little more experience.
The first step I took was to ask for examples, I started to discuss my approach with others who had previously undertaken such tasks at Frontliners and quickly realized that our definitions of "Technical design" were misaligned.
You can see the notes I took during that meeting below, it's full of interesting highlights and discoveries.
The next step was to adjust something. Now that I knew they were only expecting a Software Architecture Document I told my lead about it and started to reduce the complexity of my designs with the guidelines set by the internal Software Architecture Document guidelines.
The thing I had to do now was wait. Wait for my development team to put my ideas, my rough sketches, into something that would actually work for me. This was both frustrating and amazing at the same time. We delivered something great, but made some choices that I hadn't foreseen and maybe would've done differently if we stuck to the old plan.
Now that my team has delivered and I have done all my reviews, knowledge transfer, and product delivery I could only think of one more challenge: feedback.
Though we made a great service that is now up and running successfully the road towards it wasn't as smooth as I'd have liked. I had several feedback sessions with people from all different areas: architects & leads, developers, managers,
All of them provided me with feedback and that feedback will allow me to grow further in my journey towards becoming a software architect.
“Your dedication to asking questions and preparing technical examples is inspiring. Can you share a specific instance where asking questions played a crucial role in solving a problem or improving a process?”
A concrete example would be the various discussions around Domain Driven Design. We've had many new people join Frontliners. Since there are a lot of articles explaining DDD online people often have a slightly different interpretation about some of the more fine-grained details. In this case, my lead developer had explained a slightly different interpretation to me than I got from the architects which was throwing me for a loop. By asking the right questions about the concepts I was able to shine a light on these different interpretations and make sense of the situation.
This also demonstrates one of the best things about me asking all of these questions, there are a lot of people involved and they might have different interpretations at first. By asking the questions I can make sure everyone is at least aligned on the definitions.
“Can you share some insights into the impact of the webhooks service on the company’s operations and customer experience?”
The webhook service itself is not just some piece of software that adds some value for our customers. It is a piece of software that enables the success of other squads. By creating and publishing this service we make it possible for other squads to easily integrate third-party webhooks without having to change their domains.
In reality, the possibilities are almost endless, our customers, our clients, can consume the API in near-real time themselves as well and build whatever they want on top of it too! How exciting!
So as a dev, I'm proud to not just deliver something that adds value for the customer but to deliver something that offers value and will be used by the other squads to offer even more value op top of also allowing a third party provider to build additional software based on the data gotten from Transfusion by webhooks!
“Looking ahead, what are your aspirations and goals as a developer? How do you plan to continue your journey of growth and contribution within the company?”
As previously mentioned, my end goal is to become a software architect.
I recognize this is a long journey, but I'm willing to take it on. I want to deliver an entire structure/document/guidelines which will lead to expandable, scalable, reliable software that helps the customer with their needs.
Frontliners offers me a lot of opportunities to grow into the role of architect eventually, be it with great advice or with challenging architecture items that push my boundaries like this webhook service item
Conclusion
Matijs' journey from a new developer to a key contributor is an inspiring tale of dedication and collaboration. His ability to take on a complex project, learn rapidly, and deliver core functionality in a relatively short time is a testament to the potential that new talent can bring to an organization. In the ever-evolving world of software development, it's not always about experience; it's about the passion to learn, grow, and make a difference. Matijs has certainly shown that the future is bright for those willing to seize opportunities and take on challenges with determination.
