Hey, what’s up? I’m back with an article that is not as technical as usual. I thought I’ll share with the world some cheat codes I learned while playing the software dev game for several years. When I started playing this game, I was alone, with my old Packard Bell PC, in my room somewhere in Cameroun using an old “Sams teach yourself C in 21 days” and a poor internet connection. I had no mentor, no peer, just me and my desire to be as smart and skillful as Chloe O’brian (from 24) and Shadow Walker (from Nikita). As you might have guessed, I went astray several times, learned completely obsolete stuff, and used tools inappropriately. Luckily, I didn’t give up and found the right path.
I’m not a rock-star dev, I’ve not seen it all yet, but I still feel like what I learned can help any dev out there, that is the reason why I’m writing this article. I wish someone told me what’s in this article when I first started playing the game. Please don’t hesitate to share, like, and subscribe to notifications. You can reach out and follow me on social media for more.
Things I wish I Knew as a Junior Dev
Before I start, I will ask you, to share your opinion about these tips in the comment section. These are my principles, and they work for me, but I wish to know what works for you as well. Tell me if you share my opinion, and if you’re a Junior dev reading this, let me know if it helps you 😊.
1- Tutorial Code isn’t the state of the art.
Most often, tutorials we see online contain code purely for demo purposes, and should not always be used as is. The people writing the code most often omit some stuff for the sake of brevity. When you got started building software, I can bet what you want that you thought following a tutorial online with code snippets in it always meant that code can be used as is in prod, for that feature in your project naively thinking that it is always the right way to do things.
Let me explain. For example; you learn a new programming language, and you follow a tutorial telling you how to use an HTTP client to call an API from your client app. This tutorial tells you; HttpClients should always be disposed of. You follow it, the next thing you do is, dive into your project and create a new HTTP client in every method or class calling an API, and dispose of the HTTP client after usage. This sounds normal in the beginning, but once get more experience and you start working on real-world apps, you notice that the right thing to do is to use an HTTP client factory, or reuse the same client for the app’s lifetime depending on what you’re building. Note: though you dispose of your clients, sockets might still be opened and this might cause memory leaks. For more information on why this is not the former is not the right thing to do, you can read this article I wrote.
To avoid falling into this trap, you should go through the source code of real-world software that uses the functionality you want to implement, even if you followed a tutorial about that feature. You could also ask the person who wrote that tutorial for guidance.
2- You are expected to Ask for help! You won´t be looked down upon
You’ve started this first job or internship as a software dev. You’ve spent hours mastering your programming language and framework. You want to show what you’re worth, but bam! On the first day, you’re assigned a task you can’t finish or even comprehend how to tackle it. You spend hours or even days searching and trying things alone on your own. You can’t find a solution, but you don’t want to ask for help because you think you should do it on your own, for fear of being judged or looked down upon as an incompetent dev.
Stop! and ask for help. it is better to ask for guidance as soon as you realize you’re stuck than to waste hours figuring out things a senior dev could just show you in seconds. You’re expected to ask questions in fact, a lot of questions. Just don’t make your colleagues repeat themselves too often, and be smart enough to assimilate quickly. Remember, software development is a Team work.
3- Join a community as early as you can
Imagine you’re getting started on something that needs perseverance and hard work, will you be better off doing that all alone on your side or with comrades who share your passion, in a community where you can help each other, share tips, insights and opportunities? I prefer the latter. Obviously, being in an online or local community can be a catalyst for your growth. There are several communities on the internet or even local communities. earlier in my career, I was an active member of my local community in (Silicon Mountain) Cameroun and this helped a lot. Especially when it came to motivation. If you have a framework or programming language you love or would like to learn, just Google user groups around you. You’ll find several meetup groups, or even Facebook groups, slack, or discord servers with people who will welcome you. By the way, if you’re in Cameroun and love dotnet, you can reach out to me or join our meetup group 😉.
I remember when I was in the silicon mountain in Cameroon. We had a community made of awesome people, and we used to help and motivate each other. Sometimes working and coding all night and having fun. I miss those days.
4- The key to understanding a poorly documented codebase is reading the unit tests first
This is something I learned the hard way. By the way, do you share my opinion here? does it sound very obvious to you ? or do you have another method? Back when I had enough free time to play around with code on GitHub, and explore frameworks and code samples, I had a hard time going through the code base and reading it, then connecting the dots. When you find yourself not knowing what code portion does what action, just go to the unit tests. They show you exactly what the code is supposed to do, plus the expected outcome after the code’s execution. This trick works everywhere, every time, every day, even on Sundays lol.
5- The quality of your work is more important than how many hours you clock
You’re better off producing quality work fast and leaving early, than staying the latest but having a poor output. There is this culture of proving your dedication by showing up early and leaving late. Though this is great, it only works if you really put in the work and enough effort in the right direction during the time you are at work. You should always focus on performance rather than the hours you clock. Those I respect the most are productive people who do things at their pace, and also know when to use the extra time they have at their disposal to be more productive. All of the places I worked at always favored productivity as a performance metric, rather than the time spent at work. I believe managers who do not think this way have it all wrong.
If you find this article useful, please follow me on Twitter,  Github, Linkedin, or like my Facebook page to stay updated.Follow me on social media and stay updated
6- Softskills matter a lot
Only focussing on technical skills will not take you far. I learned this the hard way. At the start of my journey in the Software engineering game, I believed sharpening my technical skills was the single most important thing that mattered, and everything else was far behind in priority. If you think that too, you’re on the wrong path.
Here are some soft skills you need to add to your backpack to keep playing the game smoothly.
- Understanding requirements is part of the implementation process, and you should take that seriously. Don’t rush into implementation just because it is the most exciting part. Take time to note down what you are asked to do, ask questions, and don’t stop until you’re sure you’ve understood. The worst thing would be to put in the right efforts in the wrong direction, and you should avoid that.
- Self-awareness is invaluable. Be aware of your limits, your strengths, and your weaknesses. When you’re aware of these, you can seek proper guidance and mentorship. Don’t forget that denying that you don’t know something is seen as a weakness. No one knows it all, the best professionals are those who confidently say, I can do this and I can’t do that.
- Try to be self-taught. You’ll need to learn constantly and knowing how to learn is a must. So many developers are self-taught, so this might not be a big deal.
- Emotional intelligence is important, especially because software development is a team game. Imagine you’re a senior dev working with a junior dev that constantly gets mad and argues when he is corrected, or when his silly mistakes are pointed out for improvement. Or, imagine a senior dev that won’t admit and fix his mistakes when they are pointed out by a junior dev because he is not humble and objective enough. You should be emotionally intelligent, to make communication and collaboration easy. I’ve come across people that made it feel like hell to work with them. Don’t be this kind of person.
7- Working in a team is very different from working alone on your side project
If you’re like me, a lone wolf that learned mostly on his own, alone in the dark at night on his side project, When you later join a team, you’ll notice there are differences. Just remember that you should obey the standards set by the team. This might include;
- Respect coding style, rules, naming conventions, etc.
- You can’t commit any file or leave console logs or remarks for yourself inside your code.
- Don’t submit pull requests with code that will break the build pipelines.
- Make it as easy as possible for your colleagues to take your code from when you’re gone.
- Make the code review process smooth.
- Always remember to merge or update your code before going on with your implementation process.
8- The best way to learn is by doing
Do you want to learn java? Build something with Java. Do you want to learn Flutter? Build an app with it. Do you want to learn Angular, React Vue, etc? Build a web app with it. No matter what you’re building, just do it. The process of asking yourself how to implement a functionality will make you learn more than someone who just reads programming books, follows courses, tries to cram keywords, and thinks they are ready to be software devs.
I have a friend complaining about someone he met who could tell him the history of the Java programming language, the keywords, and high-level concepts, but couldn’t write working Java code. If you think you’ll learn software development as you used to learn history, literature, or geographics in school, then you’ll never get far. Learn by doing instead.
9- Your skills are worth nothing until the world knows about them
You might be extremely skillful, but what value does it have if you can’t prove your worth to the world? When it comes to getting a job, the person hiring you should be able to quickly evaluate your skills and compare them to your peers. Passing the tests of a job interview is not enough for that. The ideal way of proving to the world your software engineering skills is by;
- Building software used by people.
- Contributing code to GitHub
- Creating content; YouTube videos, blogging, technical writing, etc
10- Keep yourself updated every day
Always remember this; In this field, things can become outdated or obsolete in the blink of an eye. You need to stay up to date with things going on. Once you start your journey in software development, you should never rest and stop learning. If there is one thing that should be constant in your life, it should be learning. If you take a break for only 6 months, you will come back and be obsolete! Things are moving extremely fast.
These are ways I use to stay constantly updated, and be at the bleeding edge of everything going on.
- Subscribe to Github release notifications of your frameworks and libraries. Then read the release notes when you’re notified.
- Follow the engineers who build the stuff you use to do your work. New announcements will most likely come from them.
- Follow bloggers/YouTubers in your field (front-end, mobile or back-end dev etc).
- Subscribe to weekly newsletters about everything going on in your field.
Conclusion
Software engineering is the most exciting field of expertise. What I love the most about it is the ability to materialize your thoughts into something real. The only limits you have are those you set for yourself. This article is one I wish I had read when I first started writing code. I write this as an effort to impact positively any junior dev that might come across it. Don’t hesitate to share, comment, and reach out to me on social media 🙂
Follow me on social media and stay updated
Leroy Van