I’ve been with Helpshift for about a year now, and it’s been a great experience so far. Filled with mistakes, lots of learning and surely lots of fun. Whether it’s learning how to write good code, documenting projects and meetings, communicating with different teams, playing FIFA, TT, chess, badminton, football and so many new board games, it’s been amazing.
I work as a frontend engineer at Helpshift and every day has been fun and challenging. Working on exciting new projects, participating in various types of discussions, and cherishing the people and culture the team has developed, every day is unique in its own way.
With this article, I will try to cover different aspects that have been part of my journey at Helpshift so far.
- Inter-team discussions
- Code review
- Knowledge sharing
- Debts and technology initiatives
- Session 1 of 1
- The fun pieces
Each project involves a collective effort between teams. The product team provides documentation of the problem we are trying to solve and a potential solution – The product requirement. After extensive discussions, once the product requirements are clear, using the product document and detailed design document, developers should come up with time estimates. The frontend developer and the backend developer create and decide on an XHR spec, which is the contract for different APIs to be involved in the development process. This basically involves changes to existing XHRs and details of new XHRs to be added.
Once you have started the development phase of the project, you start by having the development specification reviewed by 2 other engineers on the team. A development specification (developer specification) is essentially a detailed documentation of the implementation plan, identifying areas of code to change, new requirements, and corresponding pseudocode. The review discussion is usually initiated by a brainstorming session around the project and its expected implementation. This is done just to make sure that all possible scenarios are covered and nothing is missed, neither from a code understanding point of view nor from an edge case handling point of view. In this process, you also need to break down the entire project into smaller tasks with estimates for each.
Once you get started on the coding part, we’ve put together a set of coding conventions. It is encouraged to make smaller commits, following these conventions and each commit is reviewed by 2 peer developers. When reviewing a commit, a developer views it from the perspective of readability, efficiency, reusability, and convention adherence. Reviewers approve the commit if the commit looks good to them or they leave comments specifying things that can be improved in the commit. Once all comments are resolved and you get approval from both reviewers on the commit, only the commit is merged into the branch.
This is one of the very important ways to learn while growing. Similarly, you also review code from other developers and are therefore able to learn by being on both sides of the process.
Each developer works on a different project and therefore encounters different types of problems or interesting topics. All of these topics are discussed within the team and many are documented for further action. It brings a lot of learning that you wouldn’t have encountered otherwise.
Also, every Thursday we have a frontend flash chat about learning new things in the frontend space – whether it’s around performance, libraries, security, browsers, basically anything that is frontal. One of us comes up with a topic/learning and introduces it to the team and explains everything, the team discusses it and whenever there’s a possibility that it’s useful for the product, we tend to make one-page documents at this get ahead.
Similarly, we have more such weekly sessions between teams and a general engineering blitz every Friday.
Along with all the good code you write, repositories also house technology debt or things for improvement because technology keeps changing and evolving at such a rapid rate.
It’s important to pause and take a look and take initiatives in that direction – how do we remove technology debt, how can we improve processes, what can speed up the development cycle and all other things that fall within that territory.
Additionally, as mentioned earlier, we have coding standards in place. If, during our development phase, we believe that a convention is not really useful, or if a new convention may be useful, we encourage such discussions and make changes accordingly according to the extended team.
Taking initiatives in such directions, identifying debt, breaking it down into achievable, improving workflows, is encouraged throughout the team and done with enthusiasm by many. It also works to help you grow in multiple ways as an engineer.
Mentoring is a very natural process at Helpshift. Every day you will end up learning something or the other from all the people here.
The simplified mentoring process consists of 1:1 sessions with your managers or senior developers or peer developers. 1:1 sessions are encouraged to be good, meaningful conversations about growth, career, aligning journeys, setting and knowing expectations, getting to know the other person and their thought processes better, and a insight into how things work in other verticals.
They can be about literally anything, the way you expect them to be, and therefore looking for the maximum benefit you can get from them.
When I joined Helpshift as an intern during my last university semester, I was fascinated by the culture and the people here. Besides being amazing developers, many of them had such interesting hobbies that they passionately followed along with work. You would find people playing sitar and tabla in the office after hours, you would find people playing new board games every day with the same enthusiasm to learn the rules and try. You will find people jostling on the TT table, battling in FIFA matches and much more.
Apart from this, the team reserves a pitch to play football and badminton on a weekly basis. We go to the chai outside of the office and have so many fun and funny conversations. Although the work environment is now hybrid, the passion of people to follow their hobbies, the urge to maintain this culture is still there intact in online and offline environments.
Overall, Helpshift is a fun place. Not only do you grow technically here, but also as a person and end up making good connections. I’m sure there are a lot of things I must have missed mentioning and many more that I haven’t experienced yet.
Although this may sound like a marketing article, surprisingly, it is not! That’s honestly how my experience at Helpshift has been so far and that’s what makes me look forward to growing here.