Key Takeaways
- Writing answers on StackOverflow did more for my career than any certification or formal training. Teaching forces you to understand a concept deeply enough to explain it clearly, and that depth compounds over the years.
- The transition from developer to product builder requires a fundamental mindset shift: from “how do I implement this?” to “should this be implemented at all?” That question is the dividing line between coding and engineering.
- Community participation – blogging, speaking at meetups, contributing to open source, answering questions online – creates compounding career returns that are impossible to predict in advance.
- The hardest career skill to develop is not technical. It is learning to say no to features, to projects, and to opportunities that do not align with where you want to go.
- Building a company requires a completely different skill set than building software. The code becomes the easy part. People, strategy, and communication become the real challenges.
I started my career as an Android developer intern in 2009. The emulator took minutes to boot. StackOverflow was barely two years old. The Android developer community was small enough that you could recognise the regular names answering questions. I wrote about those early years in detail in my Android development history reflection.
Seventeen years later, I run a software company named SolGuruz with over 90+ team members. I have answered thousands of questions on StackOverflow, written hundreds of blog posts on TechnoTalkative, organised developer events through Google Developers Group Ahmedabad, and built products across healthcare, fintech, real estate, and SaaS.
None of that was planned. There was no five-year career roadmap. There was just a consistent pattern of building things, sharing what I learned, and making decisions that felt right at the time – some of which turned out to be the most important decisions of my career, and some of which I would do very differently today.
This article is the honest version. Not the LinkedIn version. The real lessons, including the mistakes.
Lesson 1: Teaching Is the Fastest Way to Learn
I started answering questions on StackOverflow not because I was an expert, but because I wanted to become one. The process of reading someone’s problem, understanding their context, researching the best solution, and then writing a clear, tested answer forced me to develop a depth of understanding that simply writing code for my own projects never did.
Over the years, this accumulated. I became a top 0.1% contributor. I earned the Android gold badge. Recruiters found me through my answers. Speaking invitations came because conference organisers saw my activity. Consulting opportunities arrived because potential clients saw that I could explain complex concepts clearly.
Every answer you write online is a permanent demonstration of how you think. Over time, that library of demonstrated thinking becomes more valuable than any CV or certification.
The same principle applies to blogging. TechnoTalkative started as a simple Android tutorial blog. But every article I wrote forced me to understand a topic well enough to teach it. That depth compounded across hundreds of posts and eventually established the technical credibility that made everything else possible.
Lesson 2: The Shift from Code to Product Thinking
For the first several years of my career, I measured success by the quality of my code. Was it clean? Was it performant? Did it follow best practices? Those are good standards for a developer, but they are insufficient for someone who wants to build products that matter.
The turning point came when I started working directly with founders. I would build exactly what they asked for, deliver it on time, and then watch it fail in the market. Not because the code was bad, but because the product assumptions were wrong. The features were unnecessary. The user flow was confusing. The problem being solved was not painful enough for anyone to pay for.
That experience taught me the most important question a developer can learn to ask: “Should we build this at all?” Before “how do we build it” and before “how fast can we build it” comes the question of whether the thing should exist. Learning to ask that question, and being willing to hear an uncomfortable answer, is what separates engineering from coding.
I explored this dynamic in my article on how AI is changing mobile app development for developers and founders. AI has made the “how do we build it” question easier. The “should we build it” question remains as hard as ever.
Lesson 3: Community Compounds in Ways You Cannot Predict
Organising the Google Developers Group in Ahmedabad taught me something that no business book could: the returns from genuine community contribution are impossible to predict but consistently valuable.
A talk I gave at a local meetup led to a conversation that led to a consulting project that led to the formation of my company. An article I wrote on TechnoTalkative was referenced by a developer in the US who later became a client. A StackOverflow answer I wrote in 2012 still generates profile visits today, thirteen years later.
The pattern is always the same: you share knowledge without expecting anything specific in return, and years later, the returns appear in forms you never anticipated. Conference speaking invitations. Partnership proposals. Hiring referrals. Client introductions.
This is not networking advice dressed up as altruism. The returns are real and measurable. But they only work if the contribution is genuine. People can tell the difference between someone sharing knowledge because they care about the community and someone writing content as a marketing exercise.
Lesson 4: The Hardest Skill Is Saying No
Early in my career, I said yes to everything. Every project, every technology, every speaking request, every collaboration. I was afraid of missing opportunities. What I actually missed was focus.
The turning point came when I started running my own company. With limited resources, every yes to one thing is a no to something else. Saying yes to a project that was not aligned with our strengths meant saying no to capacity for a project that was. Saying yes to learning a new framework we did not need meant saying no to deepening our expertise in the ones we were already good at.
The opportunities you decline define your career as much as the ones you accept. Focus is not about doing more things. It is about doing fewer things at a higher level.
For developers early in their careers, this is counterintuitive. The instinct is to learn everything, accept every project, and build breadth. And breadth matters early on. But at some point, the highest-leverage move is depth: becoming genuinely excellent at a specific thing rather than competent at many things.
Lesson 5: Building a Company Is Nothing Like Building Software
I assumed that because I was a good developer, I would be a good CEO. That assumption was wrong in almost every way.
Software development is deterministic. You write code, you run it, and you get a predictable output. You can test it & debug it. Cause and effect are usually traceable.
Running a company is not deterministic. People have motivations, insecurities, aspirations, and communication styles that do not compile or produce stack traces. Strategy involves making decisions with incomplete information and living with the consequences. Revenue depends on factors outside your control. Hiring is a skill that cannot be automated.
The technical skills that made me a good developer are maybe 20% of what I use as a CEO. The other 80% is communication, people management, strategic thinking, financial planning, and the emotional resilience to handle the uncertainty that comes with building products from scratch. Nobody tells you this when you are a developer dreaming about starting a company. They should.
Lesson 6: The Technology Changes. The Principles Do Not.
I have lived through Eclipse to Android Studio. Java to Kotlin. XML layouts to Jetpack Compose. Volley to Retrofit to Ktor. AsyncTask to Coroutines. And now, manual coding to AI-assisted development.
Every technology change felt significant at the time. Some were. But the developers who thrived through all of these transitions were not the ones who memorised the latest API. They were the ones who understood the principles underneath: separation of concerns, state management, testing discipline, user empathy, and the willingness to keep learning.
The specific tools do not matter as much as the thinking behind them. Compose and SwiftUI look different, but they share the same declarative principle. Kotlin Coroutines and Swift’s async/await solve the same concurrency problem. AI coding tools change how we write code, but the architectural thinking that determines whether the code is any good remains entirely human.
What I Would Tell My 2009 Self
If I could go back and give the intern version of myself three pieces of advice, here is what I would say:
- Write in public from day one. Every blog post, every StackOverflow answer, every open-source contribution compounds over time. You will not see the returns for years, but when they arrive, they will change the trajectory of your career. Start before you feel ready. You will never feel ready.
- Learn the business side earlier. Understanding how money flows through a software business, how clients make purchasing decisions, and how products find their market is just as important as understanding how code executes. The developers who understand business context make better technical decisions.
- Protect your focus ruthlessly. Not every technology trend needs your attention. Not every project needs your time. Choose the things that compound: deep expertise, genuine relationships, and work that you are proud of. Everything else is noise.
The journey from answering questions on the internet to running a company is not a straight line. It is a series of small decisions, each one building on the last, with long stretches where it feels like nothing is happening. And then, looking back, you realise that everything was connected. The modern Android development guide I wrote recently is a technical document on the surface. But underneath, it is the product of 17 years of accumulated decisions, mistakes, and lessons that I could not have written at any earlier point in my career.
The best time to start building in public was 2009. The second-best time is today.
