Is Software Engineering a Winner Takes All or Auction Profession?

books, algodaily, career, javascript

Table of Contents

Cal Newport has studied the science of high mental performance for years. He's written multiples books about getting better results in school and work, and has recently shifted his attention towards the problems of the modern day technology worker.

Newport himself is an Associate Professor of Computer Science at Georgetown University-- a position he argues requires long periods of deep concentration in order to produce results-- hence his interest in this topic.

In his seminal book about focus, Deep Work, the author makes the case that the ability to zoom-in without distraction on a cognitively demanding task is essential to thrive in today's modern knowledge worker economy. In order to cultivate this skill, he talks about implementing a personal schedule and various work habits that enable deep work (depending upon your profession).

The Job Markets

He also explains that every type of profession can be considered either a "winner takes all" type of market, or an "auction" market.

I'll break down these two types: in a winner takes all market, mastery (or at least proficiency) of one skill is the most important thing. An example from the book-- if you're a comedy writer, the most important thing that matters is your ability to write good scripts. You wouldn't enter this "winner takes all" market and then try to get really good at carpentry-- it simple doesn't serve a purpose in your career endeavors, and won't help you become a better writer.

Alternatively, in auction markets, it’s best to build and accumulate a variety of different skills. For example, a venture capitalist does many things -- pure strategic allocation of capital is just one aspect of their job. He or she also needs to be a great networker, have above average communication and presentation abilities, be able to keep up with market trends, and have a deep sense for product and business strategy.

An auction market, by contrast, is less structured: There are many different types of career capital, and each person might generate a unique collection. - Newport, Deep Work

Where Does Software Engineering Fit?

It's interesting to think about whether software engineering is a "winner takes all" market or an "auction" market. At first glance, many (especially outside the field) would immediately say that your value as a developer is almost entirely based around the quality of the code that you write.

After all, isn't it a trade like carpentry, or writing? Carpenters produce woodwork, writers produce literature, and software engineers produce... code?

This might be true for the first few years in your career as an engineer, but as soon as you get over the hump of figuring out how to express your thoughts in sequences logical symbols, the game changes in a few ways.

Good Software Engineering?

First, let's define success in software engineering-- I'd argue this means the timely launch of good products via the completion of technical projects.

After all, the value derived from software is only partially the underlying technical decisions made-- Slack is an Electron app written in Javascript that talks to a messaging system mostly in PHP, which is completely different from IRC (Internet Relay Chat). As of this writing, Slack's market cap is around $18 billion, whereas no IRC client has ever come close to being worthat much. Obviously this is a contrived analogy, as millions have derived value from IRC personally-- but my argument stands, as Slack could have been built on IRC channels, but the $18 billion valuation is moreso a result of its client list and product design.

I bring that up to explain how the success or failure of a technical project often has little to do with how good the code is. It usually has more to do with whether the requirements were clearly defined and if the processes in place allow for consistent, incremental progress towards shipping.

Engineering Career Focus

Following that logic, two software engineers with the same level of technical depth (in terms of writing a React component or a Django API, for example) should seek to improve upon their project management, communication, and team-building knowledge. This will let them improve upon their value-add to an organization.

And if you've been working in the field for a while, you'll know that it's especially false in higher level roles, such as engineering management. A software engineering manager's biggest value add is getting stuff out of the way and building up engineers. Ultimately, what gets produced is still code, but it's through a different vehicle and skills.

Similarly, in senior individual contributor roles, there's still responsibilities that go beyond pull requests:

  1. Mentoring junior engineers
  2. Designing/architecting systems
  3. Producing documentation
  4. Project management
  5. Managing stakeholders

However, to play devil's advocate, one can also argue that the ultimate goal of this analogy is whether you should focus on developing one skill or multiple. At the end of the day, to get to senior levels of software engineering, you still need to be a reliable technical contributor.

This is to say, there is still a minimum bar to meet-- you can be a regular speaker at frontend conferences, but if your personal site looks like a 1999 geocities page, you won't command much respect. Thus, despite the line of thinking that software engineering encompasses many different skills, and should be seen as a "winner takes all" market, technical proficiency will still need to be one of (if not the) overwhelming focus.

What are your thoughts? Is software engineering a "winner takes all" or "auction profession"?

Sign up for our newsletter list and join others to get lessons and daily coding challenges sent to your inbox!