I graduated in 2011, two years later than planned. It didn’t bother me then and it doesn’t now. People who learn it are surprised, so here is why.
The two missing years Link to heading
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. 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 kept me going, and my friends kept me motivated, drunk and high all at same time. This may seem sad reality to you, 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 don’t regret the gap. Without it I’d be someone else, and it’s where I found the work I wanted to do.
The first computer my schoolmate 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 in just 8 months, plus a lot of OS reinstalls and upgrades. A distant relative of his bought it, for home use rather than work. He later left computers thing 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 heard the word “Resume” first time from her, and her printed resume was fascinating to me. Her books, five hundred pages and more, full of symbols I couldn’t read. That glimpse woke up something from the C and C++ I had written in first year.
Those first-year programs weren’t “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 didn’t 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 couldn’t 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.
He didn’t teach me this, I learned it from him: “Be loyal to your work, everything else is secondary.” I overdo it. I’ve 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 weren’t 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. 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.
My father explained to me how mechanical governors used to work before ECU. How it’s more efficient now and reduced number of mechanical parts. He mentioned it comes sealed from the manufacturer, delicate electronics and a program you don’t touch, and if it needs changing the manufacturer sends a trained technician. My conclusion 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. She taught me never to back down when I’m right. It bites me to this day.
If I had learned what to do when you are right and everyone else is arguing, I would have saved my time and energy on battles that were not worth fighting like struts vs spring, jQuery vs dojo or Jenkins vs YAML based CI pipelines.
She draws रांगोळी /ɾaŋ.ɡo.ɭ̆iː/ with lines I couldn’t 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 what I admire most in her. It carried all of us through the hard years, the ones when my father worked seventy-two hours a week, and I haven’t matched that either.
There’s more to say about them and my brother, and the internet isn’t 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 won’t 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 couldn’t think of one thing I wanted to build that needed Java. The course got me my first job, and I’m grateful for that and for nothing else about it.
The startup, 2012 Link to heading
I started in July 2012 as what I’d 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’ve read. The product listed schools gathered from open data, and search was the whole interface, which is where Lucene came in. Data kept arriving and every batch meant restarting Tomcat to rebuild the index, until I worked out a directory watcher that built a second index and swapped it in for the stale one. It never shipped and I can’t say why; it was my last few days there anyway.
I wasn’t the only new hire, so it was a fun place, and the company built things clients paid for, which for lot of startups now is just a game of venturing and funding, scale your sail and then sale and bail; on to the next. Almost everything I learned there came by CopyPasta: 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 hadn’t 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.
Overall I was doing good job, it was still not engineering, just monkey wrenching at best, even though I’m an engineering graduate.
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’d 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. I don’t remember their exact response but a slight smile on their face looking at me lifted little weight on my head as I was expecting on the spot termination. 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 wouldn’t have saved me.
It was an engineering mistake and not a typing one.
Don’t complicate the solution: cd into the parent, rm -rf dir1 dir2, then mkdir it again.
I’ve 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’ve 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. You can feel that when a pee break is also considered outside of 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 didn’t 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.
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.
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 to ₹7,26,000 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’m thankful to that job for Tejal. She also comes from Engineering background in E&TC and worked as Test Engineer. This definitely Bollywood scene for me and her a developer and a tester, either you complete each other or you destroy each other 🤣. Till this day she finds my mistakes, not in bad way though, and I wonder how she keeps doing it so consistently. Either I’m very predictable or she out of my league, I’m pretty sure all close colleagues and friends know what the answer is. About my job though 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’ve had. They had such a calm demeanour, always used to let me finish speaking, asked short and sharp technical questions, accepted answer with clear nod or followup questions. Interacting with them was engaging which I always looked up for.
Their patience and way into a problem are what I try to copy, with mixed results. I owe a lot to them.
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 wasn’t 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 didn’t 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’d 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.
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 a pipeline that could only run once two or more upstream pipelines had gone green, and somebody had to sit there and trigger it by hand. Nothing in Jenkins 1.x did that without a condition bolted on, so in 2017 I wrote and published JobFanIn. Jenkins changed major version soon after and the plugin aged fast, it is still public, and it is part of why the next opportunity came.
What I was by 2017 Link to heading
In the start of my career I was not a software engineer, I was an engineer, a production engineer who can write code. What my engineering education taught me, mass, batch, manual, tiered, any way of turning inputs into outputs with people and machines in between, was yet to be useful to me.
I can understand a process of any kind and explain it in simple terms to anyone, and that is my biggest strength.
By end of first job I was junior software engineer with confidence that I understood what makes bunch of text files a software not necessarily in technical depth but process wise that too delivered live production applications.
At the end of second job I was software engineer who can contribute independently and understand how software architecture at large scale systems work. What it takes to collaborate on it with remote peers. And in reality what an enterprise software engineer’s career and progression looks like.
By the mid of 2017 I was specialist software engineer who could do complex application development, publish and contribute in open source world. Got more in-depth with large scale software development and operations. Had experience leading couple of software engineers and directing them technically with organisation practices and what I collected as general best practices of software engineering.
What I would tell myself in 2011 Link to heading
- A two-year gap is not a hole if you can say what you did in it, don’t hide it, it’s only an issue till you’re in.
- Build relationships with people you don’t find likeable, chapter 2 says what it costs when you skip it
- Loyalty to the work will cost you people if you don’t watch it, I have not always watched it.
- Technicians master technology. Engineers apply it to add value and prevent accidents, and a good engineer doesn’t stop at preventing them, they prepare for the one that gets through. In chapter 2 that turns into a job
- Master the protocols, the reasons of algorithmic approach than any tool you master
- Trial and error or troubleshooting based development will get you only so far; what breaks loop is specification and fact based development which comes in many flavours.
You can follow Engineer: Chapter 2 for later years.