What I learned at a startup I didn’t learn in school

Guest Blog by ELP Student Arthur Shi – Computer Science – Literature, Science, and the Arts – Class of 2019

As engineers, we go through our schooling with the understanding that skills we develop in our courses will prepare us for the workplace. While this is true to an extent, entrepreneurship and academia take very different approaches to learning. Having completed the core of my Computer Science degree at the University of Michigan, I’ve found a few major gaps between the skills gained in my coursework and the demands of bringing software to the market.

Here are some thoughts on things I’ve learned at startups that I didn’t learn in school, from a high-level and hopefully holistic perspective.

(**Disclaimer: I’ve only finished two years of school. The point of this article isn’t that schools don’t teach you anything, but rather that the startup environment encourages you to learn in a different way and demands skills that a degree doesn’t necessarily emphasize**)

Limited Resources and Prioritizing

I work for a company called MySwimPro, which produces a primarily mobile app-based training platform for swimmers. We’re fortunate enough to have hit traction and a growing user base, but like most startups in this position, at any given time we have more demanded features than we have development resources available (read: developers, and, cash to pay them with). This means that we need to prioritize how we choose to build our product. This is not only about creating value for users, but about how much value is immediately captured as revenue.

At any given time, there are probably plenty of items to be built. If said features can’t convert into sales, it’s not productive to focus on them. Thorough understanding of market segmentation and revenue-generating value is needed in order to spend an early stage startup’s resources wisely. Unlike in school, nobody hands you a project-spec set in stone and says, “if you can complete these computations under certain runtime and memory bounds, you get full marks.” It’s your responsibility to understand what the real metrics for success are. It’s your responsibility to roadmap your product effectively. It’s your responsibility to keep in mind that your business model is subject to change and these metrics may shift.

 

 

Appreciation for a Diverse Stack

Almost all of my experience in my courses so far has been in C++. This is a good place to start. If you’re considering anything other than systems programming, it’s beneficial to expand your stack and get some more context for the various opportunities currently available in the (very broad) fields of computer science and software engineering.

I’m working in iOS this summer and have also been diving into web development. This has involved learning about app architecture and methods of separating user views and underlying data models, such as the model-view-controller (MVC) and model-view-view model (MVVM) models. The introduction of a user interface creates a number of technical challenges that have a learning curve. It also allows development of more interesting and elaborate user applications.

Webdev, mobile dev, cybersecurity, robotics, computer vision, and predictive analytics are a few examples of fields that are booming right now. Each has a set of tools and frameworks that empower a developer in ways particularly advantageous to its goals. University curricula takes at least 3 or 4 semesters to expose students (even minimally) to the opportunities afforded by a varied development stack. Gain some context for these possibilities early on!

 

 

Software Development Practices

At school, we’ve mostly been programming terminal-based applications with no GUI. We are taught to use the C++ STL effectively, with emphasis on understanding underlying memory models, which sometimes involves having students reimplementing well-documented data structures such as linked lists or hash tables. As previously mentioned, our project objectives and design goals are static.

While there’s merit in developing strong object-oriented programming fundamentals, this alone doesn’t prepare a student to develop software for clients/users efficiently. In particular, I often found myself worrying about the mechanics of a language (things like pointers, type-casting, compiler handling of syntactical features), when it was more productive to dive in and learn by breaking things. The academic approach to learning computer science almost holds you back from adopting the Agile paradigm of software development that’s becoming increasingly common in industry.

To be fair, some upper level courses take a look at a few of these ideas. Even then I think the attention given to them is inappropriate.

Here’s an overview of skills that I wish I learned in school:

  • How to pick up a new programming language quickly
  • Version control (Git in particular)
  • Using open source API’s to accelerate development
  • Responding to changing user demands
  • Agile development / team dynamics
  • Organizing and navigating projects at scale (100+ source files)
  • Application architecture / UI design

I’m not arguing that the first two years of computer science at university should be taught very differently than they are — strong fundamentals are important and you can only learn so much so fast. But, I’d encourage computer science students to remember that an engineer’s toolkit consists of much more than theory. Understanding how your skill-set fits into a business model and being aware of and developing practical skills early on will make you much more effective and flexible as you begin your career as a developer.