Some Tips for Junior Devs

1) Learn SQL and how to use a debugger. 2) Never come up emptyhanded, even if you don't fix the bug.

Want to get notified about new posts? Join the mailing list and follow on X/Twitter.

Tip #1: Learn SQL and how to use a debugger.

Do yourself a favor and learn some serious SQL during school. Get really good at writing, organizing, and debugging big-ass queries.

This is of course not the only thing you need to learn, but it’s up there as one of the most important things, and it’s weirdly absent from CS curricula.

Also, get really good at using a debugger. Breakpoints, conditional breakpoints, knowing how to watch variables, and knowing when to set a breakpoint vs log information to the console.

I don’t mean just “know what a breakpoint is and how to set one,” I mean actually practice using them to debug really complicated code. Again, weirdly absent from CS curricula, but you are absolutely gonna need it.

I didn’t learn SQL or how to use a debugger until I was on the job (actually my second coding job, my first job was mainly just scripts in jupyter notebooks). And boy do I wish I learned that stuff earlier.

Initially I figured I hadn’t been exposed to it because I majored in math instead of CS, but later on I learned that common for CS students often don’t come out with SQL/debugger skills either, which I still find really weird.

Personally, there is no way in hell I would have been able to build the AI system behind Math Academy without a debugger. It would have taken so much longer that it just wouldn’t have been feasible.

So many bugfixes have come down to pausing the dataflow in just the right place, often in the middle of a complicated graph traversal, and being able to run various ad-hoc analyses on the entire graph at that moment in time to figure out what’s going on.

And the specific place to pause, the specific analyses to run, I wouldn’t know beforehand – I would only figure that out by stepping through the code and taking a look around at the overall state of things.

Tip #2: Never come up emptyhanded, even if you don't fix the bug.

When you are tasked with attempting to fix a bug, and things are not going so well, keep a “lab journal” log of what you looked into. Why?

1) Even if you can’t solve the issue, if you have a bunch of “here’s what I tried and here’s what happened,” “here’s something weird I noticed,” it might spur your supervisor to come up with a suggestion of what you might look into next.

2) It will also demonstrate how much work you did on it. It’s never a good idea to work on a project for someone else for an extended period of time and risk not having anything to show for it. If it’s possible you might not come up with a solution, you always want some kind of log of what you did. Usually that’s just writing code, but in the case of wrestling with a nasty bug, it’s like a journal of what you looked into.

Want to get notified about new posts? Join the mailing list and follow on X/Twitter.