Top 10 ways to fake it as a software developer
How bad developers succeed in poor teams
Contents
Introduction
Or “how to survive in a role where you are supposed to have technical skills when you don’t really have any”.
If you’ve spent any amount of time working in software development then sooner or later you will get to work on a team where there are one or more ‘less than productive’ developers. If you’re particularly unfortunate then you get to work with someone who is a complete negative net asset - they consume more time and effort than it would take to create the work they ‘produce’ and no one seems to notice that they never really contribute to getting project features completed and instead spend their days interrupting others and creating problems.
But they survive and seem to even thrive, probably being paid more than many other people on the team who are actually getting the work done. How do they do it? Well, these are their techniques intended to help you to spot them early, not to become one of them!
Edit the read-me file
If you are struggling for something to do and need a few commits to give the appearance of being busy and productive, nothing beats editing the project read-me file. It’s safe because no competent developer needs to read all the bits you’ve copied from the internet about how to install packages with pip, npm or bower so it’s unlikely that you’ll ever be called on it plus it contains 100% guaranteed non-executable and non-compiled content - you literally cannot break the project.
Giveaway phrase:
I spent the last 3 days trying to run the app but forgot I needed to install the required runtime packages first … I’m going to work on improving the read-me this week so the team doesn’t waste any more time.
Bonus: don’t just quickly edit the page in github, make sure it takes at least half a day and includes a pull-request for the changes.
”Refactor”
No, not that ‘proper refactoring’ where you remove duplication and improve code clarity or performance. This is just moving classes around and changing method names.
The real beauty of this technique is that you get to ‘take over’ the hard work of others and it then looks as though all that clever and impressive code that a colleague developed is yours. Managers will be fooled, trust me.
Giveaway phrase:
I made some improvements to that complex engine module that Bob worked on for months, I think we both deserve a lot of credit for what we’ve achieved.
Invent lots of issues
Ideally these should be things that you can work on to make yourself appear busy and productive. But wait, doesn’t that sound like you’re documenting future work that needs to be done and then doing it? Sounds like productivity doesn’t it? Oh, silly - of course it’s not, it’s just meant to give that appearance remember!
The issues you enter should be really simple. If you need to add an API key to a config file don’t just do it, create an issue describing the work and don’t worry that even the issue title is more text than the line of code you’ll be changing.
Giveaway phrase:
I have a long backlog of issues that I discovered and am now working hard on.
Write tests
Sometimes code that you’d like to put your messy hands all over is simply too scary and complicated that you don’t think you can even rename things without it exploding in a shower of build failure. That doesn’t mean you can’t make a claim of part ownership on it though. Simply add some more tests!
You need to pick something that already has a comprehensive suite of tests of course but it will look as though you are being thorough and contributing to project quality when really you’re just thinking of new strings to pass to a function that already includes a sufficient variety including the important edge-case ones (null, empty etc…).
Giveaway phrase:
I thought we needed more tests around that critical module that Bob worked on last week so I’ve been enhancing the test coverage.
Add monitoring
An easy win that always impresses managers is to add some monitoring - they just love anything with dashboard and charts because it gives them something pretty to show to their boss to distract attention from the lack of working features. It doesn’t matter that you only have 5 visitors to the app a day, there’s benefit to be gained by hinting that “we’d be more professional if we were using New Relic”.
Remember, you’ll need to spend at least a week evaluating different services to make this work sound comprehensive and be sure to sign up for the enterprise package of whatever service you pick - nothing screams “professional” and “important” than a developer who doubles the hosting spend.
Giveaway phrase:
I signed us up for the enterprise monitoring package, it’s expensive so it must be great and I must be professional.
Add some automation
No, I’m not talking about actual build scripts or tests, just add another way to run a command that can already be run. Is typing bower install too difficult? Why not create a bower-install.sh that will run it for you? Or even ./run.py bower-install?
The great thing about this is that again, you are unlikely to break anything (erm, just make sure your script isn’t an actual command!) and as a bonus you will get to also edit the read-me to document the middle-man commands you just added.
Giveaway phrase:
There are too many complicated commands to remember so I added extra non-standard ones that we should all use instead. It’s in the read-me.
Talk about the latest languages
Learn some expressions, mention Lambdas, Generics and List Comprehensions and post some links to the latest conference talk about Swift, Go, Ruby, JRuby, Groovy, Booby or whatever as though it’s important to you and it’s the language compiler that’s been holding you back all this time, not your inability to understand simple boolean logic in a language that other people wrote monster sites with 10+ years ago.
Giveaway phrase:
Finally, I have access to a REPL!
Get someone else to do your work
How? Simply ask for help.
Woah there, what? Won’t this blow your cover? Of course not - it’s not like you’re going to openly admit that you are struggling with something and can’t do the job. Just wait until Bob is on his own and the rest of the team is out or use a private 1-to-1 messaging chat and ask for his input on a problem.
You are not interested in being taught anything or improving your skills so if Bob starts explaining the reasoning or a typical approach to a problem you need to cut him off and maybe ask if he can “express the ideas in code to make it more concrete for you”.
The great thing about this is you achieve several things:
- You stop Bob being so productive so you don’t look as bad by comparison
- You get Bob to provide some code that has a better chance of working than your own
- You don’t have to admit that you didn’t even know where to start with the task
- You have something to complain to your boss about Bob if he refuses to ‘help’ (do your work)
Giveaway phrase:
Of course I know how to do this, I’m just interested in getting your input to check we’re on the same page … especially in the form of copy-pastable code.
Make friends with the boss
Let’s face it, if you’re a fake then even an average developer is going to make you look like a useless sack of soggy paper. Imagine if you have a rock-star developer on the team - oh noes!
Don’t worry - you just need to be proactive. They are probably productive because they are spending their time and attention on the project code. That may make for successful projects but it doesn’t mean you can’t still be a successful developer.
While they are busy coding and carrying the team you can chat with the boss, laugh at his jokes, mention the latest language video you saw, even slip in some complaints that you aren’t getting the help you think you should from Star Bob. Complain that he was grumpy and mean the other day (but don’t mention that it’s because you force-pushed an old ‘read-me update’ branch to master).
Giveaway phrase:
Hey boss, how was your weekend?! I’m going for a coffee, can I bring you one too?
Rehearse for the team standup
Don’t ever be caught speechless at the morning standup when asked what you’ve done or what you’ll be working on. Write some things down so you can read them. Mention automation you’ve added, refactoring you’ve done or the updated read-me or how you and Bob are going to collaborate on the next important task.
You are bound to have some issue that’s preventing you from working but be careful not to give away that the issue is something you introduced with the last attempt at “refactoring”.
Giveaway phrase:
Yesterday I made some improvements to the build system. Impediments? Yeah, my build has stopped working for some reason so I’ll probably need to ask Bob for his input at some point - he wrote the build originally so he really should help get it working for me.
Private Legacy Projects
So the team is working on a project and of course you are getting nervous that someone is going to notice that all you are really doing is peripheral non-work: updating read-me files, changing method names, repeating tests and generally consuming everyone else’s time to explain why your pull request makes no sense and doesn’t match the task description in any way, shape or form.
The solution is easy: work on something else completely.
If there is any legacy app that you can ‘enhance’ then you’ll be working on your own without the inconvenience of someone reviewing your work and you can string the boss along for at least 2 months with excuses and believable-sounding reasons why things aren’t finished yet or how the codebase is so bad that you are having to do a lot of refactoring first.
By the time you are found out you’ll be ready to leave and off to your next gig thanks to including mention of the awesome project on your resume that the rest of the team really did without your help.
At least Bob will be kept busy untangling the mess you made.
Giveaway phrase:
I’m off - another company was really impressed with “our” project and my description of my involvement on it and they offered me a great package. Can everyone endorse me on LinkedIn?
Oops, was that really 11 things? I’ll go update the read-me file …
