As an engineering student, a challenging internship is really important so as to get real-world experience & luckily I got a chance to work at Haptik. In this article, I’ll be sharing my internship experience at Haptik and why it is one of the best places to be an intern. I joined Haptik as an iOS Engineer Intern and worked in the iOS SDK team.
Before joining Haptik, I had worked on a few projects, which helped me learn some necessary technologies but they were mostly personal projects without any deadlines or maintenance.
And, it just couldn’t get better; I was assigned to a live project at Haptik. I’ll try to cover my learnings and the change in my thinking process during & post the internship in this post.
One great experience in the first few days at Haptik was the on-boarding process. From my reporting manager to each and every member of the team helped me get on-boarded. From going through the Haptik’s Tech Jargons, the Git structure that is followed at Haptik, to the existing codebase of the iOS App and SDK.
While working on course assignments you had detailed requirements about what you needed to make, your sole objective was that the code you wrote, worked. You didn’t need to look back on it or explain it to anyone. All they needed to know was that it worked.
But this isn’t the case when writing code professionally, changing requirements means a change in code, which could mean changing code that one wrote yesterday or years ago and finally affecting user experience.
One thing I learned is that one needs to write code that can be understood by itself without someone needing to explain it & also that it is flexible enough to change behavior without breaking the system. Also, it should be easy to make changes and maintain the codebase down the line without much effort.
There are a few things that can help with that:
Design Patterns – When working with a massive codebase you need to write code that can be changed with time and is abstract enough that the developer updating/modifying it can work independently without knowing about the entire code base. That’s where the design patterns come in, design patterns help keep the code organized, modular and abstract enough. Design patterns break down functionality into components, splitting the implementation. These, then add abstractions as the various components don’t need to depend on the implementation of others. Since design patterns are common, any future developer trying to change anything will know where to find it and can make the necessary changes knowing that he is not breaking anything else.
Documentation – You’ve already heard this everywhere, and there is possibly nothing that I can say about writing readable code that you haven’t already heard. In my experience documentation goes beyond well-written code, since developers are almost always too busy to read the entire code to understand what a function does.
You need to document each & every function/variable & class, it reinforces abstraction as other functionalities are built without considering the implementation of your class. A descriptive git commit message is just as important. Make sure your Git commit message is clear and precise. This is better explained here.
Unit Testing – How do you as a developer, make sure that the functionality you wrote is resilient to changes and keeps functioning as it was intended? Unit tests are the answer. It can be used to test that the code you have written behaves as expected, and help to detect any bugs in the initial phases of development before integration. It can be very costly to remove a bug if discovered late in the development stage. A set of well-planned unit tests can find the basic bugs (which may have a potentially huge impact on the system later) during the development. Haptik follows and abides by unit testing on a day by day basis and as a developer, it is a really good experience to design, think & write unit test cases for each and every line of code; 100% code coverage.
Planning your work
Since we are now working with deadlines, you have to be able to estimate how much time/effort a task would take. While distinguishing between hard and easy task might seem easy, it’s not that straightforward when estimating a task down to the hour. While estimating a task might help you plan it, it’s more about how estimating a task changes the way you do it. Wrong estimates might make you skip a few things and edge cases that you might have taken care of if given more time.
Estimating a task requires you to plan out the details and visualize the complete picture before you start to work on it.
This allows you to see all the pros and cons of an approach before you commit to it. Haptik has helped change my initial mindset to find possible solutions for the bug/task, and estimate them based on the time required considering scalability before choosing a solution.
Personally, this has stopped my initial code-as-you-go approach, & now I make sure to scope out the necessary changes beforehand. This gives me a complete idea of what I should be doing before starting, thus I know the functionality that I will be adding, the number of classes that this functionality would be split into and how these classes would be interacting and what functions/ classes should/can be tested.
What initially seemed like time wasted on planning the changes that “you were gonna do anyway“, suddenly started making sense. This led to my writing code that was more suitable for iteration, testing and more understandable.
Yes, as an iOS Engineer, you’re given a chance to work on the UI/UX side of things as well. We have people using our software, so we need to keep in mind the user interface and end-user experience as a developer too. While one may argue that why should a Software engineer care about the UI, isn’t that the job of UI designer, software engineering is about creating something useful that people can use but if the user decides not to try out some of your product’s features because it does not work the way they want, you have basically wasted time in implementation.
While having a UI designer removes most of the guesswork, you’ll often be required to make decisions on the UI. Since you are the first person to see it in action, you need to verify that the UI/UX is good, responsive and easy-to-use.
Few other things I learned during the internship are:
- Work-life Balance:
More isn’t necessarily more. If you’ve worked too many hours and are no longer efficient, recognize that and take a break. It is a marathon rather than a sprint, make sure to not exhaust yourself. There is more than enough to clear your mind at Haptik with great colleagues and regular activities.
- Learn to unblock yourself:
There are going to be times when things are not working as you expect them to, learn to use the resources available to you, figure out the underlying implementation, and discuss with your colleagues. It is not a good idea to spend time figuring out a solution that could be solved with a mere discussion.
- Move fast/discuss approaches:
Submit code early and submit code often. Do not wait until you’ve completed a feature to get feedback on it. Submitting/sharing your code early will give you time to work on any changes requested and prevent unnecessary effort and delays. Even better is discussing your approach before starting to work on it.
- Question existing code:
While working with existing implementations, you are bound to come across suboptimal code. If there is anything that can be changed to make it better or any code that does not make sense, be sure to improve it. just cause it was reviewed and approved doesn’t mean that it is perfect. I got a chance to refactor a lot of old code as well. You maintain the health of your codebase via such improvements over time.
I hope all this gives you an idea of what my internship at Haptik was like. I was treated as a regular employee and everyone in the Engineering department was warm and welcoming. Working at Haptik as an intern has made me learn a lot of things and this will hopefully help me grow in my career. Visit Haptik’s career page for job opportunities.