What my first company taught me
Three lessons from a wild first job, and why people remain the point.
My first company was a wild place to start a career, the kind of place where you learn everything in the wrong order and survive anyway. This post is not about the actual job, but about the lessons. I learned many while I was there, but three have stuck with me through the years.
The first is that grit is a superpower, and not the loud kind. It is the kind that just keeps showing up after the day has already gone sideways. The second is that proactive beats reactive, every time. You either get ahead of the problem or you spend your week getting dragged behind it. The third I have been practicing since I was a kid: listening to other people talk about their hard lessons does not shortcut your own. You still have to walk into the wall yourself. But it changes how you receive the lesson when it finally arrives. You recognize it instead of resenting it.
Looking back, the chaos was the gift. A calmer first job would have taught me the same things eventually, just slower and with less conviction. When everything is on fire, you find out quickly what you actually do under pressure: whether you freeze, whether you reach for someone to blame, or whether you pick something up and start carrying it. I learned I was the kind of person who picks something up. That is not a thing you can read in a book or borrow from someone else's war story. You have to be standing in it. In those hard times you forge bonds with the people around you, you get pushed in ways you can't imagine, and you are forced to sink or swim, so you had better swim. Keeping with that analogy, you had also better grab the helping hand or life jacket when someone tosses you one. Leaning on others is necessary in those kinds of environments.
On my first day as a software engineer, I dropped the production database. Once I got past the immediate panic attack, it was time to own up to a horrific mistake. In doing so I built trust, I learned what not to do, and thanks to the people around me, I learned how to act when a bad mistake has been made. I recall sitting in an office, being questioned in pure fascination about how I had managed to drop the database without any permissions. It was during those hours, when it became clear that there wasn't a failure on my part but instead a failure of the process, that I became fascinated by how to develop processes outside of code.
Proactive versus reactive is one of my favorite principles, and one I quote often to the teams I have been on. Look, I love chaos, but I love dependability more. I know first hand that when you are putting out fires constantly, you start to assume every ask or problem is a fire that needs your attention, burnout included. Eventually you need to start making space to look ahead. Sometimes that means you carve out extra time, sometimes you protect yourself or your team with longer-term solutions, and sometimes it even means an escalation. At the end of it all, you and your team need to know not only how to resolve an incident, but how to stop similar incidents with investments in long-term solutions (plus how to pay for that). A healthy team does not think about today's features, problems, or solutions; they consider the items six months from now and how they layer together to build something truly long lasting. Next time there is an incident, lean super far into the COE (or RCA, whatever your company calls it) and use it as an opportunity to be proactive instead of reactive. You may find it bleeds into other acts of software engineering.
Finally, listening to war stories from others is beyond helpful. Take their lessons and internalize them when given the chance. Even small wins come out of them. One of the first projects I was ever given a chance to lead involved a feature for the dynamic loading of potentially thousands of file storage items to display to a user. It wasn't the most difficult feature, but product and our users demanded it be done near instantly. I was slamming my head against the wall until, eventually, a senior engineer and I walked through the possibilities on a whiteboard. As we worked through the constraints, the feature, and the possible solutions, we kept running into the same scaling problem. Finally he looked at me and said, "Sometimes things won't work under the constraints, and you have to say no." As we talked through what that meant, he pointed to multiple moments in his career where the demands being asked simply were not possible at the time. The best you can do is offer a path forward and try to make it work, call out the issues at hand, escalate to stakeholders, and hold an opinion. Truly, I could have tried to force that feature, to make it work for only a segment of customers. Or I could follow his advice and come back with an "it won't work." Leaning on others and learning from their past experiences make you better.
One thing really held up at my first place, and it goes back to a root item for me. Fitting in, or connecting with people, did not come easily to me growing up. As such, it is a little strange that it became the thing I care about most. Every company I have joined, I joined for the people, or for the idea of who we might become together. That is the real reason, underneath all the other reasons, and it took me a while to trust. Joining for who people could become sounds romantic, and I am suspicious of romantic ideas about work. But it has held up. The best teams I have been on were not the most talented on paper. They were the ones where people were quietly turning into better versions of themselves and pulling each other up while they did it. So when I size up a team now, I am only half-looking at where they are today. The other half is looking at the slope, the projection: are these people getting better, and are they getting better together?
So what does it actually take to build a team like that? It takes grit, again, and determination. It means showing up proactively instead of reactively, and doing the small, unglamorous things that protect trust before it ever needs repairing: the one-on-one you did not technically need to have, the credit you handed off, the hard message you delivered early instead of late. It takes clear communication, showing up honestly, and trying to do the right thing on the ordinary days, not just the dramatic ones. That is the job.
I used to work more hours than I cared to count. I work smarter now. Some days still demand the hours, and I am fine with that. Effort is the clearest way to tell a team you are in it with them, and they can always tell.
I do not know yet what the next company will teach me, but I know why I will join it. It will be for the same reason as the last one, the people. It always comes back to them.