It’s been just over a year of working at Airlift Technologies, and at my 1st anniversary I wanted to reflect on some of the takeaways I have had while working here. I have had the unique opportunity to join a hyper-local product company at a time when its growth trajectory was at a tangential point. Switching to a new vertical and building an in-house product from scratch at express speed was simply a transformative experience; one that has challenged my pre-existing notions about my role and really instilled within me what being a software engineer entails at an emerging product company.
Engineering is essentially a communications problem
I view software engineering as the discipline of translating business requirements into software. We are simply the bridge between the product team and the end user themselves. While this may be a reductionist way to look at things, it helps us focus on the overarching goals which is understanding what our product team wants and given the tools at our disposal how we can achieve those goals. And anything that helps in achieving this, or speed it up is essentially engineering.
One of the constant features of an engineering role is communication. This communication can be both internal and external. Code is never developed in isolation and there are many other moving parts within a team. For example code before reaching production needs to be tested or QA’ed which requires communication with other stakeholders to explain how the code will behave with those set of requirements. Sometimes you will end up working with frontend and device developers to negotiate on API Contracts and require a shared common understanding of how our systems work. If communication systems are transparent, they no longer become just a black box but its apparent merits and bottlenecks become obvious to everyone. ٓAnd for that it is crucial for a developer to communicate their understanding to other people beforehand. I have often found myself fixing bugs simply because of an incorrect understanding I had. If every stakeholder is on the same page then that makes the job much easier.
Similarly, there are also external communication stakeholders that need to be accounted for, for example once features are built, it needs to be signed-off and forwarded to the product team for rollouts. And then, overseeing all of this is done by your upward communication channels through your line managers whom you relay information regarding potential delays or any red flags amongst other things. With all of these communication channels processing in parallel, I believe this is the reason why engineering is still a very labor-intensive role simply because of the immense amount of human-to-human communication we do, otherwise if engineers simply had to ‘write code’ then there is no one better suited than the computer itself!
It means to get comfortable in rewriting code
One of the things I always find myself getting very defensive about is the code I check in. I fundamentally believe as we write code, and as it grows old and stays, we almost grow a sense of attachment to it.
If somebody asks us to rewrite our code, we would flinch and hesitate because it almost feels like destroying something which you just built, only to tear it back down again. Funnily, this is why we prefer commenting out lines of code rather than pressing the delete key. We feel the code needs to be present, even with advanced versioning control systems in place we still feel the code to be there and would preserve our code as much as possible.
Now, yes some code is legacy and is truly tried and tested and unless there is a very pertinent need to change it, legacy should not be changed. But generally speaking, with the context of a technology company, code needs to be updated and refreshed periodically to keep pace with the changing requirements of the business and tech in general.
And I believe if there’s anything fickle, it’s software. The only thing constant in it is change itself. New requirements come up. Things need to be scrapped. Code grows slow. So we should all be prepared to rewrite v2s and v3s and rewrite our code to keep it with parity to the business. And this is fundamentally true at startup spaces who generally operate at fast velocity with the MVP mindset. Build the product fast, launch early. See what works, and swap out with what doesn’t. Rinse and repeat enough times and you have your finished product.
Now contrast this with the traditional approach which tries to make a fool-proof exhaustive application beforehand which may be the desired course of action to take especially for very critical software , but if you are working in a fast-moving market, achieving early presence is more important than other considerations
In addition to that, I also think we really need to debunk the myth of the perfect algorithm or codebase; needlessly obsessing of having a perfect system is the wrong way to start, since many things will evolve with time and will change with nature’s due course, and striving for completing perfection in the first go is unrealistic in my opinion.
Always keep the end user in mind
While this may seem pretty obvious at first glance, it is one of the things that I find myself losing focus on much too often. Sometimes we are too tunnel-visioned in our focus of delivering software; this developer-mindset makes us lose track of the big picture. There is an innate tendency to start focusing on things that might be too trivial and end up over-optimising on things seemingly important to us. Because no matter how beautifully succinct your lines of code are , or how optimised that function is, if that code is not helping the organisation in achieving its goals , it is a tech debt on our end.
But that is no excuse to write bad code, it just means to strike the right balance, and always try to step into the end-user’s shoes once in a while to give yourself a fresh perspective.
And doing this at a customer-centric product company is super important, because you are not simply delivering a set of requirements, you are associated with the business, and have a high degree of ownership with the product and therefore the customer should always be on the top of our minds.
And believe me if you do it correctly, it becomes extremely gratifying for a developer, especially after seeing your things go live and see them being used by thousands of people nationwide. This is why it is not simply enough for our code to be functionally correct but also we should be developing user-friendly and user-first features in service of this ideology as well.
These doodles are made using a wonderful tool I found online Try it out here