So you've spent the last few months navigating the treacherous interview seas and have eventually emerged employed. Congratulations! Whilst getting your foot in the tech door might be the end of a long road, it also marks the beginning of a hopefully even longer one, one accompanied by its own, unique set of challenges.
In this article I will outline 5 things I learned over my first half year as a software engineer that I found surprising. Of course, everyone's experience will be unique based on their background and the nature of the role they've accepted, but I believe the points below are general enough to apply to most freshly minted paid developers.
1. The codebase is intimidating
And I mean truly, deeply, gut-wrenchingly intimidating. I can pretty much guarantee that the first time you examine the codebase, you'll have no idea what's going on. Your mind will be occupied by vast swathes of cluelessness and panic, punctuated by the occasional impostor-syndrome-esque thought here or there. If you don't cry at least once during your first few weeks, your stoicism rivals that of Seneca.
Perhaps you've only learned JavaScript, whereas the codebase is in TypeScript, perhaps you're encountering a library (or 53) you've never heard of before or using an exotic framework the workings of which you cannot even begin to fathom. Perhaps your eyes are widening as you first dip your toes into AWS at the sheer number of otherworldly sounding services they offer, or perhaps you are exasperating over GCP's inscrutable UI. Or perhaps, as was the case for me, you're experiencing all of above simultaneously.
This is all okay and normal, and you should seek comfort in the knowledge that even seasoned developers struggle in the first months after changing a job. It takes a while to build up company-specific domain knowledge that allows you to understand how everything links up together. Have faith - the impossible will eventually come to pass and you'll one day realise that you've learned enough to start making meaningful, albeit small, contributions to the codebase. I promise!
If you're anything like me, you'll then explain your mini-breakthrough to your colleagues in way too much detail, enthusiastic and wide-eyed, and receive minimal reactions, because the task you're taking pride in is one they could literally do in their sleep, so they probably don't even realise you're currently boasting. But that's okay. You do you.
2. Expectations are low
Thankfully, the expectations placed upon you are likely to be in line with just how useless you feel. You know nothing, your colleagues know that you know nothing, and your manager, too, is in on the secret.
The skill level required to enter a software development profession as a junior is relatively low compared to other professions - you largely need to demonstrate your knowledge of a few programming languages and your enthusiasm for learning. It's as if you were hired as a doctor based on knowing the anatomy of the left hip and right arm and having successfully administered a few band-aids before.
During my interview, I asked my manager how she'd define success in my first year in the role, to which she replied she'd basically expect me to be largely learning and figuring things out throughout the entirety of the first year. In any reasonable workplace, your senior team members will be ready and willing to help you find your footing.
Your standard workplace will not demand that you conduct large chunks of independent work until you are ready. I have to admit that this feels frustrating to me - in an ideal world, I'd already know the tech stack intimately and be able to make large, independent contributions to the codebase. But in reality, I still have to rely on my colleagues to make significant changes, especially when it comes to data engineering and infrastructural work.
And when I say I rely on my colleagues, what I really mean is that we set up pair programming sessions to work through the challenging tasks together. For me, pairing has been integral to developing new skills. There's a balance to strike here - too much pairing will drain either party, but a reasonable amount will support the junior's learning while solidifying the senior's skillset.
3. Communication is key
Software engineering is a highly collaborative profession and as such you will be in constant close contact with your team. Being able to admit when you don't know something, being able to ask for help, and being able to voice any additional support needs you might have are all qualities that will make your life easier.
It can be intimidating to bring up concerns or to admit to struggling with a task. But unless your colleagues are superhuman and possess the skill of telepathy, which is even rarer than the mythical skill of exiting vim without using google, the only way things can improve is if everyone is on the same page. Get comfortable with asking for help.
This can be especially tricky in a work-from-home context, where as a beginner you might feel completely isolated with nobody physically around to ask for assistance. But if you're working remotely, communication becomes even more important, since in the absence of spending time together and socialising, your colleagues won't have the chance to pick up on you having a tough time unless you make this explicit. I've tried to live by the adage that over-communicating is better than under-communicating, and it's served me really well so far.
You have to be your own biggest advocate and try to make sure that you have everything in place that you might need to eventually grow into a valuable and knowledgeable team member. Most companies will have structures in place that will allow you to feed back your needs to the team, for example via retros or debriefs. But it will be your own responsibility to use this opportunity fully and speak up for yourself. After all, it's something nobody else is able to do on your behalf.
4. Learning is non-linear
If you've come straight out of a bootcamp or an academic degree, you might find that the way in which you are now expanding your knowledge starkly differs from what you're used to. It's likely that you will no longer come across new topics in an organised, linear fashion, but instead encounter new, seemingly unrelated problems every day. An exception to this might be graduate programs or internships at large organisations.
But in most medium or small companies, you will no longer be spoon-fed information in the exact order it's deemed most accessible by teaching experts. There will be no carefully crafted tutorials on how your internal tech stack works and interlinks. You will have to go searching for relevant material online, read a lot of documentation and ask your colleagues many questions. It's now up to you to identify where you lack the basic building blocks you need to master a technology, and to go fill these gaps independently.
As someone who went to a 9-month bootcamp which encouraged us to build lots of applications independently, I was used to producing a shiny new app every month or so, from scratch to finish. It felt like I was making massive leaps and continuously absorbing the maximum amount of information my brain would allow me to store.
Nowadays, I feel like my pace has slowed down significantly - for one, the tools I'm learning are trickier to master, and often send me down a rabbit hole of other concepts I need to understand before I can fully comprehend the problem at hand - my own brain's private version of npm dependency hell. Secondly, once you find a solution to your problem, you are likely to have other sprint priorities to return to, and will as such be forced to stop exploring the subject. This means your learning style will likely change from continuous, long chunks of deep subject exploration to discrete, smaller bits and pieces here and there.
This is not to say I haven't learned much over the last half year - the opposite is true. It's just that the learning has been more incremental and less organised. I've really benefited from documenting everything I've learned and taking notes on how I solve certain issues. More likely than not, the same issues will resurface elsewhere, so having notes to rely on instead of my own leaky memory has been super useful.
5. It's not just about writing code
Code comprehension
Say goodbye to visions of yourself banging out line after line of novel code from 9 to 5. The reality is that most days, you will end up reading more code than you write. You will spend ample time building a mental model of how a specific part of the codebase works, until you eventually distil your newfound knowledge into a few lines of code that achieve the required change. These will then go through a code review and if deemed acceptable, become part of the codebase.
Algo-what?
While you're at it, you can also say goodbye to sorting algorithms, hacker rank problems and Big O complexity. Be prepared to not encounter problems that require a ton of algorithmic thinking, at least for now, while you're still a baby dev. This is not to say there is no value in continuously practicing these in your own time - if you have spare energy, by all means, do. But don't expect the job to contain a lot of opportunities to implement the types of algorithmic problems most employers still ask during interviews. Weird, it's almost as if the recruitment process doesn't actually reflect the job accurately... 🧐
Discovery
Not all tasks are glamorous. By this I mean, not all tasks involve solving interesting problems programatically. Sometimes, your job will be to read frequently incomplete and badly written documentation to figure out how the tools you are using work. Setup, configuration, and similar, arguably boring preparatory tasks, are part of the deal - especially when starting new projects or breaking novel ground and doing discovery surrounding existing projects. I suppose that this is the price we pay to earn a decent salary and have fun coding whilst tackling the other, less config-heavy tasks.
Meetings
Expect many meetings. Sprint planning, retros and daily stand-ups. Making sure there's alignment within your team, as well as cross-team alignment. Socials, if you're lucky. In any case, seeing people in 2D on a screen will quickly become part of your daily routine.
Conclusion
Being a software engineer means being in constant contact with people. It's a highly collaborative discipline, and you will benefit from being able to communicate well. The codebase will initially seem indecipherable, but be patient and kind to yourself - things will eventually click. Your colleagues will help you, but you should also be prepared to do a lot of research and learn new tools independently. Be ready to spend more time reading code than writing it.
Have my first 6 months as a software engineer been at times arduous and challenging? Yep. Has it all been worth it? Absolutely. In my own, biased, opinion of course.
Top comments (7)
I just completed around 4 years of development experience, and I cannot stress enough how accurate this is. Step by step, exactly like that.
I would also add: Expect some harsh feedback and do not take it to heart. The quality of your code is not only what you're made of; instead, use the criticism as a way to improve your next commits :)
Great point, very true!
Fantastically well written and scarily accurate description of the daily work life of any dev.
Thank you so much for writing this!
I guess this post is for me because it's my Software Engineering Job
Loved this line, "my own brain's private version of npm dependency hell" - it feels too true!
Do you have a certain way of organizing your notes so that it is usable for future similar issues? I've been taking notes for most tickets I work on, and saving links that may be useful in the future, but wondering if I should organize by topic or something instead.
Hi Hanna, I personally use Notion and organise my notes by topic (or at least I try to).
I have a TypeScript section, a Git section, a Data engineering section, etc. The topics I want to remember don't always neatly fit into one or the other category so I just try and do my best to keep notes in a place I will later remember to look up.
Excellent article. Thanks for writing this. While my first job is titled as a "Support Enginner" (finding, reproducing, fixing, and/or triaging bugs), this still spoke to me 100%. It's been nearly a year now, and the codebase is clicking. Well, the front end is still rough, which is funny, because it's React and I learned React in my bootcamp. The backend feels easy and intuitive, and it's Python/Django, which I never touched before. Funny how it worked out this way.