The Three Things that Most Computer Science Programmes Didn’t Prepare Us For

Is having a solid Computer Science foundation per se enough to thrive in the IT industry?

A Computer Science (CS) degree undeniably equips us with the basic building blocks to be a great software engineer. It taught us how to analyse an algorithm in terms of its time and space complexity. We often denote them with a seemingly recherché notation called the Big-O Notation. The subjects that we use daily include, but not limited to, algorithm, data structure, database, indexing, and distributed system.

The course itself also taught us how to divide an insurmountable technical problem into small manageable pieces. Remember the divide and conquer technique that we learned in our freshman or sophomore year? In general, a computer science degree gave us the necessary knowledge to solve any technical challenges with codes.

In this Industry 4.0 era, coding skills have become one of the most sought after skills. Knowing how to code per se will help us in multitudinous ways. Be it in securing a full-time Software Engineer role or even building a successful startup. Check out my previous article if you are interested in knowing how Artificial Intelligence (AI) has changed the way we live.

However, it fell short of telling us: “How can I write robust production-grade codes and ship them in time”.

1. The Keep It Simple Stupid (KISS) principle

We might have heard about the KISS principle¹ during our university days, but we rarely had the opportunity to get our hands dirty. Most of the projects given by our professors and lecturers are considered well-defined problems. In other words, we can find most of the answers on the internet or in books.

The projects that we did back then in school are incomparable to the real-world problems that we solve in our job. The problems that we solve in our professions are way more ambiguous than our school assignments.

Our goal back then was to complete the assignments as fast as possible, even if it comes at the cost of tons of repeated codes. These repeated codes, in turn, reduced the code readability. This principle is closely related to the Do not Repeat Yourself (DRY) principle².

Code simplicity might not be on our priority list when we were still in school. The fact that we were mostly doing projects alone or in a small team caused us to forego the readability of our codes.

However, once we started our professional career, we are expected to up our game. Writing spaghetti codes is no longer acceptable as it is going to make our codebase highly unmaintainable. Moreover, as the codebase grows in size, it will make the debugging process excruciatingly painful.

Writing code is also a form of art. There are many ways to achieve the same objectives. The most important question is: “How we can increase our team’s velocity by writing clean codes?”

2. The importance of writing great tests and automating them

I still can vividly remember that we rarely wrote tests in schools as we thought it was a waste of time. Or rather, we merely test our codes by simply looking at the final result or printing the final output. The fact that there is a high probability that we will not touch the project anymore once we submitted it made things worse. The nature of the project does not necessitate us to write any tests.

With all of the great tests in place, you can rest assured that we will not break any parts of the system when we are refactoring our codebase or adding a new feature. Although, I have to admit that writing a comprehensive test suite might be challenging when time is not on our side.

Writing test is also one of the few great documentation techniques that we can use to help other engineers understand the flow of the codes better. Therefore, writing great tests is of paramount importance — it is our living documentation!

Before I started working, I did not have the faintest idea of what unit, integration, and end-to-end (E2E) tests are. In a nutshell:

• The unit test helps us understand what a class/module does, and it helps us catch erroneous class-level behaviours timely.
• On the other hand, the E2E test tells us how do we gel these different classes and modules together. Most of the time, these tests only contains happy flows. It is because the sad flows are by and large sufficiently covered in our unit tests.
• Lastly, the integration test depicts how we gel the external modules with our internal modules and how we process the responses we get from the external modules.

We can also leverage the Continuous Integration / Continous Delivery or Deployment (CI/CD) pipeline³ to speed up our development process. Although, we might often opt for the continuous delivery option as we might not want to deploy every commit.

It boils down to the software development methodology and policies that your company adopts. Some companies might prefer to ship the features as soon as they completed the features. However, some of the companies prefer to have a scheduled weekly or monthly deployment.

3. The true essence of agile software development

The agile methodology might be something that our professors have taught us in school. We might also have ever heard about Scrum, test-driven development, extreme programming, and the waterfall model⁴.

However, we merely had to regurgitate these definitions during the exams, which we will most likely forget after the exams. There were no hands-on materials to help us understand these concepts better.

We were often encouraged to choose a software development methodology other than the waterfall model for our school projects. To our chagrin, we had to stick with the waterfall model all the time. It is because the deliverables that we had to submit closely resembled the waterfall model.

Although, I have to admit that it is much more suitable to use the waterfall model for our school projects because the problems we were trying to solve were well-defined.

I also learned that reaching an impeccable sprint forecast is far from realistic. The scrum dictionary⁵ defines sprint forecast as the best guess and not a plan or promise. We often have to deal with ad-hoc (or additional) works before on top of our current task during our sprint. These ad-hoc events encompass, but not limited to, hotfixes and urgent features.

Therefore, we have to consider none work-related tasks like code reviews, onboarding new colleagues, meetings, etc., during our sprint planning. An inaccurate spring forecast will not affect not just your team, but it will also affect the other teams that rely on our codes.

Conclusion

I am by no means insinuating that getting a computer science degree is pointless. One of the skills that we need to acquire when we were in school is to learn the way to learn (no pun intended).

Working in a fast-changing Information Technology industry entails us with a responsibility to constantly upgrade ourselves. The same notion was resonated by my lecturers and professors back in university. They often lamented how the programming languages they picked up back then (e.g. Cobol) is no longer relevant.

It reminded me of the conversation I had a few years ago with a Grab⁶ Driver who happened to study Computer Engineering at Singapore Nanyang Technological University (NTU). He told me that most of the stuff that he learned in university did not help him with his job.

I can not commiserate what they told me until I started working on the startup I co-founded, Pengacaramu, and later until I got myself a full-time job as a backend engineer at Xfers.

print(“Thanks for reading and #HappyCoding!”)

Footnote

[1] Keep It Simple Principle: https://www.interaction-design.org/literature/article/kiss-keep-it-simple-stupid-a-design-principle

[2] Don’t Repeat Yourself Principle: https://dzone.com/articles/software-design-principles-dry-and-kiss

[3] Continuous Integration VS Continuous Delivery VS Continuous Deployment: https://semaphoreci.com/blog/2017/07/27/what-is-the-difference-between-continuous-integration-continuous-deployment-and-continuous-delivery.html

[4] Software Development Methodologies: https://blog.planview.com/top-6-software-development-methodologies/

[5] Sprint planning definition: https://scrumdictionary.com/term/sprint-forecast

[6] Grab is Southeast Asia’s leading super-app. It provides everyday services like Deliveries, Mobility, Financial Services.