My Journey in the IT industry- Part 2
In case you haven’t read it already, please read part 1 of this series
My experience with Sahaj
There are a lot of common beliefs with developers on whether to work with a product company or a services company. I had a few of them but I was driven more from a learning perspective and it didn’t really matter to me whether it was a Product or a Services company. In my previous blog, I discussed a few aspects that enabled me to get into a product company and how my learning curve was really high. In the last part of this blog, I will discuss my experiences, working in a services company.
Breadth of experience
Coming out of my product company stint, all I knew was Java. Getting into my first project at Sahaj was an exhilarating experience.
I had to maintain a list of technologies that I had to learn in order to start working on that project. Some of them in the list were Groovy, Spring Boot, Jenkins, Docker, Cucumber, Spock, etc. I wasn’t aware of unit testing or integration testing and developers are supposed to write that. But all I had to do in that project was to modify a JSON response which was still interesting because of the exposure to the different technologies, critically of the engineering rigor I experienced for the first time. The project lasted for about two months.
I got into my second project within two weeks. This time I had to develop from scratch which was one of the most rewarding experiences. I created six microservices and implemented a custom chat solution using MongooseIM which was based on Erlang. We used Kafka as a messaging queue among them. The tech stack consisted of Java, Spring Boot, Kafka, MongoDB, MySQL, Jenkins, Kubernetes, and AWS. This project lasted for six months.
In the third project, I was introduced to data engineering which was a whole new realm of technologies and it lasted around one year. This project was closest to a rigorously engineered project and I got into the middle of development. In this project, we used Apache Airflow to orchestrate the pipelines and set of microservices to represent the business entities and Apache Spark to carry out the Big Data jobs. We had our microservices in different combinations like Java and Spring boot, Kotlin and Spring Boot, and Micronaut and Kotlin. We had spark jobs in Java, Scala, and Python. All our services are deployed in AWS and we used terraform for deployment.
My learnings — a summary
If I looked back into the list of technologies used and I had to learn, it included Scala, Python, Kotlin, Apache Spark, Apache Airflow, AWS EMR, S3, Micronaut, Terraform, etc. I might have missed one or two. This will count as one of the best experiences to understand the entire lifecycle from end to end.
After a year, I was assigned to another project. This time, I was a more mature developer than I was in the past. Rather than starting to code once we get the specs, I spent more time thinking about code design and maintenance. There wasn’t anything new in this project except the problem we are solving. Every day I’m trying to apply whatever I’ve learned in the previous three projects and provide a more refined solution.
Going back to my early days in the career to where I am now, I can see how my approach to solving problems has changed. I still bank on my knowledge of Algorithms, DS, and Programming. But I have embraced wholeheartedly the use of XP practices like TDD and CI/CD. Working directly with customers, we also get an idea of how the systems, services we develop are used along with their constraints of operation. This has a big impact on how we look at the designs of our systems.
The Sahaj difference
One of the critical differences working at Sahaj is that you work directly with customers. This aspect of seeing things end to end and going the full length from having a sense of the customer's requirements, their environment, and constraints to the entire deployment has made a big difference in my learning.
I am learning and will continue to do so as the scale of our work with our customers undergoes a massive change. I will cover other aspects such as culture and the open work environment in a different blog.
Hopes for the future
Whatever I’ve mentioned above happened between May 2019 — Present. Each project has introduced me to a new environment, either the problem or tech stack or the architectural patterns were different. Am I an expert in them now? Absolutely not, but trying to become one. I realized the myth that if you join a service company that you can’t learn is completely false. It’s not the company you work for, it’s you who has to take the steps to develop yourself. I don’t know I would have been the same if I stayed in my previous company, but I don’t think I lost anything by being here. In fact, there are significant improvements in many aspects of being a developer. I’m pretty sure I would’ve missed many interesting facts about this company but I hope I covered the main aspects.
I’d like to thank my wonderful colleagues and company for what I’m now.
