There is hope if you’re struggling in your first job writing code
Your first job in software engineering or data science can be demoralizing. Especially if you don’t have a background writing code. I often get messages from people asking for advice on how to improve. But what they really need is someone to tell them — “you can do it!”
Below are mistakes I personally made during my first software engineering job. This should make you feel better if you’re having a tough time.
1. Writing Clever Rather Than Readable Code
Writing good code is hard. Understanding bad code is harder. But this isn’t intuitive when you’re started out. Thankfully I had a senior developer who called me out on each of the below points more than once.
- Multiple nested if/else statements on the same line
- Excessive use of chained methods
- Regex copy/pasted from stack overflow without comments
- Over abstraction
Compressing logic into as little space as possible made me feel smart. But it also made my code unreadable. Now I always try to err on the side of readability.
2. Using Variable Names That Give No Context
Coming up with good variable names is surprisingly hard and I wanted to complete tickets as fast as possible. So I’d choose the first name that popped into my head.
- A user’s last name became uln.
- An array of emails became array.
Both are bad ideas and made it difficult for anyone to understand what I’d written (including myself).
3. Allowing Security Holes
This is another situation where I’m thankful to an awesome senior developer who saved my code from getting hacked. I’ve done all the following:
- Allowed SQL injection
- Allowed accessing restricted pages by URL jumping
- Used only front-end validation
- Namespaced URLs with incremental ids
It took a long time to build up a mental checklist of best security practises, which I now use when reviewing other developers’ code.
4. Writing Code Immediately After Reading A Feature Ticket
Spending a week on a feature and then realizing its the wrong feature is embarrassing. I’ve done it more than once. Taking a breath, understanding the business problem, and planning code around it is a huge multiplier for engineers.
Learning from this, I make new developers in my own startup plan out tickets in detail before beginning. This level of micro planning helps clarify thought and develop more effective solutions.
5. Commenting Too Much Or Too Little
In the beginning I commented nothing. Then I went through a phase where I commented every line. A method called add_two_numbers would have been commented with # adds 2 numbers. This is too much.
In retrospect, the right amount of commenting didn’t click until I’d read enough code written by other developers, and noticed where I wished they had added comments.
6. Pushing Duplicate and Unused Code
I’ve done all the following:
- Written functions that already exists in an app
- Left autogenerated but unused files (ie: test files)
- Added packages that weren’t used
Some frameworks autogenerate a lot of unnecessary files. You also don’t know all the existing code when you start working on an app. Anecdotally, I’ve found the best way to avoid these problems is walking through code you’ve written in detail before submitting it for review.
7. Writing Inefficient Database Queries
I knew zero about databases when I started my first job. It probably took me a year before I figured out database indices.
In that time I wrote a lot of N+1 queries, and created db tables to store large amounts of data without indices. Both are recipes for an annoyingly slow app.
8. Using Error Based Conditional Logic
Conditional if/else statements are a core part of software. Sometime we need to rescue an error, like when hitting an unreliable API. But this should be the exception rather than the norm.
9. Submitting Code For Review That Combines Multiple Features
One of the first things I learned was to not combine multiple features in the same pull request. It’s not nice to the person reviewing code. Going beyond a couple hundred lines can make it difficult for others to mentally walk through different paths of execution.
Sometimes this is the result of poorly scoped tickets. So I always tell new developers to push back if they think a ticket could be further broken down into sub tickets. Smaller is better.
Conclusion
Learning to write software is hard. There’s a hundred moving pieces that you can only learn by doing. I hope that reading about my fumbles makes you feel better if you’re struggling yourself.
What helped me the most was having a senior developer give detailed feedback on every piece of code I submitted. Find a company/team where you get that. It’s the fastest way to improve.
