← Blog

From building to engineering software

#learning #work

A case for software engineering

Recently, I had a chance to read Modern Software Engineering (2022) by Dave Farley, a veteran software engineer best known as a pioneer of the Continuous Delivery paradigm for developing software. I can’t say I’ve read many books on software engineering, but this book gave me an impression that it might be an instant classic for the genre, on a par with other classics like The Mythical Man-Month by Frederick Brooks, The Pragmatic Programmer by Andrew Hunt, and Refactoring by Martin Fowler.1

The book presents an ambitious yet well-reasoned argument for what “software engineering” should be. It starts with defining what engineering is (“practical application of science”), then goes on to dicuss:

  • Why engineering matters to software (“craft is not enough”);
  • How software engineering differs from other types of engineering (“design engineering, not production engineering”);
  • Which measurements are most relevant to software engineering (stability and throughput); and
  • What software engineers can do to improve such measurements (be experts at learning and managing complexity) as well as how (Parts II and III).

This blog post is not intended to be an in-depth review of the book, so I won’t delve into details regarding, say, the suitability of specific recipes in this book to achieve these goals. For instance, many people still have genuine, good-faith questions on the effectiveness of Test Driven Development (TDD) in building software,2 which is considered a key element of optimizing for learning as well as managing complexity in Modern Software Engineering.

Nevertheless, I do find Dave Farley’s argument to be a compelling one. I am convinced that software engineering should be an iterative process of continuous experimentation; that managing complexity is critical to the success of software projects; and that building high quality software requires more than diligent craftsmanship—expecially at scale and in the commercial context.

The first glimpse into the software engineering industry

Also recently, I went through an interview process. Unlike the one that got me to my current position about two and a half years ago (a series of conversations and a take-home task), this one was done in a more standard “tech interview” style, consisting of a few rounds of coding interviews, a system design interview, and a behavioral interview.

I’m well aware of the fact that this kind of “tech interview” is a hot-button issue in the industry, and I’m not here to argue whether this style of interview is a definitively good or bad way to gauge candidates’ qualification for software engineer positions. But I can say that I gained a lot from going though it for the first time.

I’m not sure how to best articulate what I gained from this interview process, but one way to put it would be this. Reading books and articles on the “tech interview” process in general, practicing coding and system design interviews, researching the company I was interviewing for (a highly regarded “tech company” as well as a household name), and finally talking to my interviewers who are accomplished engineers at varying stages of their careers—these all pushed me to expand my horizons and the scope of what I think of my work. Maybe I can call this a new pespective, gained from taking a peek at the software engineering company and the industry.

Yes, I have been building almost exclusively single-page web apps that run on browsers. Also yes, the position I interviewed for was called Web Engineer. However, if I were to be hired as a Web Engineer at the end of the interview process, I wouldn’t be paid to build web apps but to solve problems and satisfy needs with software—by contributing to an ongoing engineering enterprise at scale.

My step toward becoming a software engineer

Here, at the final third of this confused blog post, I’m overjoyed to reveal that I’ll be joining Spotify as a Web Engineer!

I’d be lying if I said that I’m not proud of myself for breaking into a “Big Tech” company. Or that I’m not happy to see that my salary has more than tripled compared to when I was still working for the state government less than three years ago. I’m utterly dumbfounded as I type out these words. 🤯

Most importantly, however, I’m delighted to be a part of a team and an organization that puts software engineering front and center.3 I’m convinced that Spotify’s organizational structure and engineering culture embody what Modern Software Engineering advocates. Spotify “believes that speed of iteration beats quality of iteration”, which is another way of saying they optimize for learning by keeping feedback loops tight. Spotify teams are small and operate autonomously, which is only possible at Spotify’s scale if they optimize for managing complexity.

In other words, to me, joining Spotify means participating in genuine, industry-leading efforts at software engineering. It’s an exceptional opportunity for professional growth and a distinct privilege that not many builders of software get to enjoy. I very much look forward to it!

Footnotes

  1. These books are my personal favorites on the subject matter and there are certainly more books providing timeless insights. And, of course, people may have different opinions on whether they are “classics” or what counts as one. ↩

  2. One recent example of such questioning can be found in this Hacker News discussion. ↩

  3. Here I do not, I repeat, do NOT mean to say that my current teammates do not take engineering seriously. However, it is difficult for many small software teams juggling multiple projects and impending deadlines to prioritize setting up infrastructure and processes to support its engineering efforts. Intended or not, sometimes that’s just the reality. ↩