College life vs. dev tech life: 7 things I wish I'd known

At 23 years old, my life has been full of transitions—from being a toddler to attending K-12 to going away to college and finally entering the workforce. So far, about 3/4ths of my life has been dedicated to school and education so I don’t think I’ve experienced a bigger transition then graduating from a CS program and entering the workforce as a software developer.

So how is studying computer science different from actually working as a software engineer in the tech industry? I find that the biggest discrepancy is the fact that my education was theoretical, its purpose was to show underlying concepts. But enterprise solutions are focused on building projects that are scalable, reliable and maintainable—which school does not always cover. Although I learned a lot from my four-year computer science program, there were many gaps I’ve had to fill in on the job.

And I know I’m not alone. So I thought it would be helpful to explain some differences I experienced and clear up some misconceptions for aspiring software engineers studying CS at college.

1. Office hours don’t stop with the degree

During college, I attended lots of office hours. Many times, professors had written vague assignments and requirements and help from TA’s was crucial in the success of my coursework. However, running across campus to sit in a line to only catch a few minutes of someone’s time was very tiring to me. Upon graduation, I was relieved to no longer have to worry about making office hours.Therefore, it came as a surprise that, as it turned out, I still had to attend office hours … We just don’t call them that anymore.

What do office hours in an enterprise tech company looks like? My team’s product uses two inner-sourced projects, when we have questions about them, we go to their team members for help. However, they are not always immediately available since they may be busy with their own work. But they do hold office hours a couple times a week to help answer questions and provide guidance. Attending these office hours has proven the best way to get unstuck from our problems.

I also noticed that there are many similarities between office hours at university vs. the workplace.

• One example is professors sometimes do not provide all the details on the assignment page. Likewise, documentation for inner sourced tools, especially newer tools, is often not as thorough as it could be. (a universal problem for documentation in general)
• There were times at my university where assignment pages were modified due to a point made during office hours. Likewise, I have had people say to me during workplace office hours that things should be appended to their documentation based on our discussion. Knowing I’m helping clarify things for other teams (or students) is great.
• Another similarity is that there is often a line to get help. Many people and teams use the same inner sourced projects. Likewise, many students are working on the same assignment. I suppose no one is immune to having to deal with waiting. But asking for help early and showing a bit of patience makes this process better.

2. Expert in a language != expert software engineer

A big misconception that I know a lot of new or aspiring computer science students have is that programming languages are the ends to the means. That simply by reading or memorizing a book on Java or C++ they will become a seasoned expert. Nothing could be further from the truth.

Programming languages are just tools to do the job. Much like a drill bit is to a construction worker, it would be foolish to believe that one can construct a house by memorizing the instruction manual of a given tool. Software development works the same way. A programming language is something we learn to accomplish a task—but that’s not the only thing we need since engineers have to understand systems and architect their solutions before they start building.

In fact, much of the hard work in software engineering is from the design, not the implementation. Even from an implementation standpoint, memorizing a programming language may not be as useful as one may think. The internet contains many resources to help you. For example, I’m constantly googling how to do things in a certain way in a certain language and looking through examples online to apply to our problem scenario.

Being a software engineer means always needing to keep learning. I view this as a positive thing. It would be boring—for me at least—staying the same and never learning anything new after graduation.

3. Not everything you learned in your CS program will get used

The typical computer science education is very dense and covers a lot of bases. I view it as a spattering of different topics, from programming 101, to databases, to operating systems, and everything in between. To CS students stressed out that they have so much to learn/remember, I offer some relief—You won’t need everything once you begin working as a software engineer.

One important concept that you will need from your CS program is abstraction, defined as hiding the implementation or background details of software features. Computing is all about layers of abstraction. For example, when you use a computer you don’t need to know exactly what your computer is doing—like managing processes or memory—just that it is able to do the task that you wanted it to do. Software engineering works the same way. For example, if you are a front-end developer, you don’t necessarily need to know how the API’s that are called interact with the database, just what functions are available to you.

Furthermore, most software engineers do not need to know all the details about operating systems, compilers, or the hardware that runs your computer because it is all abstracted away. In fact, computing is so complex, it’s near impossible to thoroughly know every computing topic and abstraction. Some courses that you take will not be applicable in your day job. For example, in college, I majored in computer engineering. I got to take a lot of low level courses on circuits and microprocessors, but I do not have to apply that knowledge in my day-to-day job.

Even furthermore, many CS programs don’t even cover many basic topics that software engineers need to know for their day-to-day jobs. For example, I didn’t have a course that covered version control, continuous integration/deployment pipelines, cloud computing, agile development, etc. As I mentioned before, schools focus on teaching theory over software engineering industry practices and applications. Regardless of how important these tools and technologies are to the modern software engineer.

4. Software engineering is a team sport

There’s a common misconception that software engineering is a career for loners. It’s easy to believe this since software engineers do spend a large portion of their day looking at a screen, usually listening to music. However, software engineering is actually a team sport where communication is paramount. Every day I collaborate with various different people and teams to get my work done.

For example, I often have to work alongside other engineers as our work has dependencies, have to clarify a requirement with the product owner, raise any impediments with our scrum master, or verify my implementation is correct with our tech lead. I would describe the process as working independently but having to go out and collaborate with people to get help. I find it’s a good balance between interacting with people and being able to sit down and work independently to get a task done.

This is in contrast to school since most of the time projects are worked on and completed independently and if you fail a test or class it generally doesn’t impact anyone else in the class. When was the last time you co-wrote a final essay or took a final exam with a team? And yet software engineering is the one with the bad rep …

5. Writing essays and writing code are more similar than you think

With about a year of professional development experience under my belt, I have come to realize that writing software shares much in common with writing essays. Compare software code to the prose of an article or book. There are infinite ways to compose your words to convey the message, but some are more effective and concise and captivate the reader in better ways.

Writing software is the same. You can implement some functionality in many ways, but among the options, it’s up to you to select the best. This is a common pitfall I think inexperienced writers and developers make—stringing a bunch of advanced words together to try and impress your reader, making your prose too confusing. This is similar to coding a convoluted solution that is too complex and hard to follow.

One thing I’ve learned about software engineering is that code is more often read than written. The implications of this means that your teammates have to understand the logic behind the code you write. Therefore, similar to writing, I think it is best to strive for simplicity as it will make your code easier to understand and maintain in the future.

However, there are times when we have to make tough calls due to time, costs, or other business and technical constraints that could impact our ideal solution. In these cases, as an engineer it is important to articulate the benefits and drawbacks of potential solutions to choose the optimal pathway, whether it is the most elegant solution or not.

6. Software requirements are often less clear than school assignments

In school, the assignments you were given ideally had very clear requirements (if you had a competent professor, that is). You didn’t need to overthink it, you just had to focus on getting your code to work and completing all the functional requirements. In the tech industry, that luxury doesn’t always exist. Especially with the advent of agile programming, you often only know the requirements for the tasks assigned to you currently, and product owners often come back and change those requirements as needed.

Imagine the chaos if professors could do that—you finished your project, but he/she comes back saying the task has changed. Now that I think about it, maybe they should …

In the real world of agile development, it is idealistic to think that you’ll have every requirement you need beforehand. Companies follow this process to provide iterative feedback on the products they are building. Users may change their mind about a feature, or a market can change, causing product owners to need to switch gears. These scenarios of course don’t happen in a classroom project, and new devs may have trouble adjusting to this mode of work after graduation. (But you won’t because you read this post, right?)

7. Preparing for software engineering interviews can be misleading

Ask the standard CS student how they prepare for interviews and they will mention studying data structures and algorithms. Most tech companies include ‘whiteboard’ programming questions in interviews, usually ones where they ask questions such as reversing a linked list or binary tree traversals. Used to assess applicants on their technical capability and thought process, most actual software engineering jobs don’t involve that much complex manipulations with data structures. This can be misleading to students, as that is how they’re trained to study for software engineering interviews.

In fact, I would say a lot of software engineering work is actually connecting things together. For example, having an API be able to call a database or another API, and also having your frontend client be able to connect to a server which connects to your database, etc. Sounds simple, but there is actually significant work to make sure one piece is able to handle the request that another passes in. While it’s important to be able to pass a standard whiteboard interview, don’t lose sight of the skills and thought processes you’ll need to use once you land that first job out of college.

Putting it all together

I grew up so used to the schedule of attending classes that starting work was a serious change of habit. At school, your goal is to learn and get good grades. At work your goal is to help the company achieve a goal. The focus isn’t on you anymore, not exactly anyway, but on how you can contribute to your team. In the classroom, your success is independent from the student next to you. But in the workplace, where your whole project is at stake, you’re highly dependent on the work of peers to get things done and accomplish your goals.

I’m glad I was able to find a development job straight out of university through Capital One’s Technology Development Program. Capital One places a lot of emphasis on having the best development teams possible and I’ve learned so much from being here.