12 Things I Learned During My First Year as a Professional Developer

One year ago I started my first job as a professional developer, and I've learned so much in the last year! Everything I've been through made it crystal clear I love building things with code and don't want to be doing anything but that for a long time. Here are the top 12 things I've learned and a bonus Notion database of the resources I've found useful.

12 Things I've Learned in the Last Year

1. There is no perfect code.
   There will always be a backlog, things you'd like to fix, and different ways to implement the same thing. Similar to how a work of art is never finished, just done for now.

2. Beware those who use the term code smell.
   Constructive feedback requires ways to improve. Anything else is unsupported criticism. Also be suspicious of anyone who heavily criticizes your work and not your peers'. If someone starts making claims about what a "real developer" does, run.

3. The job is all about learning.
   Learning new features of the languages and tools you already know. Learning new languages. Learning new tools. Learning just enough to solve today's puzzle. If your first thought is "I'll Google it and try a few things" when something breaks, you've got the touch. Lean on "I don't know, but I'll find out."

4. Learn from everyone you can.
   I mean, you're already kind of doing it with Stack Overflow. If you're early in your career, hoard mentors and jump at opportunities to pair and discuss theory and design with senior developers. If you're years in, ask for peers' opinions and code reviews and still pair.

5. You can only learn so much at once.
   It's a marathon, not a sprint. Since I started studying web development, there has been this constant feeling of overwhelm because there are so many topics I want to learn and only so much time in the day. Everyone is feeling that and wondering where their focus is best spent. Eventually I realized rest and fun outside of coding are just as important as trying to keep up to date with my stack and learn cool new things. I hit a wall in the last year and had to re-examine my priorities. I've been working hard to establish healthier habits in my daily routine so I have enough brain juice to learn more.

6. You're going to break it.
   The more you break it, the better it'll be. It's fun to break it in development and testing environments. My favorite ways to learn a codebase are breaking it and investigating why it broke. Break it before production. Ask the least tech savvy person you know to break it. Ask the most tech savvy person to break it. This is how you find UX issues, security vulnerabilities, scaling issues, and more! No matter how much you break it, it's still going to break in production somehow.

7. Replicate before investigate.
   This is step one in my troubleshooting process. If you're a worrier and on production support, create a troubleshooting plan. This requires being familiar with the system so be sure to ask questions like "When something breaks, what logs do you look at first?" early and often. If you get an adrenaline kick from prod bugs, the first thing on the plan should probably be something to remind yourself that it's not life and death. The only way senior devs got to the point where they could fix a prod bug quickly was an endless cycle of breaking and fixing it.

8. Look, I'm learning about the tools people will pay me to use.
   I've gotten a fair amount of comments detailing the evils of JavaScript frameworks and how web development has devolved into a bloated, vulnerable monster in response to my public work. I'm still going to be logging in and working in React every weekday because that's what they will pay me to do. I'm all ears once you figure out an alternative that companies will use, though.

9. It's a great time to be a web developer.
   Internet Explorer is finally dying. Getting into web development is more accessible than ever before - free remote bootcamps and communities abound. CSS is having a grand old time with exciting new features like container queries and grid and flexbox support like debugging tools in DevTools. Not to mention, Dice's community survey found web developer salaries rose by 21.3% from 2020 to 2021.

10. Always be honing your communication skills.
    Whether it's self-promotion for an interview or your daily job, the ability to communicate a very technical concept to a layperson or beginner is a super power. In tech, it's not those who can't do, teach. It's those who can teach are brilliant. No one will fund your miracle math project if you can't explain it to investors like the guy who hacked the PS1 to make Crash Bandicoot. They certainly won't fund it if you never tell them about it, so learn to factually self-promote. The more I code, the more I forget I can't just show someone an error message in response to their question - writing guides and tutorials for beginners is my way of counteracting that.

11. There is no way to remove the human element from tech.
    We all know social engineering works because people are the weakest link. Every program you write is limited by what you know and want. Every tool is limited by what the people who created it knew and wanted. You have to talk to people, not only to produce your best work, but also to find out unintended consequences of your work. Then you have to analyze who wasn't represented when you talked to people. It's great to live in a time where the tech you build can easily affect thousands of peoples' lives, but what are you going to do with that responsibility? If we don't ask these questions and seek to mitigate harm, we get Facebook.

12. Tech has an inclusivity problem.
    Which is comical because diverse testing is the single best way to ensure you're putting out a good product. I don't just mean the sad hiring statistics - the lone hacker stereotype does us no good. The monolithic founder myth has got to go. A single viewpoint doesn't just make for code with blindspots, it also fails to imagine the best solution. Far too often developers are expected to sink or swim, and carry that on into how they interact with coworkers and the code they push. Developers with experience, tastes, and opinions that differ from yours, QA, DevOps, designers, accessibility experts, product owners, data scientists, IT, InfoSec, researchers, DevRel, and especially users have a part to play in improving and maintaining the app ecosystem. Acting like you alone can and should anticipate every user's situation is folly. You don't know what you don't know.

Conclusion

I hope some of these things I've learned will be helpful to you, but I know this Notion Coding Resources database will be. I started by going through the list I had made of things I wanted to come back to after bootcamp. Then I noticed how many coding bookmarks I had! I'm still adding bookmarks, but there are quite a few goodies in there already.

Comments

[Oluwafemi Micheal]

It's really helpful dude

[Melvyn Sopacua]

You've made very good observations, except one: Google it and Stack Overlow. Replace those with ChatGPT. Especially for boiler plate. As a senior, I often ask ChatGPT for starters now. I was sceptical at first, but definitely with Chat GPT 4 and a good prompt, you can get a really good base code to integrate.