Hey guys
It’s my birthday tomorrow, a time of year when I always feel quite reflective about my life. Specifically today, I am thinking about my career, as this year marks a decade since I started dabbling with web stuff.
So, here are eight lessons.
1. You are never done learning
This is such a cliche, but it is so true. The moment you think you know everything is when you need to grow, seriously. That level of over confidence, the moment of “I can do anything I want in PHP” was arguably when I was at my most arrogant and dangerous point in my career.
For me, it was about 7 or so years ago, and I knew, comparatively nothing. If I don’t think the same think in 10 years about myself now, I will have failed to continue learning.
There’s always a new framework, pattern, feature, methodology, or something you don’t know yet. Respect your lack of knowledge, for it will be your downfall if you do not.
Learning to know what you don’t know, and being self aware in that context will set you apart from many other developers.
Recognise the difference between commercial and personal experience, they are worlds apart. Just because you successfully implemented React on a WP website in your spare time, does not mean you’re ready to roll React out to an SaaS platform, or long-term-supported CMS version (etc).
Know what you don’t know. Identify what you need to know that you don’t currently, and figure it out.
It is not your employer’s responsibility (unless you’re a Junior or Trainee) to enhance your career. That’s your job. Own it.
2. You should hate all your old code
Okay, so hate is a strong word, but…
They say anything you wrote more than 6 months ago may as well have been written by someone else. I don’t necessarily agree with that, I leave a trail of flow charts, documentation, tests, and code comments in my wake; to mitigate this point, however;
If you don’t hate your old code, or (to be less dramatic), if you wouldn’t rebuild every project you built over a year ago, I would argue you’ve not learned or grown in that time.
I dislike everything I built more than a year ago, for sure, for various reasons, but every project would’ve had (whether large or nuanced) differences.
3. Your defeats are your biggest victories
The worst project. The hardest client. The most demanding project manager. The hardest bug. The slowest system/database, the most unruly repository. The most gut wrenching interview.
Every single one of these things is an opportunity for you to learn.
Every minute of pain, characterises things you will never do again, and will never subject another developer to it. It builds you up and makes you better. There’s a lesson to be learned, you just have to find it.
Embrace the suck.
4. When you are at your most comfortable, is when you are most vulnerable
I touched on complacency and over-confidence in point 1. But when you feel like this, you’re in dangerous territory.
It is almost for sure that you will make mistakes when you feel overly comfortable in what you’re doing.
You are either bored, so not paying attention, or don’t care. Neither of those things characterise a good developer, at all. This is when you’ll make a potentially career altering mistake. Which may well lead you to point 3…
Too comfortable = Complacent = Mistakes
5. If you think you are worth more, you probably are
This is not necessarily about money. Once you’ve been in the industry for a few years, you should start to recognise good and bad signs. If you start to think you are worth more, in terms of working conditions, work/life balance, management, tech stack, or generally being valued, you probably are.
Never be afraid to take the leap. Never be afraid to ask for what you want. Even when you’re afraid, do it anyway.
Side note; honestly, respect your body, your friends and your family. Seriously. Never neglect your own well-being for any employer, ever.
Bet on yourself, and take the leap. You can do it.
6. Experience, exposure, and expertise are not the same thing
I want to set this one straight. When I am hiring developers, I very rarely specify a hard minimum on experience or anything like that.
The reason for this is simple; someone is considered to have 10 years experience if they have been employed, as a developer, for 10 years. That 10 years could’ve been spent writing bug fixes for some PHP 5.6 project which should’ve been retired years ago, that nobody uses and is only maintained because it still pulls in license fees.
Exposure, however, is different. Being exposed to lots of different tech stacks (frameworks, languages, content management systems) and different ways of working is invaluable. It allows new perspective, this is valuable insight. Someone with lots of exposure usually can help with transformation, and spot own-goals before you score them. If you listen to them.
Expertise is about how well they know their subject matter. Someone might have 3 years experience, a shed load of expertise, and lots of exposure to different ways of working. Are they less valuable than someone who has done the same thing for 10 years?
Pick your heroes wisely. Never evangelise someone for whom you have no comparison. Especially if you are young in your career. Decades of experience does not necessarily equate to an expert developer.
7. You do not know more than the developer next to you, but you know different things to each other
When I lead development teams, and when I work on them, whatever level I am at, I understand what I know (and what I do not) and I respect that the “Junior Developer” (just a job title) next to me, probably knows things I do not. The same as I know things that she does not. The difference is likely age (thus years of experience) and exposures.
Never neglect the little hero sat in your office, who is obsessed with technology. Whilst you’re bogged down with implementation of a 10 million record schema, she sat up until 4am reading about [the latest amazing piece of tech] – you may well be surprised at how she can help you. So don’t dismiss a junior for being a junior.
You both know different things. Respect it and embrace it.
8. Don’t learn on the job unless you are supposed to
“Yeah, we can figure out how to do that!” – “Promise it today, figure out how to deliver it tomorrow” – in technology spheres these things suck.
If you are about to build something in a technology with which you have insufficient knowledge or experience, tell the person managing the project, and get the appropriate amount of R&D time scheduled into it.
Again, personal and commercial experience are not the same thing, and you are setting yourself up for a fail if you take on, and say you can do, technical jobs that you don’t know how to accomplish.
Well, that’s all for tonight folks, have a great bank holiday weekend!