Learnings of an intern

June 16, 2021

I would like to list down five things which are generally a part in the creation phase of a new feature or a story.

Knowledge Transfer

By definition, knowledge transfer a.k.a KT refers to sharing of knowledge and providing inputs while problem solving. In simple words, to transfer whatever you know to an individual or a team of people.

When the product manager has a story ready for development, knowledge transfer is an essential first step in the process. The developers working on the feature need to have the overview, details, usecases etc, in order to come up with an appropriate design solution before starting up. The process involves multiple meetings, slack messages, doubt solving, clarifications. The only thing to be remembered here is to start work only after attaining clarity i.e to not make any assumptions whatsoever in any part of the feature. These assumptions become obstacles in your way when you encounter a situation where the picture is not clear and certain clarifications are still needed, hence creating iterations.

One should avoid going back and forth in order to have the development process smooth and on time.

Understanding the UI

Once you have the knowledge of the story, next step is to study the UI. Engineers from both frontend and backend need to know how the customer views the feature and how will it interact with it. In this process, we take the efforts to understand the flow & user interactions. We try to understand several aspects around the design, and get to know the motive behind the decision. Multiple calls, meetings with the designer may happen here. The comprehension of design helps frontend developers to execute the next step in a smooth fashion.

Decision on components

Here, we come to the actual battleground, deciding on how should we break our UI to pieces or components without compromising simplicity. We consider several factors like

1. Component state
2. Accessing the service layer
3. Re-renders
4. Reusability
5. Passing props

On a holistic view, we keep these factors in mind while thinking about in all, how many components can we maintain. Scenarios like when we have sibling components sharing state, uplifting state to parent is feasible. How are we accessing our APIs from the service layer, how the data is modelled in order to maintain consistency across the state of the application. In case of nested components, do we really need to pass unnecessary props which cause frequent re-renders despite using memoization? and decision questions like these should be answered.

As part of maintenance, keeping components short might be a best practice.


This is solely based on standards followed by a particular organisation. As an example, if React is being used and across the app class based components have been implemented, we follow the same ritual unless a re-architecture or a migration to functional components is going on the side.

Code Reviews

Most important in the phase of development. It’s an activity in which one or more people in your team check your code by viewing and reading certain parts, before pushing it to the main branch. In the agile era of software engineering, code reviews help us save time, streamlining the process upfront and reducing a lot of work required later when bugs are reported. Unreviewed code may produce crucial bugs, get into production, resulting in affecting the customers and hence the sales suffer.

There are some common approaches which organisations use:

  1. Paste the PR: direct message your PR to your peers who would leave comments on your PR in case if any modifications are needed.
  2. Over-the-Shoulder: Sit with a peer together on a virtual meet and review. Quite effective as you are also sharing your thought process on why X was implemented instead of doing it the Y way. But on the flip side, it consumes more time and personnel.

Some may also think that code reviews are obstacles in an agile environment as the focus is on shipping as fast as possible, but we want to ship quality instead of bug-prone features. One should always take part in code reviews as it also teaches you various perspectives of the solution to the problem, thus increasing your knowledge about engineering.


Part of programming. When you don’t get bugs, the feature is not really working.

“Fix the cause, not the symptom” - Steve Maguire

In the first place, before the feature gets delivered to QA, developers should perform end-to-end testing, checking for all use-cases. Possibility is to have edge cases, thus producing bugs. The stage where one should be ready to resolve the reported bugs as early as possible making sure the existing implementations do not break i.e avoiding regression. We would want to achieve minimum number of iterations for resolution of bugs which causes delay in the release.


Extremely useful to avoid regression. An engineer entering into the software industry with pet projects/little to no experience, does not have a habit to write unit tests. Tests act as a safeguard to bugs when working in a team. They prevent existing functionality from breaking unless the server goes down 💀. It might be overwhelming to spend time on writing more code to test code, but it’s a delight for the team which will eventually change & grow in the near future.

With the above points kept in mind, a newbie can make their development process easier.

Profile picture

Written by Idrees Dargahwala who is a Software Engineer building useful things on the web. You should follow him on Twitter