My Journey in the IT industry — Part 1
The dilemma — Product or Services Company?
Like every other engineering graduate, with Computer Science or Information Technology as a major subject, I had a passion for programming and creating something unique that will bring tangible business impact. In the first part of this series, I will discuss how I started my career in the Indian IT industry and how some of my ingrained mental models of the industry changed. In the second and concluding part, I will cover how my passion to learn newer technologies brought changes in the way I learned and brought impact on the projects I worked on.
The ruminations of a college-grad
Graduating out of college, it was clear that the industry was divided into two major sectors — Product based and Service based. I had my own perceptions that all it takes to work in a product company is being able to code well. Along with the allure of being cool with no dress code and no fixed work timings, it was clear what my destination is going to be.
I gave up on a few opportunities at the campus, fine-tuned my programming skills, basic concepts like data structures, etc., and waited for my dream product company to turn up at my college.
I should also say that during this time, I had other perceptions about the service-based companies as well. I was worried about having to sit idle waiting for projects and didn’t like the prospect of having to fill timesheets.
Dreams do come true!
After some heart-wrenching moments and struggle, I finally made it into my dream Product company. Looking back I am proud of my ability to solve the coding challenges thrown at me during the interview process and happy that I focussed on my fundamentals — on algorithms, data structures, and OO. I still bank on my knowledge in these areas. Whether you are trying to build a performant microservice or build a scalable and responsive website, these fundamentals will always stand good.
Learn… Learn…Learn
My early days were fun-filled and I was learning a lot. Critically my view of what it takes to develop a working software changed completely. I was part of a small unit that worked on a reports module responsible for the data retrieval based on the customization made by the users. It was part of the bigger product, though I didn’t have an intimate knowledge of the same, I kind of understood how the bigger pieces fitted together. I had to now contend with a source repository and its associated processes. What does it take to work in a larger product with multiple developers committing to the same repository? This was like driving a car in your driveway and suddenly realizing you are on a highway. I had to understand the overall process to ensure that I did not overwrite someone’s changes. We were using Mercurial for SCM and internal tools for deployment.
I had full end-to-end responsibility for the module I was developing. I was a full-stack developer, which meant not only did I get the backend of my code working but also handle the front end to ensure the module is completed end to end. Owning end-to-end responsibility means that you are not waiting for someone to code and complete, delaying the testing and release. As compared to more specialized development methodologies, this is faster and the quality of the deliverable is much better. It was difficult to learn multiple technologies, critically shift the thinking from a back-end developer to a front-end developer. In the end, it all added up well. I will talk later about how this aspect of going the full length meant the impact is a lot higher and the response much faster. So I was coding in Java, Struts with MySQL at the backend with HTML, CSS, JQuery, and Javascript in the front end.
Many months passed and I was very proud of what I was contributing and critically learning. I had learned the impact of engineering practices and how that’s a very important tool in a developer’s arsenal in a different blog.
The turning point
One thing I started to realize after a few years is that I was doing the same set of work and my learning was starting to suffer. Also, when you work on a product it’s possible that you will work on more abstract layers which makes you a bit unaware of the database, deployment, etc. There are possibilities that the product has been fully developed and making changes to better architecture and tech stacks become difficult.
A future with Sahaj beckons
After much deliberation, I decided to search for a more enriching and learning experience and landed myself an opportunity to join a FAANG company. Along with this I also got an opportunity to interview for SAHAJ and got an offer as well. I realized that Sahaj in many ways wasn’t a typical services company. After much deliberation and discussion I decided to join Sahaj for the following reasons: working with experienced professionals, end-to-end application development, multiple projects over a period, etc.
In the second part, I will talk about my journey in SAHAJ and what I have learned along the way and also talk about the impact of going the full length to deliver working software.
Continue reading about this journey in part 2 of this series.
