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.
Top comments (50)
Thank you for sharing, Abbey
I am a self-taught programmer, and like many others in our field, I experience imposter syndrome from time to time. Learning programming concepts on my own and not having a degree in CS are constant concerns that come to mind. Starting to learn programming at 27, in addition to the aforementioned points, made me even more insecure.
By sharing all of this, I want to highlight another challenge that many juniors may encounter: shifting focus.
Now that I've overcome this mindset and found a bit of comfort and confidence in my path, I can see more clearly that I've wasted many days of my working hours being sad about the role I have and pondering a switch from front-end to back-end.
The lesson I've learned from this phase of my life is that by giving myself enough time and staying focused on my path, I can overcome my insecurities and find joy in my role again.
My message to new joiners: find what you love, stay focused, be patient.
Imposter syndrome is tough. 💙 This is another area where community is very important. I also don't have a CS degree and started learning to program at 28. I have learned that knowing about both front-end and back-end is a boon even if I'm in a role currently focused on front-end. A lot of this perspective came from talking to senior developers when I was a junior.
Yes, the community really helps. It's definitely important to learn both sides as a software engineer, in my opinion, and creating a T-shaped skillset would really help, sometimes being crucial. However, shifting career paths and putting much effort into a secondary field are what hold some individuals back, as I have experienced myself.
The you have links to community a beginner can join?
Thanks.
Sorry, unfortunately I haven't been really active in an online community untill now.
In the past, I relied on my circle of programmer friends who provided invaluable support. Over time, this circle grew, especially as I worked in various companies.
However platforms like here ( dev.to ) and freeCodeCamp forum can really help.
Also ADPList offers fantastic opportunities for mentorship and support.
I'm also a self-taught developer who begun at the age of 28. But I only learned front-end first because I was always told that as a self-taught developer, it was better to specialize first in something then doing the T-shaped skillset same as the software engineers.
And actually, it was the best advise I could get.
I specialized in vanilla CSS, then went deep in vanilla JS to make a deep dive in React. And my knowledge today, 5 years later, is good enough for having me teaching the software engineers how to use correctly React, setting the good practices and the base front-end technologies to use for the whole company and I was just offered to become the tech lead.
And this company is also giving my time during my job to learn back-end and devOps. I'm glad I focused on something to be very good at it instead of having tried different technologies, I wouldn't be where I am at today.
So my advice would be to maybe find what you like best front-end or back-end and focus on one of them first. Be (very) good on what you do and the sky will be the limit
And if that works for you, great! I and many other people have made a career out of being a wildcard person/generalist/full-stack developer. I've always seen "T-shaped experience" used to remind career changers that their previous career taught them skills that apply to tech. Using it to describe the types of tools you know well is new to me.
Being very good at a few things came from solving whatever problems were thrown at me and going deep on what I was interested in. I respect the people who can be consistent and focused on one thing, but that's never been me. Some people learn best by focusing on a few tools while building a project. Others can sustain focusing on one tool, language, or type of problem for a while. Neither is better than the other or reserved for people with CS degrees. In fact, the tip about being able to turn ticket requirements is aimed at new CS grads as well as self-taught developers stuck in tutorial hell. 😉
The important part is finding what type of learning works for you and what you need to sustain continuous building and learning. It's easy to beat ourselves up for wasting time or not making linear progress, but life happens and we still probably got useful experience (or rest) out of the detour.
Many of the best developers I know and a whole lot of the best developers in history didn't have a CS degree. I hate to see anyone feeling insecure or sad about common developer experiences. That's why I keep writing these kinds of posts and try to save space for people to share like @borzoomv has.
People have been assuming this blog is only for people with less experience than me. However, I've noticed a pattern in senior developers limiting themselves. Whether it's from a lack of community/perspective or a lack of confidence or both, it's easy to focus on the things we still struggle with, what we can't do yet, and where we are compared to others. It's a double-edged sword that we as developers have to know what we don't know. I'm proud of anyone who regularly practices the amount of learning, trying new things, and creativity it takes to build things with code. 💙
Thank you, i'll definetely check these sites.
I appreciate.
Thank you, i'll definetely check these sites.
I appreciate.
Hi Borzoo, I agree with your thoughts. even I started programming when I didn't have a CS degree. it made me feel like doing coding without any vision. I worked on myself and read a lot of articles. I finally, enrolled for a CS degree while working in an IT company. I got my CS degree last year and I still feel like I should have enrolled in the past for regular instead of distance education.
I've left that feeling a way behind now, and now I have been working in IT for 8 years. I think It's not important for me now. Rather what's important for me is improving my current tech stack and learning.
I am Number 6. Every time we type anything we add to the risk of fragility. Keep it simple. Reuse tested code. It's a winner for me.
Who is number 6? You are, number 1
Hi Abbey, An absolutely brilliant article. It highlights everything I have been saying for years.
I particularly like point 11, as I started in software development many, many years ago by teaching myself, because I discovered a passion. I went on to study a CS degree, which was the main way in to the industry in those days.
For more than 20 years I have been a web technology specialist and still love my job.
Number 2 is so important, "I don't know" is perfectly fine especially if you can add "but I can find out".
As a senior level with decades of experience, I can confirm this is all excellent advice! At this stage in my career I am mentoring and leading mid-levels. Reading this was a great refresher for me on the mindset and learning opportunities for them.
Hello world!
If you experience imposter syndrome, learn this: everyone is winging it 😂.
After working for 6 years on a single framework I can tell you that it still feels like I know nothing about it, neither do I even try anymore, you've got Google, you've got documentation (albeit bad at times), don't fear telling your colleagues that you don't know - do tell them that you are going to find out.
Hi Abbey. Thanks for sharing your advice and experience. I am still new to tech as a whole. I am in my 30s and my first degree is in Biology 😅. I discovered I loved computers but never had the chance to learn them back in high school plus I used to feel like it was a very complex field and too complicated for me to learn.
I am currently learning Full-Stack Web Development and am going to use your advice even as I am learning right now.
Once again thanks for sharing.
As a mid-level developer myself, I found these 12 tips incredibly valuable. It's always refreshing to hear advice from someone who's been through the trenches and knows what they're talking about. I especially appreciated tips 5 and 9 – they were exactly what I needed to hear right now. Keep up the great work, and please keep sharing your knowledge with us!
I have been a dev for over 15 years and these are all great lessons to learn. #4 I particular really hit home to me.
For the vast majority of my career, people have been astonished that they can describe a problem to me and I can usually tell them where the problem is in my first guess. That's because I always make sure to have a deep understanding of how the entire system works.
And now I will share a tip from an architect that goes along with your first tip (sorta)... Influence is the name of the game. While level doesn't matter, what you do and how you show it matters a lot. If you are constantly proving that you know what you are talking about and build trust within your community, it is a lot easier to influence others to your way of thinking.
If you can't build that good will and have people respect your opinions, you are never going to get a promotion. As an example, I have been with the same company for most of my career. I was hired at the lowest level of dev and I now have coworkers who have been at the company longer, were 1 to 2 levels higher than me when I started, and now I am higher than them.
Your point 10 is very spot on in this respect. Having a support system that can guide you and push you helps a lot. It helps point out your weaknesses and how to address them. I would encourage everyone (especially jr devs) to find that experienced person (whether internal at your job or external like meet ups) to be a friend and mentor.
I am glad that proving you are technically competent has been enough at your company to garner influence and promotions.
For others, I recommend keeping a brag doc, so you know what to bring up at performance review time. For those who struggle with self-promotion, I recommend practicing stating your achievements, even if you have to do it so factually even your own brain can't argue. If you find there is no established goal post for promotion at your company or the goal post for your promotion moves as soon as you get near it, I recommend moving on to get the compensation you deserve.
I am also going to push back on
Many of us get the challenge, pushing, and identifying weaknesses enough outside of our support network. It is totally fine to rely on your support network for only support. Mine has been instrumental in identifying which criticism is worth listening to and what kind of professional development environments will actually further my career/be healthy for me.
Many thanks for the great tips. Especially tip seven, as a beginner, I only recently realized how much time it takes to understand other people's code when you've spent most of your time learning to write code from scratch.
Some comments may only be visible to logged-in visitors. Sign in to view all comments. Some comments have been hidden by the post's author - find out more