9 Lessons I Learned by Creating Large Frontend Web Applications and Managing small team.

Lesson 1 — Developer must help themselves first.

at Clickable, frontend team was provided with some WAR in order to run the local server. Server application was Tomcat driven. Server setup on local machine was a problematic for UI team(at least for me). I simply did not want to run MySQL or Java Code on my machine.

Developer should fix their problems first before fixing somebody’s else problem.

Lesson 2 — Great Code/Product are not written in hurry.

After Clickable, I joined Unicommerce (a company acquired by Snapdeal). I designed their entire frontend from scratch. Best thing, they gave me initial 3 months on researching and designing the base architecture. If initial free months was not provided, an excellent product was almost impossible. I see many startups expect to deliver from the first day itself.

Always listen your inner voice and not pressure, may your product have best architecture. Ask sufficient time from CEO/CTO.

Lesson 3 — Continuous code refactor

Over the time, I realized that focusing on perfection at first instance is not going to help at all. You might end up at some architectural beautiful code which is useless.

Never focus on writing best code at first pass. Always Keep on improving your codebase. Even after your production release. Continuous code refactor will create best code.

Lesson 4 — Never commit tight deadlines.

I suffered a lot because of committing tight deadlines. It takes away your peace of mind, your sleep, and your happiness.

Never agree on very tight deadlines.

Lesson 5 — Layered Architecture is fastest way to deliver

Remember, when REST came, It gave a nice split between client and server. There is no limit on splitting code into various layers. splitting brings 2 main benefits

  • Scalability
  • Parallel development (aka — FAST)
  • Functional UI
  • Reusable Component
  • Business logic

Split the code in as many layer as possible. Always separate UI Layer with Business Layer.

Lesson 6— Strictness on Code quality using tools.

You can add or improve code quality by using tools by adding strictness in coding patterns.

  • consistent indent, eslint rules.
  • checking localisation was done or not.
  • code-copy paste checker (intra-project duplicate code locator — )

Be Strict on your code Quality, Use tool to add strictness.

Lesson 7—Increase productivity of your team members.

I applied various tricks to generate more productivity from the team.

1 — discuss/guide before assignment of the task.

If you guide your developer on what library or code to use, and how he can proceed then the developer is super productive.

  • npm package for full-screen API which he HAS to use, without understanding inner details.
  • font awesome icon path for the full screen icon to be used.
  • He needs to set up a toggling behavior and that toggling will be managed by State/Store. So I showed him existing UI component where toggling of state variable was done for some other purpose so that he can follow exact approach.
  • This button is only meant for making a full screen on whole page and full screen of any random DIV.

2. Tell developer, we can change design little bit, if needed.

design files come from product team who has no idea on what is the underlying architecture.

3. Early code reviews

A Developer worked for 4 days and ended up in a code which you do not approve? Waste of 4 days ? this is why early code feedback or code review is needed so that developer can be on right productive track.

4. Ask them again where they stuck.

Many times developer shy in sharing where they stuck. Sometimes they think that the problem on which they got stuck is genuine and will take time.

5. Increase intra-team collaboration.

Our entire schooling and college is based on competition and individual efforts. In schools, collaboration is cheating. Almost many developers stuck in their school days. We never grew up in collaborative working.

6. Spend Friday for internal tech discussion.

We started internal tech discussion in Friday second half. The response was quite good. these internal tech discussion and presentations energies developers.

7. Tell developer about the scope.

When you ask an artist to draw your image, he can finish in 1 hour or 2 days. It depends on how much detailing is needed.

Productivity of Team can be increased by simple tricks and continuous engagement with team and understanding their problems.

Lesson 8— Fast feedback cycle with stack holders

In startups, even CEO/CTO do not have 100% crystal clear thought on what they want?

Make a FAST feedback cycle so that developer can get early feedback from Product Managers or Owners.

Lesson 9— Separate UI from Business Logic

In startup word, we see frequent changes on pages and rearrangements. If you separate your UI logic and Business logic with a clean separation then it is quite easy to re-work or redesign pages later.

Always think, the page you are creating will be replaced by some better page in 8–10 month and most of the business logic will remain same. So make the clear separation between UI and Business logic.

Contact Author —

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Narendra Sisodiya

Narendra Sisodiya

12+yrs exp. JavaScript Expert. Full Stack Expert. React, Nodejs Mongo AWS, Terraform Pulumi. IITian, Open Source. Currently Software Architect @ Prophecy.io