Day in and out, I was clocking in my shift in a malaise. Days were spent running a meeting, aligning goals, working on a design, prototyping, reviewing, implementing, typical alignment and synergy, you know the deal… I was enjoying the respect I had as a tenured employee. The work-life balance was great. Work was predictable, comfortable. Despite the comfortable position I made for myself, I couldn’t shake the idea that I should be doing something more challenging.

A friend called again to recruit me for his seed stage startup. It wasn’t the first time he reached out, but this one time out of many I was finally in the right place and the right time. I weighed the risk of jumping from a cushy job to something that potentally had more opportunity. I mulled over that this may be my last chance to give it my all and try something risky. Recognizing the allure of opportunity and with a dose of a fear of missing out, I joined my second startup as a founding engineer.

Philosophy of a Founding Engineer

I anticipated that the roles and responsibilities of a founding engineer would be much more involved than from any early stage employee. I knew the experiences I carried with me from my first startup would not help me much here. I needed to be comfortable with the idea that carrying my own weight is not enough. I would have to carry the weight of my team. This was the first time in a long time that I was feeling the pressure. But as they say, ‘Something pressure creates strong diamonds…’.

How do I build this in a way so that the next developer doesn’t fuck it up

Years of engineering baggage from my previous company greatly influenced the engineering philosophies I wanted to carry at my new job. One value my CTO and I were focused on was building systems and patterns to not only make mistakes unlikely but impossible. Along with all the typical systems needed to build a web app, we built systems around composable permissions, ‘fail proof’ transactional emails, system-wide consistent api error structure, logging and handling, front-end resource caching… A new category of design consideration for me was “How do I build this in a way so that the next developer doesn’t fuck it up” We were only 6 months in into a fresh codebase and already had ~500 regression tests written for a huge swath of POC’d features.

I experienced coding nirvana as I had full context and understanding of why decisions were made how systems interacted with each other. I felt empowered to tear systems down and replace it if needed. I experienced the joy of building everything from a blank canvas and the frustration of having that code be replaced. Previously I only experienced carefully tiptoeing around monolithic code bases to insert my tweak, fix, or feature. I never realized the joy of creating the system, defending it, then seeing the decisions be validated by your team being productive. The joy of having a command of an entire codebase or architecture is something I would encourage every developer to pursue and experience.

I also experienced coding hell as the team ignored the vision. New team members were brought on, constraints were being introduced which resulted in the slow complacent degredation of the code base. Small hacky allowances were made to meet a deadline. Deployment processes were side-stepped to reach the customer faster. Team members start rewriting parts of your vision, fundamentally misunderstanding the intention. You build your castle out of Legos and yet a few weeks later you find a load bearing Duplo block. This I saw as inevitable but it hurt more when you own a bigger part of it.

Product Market Fit

We had an engineering team but we struggled to find a product to ‘engineer’. It seemed that we were working backwards where we had the tools (AI.) and were trying to find a product, instead of looking at the problem (job readiness) and solving for that. We tried a few ideas but they never took off. Whether its because we didn’t give them enough time to bake, or if it was clear there was no impactful solution. Regardless, we were grasping for straws. Day by day, it became clearer to me that the well intentioned mission statement of helping university students find jobs would require more than just spinning up a new AI powered product; it’s AI itself that is actually the problem.

The advent of generative AI and the speed of adoption is truly a poison on recent graduates. Organization are disincentived to hire junior talent in lieu of a computer that can produce similar output in minutes rather than days. Not only that, organizations today are using AI as an excuse to mask slowing quarterly profits, reduce hiring, layoff workers in the hopes to both pad their quarterly balance sheet and stifle worker wages. This means that university students will have to compete against both AI as well as those senior talent that have been laid off by AI. Attempting to fulfil the mission of helping university students to find jobs using an AI product is a well intentioned but misguided shot at the core problem.

Onwards

Shortly after one year, I became redundant. The company didn’t have a need for a large technical team for a product that didn’t need a technical solution. I was given an offer to leave which I took.

Working here transformed my understanding of work and motivation. There was about 3 months where I’d be on the laptop from 9AM to 11PM moving from task to task deploying at least 2 non-trivial feature prs and providing feedback for my team every day. Weekends are normal work hours from 10AM to 6PM. This is not an exaggeration. I’m incredulous myself to see this written down in ink but I have to iterate again, this is not an exaggeration. I felt possessed. I didn’t feel fatigue, I didn’t feel hunger. I felt numb in the same way you feel numb on a good run. It was a fast acting loop of problem, solution, dopamine, problem, solution, dopamine. If I thought of something quick to implement late at night, I’d go for it. Problem, Solution, Dopamine. It wasn’t the dopamine I was chasing, but my shot at filling the chip on my shoulder. Even today, I still have something to prove.

I’m incredibly proud of the high quality code base I left behind. The frameworks, the patterns, the components, I wish I could have taken with me. I gave a lot of love to the platform and it loved me back in return.

Onwards to better things.