Dear Junior Software Developer…
This is a letter to you, as you start on your terrifying, amazing and sometimes frustrating journey into the bowels of modern software engineering. I tried to summarize for you some lessons I learnt after 4 years and 7 jobs as a software developer.
Lesson 1. Decide what kind of software developer you want to be — it will be easier for you down the line
So, I think it would be good to understand very well what types of software development jobs exist on the market before you decide on the path you want to take. I don’t detest what I do now, because I’m fascinated by the process of developing software and building stuff, but I do regret not giving it more thought and not doing more research before starting my career in the field.
How can you know what the various programming roles are about? Ask people who work in those roles to tell you. (I just had the brilliant idea of starting a series on this topic. Let me know if you would be interested in finding out what every software engineering role is about and I will try to reach out to people and interview them about their day-to-day work).
Lesson 2. There is no perfect software development job out there
When I started, I had this idea in my mind about finding the “perfect” job in the “perfect” company. What did that look for me? Nicely written, well structured code, helpful senior software developers that would guide me as I grow, clear processes, plenty of time for both feature delivery and refactoring, unit testing to cover every aspect of the code, amazing QA who would catch all bugs in the blink of an eye…
The more I think about this image of perfection, the more I giggle thinking how far from reality it is, especially in a young company.
There is no perfect code. Most of the time you’ll inherit poorly written and/or structured code that you’ll hate. Maybe you’ll hate parts of it and love some other parts. Most code is bad because it was sometimes written without the intention to be pushed to production or kept for so long, or back then, the team had no architect or senior developer, so decisions were made that were regretted later on.
There are no senior developers who are there to help you. If you find one, cherish every second spent with that person and suck information from them like a vampire. Seriously. Most senior devs I know are busy over their heads leading refactoring efforts, writing technical designs, solving production bugs and, in extreme cases, keeping the code from not collapsing.
There are, however, good teams and bad teams. Teams where collaboration replaces competition and where you have partners to pair program with.
Lesson 3. Side projects will help you grow fast(er)
I spent way more time than I want to admit reading technical books and/ or looking at “how-to” videos on the internet (which let you dip your toes in a framework/ language, but nothing more). Don’t do that. Start a side project using the tech stack you want to learn. And no, not another to-do list, please! You don’t have to come up with an original idea (although that would definitely bring you closer to early retirement). Some examples of good side projects:
- Virtual library, with books that you can add/ remove, rate, filter per genre and rating.
- What should I wear today? Clothes randomizer to speed up decision-making. The more advanced you are, the more rules you add to the algorithm (color matching, mood, time of day, season, occasion).
- Simple social media website (implement the basic functionality of the big ones out there: Facebook, Instagram, Reddit).
- E-commerce website (I am currently working on a side project for one)
- Computer game (start with Tic-Tac-Toe or the Google no-internet T-rex game).
- Family website. A profile for each family member with photos. You can implement a full CMS solution, where family members can edit their own profiles, write blog posts etc. Bonus: add an interactive family tree.
- A more enterprise app would be: dashboard with charts (look for datasets on Kaggle.com, they have plenty). Each chart has its own widget/card and you can apply filters so that the charts update (that’s a bit more advanced).
These are all full-stack projects. It’s difficult to produce something that’s easy to show for back-end only, so try to keep the front-end minimal and focus on the back-end stuff if you want to grow in that direction.
Why are side projects great opportunities to grow?
First, because you have an end goal in your learning. I noticed that if I aimlessly read books and technical articles, I find nice ideas, but I always forget them if I don’t use them in practice.
Second, because such a project is teaching you to be self-reliant. When you’re on your own, there’s no senior developer you can turn to in case you get stuck or you run into trouble. The side effect will be that you’ll grow more confident in your own capabilities (because now you have proven to yourself you can be self-reliant). That’s a good cure for the “impostor syndrome”.
SIDE NOTE: if you don’t like side projects, you can also start volunteering in open source. A lot of open source repo’s on GitHub have “Good first issue” tags to help you start. I might write more about this in a future post.
LATER EDIT: I just received this article from Dev.to of a list of full-stack projects you can work on before 2020 ends (I’d say, work on them whenever and don’t look at the technologies they use there. Just take the project ideas and implement them in your favorite tech stack.)
Lesson 4. If you want to write better code, find good code and imitate it
In your programming journey, you’ll inevitably find people who are “subject matter experts”, that is, who know a library, a language or a framework inside and out. Who probably have repositories with code examples on GitHub. Look at their code, study it and try to imitate the parts you like. Maybe you admire the concise way in which they write code (I am a sucker for clean, functional-style code). Maybe you see a nice project structure, or a script you find useful. Feel free to get in touch with them and ask them questions if you don’t fully understand something. People are generally open to answering questions about their code.
Never copy code without understanding how it works. There’s no benefit in that.
Lesson 5. Seniority != number of years
What a shocker, right? While in other professions, number of years in the field matter, in software development, they are not a clear indication of somebody’s seniority. You can remain a junior or a mid-level developer for a very long time, it’s all up to you how fast you grow. So what’s the difference between a junior and a senior developer? There are plenty of articles written on this topic, one of my favorites being this one and this one.
Lesson 6. Software development is not only about writing code
You should forget about the idea that in order to be a good software developer, you should only be concerned with writing good code and delivering features. That’s only half of the job.
The other half is understanding in detail what that code is meant to do. The clearer you have that in your head (or written down) when you start writing the code, the easier it will be for you (and the faster you can deliver the code).
Let me try to give you an example.
- “Implement an employee performance page”, is a poor description of what I want. You have to fill in a lot of blanks by yourself, but you don’t want to do that, because then you will start assuming a lot of stuff.
- What if I told you: “Implement an employee profile page, showing charts for each skill of the employee and how those skills compare to those of his peers.” That would definitely be better, but still not enough for you to start implementing the page.
- “Implement an employee profile page, showing the following: — one chart for each of his top 4 skills, with one line representing the average of that skill across similar positions, and one line representing the employees’ own skill development over time. Another chart, a scatter plot positioning the employee among his peers, drawn based on the employees’ experience on the x axis and the employees’ total rating on the y axis”. Much better.
Why is this so important? Because you want to avoid making assumptions. Or making assumptions and not verifying them with the people who requested the feature. Assumptions are dangerous because you think you understand something, but if you don’t have a very good knowledge of the context and the reasons why that was requested, then you are probably missing important details. And even if I had perfect understanding of the context and the reasons, I would still double check everything before getting to work.
So, if you are to take one single thing from this article, is this:
In software development, as in life, assumption is the mother of all fu*k-ups.
Lesson 7. The bigger picture is important to becoming a better developer
I had an epiphany regarding what it means to be a software developer while listening to Jessica Kerr in this brilliant podcast: https://changelog.com/podcast/398
She makes the point that the one thing developers should know is how the system they build interacts with other systems and how the various parts of the system interact with each other. This is important because everything impacts everything in more or less obvious ways. This becomes very clear while bug hunting (my favorite activity).
For example, within the system, the way we write queries impacts database performance and query speed. The way in which the user is allowed to interact with the front-end of the app impacts the server by the number of requests the server needs to resolve. Poorly secured front-end/ back-end impact the whole app.
So, to be a good software developer, you need to be able to understand the whole picture, how the code you write fits in it and how all parts of the system interact with each other.
So that’s all I’ve got (so far). I’m sure this list will be different for you, and I’m looking forward to hear what lessons you’ll learn or have learnt already in your journey.