One Year At Tix!

When I joined Tix on the 16th of August 2021, I wondered what lay ahead for me. What would I learn? Would it be impactful? Is this the best choice for my career? I was thinking about all the new algorithms, patterns, and complex systems I would learn and build but my time at Tix has taught me more important things an engineer needs and I would love to share them.

Communication is important, invest in mastering it. You see, a company is a confluence of cultures. You would be working with people from different backgrounds, disciplines, and experiences so not everyone will work in a way that is familiar to you. And of course, when there are multiple cultures in a place there is bound to be a clash, in such cases, communication is the best way forward. One of my favorite culture clashes is between the engineering team and the product team. Engineers tend to go with a "Pay Me Later" approach to software engineering. We are invested in our design patterns, Test Driven Development, SOLID principles, and database normalization. Many of these means slower development that prevents much more maintenance work in the future. This often comes in conflict with the product team's "Pay Me Now" approach to things. And it makes sense because business is unpredictable and user behavior changes rapidly, so for the product team, shipping a working product now is more important than headaches in the future. This can often lead to frustration but from my time at Tix, I have come to find that simply communicating things helps to go a long way. Product/Business do not understand why engineering has to do all these things that don't seem to translate to a feature so it's important that engineers clearly communicate the trade-offs to the product team so they can prioritize accordingly.

A company is a confluence of cultures. When there are many cultures there is bound to be a clash, communication is the best way forward

The product matters a lot. Tix has an awesome culture of ensuring we are building seamless products that make our users happy. But while we work, there are times when our wants can come in conflict with the needs of the product. As engineers, we want to develop our skills rapidly, implement new shiny things we have learned, thug it out with bugs and issues in the system to feel good about our abilities, and write the cleanest of codes that don't need refactoring but these can come in conflict with the product. Yes, it's great to be a self-sufficient and talented engineer but sometimes asking a teammate for help will cut down on hours of work that will help ship the product faster. Yes, it's great to write clean maintainable code that never needs to be refactored but when the product needs it, we must go and take out that shiny implementation of a factory pattern that we might have spent hours to implement. Many times product requirements can change rapidly due to user demands and you would have to do some work all over again — get comfortable with redoing work. In all you do and the decisions you make, think about the product first. The good thing about focusing on product is that eventually it develops you into a more capable engineer. While working on the Box Office feature for Tix I had to do a lot of refactors to enable the feature to be seamless. I had to redo and revisit code multiple times. This helped me improve in my ability to read and understand other people's code, improve my algorithmic skills, and understand better how certain patterns fit in certain places. If you do good to the product, the product will do good to your skills.

The Product comes first, build with users in mind, and be comfortable with redoing work

Systems over people. When I joined Tix I was impressed by the systems put in place that guide how we work. When things go wrong, the focus is less on "who did this?" and more on "how did we miss this in our workflow?". We prioritize optimizing our flows to lead to fewer faults in the future. As much as everyone needs to be accountable for the work they do, the focus should primarily be on improving the system. Of course, this will also need to be sustained by ownership from you. Do work that needs to be done and do it on time. Don't leave workflow optimization to your manager. See some lapse in how the team works? Tell the team. Not comfortable with how a teammate gets work done? Communicate your suggestions with them. No one comes perfect, we all learn. Systems should help culture out our weaknesses, build our strengths, and learn from other people's experiences.

Working systems over working people. No one comes perfect, we build on each other's experiences.

Above all else, in whatever you do — in your reviews, in your feedback, in your syncs, be kind. This seems easy because we assume we would always be in our happiest mood, always have a clear mind, and always have a full stomach when we work but that is not always the case. When you are frustrated from working on an elusive bug, when you're swamped with work, when you've had to skip breakfast, when your favorite team loses a game, as much as you can...

Be kind

It's been an awesome year working here and I am grateful to Folayemi Agusto , Shalom Ayidu , and Dami A. for this opportunity.