42 lessons I learned as a Helpshift Engineer in 2022

Griffith Observatory telescope, by Saunved

Last year, I decided it was time to move on from my service-based software startup to work in a product-based company. A few weeks later, I applied for and was hired by Helpshift, and became a part of the Consumer Experience team as a software engineer.

This post outlines the 42 lessons I learned this year, mostly at work, and in some cases, outside of work. I’ve divided the learnings into sections based on who they would apply to most.

If you are a software engineer:

• Programming with people
• Frontend programming

If you are working in a startup or small company:

• Projects and people
• Hiring and interviews

For everyone:

• Life in general

There are a lot of learnings and not all of them may apply for you. Free to highlight the ones that resonate with you the most!

Programming with people

Photo by Braňo on Unsplash

1. Good code is written as a team. With one engineer working actively on a module, and others helping them brainstorm and review code, the quality of code is improved drastically.
2. Bad code is also written as a team. If something goes wrong in production, everyone involved is accountable, not just the person whose name shows up in the git blame.
3. Code reviews allow for new discoveries, knowledge transfers, and create an encouraging environment for new conventions and best practices to be created.
4. When things break in production, it’s important for everyone to follow a process and stay calm. Checklists are your best friend.
5. Good programmers should work autonomously, and get to set their own deadlines (as long as the project is not a blocker). This allows for trust to develop and creates a less stressful work environment overall.
6. Unit tests are the building blocks of solid features. Without unit tests, you are hanging by a thread with every refactor.
7. Subsequently, it’s good practice to ask for more unit tests to be written, especially for code paths that are crucial to the business logic.
8. Define all contracts early and maintain them throughout the development lifecycle. E.g. API contracts, translation contracts, design contracts, QA handover contracts.
9. The later in the development cycle that you identify a bug, the harder it will be to fix and do regression testing for it.
10. Along the same lines, as a developer, it’s crucial that you test things thoroughly before QA hand-off. This is especially true for when you create sandboxes and “expect them to work because it worked on your local machine”.
11. Security by obfuscation is not good security. It’s just buying you more time until the eventual failure.
12. Leave the codebase better than you found it. The exception to this is a critical hotfix. Otherwise, with every feature you add, try to refactor a poorly written part of the codebase or add unit tests.
13. It’s good to have an undercurrent of knowledge transfers happening across people and teams in a company. This allows for new engineers to become owners of specific areas and senior engineers to effectively delegate, which is a win-win situation for everyone, allowing for growth across the board.
14. When you don’t assign blame for things that break in production, it makes engineers feel safe. In such an environment, most people will actively admit to making mistakes, take ownership of the fix, and ship them as fast as they can instead of discussing “who broke it”.
15. It helps to look at bugs without assigning blame to a particular person or team. If something goes wrong, it’s our job to fix it without pointing fingers. How the mistake can be avoided in the future is something that can be discussed in a retrospective.
16. Good professionals don’t keep knowledge in silos in order to become “experts” at their subject. Pretty much everyone at Helpshift is very curious about how different services and modules work, and most people are eager to explain what they know.
17. 2+ level nested bullet points are hard to read. We’ve all been down the path of (1), (1a), (1ai). It’s really annoying. There’s usually ways to keep the structure of your communication flat and/or create discernible headings and sections instead.

Frontend programming

Photo by Lukas Blazek on Unsplash

1. JavaScript is useful because it enables asynchronous programming, not despite it.
2. A lot of so-called React “best practices” (containers, hooks, etc.) might not actually be relevant to your use case. Don’t fall for the trap of using them without doing your due diligence.
3. Frontend caching is hard. Frontend cache invalidation is even harder. Browser caches, service workers, CDN caches, and server caches all have different policies. It helps to follow the network request path, read up on cache control headers, and try out proof-of-concepts.
4. It’s good to test your product by throttling the network speed. More often than not, you’ll run into inconsistencies that many of your end-users will face.
5. Similarly, it’s good to test your product by throttling the CPU speed, for similar reasons.
6. Most modern approaches to making CSS more maintainable eventually involve having as few CSS files in your project as possible (e.g., Tailwind, CSS-in-JS, styled components, etc.). None of the approaches are foolproof, and all of them rely on developers being careful with global and shared styles to avoid issues.
7. It’s easy to fall into the trap of using a library because “it seems good”. Always list down the pros and cons and look at it objectively before recommending it to others.
8. Account for translations when you write anything the end-user will directly be reading. Your product might not need translations today, but it’s good to store these strings in a single constants file, and pass them through a mapper (it can be mapping to only English for now, but may eventually map to other languages).

Projects and people

Photo by Marvin Meyer on Unsplash

1. Just because a new feature is like some old feature doesn’t mean that it is easy to do. The challenges and biases that “similar” things introduce often times add more entropy. Don’t underestimate “similar” projects.
2. Providing a good estimate for your project encompasses accounting for things like your leaves, other peoples’ leaves, adding buffers for unknowns, code reviews, self-QA, parallel projects, on-call weeks, and finally, the actual time it will take for you to code.
3. Projects tend to fail where communication isn’t done right, which good “contracts” (handover documents, spec documents) help avoid to a large extent. In certain situations, it may even be okay to “over-communicate”. Let others tell you that they don’t need this information and prune it down in the future.
4. Writing down your idea properly is crucial to getting it accepted (or rejected quickly). If you just keep talking about it without having the foundation of a document, people will hear you out, but they’ll have no place to follow up on it. Write documents, gain traction on your ideas, and get closure for them.
5. Good engineering managers enable you to do your best work. They help you schedule, prioritize, and offer better perspectives on the product or feature that you are working on.
6. Don’t try to surprise your coworkers with some “awesome code change”. Involve your peers as soon as you have a one-pager or small proof-of-concept ready. Get the idea validated. You will save a lot of time.
7. Checking in on your coworkers, ensuring that they’re not stressed out, and giving them space to figure things out almost always leads to better team morale and better project delivery.

Hiring and interviews

Photo by Tim Mossholder on Unsplash

1. Many fresh graduates are theoretically strong, but they usually don’t have practice and lack a well-defined developer environment. Defining the way you work is the key to becoming a good potential candidate. Ref: Young software engineer basics
2. Good candidates usually accept advice and hints, and manage to incorporate your suggestions instead of rejecting or ignoring them during interviews.
3. People who write good code aren’t necessarily good hires. Having good programming skills is about half of what you need to be a good engineer. The rest is your ability to learn, to ask the right questions, and to communicate clearly.
4. Asking open-ended, real-life programming questions helps gauge a candidate’s skills much better than abstract problem-solving. Both skills are necessary, but I, personally, care far more about whether a candidate can fetch data from an API versus whether they can “invert a binary tree”.
5. Candidates with GitHub profiles having good repositories are rare. Very rare. As a candidate, try creating at least one legit GitHub project. Code it yourself end-to-end, get feedback from people, and make sure it is useful in some way.

Life in general

Sunset at Laguna Beach, by Saunved

1. Talking about the not-so-good stuff in your life with someone close to you can be hard, but it can pay off in the long run.
2. Anger can be a powerful weapon if used correctly, but being hasty while you are angry is a terrible combination.
3. Not everyone is good at reaching out and finding out how you are doing. Conversely, some people are really good at it. Either way, it is not always a direct reflection of how much someone cares about you, and it’s okay if you’re the only one reaching out. You can hope for there to be a balance, but at the end of the day, it’s not a competition.
4. Well-timed vacations are crucial to performing well at work. It doesn’t have to be a long vacation, but you need to completely detach from work when you take it. (I am not very good at this, but I am learning!)
5. Humility doesn’t mean you pretend to be bad at something you’re actually good at. It simply means knowing what you don’t know and acknowledging it.

I wrote a similar post last year: “70 lessons from the last year as a developer and co-founder”. Reach out to me on LinkedIn if you’d like to chat about working at Helpshift, programming, or tech in general.