Learning of my Software Engineer Journey So Far
It’s been approximately two years since I have been working full-time now. During this period of time, I have learned a lot, failed a lot, broke a lot of systems, and built a lot of them. Here in this article, I would love to admit all my mistakes and their learnings, so people who are starting off, or in the industry can learn and prevent them. I’ll go into iteration from each of my mistakes along the way
Learn from the mistake of others. You can’t make them all yourself
— Eleanor Roosevelt
Action, without Plan
When I first started as a DevOps intern at Kuliza, I used to listen to every senior employee there, literally everything. I’d listen to one person and learn one thing, and then the next day listen to another employee and start learning something else. Had no sense of clarity or impact analysis of what doing any particular task meant to me. Although I was the top-performing intern, I ended up with no solid growth. Up until one day, my Director of Engineering called me up and asked me about what all I had learned in the last few months. I had a lot of terms, but nothing concrete. This got me thinking. So I started doing focused learning and decided I would end up doing only a few, but amazing things. Ultimately, I learned to write automation ansible scripts, deploy and manage Docker and Kubernetes clusters, know-how Load Balancing works, what to do when containers go down, and other cloud stuff. Although I left the place only after 6 months, the habit of doing focused learning has stayed with me still.
You are not smart enough as you think
I joined Ula.app as a Software Engineer ( Backend ) on August,20. I was doing good and was learning a lot of new things, working on a new tech stack, writing production-level code, working in a team, and henceforth. But an interesting or rather funny thing, happened one time, a ticket was assigned to me during sprint planning, I missed the grooming for the ticket but thought I understood what was written on the ticket and I would be able to pull it off. I worked well, took my sweet time and finished it, got the regression and functional testing was done but when I gave a UAT to my PM, he was shocked and told me that this is not what was the expectation, and then gave me the complete context again. The loss was of 4 days of engineering bandwidth. I apologized and said will fix it soon, so did I, but it turned out to be a great lesson, Always gain clarity of the task you are picking, it’s okay to ask 5 extra questions, schedule an extra meeting, initiate a new discussion or start a day late, but working on things which you don’t have clarity of, will always end up in failure. Fast forward today, I believe I ask the most questions, start the most threads just to know the significance of each line of code my team is writing
Non-Functional Requirements are not Required
This is quite a ubiquitous mistake I see early [ sometimes experienced ] developers do, and I am guilty of it too, building for solving the current problem at hand, resolving the ticket, without thinking for the future or the scale it can get. So I worked on a feature of restricting coupons to locations, I thought I’ll build the best of it, write the best code, release it without any bugs and was able to pull it off and it worked fine. But one fine morning, the operations team made the coupon eligible for all the locations except 2, the code I had written used to pull all of the data into the service layer and do computation on it [ purpose was to save DB Calls ], but loading millions of rows of data and then doing processing on it caused the NodeJs Service to go down frequently and customers weren’t able to place orders with coupons. Ultimately had to fix the query and segregate it into parts and get only the required data, causing intermittent but 4 hours of downtime to the Coupon engine. Fast forward to today, Everything I design or code, I always ask or think through myself, what all are the Non-Functional Requirements. Sometimes you won’t get it right and if you are not that might also mean your organization is growing fast. But if you are not thinking about it, then you are definitely wrong, I learned it the hard way, and you shouldn't.
Backward Compatibility, Is that even a thing?
Yes, when I first heard the term from my Lead Engineer, I was like what’s that, I heard of BackDated Options from Suite’s but didn’t seem relatable, and I was like might be something for Senior Engineers xD. Up until I f**ked up again. While working on a feature, I changed one API Contract, gave it to the Mobile Dev, got it integrated, and launched the feature. Then came a morning where Old app users were not able to see that feature and the app failed when it reached that particular page. The reason, is your over-smart friend ignored Backward Compatibility, so I got on a call with my lead engineer and fixed it. Backward compatibility is the smallest, but most ignored thing I see devs missing. But believe me, it can make you cry some morning. It won’t always be possible to make features backward compatible, but always keep it in your checklist before releasing a feature.
Clean Code, Nah I’ll Refactor It Later
I was always a fan of doing things fast [ i struggle with patience a lot in a lot of tasks xD ]. I always thought if I do it fast and get it launched before anyone thought I would be the best employee [ niche things you think when starting out ]. I was given the task of setting up the microservice in Spring Boot when launching the Fintech Charter. I was all excited, but as I had spent a lot of time understanding even what Fintech was, it was already too late. So came the “Hasty Monster”, I started writing code for the first phase, since it was hasty, I wrote everything justifying the timeline. I got it reviewed in hurry and sometimes from the people having no context [ since it was a new project only one engineer knew about the complete context ]. All this fired back six months later when the code got complex and new devs came. I had to spend a sprint refactoring it and getting everything in place. Clean Code by Robert C Martin + My new teammates who reviewed my PR helped a lot in improving my code quality. Though I am improving still, when I look back to that time, I just laugh at myself and my code xD.
Writing or Doing Tests, Nah That’s Not My Job
Ohh boy, this is something a lot of my co-employees who have worked with me or reviewed my PR will agree to, I used to raise so many fix PRs to dev and staging [ and even to Production ]. Unit tests were something I least cared about and dev testing the basic scenarios was the end of the story. I don’t have a story for this, because there are many such times I have done this, and you only learn the importance of it once you get Production Bugs. Getting this habit took the maximum amount of time, as I already told you I am a Hasty Monster, I love doing things fast. But with regression bugs, on-calls, sonar cloud inclusion in our code process, and strict reviewers who didn’t allow code to be merged up until a certain code coverage limit passed and when I consistently started writing Unit Tests and doing Dev Testing, I got into this habit and always try to cover all the scenarios, using EXPLAIN before adding each query and many such things before raising a PR. You won’t believe but Unit Test seems like a pain, but helps in two things, help save a lot of potential bugs + give you a sense of safety that code won’t break in certain scenarios. You trust your code even more once you have tested it yourself and shielded it with Unit Tests. I also used to maintain a sheet of test cases for each of the big initiatives and can refer to them whenever I make changes to an existing codebase.
By now you might think this is a story of a Failed Developer, but fortunately/unfortunately I am hustling as a Senior Software Engineer at Ula, working on some amazing Fintech opportunities. A very solid reason being I believe for me growing is not repeating the same mistakes, mishaps may happen, I sometimes still commit some of the above mistakes, but my subconscious mind makes sure that they don’t take place. If you are not making mistakes, that means you are in your comfort zone (the worst place to be I assure you). I am still learning and a lot of still learning is still left to do, but I believe certain above points will help you become a better software engineer yourself.
Want to Connect
Twitter: https://twitter.com/Ajitesh02
Linkedin: https://www.linkedin.com/in/ajitesh-002/
