I officially have three years of experience and a mid-level job title. My best advice has changed significantly since I wrote 12 Things I learned During My First Year as a Professional Developer two years ago.
1. Level Doesn't Matter, Results Do
Nobody asks how long you've been developing if you are solving their problems. Don't put off learning about a topic you're interested in just because it's called advanced. You never know what you'll be asked to build, so it might just come in handy sooner than you think.
2. Don't Memorize
Learn how to find the information you need. I'm not talking about StackOverflow and GenAI. For the tools and languages you're using, know where the spec or documentation lives. Find out who writes the best guides.
It doesn't matter if you can't remember if the ? or : goes first when you go to use a JavaScript conditional operator. It matters that you know when to use a conditional operator and where to find the exact syntax.
Tools constantly update. Always check the version of the docs you're reading. Find a way to keep up to date, whether it's a newsletter or that one friend who's really into CSS.
3. Go Deep on the Basics
Take it from someone who's worked in three JavaScript frameworks in 3 years - if you know the basics well, it's a lot easier to learn a new tool in the ecosystem. You'll probably end up writing simpler, more robust software. You won't try to write features that already exist because you didn't know they existed. You'll better understand the errors you get and anticipate errors before you cause them.
4. Systems Thinking Will Get You Far
Troubleshooting any bug requires systems thinking. If you don't think about the plug in the wall, you won't think to check it when the toaster won't turn on. Being able to think about the system as a whole makes it easier to predict edge cases and design new features. Read more on how to create mental models for your codebase in Getting Started in a New Codebase
5. Trying Before Asking Ensures It'll Never Be a Stupid Question
Developers are usually problem-solving oriented. If you can show you tried a few things and they didn't work, they're probably going to want to dig in themselves to find out why the obvious solutions didn't work.
6. Every Line of Code is a Liability
Write code like someone else is going to have to fix it. (Even if that someone is just you in 6 months.) Install packages like you're going to have to update them frequently. Document the why so you don't accidentally break something later. Learn the opinions of an opinionated tool before you make it integral to your system and find out its opinions clash with features you need.
7. Practice Reading Others' Code
The way software development is often taught may lead you to believe that you will often get to create fresh, brand new apps. It's much much much more likely that you will be fixing and adding features to an existing codebase. You may even spend more time reading code than writing it. Practice reading code and refactoring code without introducing new bugs.
8. Test, Test, and Test Again
As Chocho said in his DevNexus 2024 talk, "Code is theory. Software is practice." Always run your code and test it before asking for review. Practice writing tests as much as possible. You'll find anticipating how a user could break your code and thinking about more than the happy path will make you a better developer.
9. Practice Turning Requirements into Software
Ticket #387
- Add a button to the page that opens a modal and allows a user to edit this data.
It will be expected that you can turn a requirement like that into a list of steps or pseudocode. If the ticket is too vague, it'll be your job to get the answers you need.
After ironing out those steps, you'll be expected to turn them into code and (hopefully) tests for that code. Then it will be your responsibility to get that code through your company's version control, (hopefully) review, (hopefully) QA, and deployment process.
Open Source is a great place to practice this.
10. Community is Extremely Important
You're not going to get the most nuanced, unbiased perspective in social media posts. You need a support network to call when you need that perspective.
Mentorship is a part of this. Going to local meetups and conferences are a great way to build your network and expand your development world view. Joining networking groups will give you access to senior developers' perspective.
Don't try to do this job all on your own. There's a lot of information out there, and it's easy to get overwhelmed or get tunnel vision.
11. Find What You Enjoy About Programming
I'm not saying love your job or become the elusive Passionate Programmer. However, constant learning is opening yourself up to repeated discomfort. If you don't know why you want to keep waking up and doing that to yourself, you're going to burn out. It can totally be a selfish reason, but you have to know your why.
12. Everyone's on Their Own Journey
You're not competing with others' careers and content. Someone else's path to success may not work for you at all. Focus on your unique perspective and strengths. Find and share your voice. Someone out there wants to hear it.
Conclusion
Looking at my (or anyone else's) profiles may lead you to believe that my road to mid-level developer was straight and smooth. It couldn't be more to the contrary. I've stumbled and cried, broken prod, burnt out, and gotten stuck in many a rabbit hole.
For that reason, I have to earnestly thank my husband, family, friends, and tech community for helping me stay on my feet. I must also thank many coworkers for taking a chance on my potential. Without y'all, I wouldn't have made it this far. I'm so grateful that I have.
Number 2 is so important, "I don't know" is perfectly fine especially if you can add "but I can find out".