ZS Associates , Pune Work Experience For Internship

I was a student at an engineering college in India. After 1 and a half years of learning computer science academically, I now had a chance to test my knowledge in the real world through an internship.

In this article, I’ll be sharing my internship experience at ZS Associates, Pune with the hope that it is helpful to other IT and computer engineering students who are looking for internships.

Like most of my colleagues at the college, I had a minimal view of software development in general and didn’t know what to expect from an internship.

Lucky for me, I was assigned a live project, which was based on Ruby on Rails, something that I had already developed an interest in.

After I had learned PHP and MySQL in the 2nd year of my studies, I built a basic web app, and all that it did was some CRUD (Create, Read, Update, Destroy) operations. I remember talking with a friend who had similar skills to mine, and said “Even we can build Facebook now that we know PHP and MySQL!”

How ridiculously simple things seemed at that time. Now I understand how complex building/maintaining a software can be.

So here’s what I learned from my Internship while working on a live project.

General lessons

• Scale Makes a huge difference
• How many users are going to use the software?
• How much data will be processed?
• What are the expected response times for a function?

These are questions that we, as college students, hardly think about. Our college projects were usually short-sighted. In real-world projects though, the above questions fundamentally affect decisions about hardware, technologies/tools to be used, system architecture, algorithms, and so on.

Working with a large codebase

Back in college, we used to work on projects that had like 15 - 20 files or so. Built in under a week, the whole project could be understood in a few hours.

Now the project I’m working on has hundreds of files spread across dozens of folders. It can take months to understand the whole project, and hours to debug a bug that’s spread across multiple files. And the first time you look at the whole project directory, you don’t know where to start understanding the code.

Writing maintainable code

Knowing that the code you write will be read, understood, and improved/changed by someone else (or even yourself) in the future makes you write maintainable code.

In college, all I focused on was getting the expected functionality to be complete and never considered whether the code I wrote was maintainable.

This resulted in scrambled pieces of code that somehow worked at the time. But two days later even I wouldn’t understand why I had written a certain piece of code that way. And changing some parts of the code almost always broke other parts. ?

Code Maintainability is easier to recognise by its absence, like when something you thought should take an hour ends up taking a week.

Using a version control system - properly

When I first started building small software, all the files existed on my development machine, and maybe they were backed up to Google Drive as regular files.

Then I got to know about GitHub, but I merely used it as a safe storage place for my code. I used the GitHub desktop app to commit all changes on just the master branch. I even hesitated using it through the command line.

Now not a day goes by that I don’t use Git. It’s such a great tool for collaboratively writing code, distributed development, branching out for new features, pull requests, and so on.

Here’s a little article on why version control systems are awesome!

The importance of using a Test Driven Development approach:

During my internship, I was assigned to work on a new feature that was to be added to the main project.

I wrote the code and tested if it was working the way it was supposed to. It worked perfectly, or so I thought. I deployed the feature to the production confidently and moved on to work on something else.

After a few hours, Rollbar, a real-time error reporting tool burst with several errors in our code deployed to production. I checked the errors and they seemed unrelated to anything I had ever worked on.

After some debugging, all of those errors are traced back to a single method. A method that was called in numerous places, and in which I had modified just a single line, and hadn’t checked where else it was used.

Now this could’ve been avoided if the code that used that method had test cases written for it, and if I had checked if all the test cases ran successfully before deploying the code. That made me realize the importance of test-driven development.