I started my first full-time job on January 20, 2003. Twenty years on, I’ve decided to look back at what’s changed and what hasn’t in my world of software development. These opinions are strictly my own and don’t represent those of my employers, past or present.

The early 2000s were an unfortunate time to be graduating from college with a degree in computer science. The dot-com bubble had just popped, sending stock market valuations and employee counts plunging at previously high-flying startup companies. Some of my classmates, sensing the sudden shift, changed majors, opted for graduate school, or sought jobs in other industries. I tried to apply at every company that appeared to be hiring, but after my exhausting search, I had two job offers to consider: one at Computer Associates, the conglomerate software company where I interned in 2001, and one at CombineNet, a startup co-founded by my artificial intelligence class’s professor. Each offered me about $50,000 a year, with no grants or options of publicly-traded stock. I opted for the startup.

At CombineNet, I built front-end software quickly and made product decisions on the fly. I greatly enjoyed my time building procurement applications for clients large and larger, learning about the tradeoffs and processes that weren’t taught in school. As the tech world gathered itself up again, newer companies like Google started to go public and grow like gangbusters, offering lavish pay packages and fringe benefits. After doing a couple of cross-country flights for on-site interview loops, I moved to Seattle to become a junior software development engineer (SDE I) at Amazon in 2006.

Shortly after arriving at Amazon, I fell into all the traps for inexperienced developers. I tried to learn everything about Amazon’s tech right away. I presumed that Amazon had established, polished, and consistent processes written in thick binders, as Computer Associates had done for the benefit of its ISO 9000 auditors. I had to learn what the industry now calls “DevOps,” that combination of developing and operating services at large scale, and maintain key services on impossible-seeming timelines and budgets. The financial crisis began about a year after I moved to Seattle, and many tech companies either went out of business or went into austerity mode, slashing expenses and limiting hiring. In the late 2000s, I considered transferring to Amazon Fresh, the company’s then-new grocery division, but decided against it, worried that the company might shut it down. (More than a decade later, Fresh is still in business.)

Joining Amazon with 3 years of startup experience was very much like enrolling at a challenging university: any pride I felt from getting in was overtaken by the realization that I was surrounded by people with more knowledge, skill, and experience than I had. As a former colleague told The New York Times for its infamous 2015 article about Amazon’s culture, “Amazon is where overachievers go to feel bad about themselves.” In addition to learning the challenges of building and operating services at scale, I worked with mentors, managers, and peers to build up soft skills, such as to be persuasive but not political. I had to learn to push back, but not punch back, when I disagreed with something. After four years working on Amazon’s email platform, which was vital but relatively slow-growing, I transferred to the Kindle bookstore team, which had just split from the device sales team and which had six engineers including me.

Kindle was in a hyper-growth mode in 2010; we were held up as the physical embodiment of Amazon’s future. My highlights from four years on Kindle included adding support for Audible audiobooks and other content types to the store; supporting new stores for touch-screen E Ink devices, Amazon’s color tablet devices, and third-party devices; and leading development of Kindle Owners Lending Library (now Prime Reading) and Kindle Unlimited, a subscription service that offers access to over 3 million books (including mine). By reading The Elements of Scrum and following its lessons, I turned myself from a Scrum skeptic into a Scrum Master in a matter of weeks. After four years, my team had grown from 6 developers to over 100, including a fully-staffed team in India with whom we shared our on-call rotation for follow-the-sun support. I conducted over 300 job interviews, including all-day and multi-day events, to help grow our team. There were occasional long days and occasional missteps, but on the whole, I am proud of the work I did in Kindle, and I’m still a happy user of the apps and devices I helped to build.

In 2014, I applied for a job at Tableau, a medium-sized company focused on data visualization and analyics. It was the first company I had applied to by myself, without first being contacted by a recruiter, since I was a college student. Half an hour after my interview loop ended, as I was arriving home, a Tableau recruiter called me to tell me that the company liked what they’d seen and wanted to hire me. Tableau in 2014 was, like Kindle in 2010, in hyper-growth mode. I spent my first 3-plus years working on visual formatting, storytelling, and dashboards, focused on bringing these features from our desktop clients to the web. I had to lean on my experience doing rapid web development at Amazon, while also respecting Tableau’s distinct and supportive culture. Tableau’s core values at that time defined “honesty”, “respect”, and “work as a team” in explicit detail. I supported five Tableau Conferences in person, three of which were in Las Vegas, and met up with countless customers who were passionate about the work that my teammates and I built.

At Tableau, I worked for over 3 years on the Formatting team, and then transferred to build what’s now known as Tableau Catalog, a metadata system for our largest customers to manage the data they use with Tableau Server. That required me to learn TypeScript, a new language for me; GraphQL, a new query language; and Apollo, a new library that can generate TypeScript from GraphQL schemata. I found Tableau Catalog challenging because, unlike visual formatting, I’m not the intended end user. We had good product teams and visual designers who connected customer needs with technical goals, and in late 2019, we delivered our first version of our catalog. Our work only continued from there, as we responded to customer feedback and market movements to make Catalog ever better. Salesforce acquired Tableau in 2019; I spent my last two years trying to balance my team’s work with the adjustments to our new parent company and its different culture.

In July 2021, an Amazon Web Services (AWS) recruiter reached out to me, asking whether I’d be interested in working on a team that was building software for AI, machine learning, and computer vision. Almost sarcastically, I replied “yes”; my last AI course had been about 20 years earlier, I had no substantive industry experience with any of those technologies, and I wasn’t sure that AWS would want to interview me at all. These doubts fell away when I talked to Brian, who is now my manager, and who told me about Jupyter, the open source project that he had been building for about a decade, and that AWS now sponsors. AWS is now at the center of Amazon’s open source efforts, and we have executive-level support for open source development. After my first full, external interview loop since 2006, I decided to boomerang back. My team now includes four full-time developers (and Brian still contributes as well) and I also work actively with people at other companies and organizations for the betterment of Jupyter. I’ve also retained the values of respect, honesty, and teamwork that Tableau ingrained in me. I’ve gotten some occasional snickers at AWS by, for example, crediting other people during a demo, instead of hogging the glory for myself. Since rejoining, I’ve also been openly supportive of my fellow developers, providing guidance and mentorship about their professional development. I still believe that Amazon is a great place to work and a great place to build one’s skills as a software developer and service operator.

In a later article, I’ll talk about reflections on my first 20 years in tech, in the form of advice I’d give to people who are earlier in their careers.

Updated: