Yet, when I showed my friends what I had spent the better part of 2-3 weeks on, the most common reaction was shock that my last post was nearly a decade ago. It's a stark reminder of how much time has passed and how easy it is to let old passions and commitments fall by the wayside. Ironically, the first post was about my public commitment to write more. Whether it's code or words, looking back at your younger self's writing is always a bit cringeworthy - a feeling that only intensifies with the passage of time. Must be tough for authors – I don't know how they manage it. I should try to meet more of them, especially now that I'm in L.A.

But I digress. Other than sharing my observations and experience with anyone curious, hopefully I'm able to nudge some other rusty engineering leaders to get back to their coding roots after seeing both the struggles and the simplicity from my experience.

Motivations

As I've been transitioning away from my day-to-day duties at Brex over the past few months, I wanted to fill that time with things I've neglected, hoping to rebuild some habits before diving into my next adventure. Coding was high on that list, and the more I did it, the more I realized how much I'd missed it. Of course, it's almost always more fun to write code for hobby projects than to work in a massive, technically-indebted codebase with complex CI/CD pipelines and the looming threat of introducing bugs you can't personally commit to fixing.

The next question was what to build. Most of my professional engineering career has been focused on backend services and systems. The last time I wrote any significant frontend code was when I built the original Windows Azure sign-up flow [0]. That project made me realize I'm much more passionate about backend systems, and for the rest of my time at Microsoft and Stripe, my frontend contributions were minor.

One reflection from my time at Brex was that I've not managed to bridge the cultural divide between frontend and backend [1], and part of me thinks we should've switched to a full-stack model when we decided to evolve from Elixir [2]. This seemed like the perfect opportunity to scratch that itch and build some intuition around frontend development. Karri's tweet inspired me to build a personal website as a playground [3].

Initial iteration

I'm a strong believer in using the right tools for the job. After several mentions of Eleventy and reading through their comprehensive documentation, I started building. It went quite well at first – I put together a few layouts using Nunjucks and Markdown templates, and had a basic skeleton up and running within two days. But by day three, I decided to abandon that path and look at Next and Remix instead. There were two reasons for this:

1. The more I built, the more specifically complex things became, particularly with Nunjucks and Eleventy modules.
2. While that was all well and good, a big part of building this playground was to try out technologies I'd use beyond this specific (and arguably simplistic) use case.

I couldn't see myself using Eleventy for anything other than a static website, which is what the framework is designed for. I wasn't getting the learning satisfaction I was craving, so I tacked.

Next vs Remix

To embrace the full-stack mantra, you really only have one language choice: JavaScript. And when working in a codebase at scale, I've found that a robust type system is necessary, so JavaScript -> TypeScript. It doesn't take much research to see that React has won the battle of frontend frameworks, and within that, the top React frameworks are Next and Remix. The holy war characteristics are reminiscent of Vi vs Emacs, Debian vs Ubuntu, MySQL vs PostgreSQL, Python vs Ruby, and so on. So I'll just point out a couple of personal observations and my rationale for the choice:

• Both frameworks have a large overlap in terms of characteristics and abstractions.
• As such, both frameworks require some experience to avoid common pitfalls.
• Next uses more magic than Remix, which means more pitfalls (e.g. dynamic rendering, caching, server actions).
• At the same time, Next has a larger community, resulting in more examples and components specifically for Next compared to Remix.

Ultimately, I could see myself using either of these in a professional environment. I ended up going with Next this time because I already have enough things to (re)learn, so I chose the framework with the broadest content available.

Learning curve

After going through a few YouTube channels (H/T Wesley and Guillaume) and GitHub repos (H/T Lee), I started rebuilding the existing skeleton and looked at some Tailwind components to avoid needing a design degree in the process.

The first theme of complaints was around CSS. It honestly hasn't changed much from what I remember, meaning I still find it intimidating and frustrating. Personally, I found Tailwind CSS easier to manage, but I can definitely see the arguments against the utility-first approach. And most designers rely on Figma to handle the majority of their project's CSS anyway.

Next came what I'd describe as the "random bugs stage":

• When switching between light/dark modes, there was a brief flicker that drove me nuts.
• Turns out using <post> as an HTML element results in a client-side warning. You don't see it unless you open the Inspector, but that was enough for me to have to change it.
• And despite working with a typed language, refactoring isn't always foolproof.
• Furthermore, it turns out I was just trading a client-side warning for a build-time warning, but at least I could fix that.

But the biggest confusion came from server vs client rendering. Despite plenty of literature and videos discussing this in depth, I still fell for it. This manifested in one of two ways:

1. Everything worked great locally but broke when deployed on Vercel.
2. Everything was working great until I made a change, and suddenly posts didn't load on the home page because it had switched to rendering on the client.

Maybe it's just me, but I actually enjoy the pain of the learning curve phase because I tend to learn the most when I'm outside my comfort zone. All in all, I'd rate the pain of ramping up on TypeScript, React, Next, and Tailwind moderate.

Playground

Now that I had a website up and running, I started feeling the urge to broaden the playing field.

First up: analytics. Do I have any real traffic or content? Absolutely not, but that's not the goal of building this. After trying out several products, I ended up sticking with Simple Analytics, in part due to Pieter's endorsement, and also its the simplicity and privacy-oriented design. But honestly, when it comes to pure analytics, I didn't see a ton of differences between the popular products, so I'd probably just stick with what you're familiar with. Outside of basic analytics, I found Posthog to be great, though hard to really appreciate on such a simple website.

Next up was having a database. Does a static website need one? Absolutely not, but that's not the goal of building this. I ended up using Redis from Upstash to simply store some metadata. Managed services like Upstash, Vercel, Supabase, etc. are great for smaller projects, but at scale, I would just use AWS anyway, so I didn't put much emphasis on the provider.

Once there's enough code, it's time to write some tests. This page does a great job summarizing the options for different scenarios. I ended up going with Vitest for unit tests and Playwright for end-to-end testing.

Logging is yet another thing that's not needed for something like this but would be essential for anything serious, so I ended up rolling with both Winston and Pino. Ultimately, more important than the logging framework is how you access said logs, and unfortunately, all popular services get very expensive very quickly.

Every real application has users, and I'd really prefer to avoid rolling my own authN (or authZ, for that matter) in the future. This one was actually tougher than the rest because there are differences, and it's hard to define or achieve an "optimal" solution. The solutions I looked at were Firebase, Supabase, Auth.js, and Clerk:

• I wanted to stay away from Google services since I'm much more likely to use AWS vs GCP, so Firebase was the first to go.
• I would have probably gone for Supabase for this specific instance (just like I ended up using Upstash), but much less likely in a production environment at scale, so I decided against it (but generally found it pretty great, and Thor is amazing).
• Both Auth.js and Clerk were nearly indentical in terms of technical integration, but the latter provides a lot more on the management front (both components and admin dashboard capabilities).

I ended up going with Clerk, and honestly, if the pricing model scales for your business, I would highly recommend them. It's extremely polished, and the team has several security-focused engineers. The easter egg is on my About page.

Present incarnation

Building this has been fun, and in terms of an "experimental playground," it has met the goal. I'm sure there will be more random things that I will want to dig into. For example, last week I was learning about and experimenting with fonts, and I'm curious to explore more advanced CSS techniques like animations and responsive design. Simultaneously, it has also increased my desire to write a few more posts over the summer (I've learned better than to commit to doing it while I have a demanding job). I'm also considering delving into topics like performance optimization and accessibility. The beauty of a playground like this is that the possibilities are endless, and I'm excited to see where my curiosity takes me next. If you have any suggestions for things I should try to add, or write about, please send them over.

[0]: When I say "meaningful," I quite literally mean "the entire." I've reflected on this many years ago, but it's unfathomable that the main engineer for the sign-up flow when launching one of the biggest strategic investments at Microsoft was someone 2-3 years out of college. I tried to find some screenshots of said flow, but the closest I could get is the start of the sign-up flow. It doesn't take a hyper-creative individual to imagine what that looked like after seeing this.

[1]: When I joined, there wasn't any organizational structure in Engineering, but a small number of engineers were working on the dashboard and website. Frontend engineers had their own habits and routines, which was likely a coping mechanism for being the vast minority of engineers in the company.

[2]: This topic probably warrants its own post.

[3]: My site was hosted for many years on Ghost, and subsequently on Render and deploying Ghost myself, because I was terrified of going back to touching frontend code.

Senior-level transitions aren't often discussed. Having observed many firsthand, and now having gone through one myself, I want to share more details on the process and how I approached my own transition, in case it's helpful for future leaders going through their own. Transitions at this level involve a unique set of challenges and opportunities that aren't broadly visible. Whether you're an executive facing a transition, a founder preparing for leadership changes, or simply interested in the dynamics of high-level corporate shifts, I hope these reflections can offer practical guidance and a deeper understanding of what makes these transitions successful.

Definitions

Throughout this post, I will use the following terms interchangeably:

• Employee/Executive/Individual/Leader: The person departing.
• Manager/Founder/CEO/Company: The person's manager.

Different situations

Departures fall into one of three categories, and while the first one might be the most common, the mutual bucket is the one that I would hope we, as an industry, invest more into making the norm.

Asked to leave

Most senior departures, at least within startups, fall into this category. Good managers ensure it's not a surprise and handle it with dignity. Unless the person did something egregious, people from afar won't know directly they were asked to leave. I mention this not to sensationalize the post, but because you might think many executives leave under mutual terms, which contradicts the opening premise above. It's also true that by the time the departure takes place, there probably is a mutual agreement to a certain extent. If feedback is delivered properly, the executive eventually realizes it's time to move on. This is especially true for senior individuals who have likely been in the manager's situation before.

Despite the negative connotations, there are many reasons a senior individual might not be the best match for a specific company beyond poor performance [0]:

• Stage mismatch: The executive was successful at companies operating at a different stage. This often happens when someone from a larger company joins a smaller one. The size differential influences how an executive needs to operate to be successful: org sizes, timeframes, and support roles differ vastly between large and small companies.
• Scale mismatch: The executive was initially successful, but the role's scale outgrew their trajectory. This is often the inverse of the previous reason, where the scrappiness valued early on is no longer sufficient, and they're unable to grow their scope to meet business needs. [1]
• Culture mismatch: The individual doesn't adjust to the company's unique way of operating. This is often a root cause even when other reasons exist. The earliest sign is when senior leaders don't take the time to understand how the company works and instead approach everything with "this is how we've done it at $past_company." [2]
• Hiring mismatch: The executive fails to hire great people, hurting their ability to scale and eroding trust in their abilities. A common failure is hiring ~exclusively people from their past company [3], which I caution against, especially in the first year of a new executive's tenure.
• Inadequate autonomy: The executive needs more direction from the CEO, or isn't able to navigate sudden changes. This is one of the most surprising, yet not uncommon reasons I've witnessed, as it can affect both up-and-coming executives as well as seasoned ones. For the more seasoned ones, they often join from well-established companies with mature businesses, where the CEO and CFO provide very specific guardrails. At the opposite end, many who are first-time executives want to prove themselves and demonstrate they can be independent, while also lacking the confidence to push back efficiently. Often this leads to strategic misses in prioritization or execution, which can take over a year to realize, by which point it’s difficult to recover.

Before moving on, a couple of closing thoughts on this category:

1. The more senior one is, the more nuanced their role, and the more intertwined their responsibilities. This often means a combination of reasons preventing an executive from achieving the stellar success expected.
2. For executives, "right match" is much more applicable than for other employees. I've worked with executives who were wildly successful both before and after an unsuccessful stint. The vast majority of situations where a senior leader wasn't the right fit worked out well once they found a better place for them.

Mutual

While ideal, this scenario is unfortunately not as common. Many departures categorized as mutual are actually initiated by the company. Genuine mutual agreements occur when the founder and the executive have open and honest conversations about what's best for them and the company, often after many years of working together.

Common reasons for mutual departures include:

• Bigger role: Desire to move from leading one major function to multiple (e.g., E/P/D to E+P+D, COO to CEO).
• Different role: Desire to transition between operator and investor roles, or less commonly, moving between tech and non-tech or corporate and non-profit.
• Founding a startup: Successful executives often want to apply what they've learned from the founders in their company and build something on their own. [4]
• Different stage: Some executives prefer applying their playbook to companies at specific stages, while others want to experience the challenges faced at various stages. Early-stage executives might leave when the company grows beyond their preferred stage.
• Burnout: The individual needs a break after years in a high-growth, high-intensity environment.
• Retirement: After years of booming success in tech, some executives choose less demanding roles like advising, angel investing, or sitting on boards.

The key here is open dialogue and collaborative planning. Signs of mutual departures include long-tenured executives, transparent communications, thoughtful transition planning, overlap between outgoing and incoming leaders, and often a continuing relationship between the executive and company.

Quit

More common at larger companies with many "executive" level employees, this category shares many reasons with mutual departures but includes a surprise element, requiring the company to scramble. Even when an opportunity is too good to pass up, there should be better communication and planning.

The most common reason is stagnation, where the leader feels the role or company is slowing their growth. This might lead to a "Head of" leader taking a C-level role elsewhere or making a lateral move to a company with a better brand or faster growth.

Just like the first category, there's usually a lot of nuance here as well, with a mix of reasons contributing to them quitting. The main emphasis is on the disruption caused by the departure timeline. Open dialogue in the mutual bucket allows for succession planning and flexible timing, but when someone has a new role lined up before communicating their intentions, timelines get significantly compressed.

Personal situation

As you might have already picked up based on my advocacy, my departure from Brex falls into the middle category. After three years at the company, I started having yearly conversations (typically over long walks) with the founders about what I loved about the role, what I wasn't excited about, and what interested me growth-wise. When people have asked me in the past what career conversations look like for executives, this broadly fits my expectation in terms of both cadence and substance. To their credit, the Brex founders were very good at pushing me out of my comfort zone outside these yearly chats. For whatever reason, I would schedule these towards the end of the year, and 2023 was no different. As I reflected on the past year, the upcoming year, and the standing agenda for this meeting, I realized that I really wanted to build something from scratch at some point. This was a new desire for me; previously, I was more interested in being an operator rather than a founder. For a myriad of reasons that could warrant their own post, that has now changed, and the question became “when" rather than “if”. So after further discussions, we decided to promote James, transition my day-to-day responsibilities in the first half of 2024, and have me remain an advisor for the foreseeable future.

But I was not always this methodical and forthcoming. I wrote the third category above based on my departure from Stripe. I was among the most tenured leaders, with great relationships with both founders and the executive team. When the Brex opportunity came up, I wasn't looking to change roles, but it was one of those opportunities I didn't want to regret passing on. At the time, I didn't feel I was doing anything wrong, but in hindsight, I regretted not being more transparent throughout the process. This is why I vowed to avoid making the same mistake at Brex and started having those open conversations earlier on.

This experience taught me just how immensely valuable honesty and open dialogue are in professional relationships, especially at senior levels. It's a lesson I carry with me and coach others navigating similar waters in their careers.

Blueprint

While I was leading multiple functions, this section focuses on Engineering, as that's most pertinent to CTOs. My transition took place over five months, with specific goals each month to support the new executive and the company, while progressively removing myself. I also incorporated advice from other executives who have undergone similar transitions. In my case, we promoted a well-respected engineering leader, so I didn't need to focus on onboarding a new hire, which is more typical in transitions.

Goals

I approached the transition by considering both "what would I like to see happen" and "what are the failure modes to avoid." My primary goal was simple:

Do everything in my power to maximize the odds the new executive will be successful.

This means ensuring a smooth ramp-up into their new role and anticipating long-term risks. Here are some common failure modes:

• Over-involvement: As a long-time leader, people default to asking for your opinion. I reserved giving my opinion only when asked by the new executive or the CEO, and avoided sharing it with other senior engineering leaders unless previously aligned.
• Presence distraction: Your presence can distract a meeting. People need to feel comfortable challenging past decisions, which is easier without you in the room.
• Insufficient context awareness: You need to stay plugged in enough to provide context when needed. Observing nuances first-hand is crucial, especially in the beginning.
• Crutch-enablement: Senior leaders might seek your endorsement for their proposals, but this can be a crutch. People need to learn to work together, including through disagreements and conflicts.
• Excessive communication with external stakeholders: External partners and board members might seek your insights about the new executive. You don't want to put yourself between them and the new person.

While tempting to help, it's better to provide context rather than advice since your time there is limited.

I was explicit with both the new executive and the CEO that they should question and reverse any decisions I made. This was to ensure they felt empowered to lead in their way.

Execution

I planned to reduce my involvement by one day per week each month. In February, I was involved full-time; and by June, I was down to one day per week. This schedule didn't always follow exactly, but served as a good forcing function to make myself unnecessary.

In the first month, it felt like onboarding a new hire. I led many meetings and spent considerable time providing context and solving problems. This month included performance reviews, which required my involvement due to the backward-looking nature of discussions. I stopped attending the weekly executive team meeting and had my last quarterly Board of Directors (BoD) meeting to ensure I didn't overshadow James.

In March, my focus was on our release process and providing context in areas James wasn't as familiar with, such as infrastructure, vendor management, and compliance. I stopped attending the weekly engineering staff meeting as my contextual input was no longer necessary.

April featured our week-long company-wide conference (One Brex), which provided an opportunity for final in-person 1-1s and feedback on the transition. The rest of the month involved navigating some brewing cross-functional tensions. At the end of the month, I left the executive Slack channel, shifting to an external approach moving forward.

May focused on tying up bureaucratic loose ends, like updating compliance documentation and ensuring James had all the similar IT access I did. I also spent time in 1-1s saying goodbye and made my last trip to the SF office.

In June, my involvement reduced to one day per week, mainly answering questions and celebrating team successes. It was unexpectedly gratifying to see the team achieve major accomplishments without my direct involvement.

This timeline could certainly be compressed, although I didn't cover transitions for other functions I supported. I found the sweet spot is somewhere between two and four months, which is generally the onboarding time for a new hire.

Departing thoughts

Executive transitions are a critical juncture in any company's journey. They represent not just a change in leadership but an opportunity for growth, fresh perspectives, and renewed energy. My experience has taught me that the key to a successful transition lies in open communication, thoughtful planning, and a genuine commitment to the success of both the incoming leader and the company as a whole. Despite all the thought that went into this, I still made several mistakes:

• Being too structured at the start and too unstructured towards the end.
• Feeling frustrated at times, as I was neither working at my full capacity nor taking a break.
• Occasionally giving advice despite my best efforts to avoid it.

If you're facing a similar transition, whether incoming or outgoing, I encourage you to approach the process with humility, transparency, and a focus on long-term success. Empower your successor, be open to change, and embrace the opportunity to support the next generation of leaders. Your legacy will be defined not just by what you achieved, but also by how well you prepared others to continue being successful after your departure.

Many thanks to Ariane, Bruce, David, James, Mark, Michael and Sidd for reviewing this post.

[0]: When I made the decision to join Brex, I went in expecting this outcome for myself.

[1]: This also happens all the time to less senior leaders. The benefit they have compared to an executive is their scope is much more fungible, so they can adjust it and give away their legos much more easily.

[2]: One leader at Stripe who kept saying that in meetings was literally told by a more tenured employee to not say that even if the end solution ends up being the same, because it's a sure-way to get everyone to want to solve the problem differently. Sadly, the leader did not listen to the advice.

[3]: Just like backchannels in the interview process, this can be a positive signal for a newly hired leader when other people are willing to follow them, and it reinforces the founder's decision to hire them.

[4]: During the 2020-2022 period, the biggest cause for attrition at Brex were people leaving to become founders.

To my friends and colleagues, I’m known for staying calm under pressure. Stress hardly seems to faze me, and I carry an air of confidence that sometimes borders on cockiness (though no one’s ever said I’ve crossed that line). But beneath this composed exterior is a whirlwind of thoughts and emotions that I’ve learned to process internally.

In the coming months, I’ll be embarking on a journey I’ve never taken before: becoming a founder. It’s a path filled with unknowns, and if you listen to most founders, you’ll hear an endless litany of reasons why it’s a terrible idea. A few months ago, I was chatting with a friend who’s a repeat founder. I told him how I was both excited and terrified about starting something from scratch. He asked me what I was afraid of, and as I’ve had more time to reflect, I decided to write those fears down — not just for myself, but in the hope that others in similar situations might recognize that they’re not alone.

The more I spoke with other founders, the more I realized that these fears aren’t as unique as they might seem. Everyone has their own set of anxieties, and the key difference lies in how openly we discuss them.

So, here's my unfiltered list of founder fears, in no particular order:

• Irrational optimism: The best founders I know believe that anything is possible. They tackle challenges with unbounded optimism, pushing through when others say it can’t be done — and they’re usually right. Can I cultivate that kind of optimism, or can my pragmatic, hyper-rational approach still succeed?
• Vision: Great founders are guided by a clear, long-term vision and have mastered the art of working backward from it, inspiring others along the way. In most businesses, a handful of key decisions can dramatically influence success or failure. Get them right, and you increase your chances of success. Get them wrong, and recovery is nearly impossible. I’ve so far been an operator, someone who executes someone else’s vision. Can I craft a compelling vision and turn it into reality?
• Seeking rejection: Founders must become rejection magnets, constantly putting themselves out there despite the high likelihood of hearing "no." Can I not only tolerate, but actively seek out these situations, knowing that the rare "yes" could be transformative?
• Traveling: With my co-founder in San Francisco and me in Los Angeles, not to mention the need to meet customers face-to-face, how will I balance the demands of travel with my family life? Will a move back to SF become necessary? And how will that impact my loved ones, especially my daughter?
• Jack of all trades, master of... all?: Founders wear many hats, often learning entirely new skills on the fly. Will I be able to learn quickly enough, picking up the essentials of every business function before even considering hiring experts?
• Creativity: I've never considered myself an "ideas person", and been fortunate to work with people who are much more creative than I am. Can I cultivate this skill through networking and osmosis, or is it an innate trait that successful founders must possess?
• Boundaries: At almost twice the age of many first-time founders and with a family to consider, can I find the right balance? Will my tendency to become obsessive about work hinder my ability to be a supportive partner, present father, and successful founder?
• Mediocrity: People think most startups either fail quickly or achieve monumental success. But what about the vast middle ground – the "successful enough" scenario? Can I stay passionate if I find myself running a venture that's neither failing nor soaring, just perpetually adequate? Will I be able to maintain my drive if the magnitude of success falls short of my ambitious dreams?
• Optionality: Will my passion for the business endure for five, ten or more years? What if, along the way, I find something else that captivates me? My entire career, I’ve had optionality and flexibility, but as a founder, I’ll have neither. Will I be comfortable with this shift?
• Relationship dynamics: Beyond my family, how will being a founder affect my relationships with friends and industry peers? If I’m successful, will people be genuine? If I fail, will they distance themselves?

When discussing these fears with friends, a few asked why “fear of failure” wasn’t on the list. The truth is, I’ve never shied away from it. When immigrating to the United States, I didn’t even consider what would happen if I couldn’t adapt to American life. When I left Microsoft for Stripe, I had massive impostor syndrome, moving from a huge corporation to a 100-person startup. And when I joined Brex in an executive role, I thought I was more likely to get fired in my first year than to complete my equity grant. But none of these fears ever factored into my decision-making. Failure is one of the deepest ways we learn, and while I’d prefer to avoid major setbacks, I’m eager to learn from the smaller ones along the way.

I’ve always felt restless when my learning slowed down. This is, without a doubt, the biggest learning opportunity of my career. Despite the fears, my excitement for growth far outweighs them. As I embark on this adventure, I hope that when I look back on these words in a decade, I'll feel the same mix of anticipation and resolve. The path of a founder is uncertain, challenging, and often lonely, but it’s also a journey of unparalleled growth, impact, and fulfillment. Here’s to embracing the unknown, growing through the journey, and bulldozing through every fear.

Seattle is a city full of terrific restaurants with amazing food. And after living there for four years, I'm pretty happy that I probably ate at ~80% of them. But that means that there's still probably over a dozen places that are really tasty which I didn't try out. Even in my last few weeks living there, I was finding little gems, in the form of lunch trucks around the city or small places in Pike's Place. Given that SF has at least an order of magnitude more restaurants, and the average quality is higher due to the inherent competition, a new strategy was needed.

The paradox

The reality is that, in cities like San Francisco or Seattle, most restaurants serve good food. A high number of them have exceptional food. And a few special have something you can't find anywhere else (like Paseo and Salumi). And this is where the paradox comes in: once you have a set of good restaurants, you're guaranteed to have a tasty meal. But by going to the same places, you're missing out on discovering another delicious restaurant, at the risk of being slightly disappointed occasionally.

The plot

Like anything with rules, there are exceptions. The list below exists not to allow me to game the game I set up for myself, but to set expectations for scenarios I know could result in a check-in to the same place.

• Work lunch places -- there's only a few around one's work place, and when I go it's typically in a group.
• Takeout/Delivery places -- similarly, there's only a few around one's home, and it's convenient to be able to get some dinner late at night.
• Brunch vs. Dinner -- the same restaurant can be repeated if one of the meals is a brunch and another is dinner. The menus are typically entirely different, so it's really like trying out two different restaurants.
• Out of town visitors -- hopefully friends from Seattle or other parts of the world will come to SF. When they do, I want to be able to take them to the best places.
• Group events -- if someone wants to have their birthday at a restaurant I already ate at, it would be pretty awkward to try to convince them to go somewhere else because of my silly rules; and it would be a shame to not be able to join them.

The details

So, between October 1st, 2014 - October 1st, 2015:

• you should not see two check-ins at the same restaurant.
• when checking in, each restaurant will get one of the following ratings:
  • Sucks I can't try it out for another year.
  • Meh, probably not coming back for a year anyways.
  • It's going to be much longer than a year until I come back here.
• Exceptional places may end up with a blog entry along with some pictures (and if you're curious about some place, just ping for more details).

There's quite a few people I mentioned this to, who don't think I can pull it through. And given my habits in Seattle, I do agree it's going to require lots of discipline. At the very least, it should make for some fun stories and hopefully great food.

(obligatory #firstworldproblems reference)

After I joined Microsoft I wasn't writing as much. I stopped doing public speaking, so that dropped off completely. Thoughts and ideas were the first to go. And for a while, I attempted to keep a technical blog (on my newly minted MSDN, but that was also rather short lived. Slowly but surely, the only things I would write were Facebook posts, and even those were mostly check-ins and photos.

The excuses are many, and none unique: time, laziness, complacency. Carry a notepad with me; what am I, a savage? Pen and paper are for my parents, I keep everything digitally. But obviously I'm not carrying a laptop with me all the time. And typing on the phone, while appropriate for text messages, is rather inconvenient for anything longer or formatted. After all, nobody reads the things I publish, and nobody really knows about the things I don't.

Somewhere along the way, I lost track of why I was writing in the first place. It was to organize my thoughts. It was to improve my communication skills. And it was for me to keep a history of things that I would otherwise forget. It was never about getting other people's attention, and if a post I wrote helped someone, great; but it was never a goal.

Luckily at Microsoft we used email. A lot. Too much actually, but that's for a different time. Luckily, because it allowed me to continue fine-tuning my communication skills. Most people who know me have realized at some point or another that I choose my words very carefully, especially in written communication. Being able to express yourself in a clear and concise manner is non-trivial, and I've witnessed many failures (my own included) on a daily basis.

But other things started to fade away: I had to give a talk to a larger audience once, and bombed completely. I wasn't really coming up with creative thoughts anymore. And there were those small details I kept forgetting. Most importantly though, I now realize an even bigger problem I was having: I wasn't learning as much. I slowed down writing technical articles because the technology I was using became very familiar to me, so I wasn't solving new problems. Just like my writing was gone, so were my side projects, which in the past were my outlet to working on things outside of work.

So I decided I need to fix this. A few months ago I got myself a nice notebook and a pen I would enjoy writing with, and I keep them with me almost at all times. I started sketching out thoughts, ideas and making lists. Next, I started spending less time doing useless things (like watching TV) and instead working on some side projects and learning new things. Since work was all on the Microsoft stack, I decided my projects have to be non-Microsoft. So I started learning Go, reading more papers and tech articles and building libraries and small systems.

The last part is resuming writing a blog, which is where this post comes in. Even as I had time last month in-between jobs, it was the one thing on my todo list I kept procrastinating. So I'll apply the same strategy that I apply with some of my other work I tend to procrastinate: make some public commitment which forces me to actually do the work, even if subconsciously I know that it's not really critical.

Over the next few weeks I'll write about my recent experiences with changing jobs, the upcoming move from Seattle to San Francisco, new challenges I'll discover in my new job, as well as stuff on the non-technical front. I don't want to set a fixed cadence because I know that won't work. But writing these words down and publishing them to the world, even if nobody reads them (and chances are, few will), will make me write posts. Which will help me. And if they help anyone else, well that's just the cherry on top.

This week was my first week at Stripe, and so far it's been a thrilling experience, even though my mind is still coping with the overload of information it's been subjected to. The people have been extremely friendly and welcoming. The office is both great and in a great location. The food is tasty and the beer selection is spectacular.

I wanted to outline some of the details of my on-boarding process, and compare it to my previous on-boarding at Microsoft. Also, as someone who's been using various enterprise technologies from Microsoft, I was very curious to see what the equivalents are in a small company, so this post will outline many of them.

Pre-start

Upon accepting my offer, I was sent a welcome email in which all of the company was CC'ed. While a very small thing, receiving tens of welcome emails from people in the company makes you feel happy about your choice.

Next up, a few weeks before starting (assuming there is such a period) you get another email in which you get to choose your email address and office setup, including your laptop (with whatever customizations you'd like!). This means that on your first day you've got your ideal environment available. I think this is valuable not only from a productivity perspective, but also morale. At least for us engineers, not having the hardware you want can be annoying at the very least.

This is one of the first contrasting aspects from Microsoft. When you join Microsoft, you also have your computer available, but it's not one that you chose or customized. I can see why having a custom computer for each of the 130,000 employees can have massive operational overhead, but I also believe Microsoft is moving too much in the "one way" side by institutionalizing the same hardware regardless of job or discipline. An engineer has very different needs from someone in sales. Even within engineering, someone focusing on client development has different needs from someone building web services. Empower your people to make the right choices for themselves and they'll be better, more productive employees.

Another difference worth mentioning is what's on the machine. At Stripe, my laptop had my account already created, my SSH keys configured, the VPN set up and the major repositories available. At Microsoft the first thing I did was re-image the box with the IT image, followed by endless hours of setting up the team-specific software (after figuring out all the permissions -- more on that below).

First day

Upon going through an office tour and meeting some people, your assigned spin-up buddy (another employee who helps you out while you're ramping up) goes over some of the common tools used inside the company. After lunch, you get your development environment set up by publishing your photo on the Stripe public website. While a rather trivial process, it acts as a forcing function to get your repositories up-to-date, begin familiarizing yourself with the structure of the code, and push a change through the pipeline just like you would anything else moving forward. I can't emphasize enough how huge this is! I don't remember exactly when my first check-in went through at Microsoft after starting, but I'm 92% sure it wasn't in my first week.

This is where some of the agility and modern tools start being noticed. Going through that exercise was possible because I had access to everything. For the things that weren't already set up for me, my spin-up buddy would give me access, which was instantaneous. One of the biggest complaints I heard from Microsoft new hires was that, after figuring out what permissions you need, there's a 1-3 day waiting period for replication to take place. This practically means that for your first few days, you really can't be very productive, no matter how much you try.

Tools

Most of the things above covered process, but more fascinating for me were the tools used. Before joining, I was rather confident that Microsoft has done a good job at building enterprise products, and the fact that so many companies use them is a testament to their success. Moreover, it seemed nearly impossible for Microsoft to lose its leader position. After this week, I'm less convinced of the latter.

Email && Calendar

At Stripe we use Google Apps, which means every employee gets their email, calendar and directory through Google. You want to schedule a meeting, no problem; there's even support for rooms, and of course it includes free/busy information. All the mailing lists come through Google Apps as well, and there's a nice page where you can see all of them and subscribe to the ones you need. Granted, this works because we're a small company and don't have tens of thousands of mailing lists, but there's nothing preventing that from happening. More importantly, access is immediate. There are no replication delays, or approvals. Filters are trivial to create.

But what I was most happy about is that they've solved the "nested lists" problem. I can't recall how many times I got an email at Microsoft because I was a member of some group that eventually got nested through many layers to some other group, but I had no clue what that initial list was. GMail actually tells you for every email which mailing list resulted in you getting an email. It even does that if the list is BCC'ed! Why Exchange hasn't implemented this after all these years is beyond me.

Notes

OneNote is one of my favorite products from Microsoft. It was available on multiple platforms when the rest of Office was not, and it makes note-taking orders of magnitude better. At Microsoft I would say that information is communicated in one of three formats: email (60%), websites (20%) and OneNote (20%). It wasn't until a few years back that some people started keeping meeting notes in OneNote. But the problem is that there are many OneNotes. Each feature team typically has their own, and they're typically not stored in a place that's easy to find.

Stripe uses Hackpad, which while not as feature-rich as OneNote, does one thing really well: it keeps all notes from any employee in one place. Through Hackpad I've been able to read how-tos and wikis, as well as notes sent by the co-founders or other people to the company and have historical value.

Chat

Basic Instant Messaging isn't a new problem, and it's been mainly solved since the late 90s. In addition to IM, Microsoft Lync also had desktop sharing which was very useful, and conferencing was relatively seamless. There were two problems I had with Lync: it was primarily focused on one-to-one interactions. Yes, you could have group chats, but that was a small minority of how people spent their time on Lync. Second, and more importantly, it was pretty ephemeral. Conversation history was available for the participants but, that was about it. Microsoft never embraced an IRC-like communication channel, and I think there's some very practical cases for that.

Stripe uses Slack and they've solved all three problems: they enable direct messaging within an organization. They have channels which people can subscribe to and discuss various topics. And everything said there is persisted and searchable.

Github

GitHub. 'nuff said.

It's not necessarily where you host your code that makes a huge difference (although I personally think it's pretty hard to beat GitHub). But having a modern, distributed source control technology is invaluable. At Microsoft we spent endless hours debating between Source Depot (an internal technology) and Team Foundation Service (Microsoft's source control product launched a few years back). Both were losing choices. Yes, they each had some advantages and disadvantages, but they were relative to each other. When compared to Git or Mercurial, there were zero advantages.

Luckily Microsoft is moving in the right direction: TFS has added support for Git, and teams are starting to move to that, but adoption will take some time when you're dealing with so many teams and large codebase(s).

A few notes on source control-related topics: code reviews are primarily done via pull requests. Checkins aren't gated since people use feature branches for almost any change, and there is a continuous integration system in place via Tddiumwhich will run all tests with any commit. This is somewhat similar to SNAP or TFS gating, however it has the advantage of being much more scalable since it can test things in parallel and not become a bottleneck.

Logging in

Everything inside Microsoft relied on Active Directory. Any website or tool used those credentials for authentication and authorization. One you logged in, you generally never had to type your password ever again. This was by far the aspect I was most curious about.

My laptop has a local account, and SSH keys are used to authenticate whenever connecting to another server. So far, I think this is a better experience than Microsoft's because I don't have to worry about credentials in different environments, and instead everything is managed through my public key.

Many of the tools have support for Google Account, and in those cases you go through a simple OAuth flow initially, after which you never have to log in again. There are, however, some tools that have their own authentication, and for those you end up creating new accounts.

So overall, it's not 100% centralized, but through OAuth flows it's nearly there.

Closing thoughts

I realized as I was writing this post that the tone can be construed as somewhat negative towards Microsoft. It's really not meant to be, but I do have to admit I was surprised at how well a non-Microsoft stack can function inside a company, even in areas where I believed Microsoft was the standard. Many of these benefits are due to the use of much more modern tools. There's typically no software to install and everything is available via a web interface. The data is all stored in the cloud. The products were built with scale in mind: there are no delays, and replication is something internal rather than visible to customers.

These are all contributing factors, and mostly valid ones. But at the end of the day, employee productivity is what matters the most. If a particular process or tool doesn't maximize productivity, fix it or replace it. Change inside Microsoft is underway. It's just a matter of how long it will take until it reaches the whole company. The sad part is that its competitors not only aren't spending efforts migrating and re-educating, but that they've been living in that "modern world" for a few years.

Now time to get back to learning some new stuff...

According to some recent estimates, about one in four engineers use TDD, a figure that aligns with Google Trends data. Over the past few years, the adoption rate has ranged from 20% to 25%. Based on my recent experience, I believe TDD's popularity will decline.

The rise of LLMs in software engineering

I'm sure you're aware of the increasing use of Large Language Models (LLMs) in software engineering. As a software engineer, you've probably experimented with – if not regularly used – LLMs when writing code, whether through copilots or chat interfaces.

The bad news? The integration of LLMs into coding workflows often renders TDD irrelevant or even incompatible.

The good news? LLMs excel at generating test cases and assisting with test creation, especially for unit tests of well-scoped code. Depending on the model and context, they can handle larger parts of a codebase as well.

My experience using LLMs for test generation

I enjoy thinking about test cases and emphasize comprehensive tests during code reviews. It's crucial to consider testability early in the development process to structure the code accordingly. However, writing tests can be tedious, involving repetitive tasks like tweaking mocks or fixing test race conditions.

In recent months, I've been experimenting with generating tests using LLMs. Here's my workflow:

1. Write the code, whether it's an API, utility function, library, or React component.
2. Copy and paste the code into an LLM, asking it to generate unit tests. I’ve tested various prompts and found little difference between simple and detailed ones.
3. Analyze, try out, and debug the generated tests.

It's rare for the LLM-generated tests to be perfect on the first attempt. Most errors stem from misused dependencies or improper setup. However, the core test cases and repetitive boilerplate code are usually solid.

I use both ChatGPT-4 and Claude 3.5 Sonnet, combining their outputs for the final result. ChatGPT often generates complex, less error-prone tests, while Claude's tests are simpler but require more tweaking. Typically, my final test files are about 70% Claude and 30% ChatGPT.

Why TDD is dying

LLMs are becoming more integral to programming. If we assume all code will eventually be AI-generated, the need for human-written tests diminishes. AI can write both the code and the tests, potentially making tests unnecessary over time.

Even without fully automated coding, in a world where business logic is co-written, the tests can definitely be automated. The inverse is less likely: humans will not write tests while AI writes the entire business code.

Some people really enjoy breaking things, but many more prefer building. Historical trends in software engineering vs. QA roles, and even the TDD statistics mentioned earlier, show an appreciation for testing but less enthusiasm for creating tests. Many engineers view comprehensive test writing as a necessary evil.

Productivity gains from AI

As a former executive, I was often asked about the productivity impact of AI tools like Copilot. Based on my experience:

• Code writing: Tools like Copilot (or Supermaven, which I prefer) are invaluable, akin to Resharper for C# at Microsoft. These tools significantly boost productivity by auto-completing code with high accuracy and increasing complexity. It’s essential for companies to invest in such tools for their engineers.
• Test writing: LLMs save me O(hours) each week, especially in greenfield projects.
• Resource: LLMs are excellent for learning new tools and languages, saving me O(hours) each week.
• Debugging: LLMs are less helpful for complex debugging, but can catch simple bugs. I've probably wasted O(minutes) each week.

Overall, LLMs improve my productivity by about 4-6 hours each week, roughly a 12% increase [0].

Summary

• Use a copilot: It’s a red flag if a company doesn't invest in this for its engineers.
• Leverage LLMs: Treat them as a helpful coworker always available for assistance.
• Automate repetitive tasks: Use LLMs to generate mundane code based on precise instructions (e.g. tests based on code, or a client based on a thorough spec).
• Think longer-term: Current models are the worst we’ll ever use, so future improvements are promising.

[0]: Assuming 50-60 hours / week x 70% builder time