How A Metallurgist ended up in Software Development ??

In 2017, a group of Cummins College students approached me. They were gearing up for the very first Smart India Hackathon and wanted me to mentor their team.

During our chat, I casually mentioned that I had zero formal education in programming and that my degree was in Metallurgy.

I still remember their expressions. 🙂

For context:

I graduated in Metallurgy from COEP and completed my post‑graduation in Materials Science from IIT Powai. I don’t hold a single certificate in computer science. Naturally, people often ask—then how did you end up in software?

The story goes back to 1984.

I was in 8th standard. My friend Sandeep Shiyekar’s father, a professor at Walchand College in Sangli, had access to a newly arrived computer (most likely a BBC Micro). He invited a few of us to see it and offered to teach programming if we were interested.

None of us had a computer at home, so we learned BASIC on a blackboard every Sunday.

Yes—actual programming, written in chalk.

During the school vacation, I visited my cousin Shirish Ranade. He had a Commodore 64 and a Casio PB‑100. That was it—I was hooked. With no YouTube or internet, I learned purely from books and manuals. Read. Experiment. Repeat.

Shirish gave me the PB‑100, and for the next few years I kept pushing its limits. It had just 1 KB of memory, so every program had to fit inside that tiny space. That constraint taught me more about logic and efficiency than any course ever could.

Engineering years: the real acceleration

In my first year of engineering, . I discovered Turbo C and the book “Spirit of C”. I didn’t have a computer, so I wrote programs in a notebook and exchanged ideas with my friend Jayant Walvekar through handwritten letters. Occasionally I went to Shirish's place in Thane and tried out my ideas on his IBM PCs

By second year, thanks to my friend Janmejay Nemade, I got permission to use the computers in the Metallurgy department. By then, programming felt natural. I even completed my BE project in Turbo C—building an “optimum mix” solver for cast‑iron furnace materials to minimize cost. This was 5000 line Turbo C program. Probably a record in COEP at that time.

Published on linkedin on 7th April 2026 

Stop Abusing try/catch. Its Killing Your Productivity

I once joined a consulting project where the team was drowning in bugs. Fixes took 3–5 days, customers were frustrated, and developers felt stuck.

As I reviewed the code, the culprit became obvious: 500+ try/catch blocks scattered everywhere. The mindset was simple -- "It shouldn't crash"

But here’s the irony: crashes are the easiest bugs to fix. They give you a call stack, a direct pointer to the problem. Wrap everything in try/catch, and you don’t prevent crashes—you hide them. The program keeps running in an unstable state, leading to silent data corruption and endless debugging nightmares.

I pushed the team to delete unnecessary try/catch. We went from 500+ blocks to ~50. The impact was immediate: bug turnaround dropped from 3–5 days to just 1 day. Customers were happier, and the team felt empowered again.

Stability doesn't come from hiding crashes. It comes from facing them head-on

Here’s how you can start:

1. Delete try/catch in private/protected methods. Keep them only in public methods.
2. Remove catch-all blocks (catch(...), catch(Exception)) everywhere except at the very top of your app.
3. Replace null checks with proper contracts: @NotNull in Java, assert in C++/others.
4. When a crash happens (during development or during testing), analyze the call stack and fix it at the highest level possible.

Make these changes and watch your team's debugging speed and delivery timelines skyrocket.

Published on LinkedIN on 24th Nov 2025

Scale Changes Everything

 Originally Published on LinkedIn on 15th Oct 2024

One lesson I emphasize to my team is "Scale Changes Everything." Solutions that work for tens of items may not work for hundreds, and usually fail for thousands or more. This is a universal rule, not just in software.

Examples Across Contexts

• Geographical Scale: Solutions that work in small European countries can fail when applied to larger countries like India or China (e.g., BRTS implementation in Pune).
• Business Growth: Startups and companies often struggle to scale. Moving from tens of employees to 200-300 requires significant changes in ways of working. Growing beyond 1,000 employees necessitates rethinking tools, processes, procedures, and practices in finance, HR, and projects.

Technical Examples

• Sorting Algorithms:
• Algorithms for sorting 10 items (e.g., Bubble sort) do not work well for 1,000 items.
• Algorithms for sorting 1,000 items (e.g., QuickSort) don't perform efficiently for 1 million items.
• Algorithms for 1 million items (e.g., Merge Sort) may struggle with 1 trillion items.

Software Development Considerations

The question of scale arises at various levels:

• Microservice vs Monolith:
  For a corporate application used by 200-300 users a day, a microservice architecture might be overkill, like using a Bofors gun to kill a mouse
• Technology Choices:
  
  For a small startup with 10 people, using F# for fast development is fine.- However, if you plan to grow to 100 people, F# might be a poor choice since finding 100 developers proficient in F# can be challenging.

**We need a Mindset Shift**

Unfortunately, very few senior developers and software architects consciously think in terms of scale. They often blindly select a "microservice" architecture.

If the justification for a decision is "everyone is using it", then your company has a serious problem.