How to Level Up as a Developer

Tips to Go from Junior to Pro

I’ve had the pleasure of working with some incredibly talented developers in my career. As both an individual contributor and manager, I’ve seen what it takes to become a senior developer capable of owning and managing high-stakes projects in an enterprise environment. Becoming an accomplished developer undoubtedly takes a lot of time and efort. These are some tips that will improve your code quality and make this transition a little bit quicker. In no particular order:

1. Write things to be maintainable long after you’re gone. Just because you fully understand how something complex works, doesn’t mean the person looking at it 5 years later will. Avoid designing Rube Goldberg machines. This is common with developers coming out of school used to short-term assignments.
2. Comments and clear variable names go a long way for readability and maintainability. Use them.
3. Measure twice, cut once. Briefly sketching a pattern or architecture in a notebook before you write a single line of code can save a ton of time down the road, even for small a feature.
4. Not being able to trust the state of something in the database is the kiss of death. Having extremely tight control over any state changes for a resource in your database is essential.
5. Use one single state over a combination of status flags that derive state. For example if you’re running a book store, a book could have a state of “used” or “new” instead of having status flags like “hasBeenOpened” and “hasBeenSold” which combined would derive the single-line state.
6. When dealing with related data, use transactions to ensure data is updated at the same time. If you’re using an older database that doesn’t support transactions, have a replay mechanism available so if something were to be replayed from a bad state it transitions to the desired state.
7. Knowing when to make things idempotent versus throwing an error is a skill. Generally I’d err on the side of idempotence. In the case where an operation retrying is a sinister sign of a bigger problem, then you may want things to error and breakdown before that occurs.
8. Good error handling, like propagating helpful errors from the backend, can be tremendously useful when debugging an issue on the front end.
9. Error messages should be helpful but not too specific. Raw errors should never be passed back as they could give expose important system information which could be exploited by a malicious actor. Security through obscurity is useful when used on top of strong security practices.
10. Logging software is invaluable, however logging too much will dilute its effectiveness. If there are alerts that constantly get ignored or don’t require action, they should be re-evaluated.
11. Keep little to no logic inside the API layer of your application. Instead logic should live as close to the resource it’s touching as possible. This will make your code more reusable as well as help to preserve key patterns if similar functionality is needed in another part of the codebase.
12. Consistency is key, parameter names across an API surface should share naming conventions. Responses should share a standard format. Inconsistencies in the API are generally the first sign that something has been hacked together.
13. When reviewing code, just because something works doesn’t mean it’s done right. Giving constructive feedback and expressing any concern is essential. Don’t look at it as criticizing someone else’s work. When your review is on code that introduces a bug or causes an issue, you are equally as responsible as the writer.
14. Consider performance and scaling. This separates hobbyists from enterprise-level devs. Is this something that needs to run serially or in parallel? Are the database queries hitting a good index? Will this operation work the same way on the millionth attempt?
15. Be careful of queries that don’t have a limiting factor on them, like date or size, e.g. queries that look up all documents in an initial “created” state. If there are a ton of created, and then later abandoned, resources in your system, this query will balloon in size and degrade in performance as your data grows.