Yet Another Extra Step for becoming a better Software Engineer

A photo of ENIAC: The first programmable, electronic, general-purpose digital computer. (credit: Wikipedia)

Before we begin — Disclaimer: This article contains many generalizations but I am not talking about you, of course, this is about other people. You are awesome.

The journey of software development is a mighty long path where lots have contributed till now. It all started with a dust and fog cloud called ENIAC. One day, it decides to explode somehow, causes a big bang and we got quad-core particles in return, etc. you know the drill. In the end, we got our world of software and the “ITmosphere” that we breathe in.

Joking aside, as software engineers, the journey we follow is pretty much the same at certain points. With some motive, we start learning a programming language. We get more excited as we produce working prototypes. Meanwhile, we meet with fellow engineers. From them and general communication channels, we hear exciting new developments in our area, start learning new frameworks, try out fancy libraries, experiment with new cool ultra-fast programming languages, etc. Then we repeat this cycle with the newly learned language.

The first thing about being a good software engineer is definitely being a little bit tech-savvy. That is inevitable. You need to read and learn constantly, to keep your knowledge up-to-date, alongside improving your soft skills. Becoming a better engineer in the software world needs all of those, and then some. This is the part that I want to shoot my humble suggestions into the air.

Because almost every colleague of yours does the same, so which one of you will be the next manager/director/leader/supreme emperor? What is the extra step that fewer people follow, that people are scared to go for, that will make you different or unique if you succeed? Assuming being different or unique is a good thing (this is me being politically correct), let’s dig in deeper.

For those of you who are looking for a TL;DR in here, like I did in my previous articles, you can stop looking because there is none. I take this subject very seriously so stop smiling.

When you ask fellow engineers the question “How is your product working?”, you will mostly get technical insights about their applications. Which languages they used when coding it, how many cloud servers are running on what platform etc. Furthermore, when you ask “Do you know the reasoning behind X logic?”, you will probably not get a decent answer. Because most of us have very little info about our own product’s business logic. They may even answer the question as “I don’t know, another department is looking into it but enough about that! Did you know that we are using this new super cool framework? It is awesome you should try that out!”. This represents a lack of ownership or involvement. This is the invisible line between being decent and awesome. And this is where I want to point my finger towards. Again, to be politically correct, being decent is perfectly fine, but we are on a quest for that extra step, so decent is not enough for us.

Let’s consider a fictional story here.

You are requested to build a simple application where you will be storing the temperature values of a certain location and will be giving the exact temperature value for a requested time range. This is what is written on the ticket, that is it.

Common Path: You immediately started thinking about how/where to store this data in which format. Maybe you even started drawing an Entity Relationship Diagram (ERD) for the database structure. I mean come on, creating diagrams is awesome.

This is what you came up with:

And this is how you fetch the data (to get e.g. 23.3°C for a given instant 2021–02–07 17:15:38):

SELECT
  temp, units.symbol
FROM
  temperatures
JOIN
  units
ON
  units.id = unit_id
WHERE
  start < GIVEN_DATE()
AND
  GIVEN_DATE() < end

Extra Step: You asked the departments that you will be working with about what kind of environment/tools/devices they use to get and insert their data in there. Then you learn, it is a simple thermometer with the ability to do HTTP requests at a random frequency. You also learn that this data will only be used for display purposes in America and Europa so it will never be used as a source for any other project. Based on what you have learned, you decide to design your app based on the given business logic.

This is what you came up with:

And this is how you fetch the data (to get e.g. 23.3°C for a given instant 2021–02–07 17:15:38):

SELECT
  temp
FROM
  america_temps
WHERE
  timestamp < GIVENDATE()
ORDER BY
  timestamp
LIMIT 1

Benefits:

1. Instead of converting simple data into a structured one, you designed your app based on what is given. Because otherwise, it would lead to over-engineering. You couldn’t know this if you didn’t take the longer path and talk with your stakeholders.
2. Instead of creating multiple tables with multiple columns, one-to-many relationships, indexes, etc., you just used two columns in one table. Yes, you lost your chance to make a generic app that can be improved in the future, but that was not asked. Therefore there is no need to go for uber complex structure when it is not needed. You can save up your energy and time for another feature that is worth doing.
3. Even though you went for simplicity and did not create any entity relationships for temperature units, you are still flexible enough to cover a change e.g. switching from Celsius to Fahrenheit system. When choosing simplicity over complexity, do not forget to base your structure in a flexible position otherwise simplicity can be your enemy as well.
4. In total, you practically saved half of the workload on the data provider team, your developers, DB admins, QA engineers. Everyone is happy.

Just with a little bit of communication, you saved up a lot of time and in the end, nobody will remember how awesome your app was. But they will remember how you took the initiative and went the extra step by aligning first instead of producing blindly on what is given initially.

Of course, this was a fictional and absurd example, but it felt real, right? Because we all have been there at some point or will be. However, be careful about going a bit far and crossing some boundaries.

People appreciate when you take an interest in what they do, brainstorming together for a better result. They do not like when being told how they should do their job. There is a difference between those two.

So, when to go for that extra step?

For me, the measure is simple. If my gut tells me a process can be done differently which would be more beneficial or performant, I start digging a bit deeper. After learning how a request came to its final state, you may see more easily if they missed a step or made it over-complicated.

A small example. You are working for an e-commerce company. You list products from stores that people can purchase online.

There is this feature request for your team coming from the Data Analysis team. They want to know how much of our traffic goes to closed stores or out-of-stock products. So they want you to send an open/closed event on every store page view by customers and in-stock/out-of-stock event on every product view etc.

At first sight, it feels logical. You will just check the store’s opening status and send the data. Same for the product, just checking the stock should be enough. Designs are made, components are there. The product team is really excited about this implementation. Everybody thinks this will improve our analysis of user experiences, etc.

Your gut tells you to align with the team responsible for the user interface, just in case. Because you are not sure if it is possible to ever reach those pages. So you start asking some questions to the stakeholders kindly. It turns out, the base scenario is logically invalid which makes the feature redundant because both closed stores and out-of-stock products are excluded from listings. Therefore, a customer can never view those.

You saved your precious time and energy again. Maybe you should think about opening up a savings account for all these savings. Get it? Saving…

We mentioned trusting your gut on a specific product but we missed a very important step. You should develop that gut instinct first, duh. If possible, the easiest way to get a lot of sense about your product is becoming a customer of your own product.

I am lucky in this aspect because I am working for a company for which I am a loyal customer. Every time I order food online, I have the chance to experience the journey of our customers. While doing that, try to avoid just following happy paths. Even though just using your product can be considered an extra step, there is also a further one. Have you tried using your web app with the browser on your smart TV? Or your Xbox, or your PS5?

Adding more steps

Have you tried using your competitors’ products? Just try once in a while. Check similar products which are not your main competitors, may be operating in different countries. As a software engineer, you may think this is not in your work scope. You may be right but think about suggesting the next cool new feature to your product just because you have seen it somewhere else. By spending 10 minutes from your free time to check some stuff, you shortened your next raise/promotion 5 months maybe, you never know.

I can go on and on about how and when to take initiatives, being more proactive, etc., etc. but I believe it is not my place to talk about those. However, that is pretty much what I tried to explain in here so I actually already talked about them, lol. Sorry, not sorry.

I assumed a lot in this article so if you have any counterarguments or contradicting assumptions please let me hear them so that I can tell you where you are wrong, kidding. These are my humble opinions as a fellow engineer with no expertise in telling people what to do and what to avoid. I just wanted to share a positively resulted approach to my individual story for those who could benefit from it.

I hope you enjoyed it so far.

Finally, some fellow engineers talking about the same subject for further reading:

• “The importance of business knowledge for developers” by Morgan Faget
• “Skills a developer must have for successful product development” by Shahid Mansuri
• “Why Software Engineers Should Engage in Product Development” by Krzysztof Czernek

Just Eat Takeaway.com is hiring! Click here to learn more about our job opportunities!