What I Learned During My First SWE Job
Image: My first day at work!
When I graduated college, I accepted an offer at a Series B startup, and got to work side by side, every day, with the best software engineer I've ever met. When you spend so much time with someone much smarter than you, you learn a few things. That's what I'm writing about today.
1. Be Reliable
I'd take on 10 tasks and let one slip for a few days. In my head, I was killing it: moving fast, shipping things, providing value. One forgotten task in a sea of wins seemed fine.
But the person waiting on that task didn't see any of that. They just saw that the thing they needed wasn't done. Three days later, still not done. And I'm over here pushing unrelated commits like everything's normal.
Your say-to-do ratio needs to be 1:1. If you say you'll do something, do it. If you can't get to it right away, just say that. "I'm pretty slammed, can I get this to you tomorrow?" or "I have a meeting in 10 minutes, give me an hour." People are way more understanding than you'd expect. What they're not okay with is a "yes" that silently turns into a week of nothing.
2. Understand Your Code
I was submitting PRs of code written almost entirely by Claude because the code "looked right". Because the product had no users yet, I told myself it was fine.
My manager pointed to a line during a review and asked me a question about it. I had no answer. I barely even knew what file we were looking at.
The development phase is exactly when you're supposed to be building deep understanding of the system.
Anybody can paste a problem into an LLM and ship the output. What actually makes an engineer valuable is being able to look at a piece of code and explain why it works, what it connects to, and what breaks if you change it.
If you can't do that for your own code, You're no better at software engineering than a random person on the sidewalk.
There are times where it makes sense to only understand what you're making at a high level -- maybe you had an idea for a cool internal app and want to spawn a demo. In that situation, speed matters over reliability. If you're shipping production systems, reliability is more important than speed, so you can't be shipping code you dont understand.
3. Focus
You were hired to do a specific thing. Do that thing really well before you start doing other things.
I know it's tempting to spin up side projects, jump into other teams' work, and show range. But if you're still just "meeting expectations" on your actual job, none of that other stuff matters. It just looks like you can't prioritize. It's also disrespectful to your manager.
4. [Controversial] Don't Use Your Mouse
Image: A comment I recieved under one of my youtube videos
When I showed up for work on day one, I thought my manager was a wizard. He knew his way around a computer like nobody I'd ever seen. He was doing all sorts of shortcuts and magic tricks with his keyboard to get places fast. Meanwhile, I was using my mouse to click on the search bar in vscode to find a file.
One of the highest ROI things I learned was to memorize a shortcut for every action you do frequently. Opening a terminal, navigating tabs in chrome, finding references to a method in vscode, etc. If you do it multiple times a day, create a shortcut for it and memorize it. After a few weeks, you'll be moving around your computer twice as fast.
Disclaimer: This is NOT me saying you should use Vim.