How paypal engineers turned buggy software into great stable software

The story is about “Why paypal engineers joined in a startup” and what technical and management decisions took them to turn from buggy software into great stable software

Brief about startup

After ban of TikTok in INDIA, The startup got raise with heavy users. Because it offers same as TikTok and there is no other app in market at that moment. Then later founders realised lot more features need to develop to generate revenue.

Startup made heavy deadlines especially for developers to improve the app. Then they hired initial set of freelancers and later outsourcing developers from service based company for further development and maintenance of the app.

At last the app got improved to engage users and generate more revenue streams, then later acquired large amount of users by doing great marketing techniques and raised good amount of funding by showing initial revenue streams from investors.

Funding got approved from various investors and hired great product managers along with few developers.

Everything seems going well. After period of time, Like every software product they also face some bugs in app, These bugs get assigned to outsourcing developers (who created most of the app).

Difficult phase of startup for developers

Then outsourced developers used to took some time to solve those bugs. From that moment, Bugs are never stopped to solve because code is rotten and not structured well i.e in-terms of naming conventions, reusability etc

Bugs are getting created every period of timeline especially on production environment, Developers used to solve but again and again bugs used to create, Later developers understood its difficult to solve due to bad code and not following proper coding guidelines and file structure.

Startup got more worse

Next mistake these developers are made is they used to push the code directly to prod env to solve bugs as fast as possible because if any late these users are got blocked to perform some activities in app and later prod codebase aren’t sync with pre-prod and dev env’s.

Slowly software become buggy, Almost impossible to solve these bugs.

Journey of Paypal engineers with startup

Startup realised they need to hire more great developers across global to solve the issues in the app.

After interviewed with many senior software engineers, startup hired few engineers whose had great experience working in paypal and founders thought they might be great fit to these problems and transform the app.

These engineers are hired with great package and looks cool😅…

These engineers started understanding and product lifecycle and architecture and code.

Steps taken turning buggy software into great stable software

Initially they created a mono-repo, where latest code used to contribute in this mono-repo i.e new features etc but it suitable for one micro-service, for other micro-services it not possible to contribute in this same mono repo. So continued to contribute in old repos.

Their main intention is to transfer as much as code into this latest new mono repo and to maintain latest codebase into very structured manner and modularity also writing the code with the best clean code practices. But founders not saw any difference after they hired these paypal engineers (initially face).

Introduced new Changes to team and code practices

1) Created coding guideline's

• They informed to the team that these guideline’s must follow while contributing code either in old repo or new mono repo else code can’t be merged into respective repo(strictly).
• Sample guidelines👇

Practices to follow:

- Don’t use nested ternary operators. Use if/else or switch outside return and && inside return

  Example 
  
   Avoid - const abc = a ? b : c ? d : e; 
    
   Go for - let abc = ““;
                if (a) {
                  abc = b
                } else if (c) {
                  abc = d
                } else {
                  abc = e;
                }

          
- Avoid <Button isDisabled={true} /> and Go for <Button isDisabled /> 

  Because <Button /> is same as <Button isDisabled={false} />


- Flag names should start with a helping verb and function names should start with verb
  
  Example - isButtonVisible, handleClick etc


- Try to keep all expressions outside return, assign to a constant and use the same
  
  Example 

    ❌Rather than using
    return (
      <button>{isUpgradeBtn ? “Upgrade” : “Buy Now”}</button>
    )
  
    ✅Use
    const buttonText = isUpgradeBtn ? “Upgrade” : “Buy Now”;
    return (
      <button>{buttonText}</button>
    )


- We can directly use a function definition if we need to pass the default arguments

 Example 

  <button onClick={(e) => handleClick(e)} /> is same as <button onClick={handleClick} />



- Avoid css styles with JSX(inline styling)

  Example

   <h1 style={{color: "red"}}>Hello Style!</h1>


- Use const instead of var and let if variable is not going to get reassigned

- Remove commented cod

- Use && instead of ternary if the second option is null/undefined/”” etc

  Example 
  
    const abc = xyz ? “abcd” : undefined;
    You can instead write as 
    const abc = xyz && “abcd”;
  

- Always check for an object to not be not defined as optional chaining is only for keys or something which may be undefined and not not defined.

- Use camelCase for class names in CSS modules

- Read the base URLs or such variables from .env files

- If it's possible, always use SVG images for icons, logos , or any kind of images. 

- "Alt" attribute should be added in all the images

- We should try to avoid using !important in our css unless and until it's very much necessary

- We should avoid using type any (typescript)

• These Guidelines looks like google style guides available for many software languages, Also you can check for other style guides in GitHub

2) Introduced Husky and lint for repo

• Husky will improve the code, While doing any commits to repo.
• While committing the code for any repo, If code needs to improve then husky won’t allow code to make any commit and merge to repo instead it raise errors to solve before committing the code.

Checkout docs— https://typicode.github.io/husky

3) 1:1 meetings

• These 1:1 meetings to understand individual person in a team
• Interesting, These are not to discuss any technical aspects. These paypal engineers used to ask questions like 👇

— Any feedback for team or leads ?

— Are you facing any issues with your co-workers ?

— Are you satisfying the work or any other questions to discuss ?

— Are you facing any issues other than work ?

— At end, they used to provide feedback for respective developer…

Mainly these feedback used to help developers in-terms…

• What company is trying to make app better and bring new features.
• Where these developers are lagging to improve it.

Also these meetings are conducted once in every 2 weeks.

4) New sprint master and RTB support

• Every sprint there used to be new sprint master, who will randomly pick from the team and also same for RTB support

What does Sprint master person needs to do ?

1. He/she needs to initiate daily standup call every day
2. Get the updates from team also inform team to update their tickets
3. Also identify who are not assigned task in a team

What does RTB support person needs to do ?

1. He/she needs to resolve the production bugs in that sprint
2. If any other deployments needed they need to work on it

I hope you enjoyed. Stay tuned for part 2…