Want to get ahead as a developer? Here are 3 things you can do right now!
--
I left university with a First in Computer Science, but by my graduation ceremony that was old news. I had a new mission: to be the best developer I could be. If I could go back in time and give myself some advice, this would be it. If you’re also fighting to be the best, then this advice is for you.
1) Being a team player is more important than being a code wizard.
I love coding, but as an introvert I’ve struggled engaging with and supporting other people.
As a result, In the past I’ve absolutely fallen for the trap of thinking things like:
- I know what my task is I can just plug in and do it
- I don’t need to share context with others it’s just a waste of my time
- how dare someone say they want to review my code — don’t they trust me to write it right?
These attitudes are isolationist in their nature. They pit you as someone who hassled by, not part of the world around you.
If you want to know what’s wrong with isolationist attitudes, simply work with someone who has them.
In my last article I told you about Frank. Frank didn’t like working with others. As a result of this Frank became the master of some tiny area of code.
The rest of the team didn’t want to touch Frank’s code, not because Frank was bad — in fact, the recruiter who hired Frank informed us that he was a “Rockstar developer”.
The reason that nobody wanted to work on franks code was that the code was Frank’s, he didn’t want to help anyone understand it and nobody wanted to figure it out on their own.
If you want to know what’s wrong with isolationist attitudes, simply work with someone who has them.
All bugs and changes that we’re required we’re passed to Frank. If Frank was busy then the changes got blocked. To avoid blocks, other members of the team wrote weird workarounds.
These workarounds are mess and as they are further modified they become a bigger pile of more entrenched mess. In the end everyone just spends ages wading through a large mess of code — it could have all been avoided by just working as a team to begin with.
2) Make sure you keep up to date.
TV quotes are usually rubbish. Unfortunately, that doesn’t stop my Facebook feed filling up with them. One however genuinely is good, and it goes like this:
“You know nothing, Jon Snow.”
In Game of Thrones, Ygritte was commenting on the knowledge of the the un-showered illegitimate son of Lord Stark. She could have just have easily been talking about any software engineer.
It’s really easy to think that you do know everything.
How do I know this? because as a newbie developer I thought I knew everything: for loops; If statements; Objects were a bit hard but I could do them. Everything …right?
When I did my first internship I learned that I knew nothing about Object Oriented Programming. Once I started my first job I learnt about SOLID, Design Patterns and DRY to keep up with my peers. Once that was done however I took a breath. Now I know everything…right?
Nope! I still didn’t know about Test Driven Development or Source Control. So I learnt about them too!
By this point I thought I could go into a Grad job and be 100% certain that I knew everything. Once again I was wrong. Turns out that there are other paradigms, more languages than I can count, frameworks (frameworks everywhere), web stuff, big O, Nosql databases, Scalability techniques, Security techniques…
Today I’ve just accepted undeniable truth: “You know nothing, Sam Fare.”
Now don’t take that the wrong way. In this sea of stuff to learn it can seem easy to say “Why should I have to give up my own time to do work stuff?” This is a particularly tempting attitude it seems for people who just fell into software where it’s so elegantly fit’s with the simple view “I don’t need to learn anything else, what I know is fine already.”
Let me tell you a true story. I once woke up to hear the trickling sound of water. I walked down stairs only to find the ground floor of my house was flooded. I don’t just mean it was a bit wet, there was water up to my ankles. In a panic I called my insurer and my insurer sent out a plumber. The plumber was “watersafe approved”, although he had got that a few years ago. But he plodded around my house knowingly. After a few minutes he pulled himself under the sink and inspected a pipe. He looked up and tutted, before calmly walking back over to me. “Your pipe’s a bit odd unfortunately” he said, and went on to explain how the pipes use a new type of fixture that had been introduced recently, he didn’t know to fix the fixture so, unfortunately, my house would have to flood.
After that he took his payment and began hopping off into the distance, I even detected a whistle! And everything was ok :).
You probably guessed that I lied earlier, that wasn’t a true story. Plumbers are professional enough to realise that they need to keep their skills up to date. Hell they even use their own time to do it.
Whenever you look over grudgingly at a new tech or refuse to do anything new you are being that fake plumber. You’re asking someone to pay you for a job that you can no longer do. In the short term it will be your colleagues who pay the price. In the long term it will be your career.
3) Learn to say no!
One of the most important books I ever read was Uncle Bob’s follow up to his already legendary book Clean Code called the Clean Coder. In the book, Uncle Bob describes an all too common problem. The problem of saying yes.
To describe the problem I’m going to introduce another developer who you probably work with. His name is Liam.
Liam works at a big multinational company in London that sells credit cards. One day the credit card company CEO Jessica sees that the number of credit card applications coming in has taken a sharp fall. Jessica thinks she knows what the problem is. One of her biggest competitors Armenian Express has just released an offer to give cashback to any new customer who signs up for their cards.
So Jessica has and idea, she needs to launch her own cashback offer, and STAT!
Jessica goes to Liam and tells him what she needs and as she does Liam thinks about what it will take. Liam knows that he will need to get a team of developers to modify the card transaction code to calculate the correct amount of cashback (oh god Frank wrote that code before he left! It’s going to take ages to modify). Then he’ll need a new microservice to manage each customer’s cashback account. Then there would need to be a new page on the UI but all the web teams are under pressure from complying with GDPR (He could hire a new team, but that would take months). All in all, getting the cashback system implemented would take months.
Jessica notices that Liam’s mind is wandering, so she snaps him back to the room, “This is the most critical part Liam, I need it done in 3 weeks.” Liam’s heart sinks, there’s no way he can get the changes done in 3 weeks so he turns to Jessica and they have the following conversation:
Liam: “No, There’s no way I can do that, it will take 6 months at the minimum.”
Jessica: “Liam, this is really important. We’re losing money to our competitors! ”
Liam: “I know it’s important, but we just can’t do it that quickly.”
Jessica: “Can’t you just try?”
Liam thought about that for a moment, I mean he was already doing 10 hour days, read every book on efficiency, but clearly he just wasn’t trying hard enough. silly him.
So Liam said Yes!
After the ‘Yes’ incident things went exactly as you would expect. Jessica promised the board a new cashback scheme and got marketing promoting the new cashback pledge that was going to be rolled out three weeks in the future.
The development team rushed through the code, they didn’t refactor, they didn’t write tests. After a week of coding the dev team began to spend more time fixing issues with what they wrote than writing new stuff. So the dev team decided to work overtime to do more. After a few weeks of this, morale was at rock bottom, the team’s families were on their back about all the work they were doing, they couldn’t take a break to relax either — because of the overtime, and finally because they had no pride in their work, the code looked more like the flying spaghetti monster than a working financial services application.
Now here’s the real non-surprise, after 3 weeks the feature wasn’t done. Liam’s original objections were of course forgotten and quickly became known as no-delivery Liam. Not only were the team not anywhere near to release but they had incurred weeks worth of technical debt. Because there were no tests QA found problems around every corner, and thus the team had more work to do still.
In the end, Armenian Express didn’t just have a cashback advantage, but great PR from their competitor’s IT failure.
If Liam had stuck to his guns and insisted that the cashback incentive wasn’t doable in three weeks, it would have shipped no later as it wouldn’t have been slowed down by bugs and difficult code changes.
It would have shipped at a higher quality, with enhanced reputations for the company and all involved.
The times when you fail to say no might not have the same impact as Liam’s, but you are still marking yourself out as untrustworthy by setting expectations that cannot be met.
