I am an engineer from Pune, India. This is the first chapter of how I got here, written for the friends and colleagues who asked, and for anyone starting out with a gap in their record.

Writing this sharpened how I see those years. The first version was too blunt and got parts of my own story wrong, so I keep editing it.

The two missing years Link to heading

I graduated in 2011, two years later than planned. It did not bother me then and it does not now. People who learn it are surprised, so here is why.

I was an average student. Studying was not hard. The world I saw around me did not run on marks, so I never saw the point. It runs on merit more than I believed then. Not all the way, but far enough that this post is my attempt to show mine.

In the second year of my degree I left to work with computers. Assembling machines and installing pirated Windows was one of the few ways to earn from a computer in Pune then. It paid for smokes and beer and taught me one thing: writing software was more fun than screwing boards into cases, and nobody would pay me to write it without a degree.

I tried the other door first. I sat a basic test for a technical support role and failed it. So I went back to finish the degree, with no plan beyond “a graduate can get an IT job”. I doubted I could study again after two carefree years. My family and friends kept me going, and the friends kept me drunk and high, often the same evening. Being wasted is no way to live, and those were still the best days of my education. The people and the years between 2007 and 2011 gave me the resolve and the self-belief I run on now. I do not regret the gap. Without it I would be someone else, and it is where I found the work I wanted to do.

The first computer my friend and I sold: an Intel Core 2 Duo, 4 GB of DDR2 RAM, a 256 GB Seagate disk, a Logitech keyboard and mouse, an 18-inch display and 2.1 speakers. It cost us about ₹20,000 to build and sold for ₹31,000. ₹11,000 on one sale looked like an insane margin to us. At our peak we sold maybe five to ten machines, plus a lot of OS reinstalls and upgrades. A distant relative of his bought it, for home use rather than work. My friend later left IT for the travel business.

My sister was starting her career in IT around then, first at a small firm, later at a multinational, in .NET and C#. I remember her books, five hundred pages and more, full of symbols I could not read. That glimpse woke up something from the C and C++ I had written in first year. Those programs were not “Hello world”. A professor wrote them, we retyped them and followed instructions to finish the assignment. They took user input, which confused me: after the binary ran I did not know where to click, because he never said what came next, by design or by accident. Until then a PC was for entertainment, and for some work I could not name. The small command line programs from that year stuck with me, and they still pull me harder than web development does. That is why I chose computers over the family trade.

My father Link to heading

I worked in the family business with my father from before I can remember. On paper he holds a diploma in electrical engineering. In practice he is the first engineer I met. He supported me and was disappointed by my choices, both at once, and he taught me more than anyone outside a handful of teachers. I still learn from him.

One thing I took from him without him ever saying it: be loyal to your work, everything else comes second. I overdo it. I have pushed family, friends and colleagues away to finish a piece of work more than once.

The family business is electrical generators. Around 2003 my father left his job and started M M Electricals, electrical and power solutions for businesses. Through him and his customers I learned how electricity behaves, how a generator works, how a telecom tower runs, how a manufacturing plant is laid out and what ancillary work means. All of that before I started my degree.

I remember an engine overhaul on a 250 kVA generator with him. One technician from our firm worked on the engine under my father’s instructions. The canopy was cramped, and being young and small I fit into corners to watch up close. The mechanics were not new to me; I had seen vehicles stripped and repaired before. What caught me was the ECU, the electronic control unit, which in my head was a cousin of the CPU. My father explained that it comes sealed from the manufacturer, delicate electronics and a program you do not touch, and if it needs changing the manufacturer sends a trained technician. The rest was labour, including a trip to a machining shop nearby to fix the cylinder head. We started in the afternoon and finished around three the next morning. What stayed with me: the ECU was worth more than the metal around it, and owning it was how the manufacturer kept control of that engine.

My mother Link to heading

My mother is the most artistic person I know. She never asked for top grades, never told me to study instead of playing video games or going outside. One thing she did teach me: never back down when you are right. It bites me to this day. Had she also taught me what to do when you are right and everyone else is arguing, I would never have learned on my own which battles are worth it.

She draws रांगोळी /ɾaŋ.ɡo.ɭ̆iː/ with lines I could not match with a ruler, and she stitches and crochets. Every day for as long as I can remember there has been a rangoli in front of our house. Her persistence is the thing I admire most in her. Her perseverance carried all of us through the hard years, the ones when my father worked seventy-two hours a week, and I have not matched that either.

There is more to say about them and my brother, and the internet is not where I want to say it. My parents are here because they are the ground my merit stands on.

The course Link to heading

I graduated with a production engineering degree and zero software knowledge. So I paid for a training course that cost more than a month of a fullstack engineer’s salary today. I will not name the institute; I made no connections there worth naming. Java, SQL, HTML, syntax without the reasons. I never heard the words “software engineering” there. My final project was a static website, a fallback, because I could not think of one thing I wanted to build that needed Java. The course got me my first job, and I am grateful for that and for nothing else about it.

The startup, 2012 Link to heading

I started in July 2012 as what I would now call a fullstack developer: Java, JSP, jQuery, MySQL, and deploying to the client’s Linux server myself, all within the first few months. Nobody used the word then. I read it as “responsible from the first line of code to the thing running in production for the client”, and I still do.

I worked for a couple of clients. One was a large HVAC manufacturer whose e-commerce site I maintained and extended. I also worked on the startup’s own product, which introduced me to Lucene, still one of the best pieces of Java I have read. The product listed schools, with details gathered from open data, behind a clean interface where search was the main feature. That is where Lucene came in. The challenge was that data kept arriving, and at first every batch meant restarting Tomcat to rebuild the index. Later I worked out a Java directory watcher that built a second index and swapped it in for the stale one. Whether that shipped I cannot say; it was my last few days there.

I was not the only new hire, so it was a fun place, and the company built things clients paid for. Almost everything I learned there came by copying code: sometimes corrected in a senior’s review, sometimes while helping a colleague, most of all by trial and error. Trial and error is how an early or trainee engineer learns without a guide. It is slow and it works.

Man pages were a revelation. I had not known that the people who wrote programs also wrote documentation. JUnit came next, and through it TDD and BDD, which are frameworks and nothing more. The discipline has to come from the person holding them.

I made stupid mistakes. I used to SSH into the server to run routine commands. The server was live production, database and service on one box. One day, mid-routine, everything worked and then trivial commands started failing. I kept trying, nothing happened, so I closed the SSH session and tried to reconnect. That is when it hit me. I searched in a panic, sure we had been hacked, and what I read shook me. I still had the terminal window open, and as someone on some blog suggested, I scrolled back to my own command. I had typed rm -rf /* when I meant rm -rf ./*. There was nothing to do in that moment. After five or ten minutes I found the courage to tell my manager. It was the first time in my life I felt like a screw-up. A cron job had been backing up everything important, the manager restored it onto the onshore machine, and because it was the middle of the night for the client, nobody was using the site and no data was lost.

I still get nervous typing rm -rf when the argument starts with a slash. Typing with care alone would not have saved me. The lesson was engineering: do not build an over-engineered command when cd into the parent, rm -rf dir1 dir2 and a fresh mkdir does the job. Simpler steps leave fewer ways to be wrong.

I have heard “over-engineering” about my work many times since. Some of it was fair. Most of the time nobody explained what was over about it. If you use the word, say which part and why. Otherwise the other person learns nothing, and neither do you.

One of mine: in Struts2 JSP pages I wrote <s:if> blocks that duplicated whole divs and spans where a single <s:property> would do. That was over-engineering, and someone said so. Former colleagues, reach out and embarrass me with the ones I have forgotten.

The projects went stale for me after a while. Looking back, what I missed was new technology, not new engineering, and the solutions could have been far better than what we shipped. I left in early 2014. Money was one reason. The other was steering a boat with no idea where the shore was, and I suspect the founders felt the same about me.

The finance job, 2014 Link to heading

This was no startup. The founders were in serious financial business, the kind of place where a toilet break counts as outside working hours.

The first project I worked there was old Java on Tomcat, several JDK versions behind. Process and time logging mattered more than ten lines that would have made the code easier to maintain. The one thing that job could have taught me was patience, and I did not learn it. I did learn to fill in a timesheet every day, a habit I dropped the day I left.

Spring Boot and an ESB came into my life there, on services that remediated failed payment transactions. I knew SOAP and REST already; the ESB showed me what they were for. An onshore team changing the same code you work on, with no shared architecture or practices, is a disaster on repeat, and finance is a minefield of it.

I taught myself Angular at home that year. I rebuilt a couple of static sites I had made before, then found a CRUD example with a Node.js backend and an in-memory store, which is where MVC made sense to me. At work I lasted eleven months, which surprises me now. The credit goes to colleagues who kept me sane, and I hope to return the favour. I resigned with nothing lined up. No one at home depended on my salary, no loans, nothing to stop me doing something rash.

One lesson stayed: in that kind of business you move ahead by knowing people and getting on with them, and technology comes last. That was my experience in 2014. It may have changed.

The telecom job, 2015 Link to heading

A huge leap in pay, in career and in life. I was already serving notice, the interviews went well, and they doubled my salary so I would join at once.

I married while I was there. The company name and the salary helped, because the first round of an arranged marriage works the way a recruiter screens a resume.

I am thankful to that job for Tejal. She may deny it, but the company name is what got my resume in front of her.

My manager there was one of the best I have had. His patience and his way into a problem are what I try to copy, with mixed results. I owe him a lot.

I started on Java backend work. Someone noticed my interest in frontend and moved me to a project leading two juniors. They looked up to me, and I was not sure I deserved it. I made sure the work met my own bar, which in hindsight was the wrong bar: the client wanted quantity, and I was optimising for quality. We built d3.js charts and the checkout flow for telecom bundles. For the first time since college I used Pythagoras, to draw angled arrows from labels to pie slices. d3 did not do that out of the box then, as far as I remember.

I never lost my temper with the juniors. Most of the time they were amused by my commentary. I gave direct feedback in one-to-ones, and sometimes wondered afterwards whether I had been too blunt, but nothing in how they treated me said so. It was my first time handing out criticism and praise first hand. The order matters to me: criticism first, because it takes practice to digest, and praise after, because praise given first turns into padding for the criticism behind it. Real criticism followed by real praise is worth turning over for days. That is how I want it. Others may want it another way.

I was growing sideways, more fullstack skills and now some mentoring, and not upward toward what I wanted to be, which was a DevOps engineer.

One project had an automation bottleneck: a pipeline that had to run once two or more related upstream pipelines succeeded, and someone had to trigger it by hand. Jenkins 1.x had plugins for this, but they fired when any one upstream job succeeded, and you had to add a condition to skip until all were green. So I wrote and published a Jenkins plugin, JobFanIn, which triggers a job once several upstream builds are stable. Jenkins was about to change major version and the plugin aged fast, but it is still public. It is also part of why the next opportunity came.

Chapter 2 is here.