After graduating from college in 2015, I came across an idea from a friend, Vibhor, to build a business that can help humanity and generate revenue. The idea was to bring the entire healthcare system to a fingertip and build an independent virtual personal doctor. We named it The Machine, inspired by The Machine from the TV series Person Of Interest.

The Idea and Validation

Originally, the idea was Vibhor’s and his two friends(Uday & Gaurav), who created a proof of concept (POC) in college and won a prize for Best Innovative Product. When they demonstrated it to me, I was convinced this was a revolutionary idea.

Here is the original abstract from their project:

“SPARK(Simple Prescription for Anatomical Remedies Key) is an Artificial Intelligent based Expert System which provides household tips and remedies for the problems to sufferers at his home in emergency when there is no medical help is available.

It features “fine tuning” and the acquisition of updated advices agreeing the opinions of its consultants. This project is to assist with the decisions involved in the selection of appropriate therapy for patients with infections and recommendation for Allopathic Medicines.

It also facilitates doctors with clinical decision-making. This increase in objective reasoning should lead to the reduction of human errors and improvements in the quality of care.

Causal explanation of what is happening to the patient is the basis of complete diagnosis.

Predictions about the disease processing are the base for therapy and suggesting medical relief. The process of decision making is based on identifying the criteria (Signs / Symptoms) before a feasible goal (Diagnosis) is identified. Then as a consequence of the earlier decision (Diagnosis) evaluation of the intervention procedures adopted (Treatment plan). Finally an appraisal of the possible final goal (outcome i.e. recovery).”

When I first read this, it felt ahead of its time. Reflecting on the advancements by Google and OpenAI now, I believe we could have been contenders in this space.

The Team and Initial Success

Initially, Vibhor and I spent countless hours discussing our vision for the project. We planned to develop 30 modules, starting with a Health Tracking System. We amassed over 200 GB of data on medical science, machine learning, and more. We identified the tools we needed: Bitbucket for our codebase, Java and Angular for programming, MySQL for our database, and Asana for project management(photos).

Realizing we needed a larger team, we convinced 30 developers to join us part-time. We offered profit-sharing or equity once we started generating revenue. Our daily meetings, detailed planning, and task tracking on Asana helped us achieve our first significant milestone.

It was a big success for us, our first one.

Initial Obstacle

Everyone on the team was a fresher, having worked in the industry for no more than six months.

While everyone was eager to start their entrepreneurial journey, productivity decreased by the end of the first week. Motivation dropped, and Vibhor and I struggled to keep the team focused on our common goal. We wanted everyone to visualize our product's future possibilities, but we failed to keep the boat afloat. Slowly, team members stopped joining calls and working, and we lost them all within a month.

And the Project SHUT DOWN… Partially…

Crawling Baby

Despite the setbacks, Vibhor and I were determined to keep the project alive. We continued developing the product with our limited technical knowledge over the next three years, spending a couple of hours daily, which gradually decreased to weekly and then monthly. We lost hope in fast-tracking our vision.

We connected with more people to help build the product and even tried hiring interns with minimal pay. However, no one worked with us for more than two months. We needed more motivation and dedicated time to build the project or guide interns. We also sought fundraising and participated in competitions like the DBS-NUS Social Venture Challenge Asia, but we never heard back from any of them.

Realizing this approach wasn’t working, we continued the project as long as we could, but it was a slow crawl.

Farewell

Vibhor and I became increasingly busy with our jobs, leaving little time for the project. We stopped discussing it, and although it was a buried dream, it remained alive in our hearts.

In 2018, I considered going full-time on the project and discussed it with Vibhor. We re-evaluated our idea and found it was no longer unique. Without funds or a team, we couldn’t build it to the level we envisioned. We made the difficult decision to shut down the project for good and never looked back.

My Success Story

Being part of the project was one of my biggest successes. As a college graduate with no prior entrepreneurial experience, the challenges it introduced were daunting. However, it pushed me to grow at every step. This journey taught me a lot about business, product development, team management, and the importance of good technical skills. I became a better person, and that was indeed a worthwhile result of my investment.

Within its pages, I discovered the concept of Power Editing, which highlighted the potential of editor fluency and efficient tool usage to boost productivity. The idea that a mere 4% improvement in efficiency could translate to an extra week of productivity captivated me.

It was then that I decided to challenge myself: I would go mouse-less for the next five days, embracing the full potential of my keyboard. Join me on this transformative journey as I recount my experiences and the valuable lessons I learned along the way.

How do I use the keyboard today?

I have been using basic keyboard shortcuts for a few applications:

• VSCode: Saving, closing a tab, closing windows, renaming files/variables, switching b/w terminal and workspace, closing the Terminal, deleting lines, moving lines up and down, expanding and collapsing sidebar, switching b/w open tabs.
• Git: Use commands for pull, rebase, remote add/update/delete, checkout, push, and fetch.
• IOS: Opening new applications, calculator, switching b/w opened applications.
• Notes: Create a new note
• Outlook: Send a new email

For anything else, I use the trackpad.

I am apprehensive that this challenge might hinder my productivity and result in fewer deliverables at the office. But I need to push myself to improve.

To ensure the success of this challenge, I rely on my trusty Track Pad Cover.

Day 1

I have a lot of work to finish.
I have opened many applications(both desktop and web).
I do not know many shortcuts for most of the website/applications.
I need to finish work on time.
How do I navigate through the Jira board?
How do I pick a call in Slack?
How do I open multiple instances of VSCode?
How to switch b/w multiple Chrome instances?
ohho…I am already struggling…

I took a deep breath…., and opened all possible shortcuts available for different tools: Medium, Google Chrome, Jira, Slack(this & this), Outlook, Mac OS, MS Teams, and VSCode(key bindings).

Things started working better. I could navigate b/w multiple instances of the same application, fold/unfold blocks of code and pick up/make calls over Teams and Slack. But navigation through an application was still taking time as I navigated using the Tab key to navigate to a specific option.

Attitude: I can work without a trackpad for the next five days. 😎

Reality: That’s not what happened. 😭 I had to rely on the trackpad for few times.

Not all software and websites are built keeping Accessibility in mind.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

I used the trackpad for:

1. To copy VSCode zest runner keyboard shortcuts from a webpage.
2. Maximize the current window shortcut available on Mac.
3. Switch to/maximize the pop-in window in Teams on Mac.
4. For unlocking pdf, the website does not have a navigation shortcut.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

One good thing happened: I use the Grammarly extension in Chrome which highlights potential grammatical errors. And to fix the error/check suggestion, I had to click on the highlighted text.
So, instead of using its suggestion, I make fewer grammatical errors and depend less on the extension.

Day 2

As I embarked on my second day without a mouse, I anticipated a smoother experience armed with newfound knowledge of additional shortcuts. However, the reality proved more challenging.

My first task was to review a Gihub PR. And I realized navigating to a specific line in a file is not working for me. And I could not find a way, to put an inline comment (though a solution existed).

Later in the day, I struggled to look for shortcuts to do X in application A or Y in application B.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

I used the trackpad for:

1. Navigating GitHub PR files, line by line. But later in the day, tab navigation started working and the cursor moved to the line the comment was required on.
2. Selecting the attached image in the Jira comment
3. Select and copy from PDF.
4. One application did not have accessibility control. And I had to zoom in/out a PDF inside that application.
5. For VSCode, opening and closing a new instance.
6. Outlook was not responding to my navigation button.
7. On Mac, when I close Excel, a confirmation pop-up asks to save, close without saving, or cancel. But it does not allow us to change the selection using keyboard navigation. I miss MS Windows accessibility here.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Shortcuts: MS Excel, GitHub

As I embark on my second day of this new endeavor, I find myself confronted by the challenges of keyboarding. To my surprise, I’ve come to realize just how much I depend on my trusty trackpad to complete tasks efficiently. Unfortunately, the learning process is proving to be more time-consuming than I had anticipated.

Day 3

The need for speed drove me on the third day, pushing me to work faster.

Though the day started smoothly, I stumbled when it came to answering incoming calls outside of the Teams application and navigating the calendar within Teams.

While the challenge had its benefits, it also highlighted the time-consuming nature of certain tasks without the assistance of a mouse or trackpad.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

I used the trackpad for:

1. To expand the screenshot area on MacOS.
2. Selecting Bluetooth device to connect.
3. To apply breakpoint in Chrome source in the dev tool for debugging my code.
4. To expand the file explorer section in VSCode. In JIRA, we can expand it using just a keyboard.
5. Close stupid calendar reminder

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Day 4

With a heavy workload and a day filled with lengthy calls, I am optimistic about completing my outstanding tasks within the designated timeframe.

After using Jira with just a keyboard, it stood out as a remarkably accessible tool.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

I used the trackpad for:

1. Open the link in the WhatsApp web chat
2. Selecting Bluetooth device to connect.
3. Copy from PDF
4. Move a pop-up/dialog box windows

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

The day felt exceptionally long, and regrettably, I was unable to finish my tasks, leading to a considerable backlog. Now, with only one day remaining in the sprint, I must find a solution to complete my work by tomorrow, no matter what.

Day 5

Today marks the final day of the challenge, I faced a mounting workload and an overwhelming desire to complete my tasks.

The day kicked off on a smooth note, with the first few hours passing without any issues. However, things took a frustrating turn when I needed to request a reimbursement using one of our internal tools. As soon as I opened the portal, it became apparent that it lacked any accessibility features, leaving me with no choice but to fall back on the trackpad once again.

Frustration…
I had to click so many times to apply for reimbursement.
Disappointment…

The workload was substantial, and the past five days have been quite demanding. I found myself relying on the trackpad extensively, particularly on a single site, as I tried to get through all the tasks that needed to be completed.

Now, it’s time to wrap up the tasks and put an end to this challenging ordeal (with a tinge of deep regret 😞).

Productivity after 2 weeks:

I have integrated more shortcuts into my daily routine, leveraging their benefits for tasks such as making calls, switching between multiple instances of the application, navigating through Jira, and more.

As I continue to discover and incorporate shortcuts, I strive for a harmonious balance between the keyboard and mouse, using each to complement and enhance my productivity.

By embracing the power of the keyboard, we can unlock new levels of efficiency and productivity, empowering ourselves to accomplish more in our digital endeavors.

Key Takeaway: During a recent project aimed at enhancing the Accessibility of one of our products, I made an intriguing discovery — each country has its own laws concerning product accessibility. This challenge has served as a motivating force, inspiring me to take our website to the next level by making it more intuitive and accessible through keyboard navigation.

Conclusion

The week-long mouse-less challenge offered me a fresh perspective on productivity through keyboard shortcuts and reduced reliance on the mouse or trackpad. While it’s nearly impossible to go entirely mouse-less due to the lack of accessibility features in certain applications and websites, the experience has motivated me to explore more shortcuts and incorporate them into my daily workflow. By constantly seeking opportunities to enhance productivity and accessibility, we can harness the true power of our digital tools.

Code review is an integral part of any software development lifecycle. A thoroughly reviewed code is more likely to perform well in production. However, good code review is an art. It is a journey. One becomes a better reviewer with experience. A good code review, while focussing on the functional requirements and the implementation logic, also takes into account the coding best practices, code aesthetics, and impact of the modified code on other modules of the application.

Let me give you a brief, on how I approach this activity.

1. Understanding Requirements: Go through the requirement ticket and understand the ask. Reach out to the developer for any clarifications.
2. Checkout code locally: Helps me traverse b/w different files and understand the flow/design used for implementation. Also, I can locate any code which fails Linting(esLint, sonarQube) checks.
3. Design patterns: Frontend is not known a lot for its design patterns and developers implement the logic based on their best understanding of a particular language/framework. However, it is still a good idea to use a pattern that could simplify code, and make it maintainable and extendable. There is a list of design patterns mentioned on pattern.dev that could be used.
4. Performance: Customers love fast and high performant websites and generally abandon/exit slower ones. Fast-loading pages result in higher conversions and revenues. Walmart saw a 1% increase in revenue for every 100ms improvement in load time. Similar results were reported by many other companies.
   So, I make sure, any looping operations are syntactically optimized, lazy loading is done wherever necessary, dynamic importing for selective rendering, and code splitting is done properly. Use the Lighthouse tab in Google Chrome Developer Tools to test the page performance.
   There are different frameworks, with multiple rendering patterns like NextJs. So, using the best rendering pattern is critical. Ex. Users must not use incremental static generation for a chat box.
   There are more performance-based patterns to choose from.
5. Cache: The application must avoid calling APIs unnecessarily and use an appropriate cache policy. Network calls should be only made for changing resources.
6. State Management: Avoid saving unnecessary data in stage management tools like redux. Ex. saving tax calculation for different products of e-commerce website, when it will be dependent on different locations.
7. Run changes locally: When a change is complex, it’s good to run and interact with the application to find any missing edge cases or incorrect behavior. I usually test it on multiple devices.
8. Test Cases:
   - Check the test description and implementation for any mismatch
   - warnings/errors in the console by running test cases
   - a missing scenario that is not covered in test cases.
   - Test case must be meaningful, and must not be written to satisfy the coverage threshold.
   - must be syntactically correct.
9. LightHouse report: For Accessibility, SEO (and PWA (Progressive Web App) — if applicable)
10. Analytics: Analytics Tag Manager events must be correctly implemented.
11. Generic Feedback:
    - function name
    - variable name
    - File name
    - Code Segregation into different files.
    - CSS/HTML structure: only optimized structure is passed
    - scope change of a function/variable
    - Is a new/better syntax available in ES?
    - Duplicate code
    - Reusable code
    - Unused code
    - Inline styles not allowed
    - Following programming principles? especially the Single Responsibility Principle
    - Documentation
    - Comments
    - Complexity
    - Functionality
    - Type checking: proper type defined across changes(potentially using Typescript).
    - Impacting other non-dependent features.
12. PR validation:
    - Is the commit message and body descriptive?
    - Is the PR description descriptive?
    - Does pass the CI/CD pipeline?
    - Is PR broken into multiple meaningful commits?
13. Audits/Security checks: audit and security issues must be addressed on priority. The application build should fail if any major security vulnerability is reported.
14. Most important — read as much as you can about multiple technologies, advancements, other frameworks, tools, top companies engineering blogs/articles, Tech YT channels, etc.

There are a few articles/YT channels that could be a good source of knowledge and will help better understand front-end programming.
- Web Dev
- CSS Tricks
- Javascript
- YT Fireship and YT Fireship Beyond
- Design Course, All about CSS
- Page Speed improvement