7 Ways To Start Coding Like You Give a Sh*t That Earned Me £1.1 Million
Uncommon advice you won't learn at coding bootcamp
Most software developers are on autopilot.
They're so used to exact requirements and prescribed step-by-step solutions, that when you ask for their opinion on something outside the guard rails it's like nobody's home.
That was me in a nutshell for the first 5 years of my career. Happy to recite the mantra of whatever development philosophy the current project was following, but never having an opinion of my own.
Yes, it was lack of experience. But mostly I was scared.
Fear of doing or saying the wrong thing limits the impact you have on a project. It also turns you into a people pleasing rule follower with no real interest beyond just "showing up".
Your tiny pay check will reflect that reality.
Fixing this took years of self-experimentation to figure out how to get engaged in my projects and do something impactful. When you do the same, managers take notice and reward you for it.
So here's how to start coding like you actually give a sh*t:
1. Don't outsource decision making to dummies
Making a decision can be painful.
Whatever technology, framework, or architecture you choose for your project may remain for years. Future colleagues you don't know yet will have to use it.
So don't screw it up.
Weighing up your options is smart, but choosing one is the hard part. It's tempting to let someone else make the choice instead, then they can take the blame when it all goes tits up.
I once worked with a lovely lady who turned into a tyrant when us developers didn't agree with her. She didn't write code, but in one afternoon meeting tried to impose an awful design onto our new project.
After she made the suggestion, the room was quiet. Everyone was scared to disagree.
Me too.
But I spoke up anyway, suggesting a better alternative. She screamed like a baby who lost her rattle, then stormed out the room.
Non-technical colleagues love to make technical suggestions. They love it even more when those suggestions are implemented by timid developers obsessed with org charts and who’s more senior than who.
Protect your codebase from those who don't work with it on a daily basis. You'll not only ensure its maintainability but your careful approach will rub off on colleagues and gain you new levels of respect.
2. Don't fall for the management trap
At some point in your career, a well-meaning manager with nothing better to do calls you into a meeting room to present the "career progression chart" — a box ticking exercise designed to get you to imagine your entire future at the same company.
To earn a higher salary without squeezing into a made-up job description, do this instead:
Screw up the chart and throw it back in their face (metaphorically).
Unless you also want to become a manager who spends their time presenting career progression chart to their own underlings, define your own career path instead.
What does that mean?
It means following your interests to work on things that actually make a difference to your company, even if they're not in your job description — all the stuff your colleagues ignore because it's too hard, scary, or boring.
In other words, actually giving a sh*t.
By saying "no" to paper pushing managerial roles, using my own time to learn to run code in the cloud, and making my manager cry with joy when I made his dreams come true, I became the highest paid developer at my company.
And when you do this, they'll ask you to name your own job role.
3. Ignore the company BS and keep coding until the power goes off
Following your company's internal politics is as pointless as keeping up with the so-called "world news".
Leaders come. Leaders go. New ones make a lot of noise to justify their high salary.
It's hilarious how excited everyone gets when they receive the invite to an "all hands" meeting.
As well as the pre-meeting gossip, there are the inevitable discussions afterwards that suck time from what you should be doing — creating kick-ass software to solve real problems.
Besides, all hands meeting aren't designed for you.
They're for those employees who throw a hissy fit if anything changes without being "officially" notified. Employees who spend 25 years at the same company and think speaking to a recruiter is blasphemy. Employees who believe life is over if they lose their job.
On the other hand, those who give a sh*t about coding know a new role is just a few phone calls away. When an interviewer sees you're a developer who really cares, they can't do enough to get you to sign on the dotted line.
So rather than spend hours at all hands meetings or discussing the latest round of layoffs, sharpen your development skills by doing sh*t that's useful to your company.
Nobody will notice you weren't there, you'll preserve your sanity, and everything you learn you can take with you to your next role.
4. Stop wasting peoples' time by asking for permission
In the 1980s, an advisor of the Soviet leader visited London and couldn't believe there were no queues for bread.
"Please take me to meet the person in charge of supplying bread to London. I must learn his secret." he said.
The Soviet era taught us that central control over every aspect of the economy doesn't work. When the power to make decisions is removed from those with the experience to make them, the consequences are disastrous.
The same applies to software teams.
Filling a room with developers might seem like the sensible thing to do to make a "big" decision. But if most of them don't know anything about the problem, you leave the meeting with a rubber stamped, but terrible decision.
So what to do instead?
With experience, you start to know what good looks like.
Go ahead and make the required changes.
Submit a pull request to someone familiar with the code.
Email other developers an overview of the changes.
Then watch as nobody responds. They're too busy solving their own problems to care.
By not asking for permission, you got what you needed AND avoided wasting everyone's time. The 9 times of of 10 this works more than makes up for the one time it doesn't.
5. Your previous project isn't the gold standard
Before I knew what good looked like, whatever code, process, or framework I was using at the time was the de facto gold standard of software development.
That mindset came with a big dose of "lets do it like this because we did it on project X".
The most embarrassing incident was when our small team of developers were deciding what Java build tool to use on a new project.
"Hey, you've been at the company longer than us. What did you use for your last project?" one of them asked me.
So we chose the horrible option which makes you commit every library into version control, rather than the new one which makes your life easier.
This mistake reminds me to be open minded about unfamiliar solutions that could make development faster or cheaper:
Code functions you only pay for when they're being used (AWS Lambda).
Lightweight container environments that run CI jobs in parallel (Docker).
Build tools that help you do more like deploying to production (Gradle).
Each one of these is a technology a colleague showed me that initially my brain reacted with "f*ck that!". If you can ignore this initial reaction, you might find that the new thing is actually better than the old.
And when you combine what worked before with what might work better next time, everyone will look at your team and wonder how the heck you do it.
6. Stop reinforcing boring coder stereotypes like a lazy ass
Most grown men write in a way that would make any primary school teacher laugh out loud.
Terrible grammar. Full of acronyms. No regard for the reader.
Despite their extensive "training", most software developers aren't much better.
The sad thing is many organisations now expect this. That's why they create nonsense roles like "scrum master" to translate developer speak to a language everyone else understands.
Fortunately, this caveman attitude of "I write code, so organisation, documentation, and demonstration are an afterthought" makes it really easy for diligent developers like you to stand out.
Well-written user stories, clear API documentation, and release notes that actually exist are a good start.
But to really break the coder stereotype you need to own your code's entire lifecycle. I won't cover all the details, but here are three examples.
Learn the business domain so you can translate requirements into technical details better than any "Business analyst".
Test code you write at the unit, integration, and end to end level yourself, without tossing it over the fence to a "Quality analyst".
Decide how best to run your code in production, without relying on a gatekeeping "DevOps engineer".
When you break out of your developer bubble, you realise all this other stuff was your responsibility anyway. You were just playing at beginner level.
Following developer stereotypes is for those who are happy to get paid like their colleagues. But when you have a deep understanding of the whole lifecycle, suddenly you're the one with all the answers.
7. Become the fantastic nerd you were meant to be
I'm sorry to say when I was studying computer science me and my friends made fun of a group we called "the nerds". One of them wore a toolkit on his belt for emergency computer repairs.
The truth is, we were just as nerdy as them about getting drunk, rock music, and launching monkeys through the air on the 128-bit Nintendo GameCube.
The "nerds" probably had huge success with whatever they did afterwards. I tried to pretend I was a "normal" member of society, despite spending all day writing code in a man-filled-office.
It took years to realise my mistake.
Being a "nerd" is just a way to say you're not ashamed to follow your interests. If I'd done that sooner, I'd have realised I don't care about coding for coding's sake, but I get jump-up-and-down excited to make development processes faster.
When you know what really interests you, you're not scared to volunteer for scary tasks so your colleagues are left wondering what you ate for breakfast.
Following your real interests is the only way to really learn, despite what the "traditional" education system says. Connecting with others is easier than ever, so spending years learning stuff you don't care about because "teacher says so" is irrelevant.
Follow your interests whenever you can, stoke your internal flame, and see how far you can take it.
Conclusion
When you apply only the minimum effort to your work, you get paid like you don't care and can sleepwalk through an entire career if you're not careful.
Figuring out how to give a sh*t is the counter-intuitive way out of this trap. Tell me in the comments below which of the points from this article resonates with you and why.