Developers — Don’t Fall for These Traps
School. Uni. Get a job. Maybe get a cat. Marry. Have a few kids. And so on.
The typical roadmap for a person’s life (though I’d get a dog… sorry Tom). Something similar has emerged in the world of development.
As with the personal roadmap, the developer roadmap is largely indisputable. For example, every person has to go to school, and every developer has to grow a half beard.
But this article is about the disputable points.
Verging on 7 years in the same company, you tend to see trends. Trends so popular you follow them without a second thought. Myths then weave their way in among the trends, and by following the crowd you might end up falling for one.
I confidently attest to the myths in this article as I’ve fallen for most of them — and the rest I’ve witnessed right in front of my eyes. It’s time to put our James Randi hat on and debunk these 6 spurious notions.
You need a Computer Science degree
After graduating from a heavily back-end focussed Computer Science course (I’m a front-end developer), I was proud to be applying for jobs with a related degree as a pre-requisite. “Now, I’m part of the crew who can get this job”, I thought. However my degree didn’t end up so related, as it certainly didn’t prepare me for my front-end developer position.
This got me wondering how ubiquitous related degrees were among developers around me. It turns out not very. I have colleagues with no degree and one noteworthy colleague with an unrelated degree. The latter, sporting an Economics degree and a development portfolio, ultimately outclassed a supposedly “better qualified” rival interviewee — with an Engineering degree but no portfolio.
Why?
They didn’t rest on their laurels, that their related degree would see them through. The same laurels that will deliver a potentially lazier candidate (yes, I’m looking at myself) that automatically drifts towards a development job after graduating a development degree. Pit this candidate against one who goes out of their way to learn how to become a developer, and, well, the accolade of the degree becomes irrelevant.
You need to practice at home
Let’s start by saying pet projects are great. Obviously. To get that urge off your chest or to show future employers what you’re capable of (when you don’t have the bureaucratic s*** to deal with) is fun and should be encouraged.
It’s the apparent notion that a 20-hour course to master the .reduce() method and the like is the best use of your precious spare time. Yes, it’s good to have a base-level of understanding, but the skills acquired will need to be re-learned in-situ. Whereas if you find yourself in a scenario in the office (remember those?) needing to manipulate an array, figure out how to manipulate that array in the moment. The skill you’re then learning is, by nature, applicable to a real-world situation.
Too frequently do developers perceive self-progression purely by completing online courses. A great way to start out, but the chasm between a happy-path tutorial and a real-world problem is too wide, and will only be narrowed by experience on the job.
It’s important to keep a healthy work-life balance so you don’t hate development before you’ve even started. You’ll never stop learning on the job — so keep tabs on your free time and don’t spend it following suit after reading some success story on Medium.
You need to be “full stack”
Ah, the age old “Jack of all trades” strikes again. The myth appears to be that becoming a full stack developer is the holy grail. That if you’ve ticked both sides of the forever blurring line between front- and back-end you’re somehow more successful. I’m sure there are persuasive arguments that advocate becoming full stack, just don’t fall into the trap of automatically thinking it belongs on your roadmap.
If you’re a back-end developer who has to occasionally cobble together some CSS, or a front-end developer who’s finished their “My first Express.js app” — it’s time to remove “full stack” from your LinkedIn profile.
Full stack developers dilute themselves from their once specialised selves by branching out too far from home, leading to the unfortunate title of “Jack of all trades, master of none”. Please, enjoy being a master in your natural habitat and keep your average score up!
This title reminds me of a Greek/Chinese restaurant I went to on the island of Kos, Greece almost 10 years ago. I had moussaka and my friend sat opposite with chicken in black bean. Neither of us left happy. Why did we ever think that restaurant was a good idea?
You need to know everything
Possibly counter-intuitive on the face of it, but you’re better off not knowing it all. Bare with me…
To those of you juniors, ask everything and anything to those around you — to the point of thinking you’re being annoying. Give your colleagues the chance to flex their dev muscles. They’ll love it and you’ll learn exponentially faster than if you act like you already know it all.
To those of you seniors, be humble and embrace the fact everyone knows things you don’t. Your knowledge is also going to get tested from time to time — when the juniors from above are bombarding you, remember what Geoff down the pub (or Einstein, can’t remember) once said:
“If you can’t explain it simply, you don’t understand it well enough”
I’ve certainly been caught on my toes not knowing exactly why/how something behaves the way it does — which turns into a pleasant learning experience for the both of you, if you allow it to be.
The development industry is a microcosm of the world’s population, no matter how stereotyped Silicon Valley makes it seem. The spectrum of types of developers is as wide as the spectrum of types of people.
One type of developer exists who, on the face of it, is Mr./Mrs. Confident. However, these are comfortable, and successful, in the fact they don’t have the answers in their head, but importantly they do know how to obtain answers from someone else. They do this by knowing the right people, something my colleague Daniel Yefet writes about brilliantly in his latest piece:
Mr./Mrs. Confident is now proving you don’t need to know everything to succeed. Over time, they are absorbing what they discover through their growing network of acquaintances — carrying out the adage “fake it ‘til you make it”. Memorable meal-time video on this:
Making it in this scenario is to overcome your shortcomings. Making it, in the sense of reaching the end goal — winning, is something you need to realise isn’t going to happen in development. Yes, you’ll have periodically, glorious “a-ha!” moments, but the day you think you’ve reached the end is rather the beginning of the end of your career as a developer.
You need to be flawless
People make mistakes. Therefore developers make mistakes. It’s après-mistake where you win or lose.
- To hide your mistake is your second mistake
- To learn from your mistake is of course a wise move
- To own your mistake is where we’re really cooking on gas
It doesn’t take a psychologist to observe vestigial behaviour of the child afraid of their parent(s), who hides a slip-up or shifts blame to a sibling as a sort of get-out-of-jail-free card. This is done instead of the much harder to swallow admission of guilt, avoiding momentary weakness.
Developers, heck adults, struggle to rid this lingering habit, perhaps a coping mechanism to convince ourselves we can do no wrong. This all in spite of (apparently little-known) advantages to owning your mistakes.
Owning your mistakes gains you respect from your peers. You’re seen as someone who can admit fault. You’re seen as someone who wants to improve. You’re seen as the bigger adult.
Slight tangent to end this one: what is everyone’s obsession with immediately trying to assign blame? Seems to be two things: a) some people’s favourite thing, and b) more important than solving the issue itself. Not a fan.
You need to go into management
Becoming a manager is a huge career change; the importance of which doesn’t get the attention it merits. Especially for a developer. You got into this lark to develop. You progress and think you’re in line for a promotion. But what that actually equates to is your time spent developing is heavily reduced (exponentially more so the further the hierarchy you climb).
Doesn’t sound right.
Unfortunately, career progression and management seem to occupy the same space in the modern world, and the development department struggles to escape it. Suddenly, you’re responsible for other people’s wellbeing and their careers.
If this is actually part of your personal roadmap, then great — you were never destined to fall in this trap. If not, and management is sold to you as your next step, really ask yourself if it’s the right move. You could soon land yourself in middle management with literally zero time spent developing.
Take your time to find your sweet spot. Quiz yourself to figure out exactly what you’re looking for from your next role, that you’ll see as progression, as each of the below are absolutely achievable without the move into people management:
- a more technical role
- a wider industry reach
- more responsibility
- more money
- a title change
Not for a second am I arguing that stepping into a managerial role isn’t a worthwhile and prosperous move, and it’s a career switch that many are absolutely right to follow — hierarchy simply shouldn’t be seen as the lone end goal.
Welcome to the end of the article, I hope you enjoyed it! If you did, please share with a friend or colleague, and if you didn’t, please share with a friend or colleague!
