Imposterism, Continuous Learning & Bean Bags — My First Year as a Software Engineer
A year of professional experience marks the first of (hopefully) many significant milestones of my career. A lot has happened in these first 12 months, so I figured I’d share four of my biggest takeaways and hope that they offer some form of insight, or at least entertain you for the next 3 minutes.
I’m not good enough to have imposter syndrome
Being a novice dev is often accompanied by a nagging reminder that you probably aren’t cut out for any of this anyway. And while (I believe) most would agree that imposterism at this phase of one’s career is not only understandable, but also expected, allowing it to go unchecked only serves to hold you back.
Now I won’t pretend to understand the phenomenon, but we can make a few guesses as to why the syndrome is so prevalent among novice devs. For one, the field as a whole is an ever-growing, ever-changing pit of lore. Staying up to date with all the changes and innovation can be overwhelming for senior engineers, let alone fresh devs who aren’t even aware where their knowledge gaps lie. Add to that the arguably high expectations — being fluent in a language or two, striving for stereotypes of 10x engineers, preparations for DSA interviews, intense competition, and you’ve got yourself the perfect recipe to skyrocket your self-doubts to the moon. At times I felt like a fraud because I hadn’t been blessed with the kind of smart gene that’d enable one to port Doom to a pregnancy test; at my worst, I felt like I’d conned my way into a job I wasn’t cut out for, like I’d made all the wrong career decisions. Then I’d do a double take on a line of code, fix a bug, and feel like the smartest person in the world. It’s all very weird, but I digress.
Imposter syndrome has done far more harm than good for me. Aside from your regularly-scheduled creeping insecurity, in the worst of it, it stopped me from asking questions because I felt like I had to resolve things on my own; that if I couldn’t figure a task out and needed help, I’d be wasting other people’s time (in addition to proving to them that I’m really stupid, of course). The irony here is I’d instead waste hours on something that could’ve been resolved in mere minutes. Thankfully, after a handful of months, much of the initial anxiety had worn off and I felt gradually more confident in asking questions, irregardless of how seemingly dumb they were. I think the biggest thing that helped me here was working with other engineers on tasks. Seeing a senior developer be completely clueless when faced with a problem inadvertently eased the stress of the unknown, reinforcing the idea that the goal isn’t to have all the answers, but to develop the skill-set to be an effective problem solver.
In all honesty, I don’t think imposterism goes away; I’m sure it fades as one gains experience, but I reckon a sense of incompetence will forever haunt me (but hopefully in a cool, motivating kinda way). So my plan really is to not fret, and gradually get those 10,000 hours in.
Death, taxes & change
In the time it took you to read up to this point, 5 new JavaScript frameworks have been released and each one promises to revolutionise the way you write SPAs. The ever mutable nature of software means that change is the one constant, forcing us to embrace the fact that there’s no end in sight to the learning that comes along with staying competitive in this field. On one hand, this can definitely be overwhelming. But on the other, if this doesn’t excite a junior dev in the slightest, I’d question why they’re in this field in the first place.
The amount of learning that’s gone on for me in the past 12 months is incredible, and it’s often only in hindsight that it’s actually obvious.
I was fortunate that my company, ServiceRocket, engages all new devs in a company ritual — having them embark on quarter-long onboarding projects where they can build practically anything they deem of value to the team or the company. This helped me gain familiarity with how our teams’ products (which at the time was mainly Atlassian apps) were built from the ground up. It gave me the space to really fall on my face — learn and explore the technologies independently, gradually gaining insight into our own codebases, practices and norms.
A massive chunk of learning was done simply through pairing/mobbing with other teammates. It not only helped me learn the ins and outs of my job faster, but taught me dozens of quick quality of life improvements, debugging skills, and best practices that I probably would not have learned on my own as effectively or as quickly. It also taught me the importance of not jumping headfirst into a problem — it’s far more effective to take a step back and ensure that you fully understand what the requirements are, and preemptively spot some possible obstacles.
And of course, I’d be lying if I said that 99% of my knowledge didn’t come from me Googling something. The internet is an amazing place, full of fantastic people that will teach you absolutely anything for free. The same goes for staying up to date — there are dozens of excellent email newsletters, YouTube channels, and Instagram pages that help me stay immersed in the environment even in my off hours.
So really, as a novice dev, you aren’t short of avenues to learn from — it’s accepting the fact that you have to, and putting in the effort that’s the real tough bit.
Yapping is heavily underrated
It feels as though half my day is spent communicating with people, while the other half is spent communicating with machines (which mostly looks like begging the TypeScript compiler for mercy). Needless to say, I think one overlooked aspect of this field is the extent to which we rely on our interpersonal skills.
“How well we communicate is not determined by how well we say things but how well we are understood.” — Andrew Grove
Programming is rarely, if ever, a solo gig. Even as a freelancer, you’ll find yourself sweet-talking your way through meetings, perhaps desperately trying to convince the client that the “quick lil feature” they want is in fact a massive overhaul of their system. Likewise, in regular teams, you’ve got your engineers, designers, maybe a product manager. Trying to navigate that dynamic without proper communication skills is trying to insert a circle in GIMP — definitely doable, but not without wanting to rip your hair out. Sure, you might all be building the same piece of software, but everyone is coming in with varying perspectives and priorities, which inevitably presents some trade-offs to be weighed and negotiated for. Without effective communication and persuasion skills, differing viewpoints could lead to deadlock, or worst of all — sow seeds of resentment. So while the project manager may have the final say, their decisions are (dear God, hopefully) shaped by the input of the entire team.
Communication abilities don’t seem to be indicative of seniority either. Take documentation, for instance; it’s typically written by domain experts, so you’d expect it to be really easy to follow and understand — but being a domain expert does not automatically mean you’re a good communicator or teacher. Experts can easily fall into the trap of taking their own context and understanding for granted, and find themselves being unable to ‘come down’ to the level of novices, and you end up with something like AWS’ docs.
What I guess I’m trying to say is that communication is an inescapable aspect of the job — it’s deeply intertwined with individuals and teams’ efforts. Having the ability to understand interpersonal dynamics, express complex ideas concisely, and foster discussions is possibly just as essential as your technical proficiency. So yap away — but do so with purpose and cohesion.
Culture beyond bean bags & pizza parties
I’m not sure to what extent I have pop culture to blame here, but I used to dismiss the idea of company culture entirely. Bean bags in offices, bi-annual pizza parties and being called ‘family’ all seemed like fronts for UN violations taking place in broad daylight. It took me working for ServiceRocket to realise just how important culture is, and what culture done well looks like.
Company culture in its definition can be difficult to pinpoint because on one level — the surface level — it’s simply the values and norms that an organisation practices. But really, culture is the merit of those values, the extent to which they permeate throughout the organisation, and whether they are done so in a healthy and productive manner. Good culture is far beyond quarterly bonuses and a dart board in the office, and is certainly desirable as it acts as a lingua franca; in the face of constant change, culture can be the gooey constant that holds it all in place.
Some things I’ve noticed at ServiceRocket that are indicative of a successful culture include:
- Actual work-life balance — you can’t be productive if you’re burnt out.
- The ability to ask tough questions, have open conversations without the fear of being offered as a sacrifice in an open bonfire.
- Having a manager that facilitates your improvement, from helping you come up with career plans, to encouraging your up-skilling.
- High employee retention. If people are constantly leaving, there’s probably a good reason for it.
If you’d like to actively evaluate the company’s culture, my best piece of advice would be asking questions that elicit how those values are practiced. For instance, most employers will claim to champion work-life balance, but what does that actually look like on a day-to-day basis? Here at ServiceRocket, one of my favourite things that engineers have are Play Days. On Fridays, we don’t work on any sprint items. The day is dedicated solely to tinkering; be it Kaizen, a new language or framework you’ve been dying to try out, or whipping up a prototype of one of the ideas from our innovation funnel. This not only varies the work that we do, but incentivises collaboration, creative thinking and allows for ample experimentation.
All of this is to say that culture is not to be understated and is something I’m not willing to compromise on — the whole ‘a job is just a job’ argument is a tough sell considering we spend half our waking hours doing it.
Well then, that concludes my little semi-coherent rant, but I thank you for getting this far, and hope this has been in some way useful to you. I’m sure I’ve missed out a fair bit, so do feel free to add your experiences or thoughts below. Cheers
