Old man shouts at cloud

08 Jul 2019 Old man shouts at cloud

When I started out as a developer the internet was made of wood and owl feathers, held together with spit, pluck, gumption and whatever else it is that you kids today no longer seem to have (job security? the possibility of owning your own home? a habitable climate?). We had to chisel our code out of the rocks 26 hours a day, 10 days a week, wait two years for it to compile, and the only way of knowing if it worked was if the old wise woman of the company divined the error messages in the entrails of a junior developer. I am now that wise old woman, and so I must pass on the things I have learned.

Gather round, children, and let me annoy you by telling you things you already knew and also by calling you children. These rules must all be followed exactly, especially if they contradict each other, or you will never be a great developer. Or even a mediocre developer. And you’ll probably get rickets, or scurvy, or some other disease that sailors used to get before they invented eating fruit.

Writing code

Tests

The first thing you should do is set up your automated tests. Make sure they run fast, and that you measure the coverage. You want to be running these often, so it becomes a habit. Change a line of code, run all the tests. You don’t know your code works unless you have tests that cover it, and this is easy to maintain if you start with that idea in mind. Install git hooks to run all the tests before you deploy, so you don’t push broken code by accident. Install real hooks that pop up out of your keyboard and pierce your fingers if you try to push code without the git hooks .

Tests give you confidence to change code. Good tests describe what the code should do. Some idiot will tell you to save time by writing tests later, or even not at all. These people should be harpooned, their bloated carcasses left to rot in the sun.

Measure your coverage, aim for 100% – even if you don’t get there, it’s a good target. Every line, every branch, should have a test. People will laugh at you. Harpoon those lazy oafs and move on. If you stop at 90% coverage, that’s 10% of your code where bugs can hide. Shine the light of test-coverage justice on those cockroaches and watch them scuttle into the crevices.

Language choice

“Crevice” is a disgusting word, isn’t it? Almost as bad as “moist”. Never use them together.

Deploy

The first thing you should do is set up your automated deployments. Yes, I know that’s two things you need to do first, stop complaining. Get used to deploying every code change into an environment, without you having to do anything apart from commit and push. This forces you to think about how you will deploy your changes, instead of pushing all those decisions into a big messy pile to deal with later. Even if you’re not deploying into production (which, really you should be), deploying often and in an automated way will take a lot of the stress out of your production deployments. Once again, some idiot will want you to do this all by hand. Harpoons are your friend.

Deploy often. Small changes, released often, automatically, will:

• reduce the stress of releases;
• make diagnosing problems simpler;
• turn rollbacks into reverting git commits;
• keep your skin looking younger;
• make your coat glossy;
• keep you worm- and tick-free for up to 3 months.

Branching strategies

You just need master and short-lived feature branches. Nothing else. If code is in master, then it is deployed. Nothing to keep track of, no giant merges of develop branches into release branches, or merging of hot fixes back into master after branching off release-31.4.32-alpha-fix-no-really-fixed-this-time. You’re an idiot, and everyone you work with is an idiot, you’re going to stuff this up at some point and end up with nasty merge headaches. Avoid it all.

Create your new features or bug fixes in a fresh new branch. Make your change, make a pull request, get it reviewed by the rest of the idiots. Your PR will include automated test results run against your branch so that everyone can see it’s not a steaming pile of horse poop. Merge it into master, delete the branch, and off it goes to be deployed. Keep your branches short-lived, merge often, that way you won’t have a huge pile of changes that will confuse everyone.

What’s that? Speak up, I’m old. What if you don’t want to release a feature until something it depends on is ready? Feature toggles. API versions.

Tools

There are certain kinds of people that will sneer at your choices of IDE, language, framework, use of semicolons, bracket placement. It doesn’t matter what it is, some entitled bell-end will tell you you’re doing it wrong. What they mean is “you’re not doing it the same way I would”. Brackets and semicolons don’t matter, pick one style and stick to it. Editors and IDEs don’t matter, if you can edit code with it, it’s fine. Want to use PHP because you’re familiar with it, but Mr Rockstar Ninja tells you it is wrong because everyone is using Go now? If you’re just making a simple website, what’s the problem? The only question you need to ask about your tool choice is whether you can get the job done using it. If it does the job, then it is a good tool to use.

Don’t over-engineer

Keep things simple. Automate things so that you don’t have to think about them. Don’t build what you don’t need. These are all things you’ve been told many times, and you always nod wisely like you’ve been listening, but really you’ve just been thinking about puppies. Well, this time pay attention. Developers are always trying to cater for “the general case” or “future expansion”. Most of the time it never happens and you’ve built a buttload of beautifully flexible and complicated systems that never get used and nobody understands. Or even worse, what you imagined was going to be needed was completely different to what was actually needed, so you have to throw away your beautifully flexible systems anyway.

People

Being nice is better than good

I’d rather work with people who turn up on time and treat their team members with respect than some rockstar programmer that’s an arrogant dandy. Psychological safety is important to a team; if people don’t feel safe owning up to their mistakes or making suggestions then they are not a team. They’re a collection of paranoid liars. Everybody gets things wrong sometimes. If you can laugh about it and move on you’ll all be stronger for it. Some people get so worried about getting something wrong that they avoid doing anything at all. Getting things wrong is how we learn.

Laugh about your mistakes, and remember that everyone makes them. Learn from them, and move on. It’s not the end of the world, we’re not running nuclear reactors here.

Unless you are running a nuclear reactor, in which case your mistakes will linger for up to 27,000 years. No laughing for you.

“It works” is better than perfect

Getting something in front of real users will give you far more information about what they really want than any amount of requirements gathering sessions, brainstorming, or workshops. Give them something to try out, even if it is wrong. Then fix it, using the feedback you got from the users themselves.

That goes for your pull requests as well. Don’t stress over getting the code perfect, just make sure it works and it’s covered by tests. Feedback from the rest of the team is usually much more useful than anything you can come up with yourself – a fresh pair of eyes will see problems you didn’t. Not just because you’re an idiot.

Everybody is a fraud

Everybody googles things they did last week. Everybody copies code from StackOverflow. Everybody makes it up as they go along. You’re not alone. The longer you do this, the more you realise you don’t know. The only difference between a junior developer and a senior developer is that the senior ones are better at picking their search terms and recognise the right code to cut-and-paste the first time instead of the second. The stuff we do is complicated and goes out of date quickly, there’s no shame in having to look it up. You don’t have to keep it all in your head, it’s why we invented writing things down.

Go home.

Don’t work long hours. Don’t work weekends. It’s not worth it. You’re giving the company you work for free labour, and no pay rise is worth the lost time with family and friends. If you’re asked to work weekends, then that’s a good sign that the project is off-the-rails and heading for disaster. This is rarely the fault of the developers doing the work, but you are the ones that are asked to work harder. If you’re going to work outside of your normal hours, make sure you’re going to be compensated above your usual rates. Your free time should be valuable to you. Nobody is productive for every hour of the day. We all need time to switch off and do other things.

Get a hobby

No fork-lift driver is ever asked if they enjoy driving fork-lifts on their days off, or if they regularly attend fork-lift driving meetups. There’s an expectation that developers have side projects, or are always coding in their downtime. You don’t have to do that. There are many, many great developers that never touch a computer outside their office hours. They have families, friends, hobbies. Find something else to do, it’ll make you a better person. I personally enjoy long hours drinking myself into a stupor and weeping.

In conclusion

You youngsters today are doing it all wrong, unless you’re doing it exactly the same as I am. If you are doing it the same as me, then you’re just imitating people and need to make your own way in the world. Just don’t make your own way in the wrong way.