Programming in School vs Working as a Software Engineer

While I started studying Computer Science, I always wondered if working in the real world would be as difficult as college. I struggled to learn a lot of the theories and constantly wondered why I had to take most of these courses. It turns out the real world is much different from school.

The Academia Side of Computer Science

While studying computer science at a university, professors will generally teach you about the science of programming. Hence you'll take a lot of theory and math courses to understand the fundamentals of how programming works behind the scenes. A typical university curriculum may include some of the following topics:

• Data Structures and Analysis of Algorithms
• Theory of Computation
• Operating Systems
• The Fundamental Concepts of Languages
• Compilers
• Computer Organization, Systems Programming, and Computer Architecture
• Probability and Statistics

Generally, the assignments are well defined problems with known solutions. These assignments are meant to be solved within a well defined time span. It is very unlikely that undergraduates will be given assignments with unclear requirements since these courses are meant to help you learn a specific Computer Science topic. All in all, getting a degree in Computer Science will teach you how to write and debug basic code and how apply the theories taught in lecture.

What it's like working in the workforce as a Computer Engineer

The truth is, most university curriculums don't prepare students how to operate in a real work environment. A common misconception is that Software Engineers just sit at their desks chugging coffee and coding all day. However, this is far from reality.

Writing code

All entry level Software Engineers spend 80% of their time writing code. The other 20% revolve around going to meetings and attending scrum. Generally, PMs and a Techlead plan out the deliverables that have already been scoped out. These deliverables are small enough for any engineer to code out. Sometimes the Techlead will also provide a design doc when the implementation portion is unclear for entry level Software Engineers. Most of the smaller tasks have predefined requirements by the PMs and Techlead. Software Engineers need to digest the requirements and transform it into code.

One big difference between writing code at a university and in the real world is that most university courses don't focus on how to code in a large codebase. In the real world, you'll rarely get to start on a fresh codebase or a get skeleton that's provided by someone else. Also in the real world, most projects can take months to complete unlike university assignments which span a week to complete. However, when you start in the industry you'll notice one similarity, the requirements are all flushed out. Both university assignments and entry level tasks have clear requirements that have already been defined by someone else. You'll see as you grow in your career, this starts to change very quickly.

Designing Systems

It's important to note that in the workplace, you'll be creating products and solving real problems for real people. Hence, a lot more thought goes into designing the system as a whole.

As you advance in your career, you'll start to write less code and start to design larger systems. When I started my career, my tech leads would give me a design doc to implement. As I advanced in my career, I started to design systems with much larger scope that were meant for multiple engineers to work on. Part of this includes analyzing requirements and understanding what is technically feasible in a given timeframe. This also requires you to have a solid technical background in order to figure out what frameworks or solutions to apply.

You'll rarely use those advanced concepts taught in school. Most of the time you'll be using APIs of other frameworks or libraries. In 95% of my projects, I had to learn about other systems or frameworks and figure out how to piece them together to create something new. For example, when I made a web app, I had to learn how to use React and someone else's calendar Widget. I had to figure out how to piece their calendar widget with my React form and the best way to propagate data back and forth. However, knowing those concepts are important when applying those frameworks to your code. Being able to recognize using a certain function can turn your runtime from O(n^2) to O(n) is extremely valuable.

None of my courses taught me the importance of designing the system before starting to write code. In my courses, as long as my code compiled and passed the tests it was good to go. There was never a reason to design more than one working solution. In my current workplace, I have multiple options each listed with pros and cons. I have thoughtful discussions with other engineers on the best solution.

Real world problems are often complex and blurry. Requirements can change overtime. You're often designing systems that can be replaced or refactored in the future. This is because in the real world, you're focused on designing solutions for real people.

Testing the system and maintaining upkeep of that system

I noticed a lot of Software Engineers entering this field don't learn the importance of testing until they start working. Often, universities provide a test suite that the students can run against to verify their solution is working. In a production codebase, you'll have to check in tests with the code. Depending on the feature, it could be an integration test, unit test, or a visual test.

In the real world, you'll also have to maintain that test and the system. I learned that tests can be flaky time to time. Things like Webdriver tests aren't perfect and sometimes you'll need to revisit your existing tests to make them stable again. Production code is used by real people, so it's detrimental if your system crashes and goes down. Unlike a college assignment, you'll need to invest time into logging, capturing metrics, and scaling the system.

Collaborating with PMs, UX, Stakeholders, and other Software Engineers

Contrary to common belief, Software Engineers are not locked up in their code coding in the dark and hiding from humanity. In reality Software Engineers have to collaborate with Product Managers, UX Designers, Stakeholders, and other Engineers. PMs have a good idea of the problem that needs to get solved. UX Designers know how to create beautiful mocks and understand human interaction principals. Software Engineers know how to take both the requirements and mocks and turn them into working code.

I noticed it's a constant tug of war between adding new requirements and balancing tech debt. Sometimes PM or UX requirements have challenging implications such as increased tech debt or the solution may take too long to complete in the given time frame. It's up to the Software Engineers to flag this and work with the respective parties to come to a balanced solution.

Estimating the time and effort required to build out a system in a given timeframe

Another thing Software Engineers have to do is estimate how long it will take to complete a project. Leadership takes these estimates in order to figure out how to sequence things. Figuring out how difficult and how long a project can is also a good trait to learn. In school, you're generally bound to a fixed deadline, but in the real workplace, deadlines are more flexible since they're set based on the amount of work required.

Conclusion

In conclusion, university curriculums teach students how computers interpret programming languages and how to utilize different data structures and algorithms, but it's different from how things are in the industry. In the industry, you'll be expected to design real systems for real people. Projects will take much longer to complete due to the larger scope. However, university curriculums help provide the fundamentals required in the work place. If this article was interesting, take a look on how I Landed Offers from Facebook, Google, Uber, & Microsoft as a Software Engineer. Did you get a Computer Science degree? Do you think it was useful? Let me know in the comments section below.