10 Things I Wish I Knew After College

I graduated from RIT in 2013. I was lucky that I landed an extra quarter of co-op (“paid internship”) at MIT’s Lincoln Laboratory which set me up for multiple job offers before my final year… erm, three quarters… of senior year started.

Looking back at my career thus far, my journey through tech has changed quite a bit. I wouldn’t have guessed that I would have the day-to-day work life that I have now. Setting aside events like a global pandemic forcing everyone to work from home and contemporary uncertainty around the tech industry, I’ve changed a lot since college; some would say “thankfully”.

I’ve come up with a list of things that I wish I could tell myself 10 years ago.

Disclaimer

This is written from the perspective of someone who wants to grow in an individual contributer (engineer, administrator, programmer) role. I don’t claim to have good advice about managment roles and how to get into them.

I’ve worked in roles ranging from UNIX administration to platform engineer to SRE to software development at a few different companies in tech. Some FAANG, some not. Though my background in college was focused on infrastructure, systems administration, and generalism, this platform served me well to specialize in software development and running services.

Also, these thoughts haven’t been reviewed or endorsed by any of my current or past employers, colleges, instructors, or industry thought leaders. They’re my thoughts, opinions, tips, and irony - mine alone.

1. You don’t know everything, and that’s okay.

When you’re a new grad coming out of college, you’re coming from a space of mastering the cirriculum that was assigned to you. You’ve learned a lot, you’ve changed a lot, and you might have developed a world view of how things operate. You think you can take on anything and succceed, and you might feel that you know everything.

The real world will inevitably intervene, and you’re going to hit a wall. That’s okay.

Nobody reasonable expects you to be able to solve every problem without help. Regardless of what loud thought leaders and internet commenters say, there’s going to be a point where you need a hand. Or “An Adult”, as I occasionally quip.

Rather than suffer a meltdown, waste time, or get frustrated spinning your wheels, don’t be afraid to ask for help. It’s expected, accepted, and is more productive overall. You work on a team; use your teammates!

2. Asking for help is good; providing context is better.

People aren’t mindreaders. Your background and way of thinking about problems is going to be different than your coworkers'.

The XY Problem is a real problem that people run into. If you’re not aware of it, the gist of it is “ask for help, but say what you’re trying to do.”

I’ve worked in IT support and developer tooling support roles. It’s very common as a side effect of being a high-functioning engineer that people get “tunnel vision” and come up with a path forward that, to them, makes sense. However - when viewed in aggregate, the path they’re taking is needlessly complicated and will end up leaving them in a worse place then where they started.

The way I approach asking for help these days looks something like this:

Hey teammate. I’m trying to do X. I’ve tried Y and I’m getting Z error. I’m not sure where to go here or what’s the path forward, do you know where to look? I think the issue I’m seeing is caused by foo

Phrasing things in this way allows someone who I’m asking to help to see that I’ve done some “legwork”, and I’m thinking of a certain way of doing things. They may:

  • Provide context as to why I’m getting this error, or correct me
  • See what I’ve tried and suggest an alternative
  • Call BS on my way of going about this, and get me to focus on what I’m really trying to do.

These are all good outcomes.

Side note: don’t start your query for help with just a “hello” or “hi”. https://nohello.net/ goes into why this is a bad idea. This is counter-productive (and possibly rude) especially in asynchronous communication, when you’re potentially delivering an interrupt to someone who’s in the fabled “developer flow state”.

And for the love of all that is holy, try not to send screenshots of code or errors. Text formatting is your friend.

3. People have different backgrounds, use that to your advantage.

Similar to the above, people likely aren’t going to be thinking about your problems or way of doing things like you do. People come from different backgrounds - jobs, schooling, life experiences, familiarity with frameworks.

As Martha Stewart might say, that’s A Good Thing.

You probably have exposure to things that your colleagues might not. They probably have experience with a LOT of things that you don’t. Take your knowledge gap and see if you can learn something knew. It’s what you did for these past four-ish years, why not do it now?

4. Zoom in and zoom out - know your tools

Let’s operate under the assumption that you hit a roadblock and asked for help. Now you’ve got some insight into something you weren’t aware of before. That’s great! You probably have a shiny new way of thinking to add to your tool belt.

You may have developed in college - or in your professional career - some insight into a specific Thing in tech. Diving deep or looking at the bigger picture of this knowledge can lead you into very interesting directions and can help you specialize more.

For example, let’s say you were focused on networking in college, and you’re very aware of what happens when firewalls aren’t set up correctly - packets are dropped. Zooming out, what does that look like to an application? What errors does it see? Is it a connection reset by peer error, a no route to host error or a timeout? What’s the difference? I’ve had to troubleshoot this (usually around AWS VPC security group misconfiguration) sort of error many times. People who configured the infrastructure may not be “strong in networking” (and I’m using the term loosely on purpose.) Being able to help others understand what’s going on by framing it from the bigger-picture perspective, while being able to zoom into the minutiae around what’s going on and how to fix it, is an underrated force-multiplying skill.

Here’s another example, except around zooming in. You may super solid writing a bash, Python, Perl, or PowerShell script to set up a web server using Apache or Nginx or IIS. Note that the specific technology doesn’t matter here, at all. Have you ever looked into what’s happening on the OS side when this web service is running? How do connections come in to the service from the OS? What happens when you stop the service with in-flight requests? What sort of configuration options can you tweak on the web service (if you need to) to make it operate more efficiently?

Knowing your tools you’re comfortable with and knowing them well is another underrated force multiplier. Even if that tool is being able to carve out a script (or query Splunk) that will parse out an application log that’s misbehaving can be pivotal to your team. You can teach them how to get e.g. “what Exceptions are being thrown for all http 5xx error codes over the past 15 minutes” and they can teach you why that’s happening.

A colleague once said something to effect of “look at the tools you have, and use them differently.” It’s wise advice, and you might learn something from it.

5. Try something new

An extension of the above is to try something outside of your comfort zone. For me, I suffered a bit of imposter syndrome around “not being a REAL developer”, which I wish I could throw out. Perhaps it was a side effect of the odd semi-caste system that the computing college had, or a side effect of me reading too much into what people say on the Internet as “fact”.

I picked up Golang idly while working at one company, moved to a company where it was their primary language for programming services, and ended up writing developer tooling for Go. That’s not what I would have imagined my degree in “Information Technology” would get me doing.

Sure, I’m terrible at programming challenges, and am still growing as a software engineer. That’s expected - everyone has to start somewhere. But if I hadn’t zoomed in a bit on some of the issues I was dealing with (Java stacktraces in production, by the way) and found a new way of doing things, I wouldn’t have grown the way I have.

6. You’re not always going to get it right

I screw up on the regular. So have all of my colleagues. That’s totally fine. Regardless of how people choose to portray themselves - HackerNews comments, Instagram posts, pithy tweets, idealistic conference talks - nobody is perfect. And if someone thinks he or she is, then that’s a gigantic red flag to run.

It’s okay to not be correct or to make decisions that turn out to be sub-optimal. Many successes come at the cost of even more failures beforehand. How else do you think people learn to make the right decision at the get-go and minimize the potential for things to go sideways? Through experience.

Embrace being wrong, and learn from it when you do.

7. Respect your boundaries

My first boss once told me something to the effect of “People will sometimes respect you more if you say ’no’ [instead of saying yes]”. I’m not suggesting that you become a blocker, but it’s okay to say “no” sometimes. You’re human, and you have a finite capacity of things you can do in a day, week, month, or quarterly planning cycle.

If you think you’re out of your depth, you should ask for help. If you think you need more resources, say so early. If you see things going poorly, report on it. It’s better to do so now than later, when things have progressed too far to fix.

Another way to say “no” is to say “how.” Maybe instead of saying “well, yes” immediately when you’re asked for something, think of “how” you’re going to get there. And give timelines - something like “I’ve got a lot on my plate right now, but I can implement this software change after I do <x, y, and z>, so probably around Wednesday afternoon. Does that work for you?” can go far.

8. Communicate well

I’m not going to be sardonic here and say “Communicating well is table stakes for anybody at work” because that’s simply not true in practice. Being able to communicate asynchronously in written form, and synchronously in spoken form, is essential to getting things done. Precise wording, ensuring everyone’s on the same page, and holding productive and actionable meetings seems to be a skill that some people lack. That can be learned with time and being in the right environment. The other side of that coin is listening.

If you’re providing a conduit (or perhaps a firehose) of information for people and you’re not considering how they’re responding to it, you’re doing yourself a disservice. If people are giving feedback and you brush it off as them not understanding, what are you really accomplishing? Are you missing something, are they not thinking about a problem the same way you are, or are you and the person in completely different ballparks?

Communicate well and be precise, but for the love of all things holy, LISTEN.

9. Imposter syndrome is good

I jokingly tweeted at one point that “I got over imposter syndrome by being wrong all the time”, or something to that effect.

It’s easy in a technical field to feel inferior to others because you don’t have the same context or understanding that they do. Don’t let it get to you.

Imposter syndrome can be a healthy sign that you’re capable of growth. Don’t let it crush you; instead acknowledge it and ask yourself “why” you’re feeling that way.

Unfortunately, the tech industry on the Internet seems to value loud voices over practicality. Though cynicism can grow unhealthy if left unchecked - I know I’ve gone down that road too many times to count - having a bit of skepticism for what you read sometimes can serve you well.

There are plenty of names for the anomaly of “EVERYONE does this, so I should too”, such as sampling bias, the dunning-kreuger effect or even “cargo-cult science”.

Don’t let it get you down. Chances are, there are a lot of qualifying statements or misleading points that are eluding you when you read the latest report on why every project should (for example) build on Kubernetes using a NoSQL datastore and an async Rust backend.

10. Be a gracious human.

Admit you’re wrong. Don’t be a jerk. Use yourself as a force multiplier to help elevate those around you. Strive to be learning always. Have some humility, even if those around you don’t. Be honest.

Nothing is forever in this world, and jobs and projects are no exception. Life’s too short to bullshit people, and things will catch up to you. That’s fine, but ask yourself if when you’d look back on your emotional reaction to something if you’d regret that later.

Have some hobbies or interests outside of work. “Touch grass,” as the memetic phrase goes. Having a life outside of work gives you something to look forward to when you shut the laptop’s lid. It also makes you a more interesting human, and probably more relatable to your teammates inside work.

You’re more than your job and your employer.

Copyright © 2022 Chris Cmolik