The Gap Between Studying and Working in Tech

日本語はこちら。

I'm pretty sure all engineers who work in the tech industry agree that there's a gap between learning the technology (in university, bootcamps, self-taught, etc) and working using the technology. But I always wonder what the actual gap is. Sure, there's plenty of obvious ones like "how to use Git" or "how to setup a CI/CD pipeline" (assuming your work requires them), but I think there's other skills, knowledge or techniques that are less obvious yet still very important and definitely exist.

What could they be? Can we actually articulate them?

I've yet to see a well-defined list of these skills. I try to keep an eye out for anything that comes close or may be elements of this.

Here's some examples that came to my mind when thinking about them.

The Missing Semester of Your CS Education

https://missing.csail.mit.edu/

This is a class from MIT on, as the title suggests, the missing pieces from CS education. Topics include:

• Version Control (Git)

• Shell Tools and Scripting

• Debugging and Profiling

• Command-line Environment

• Security and Cryptography

• Metaprogramming

I've yet to watch them but can definitely see how these can be useful. Some of them like version control, debugging or shell scripting are obvious. Others, I didn't expect to be there at first glance, but make sense when you think about it.

For example, "Cryptograhy" is not something you deal in detail with day-to-day but sometimes you need to know how they work in order to make sure you're not doing something risky security-wise. I once had to setup a user on Linux server for my colleague and asked him for his "SSH key" and to my surprise he passed me his "private key". If you knew how it works, it may sound crazy but the concept of "public-private key" is not straightforward (strange, even) so it's easy to make these kinds of mistakes.

Knowing what "Good Code" looks like

Knowing a particular programming language is one thing, writing "good code" is another.

I've put "good code" in quotes because "good code" is subjective and different people have different opinions. Some people will say succinct code is good, others will say descriptive code is good and so on. It depends a lot on the circumstances and the context you and/or you code is in.

Having said that, there's many good books, blog posts and videos on this topic and I feel like there's some points that do not age.

Take this clip on "Critical Program Reading" from 1975 as an example.

It's SHOCKINGLY relevant now. Points like "keep variable names descripting", "add structure", "consistency aids understanding" can be equally applied to any programming language today.

Working in a Team

Once you start working as a software engineer, you are likely going to work in a "team". This means you are going to have to communicate with them, split work between them, have to discussion (and hard ones at times) wit them and so on. You are not on your own anymore.

This is another topic that's difficult to "learn" i a class room setting.

During my time at university, we had a course on building CPUs as a team (4~5 people). We had to come up with our own instruction set, implement it in Verilog and write a compiler for it.

As many college students, most of us weren't used to communicating among us and now that I think about it, we (or at least I) could have done a much better job if I knew what I know now. It's less about the "technical knowledge" (I think I remember less today than back then😅) but more about things like "project management" and "communication". If I knew to write out everyone's tasks and responsibilities, made sure we knew of any bottlenecks among us and knew how to communicate that between us, I think we could have done the project much better and quicker.

A Beginning of a long Journey

I've bairly scratched the surface of a huge, huge topic. There's definitely a lot of articles, papers, books and videos on this topic. I hope to keep writing about anything that I come across going forward.