My previous post, a classic rant, how-bad-software-is-these-days kind, attracted unexpected and probably even unreasonable attention. This time I’m in for something different — I’m going to preach. Behold, and open your eyes, and open your hearts, and open your minds, as I am about to tell how we should live our lives to bring about a lifetime of good software. This is an uphill battle, people will not come in droves to cheer you up on what a great job you did, but we must stay strong and fight. We shall begin now.
Whatever you do, do it well. Write code magnificently. Review relentlessly. Test tirelessly. This way is a hard way, but it is the way of the warrior.
Do not let the spaghetti of a code on your hands get into production just because you’re sick of this particular feature and want to have fun. Or maybe have fun switching from technology X to technology Y, then come back and make your regular boring code good, too.
Fix bugs. This is even less fun, but it’s your project, and it’s your responsibility to make it work. Resort to hacks if you must — a working system is worth a thousand lines of clean code. Take pride in making things that work and make people happy.
The concept of evil businesses preventing the good-hearted developers from doing their best comes up in every argument on bad software sooner or later. They hire too few people, and the ones they hire are no good, and hired too late anyways, and the management slaps a tight deadline on top, so it’s their fault. Is it, really?
The only thing that gives meaning to your work is how you make the lives of your users easier. That is a business concept, not a development one. Your code is nothing without the business it supports, but the business is still worth something without the code. So, business > software > code. Accept it.
Planning around people writing code is hard as it is. Without deadlines it is plain out impossible. Negotiate and adapt. Isn’t it better to do something imperfect that already works and brings value than to spend eternity chasing the perfection?
And then there’s this thing: if your company has no product, has no business strategy, has no sales, has none of all these things you call dirty and hypocritical — it also has no money, so how are they going to pay you? I bet you prefer being paid.
You may have heard some practices make software better: code reviews, documentation, testing and refactoring. These things work. Build them into your workflow — adding even one, even a half, will make you stronger.
If your management does not approve of you spending time on this stupid geek stuff — convince them. If they will not get convinced — do a bit guerilla-style, see what the team thinks, and if it sticks.
The fact that you are a developer does not mean that you can, or should, solve all problems with code exclusively. Sometimes it’s better to work your way around it, even if it means no code and no fun.
Have a particularly hard problem you want to slap machine learning / AI on? Leave it for the user to do manually, or do it yourself, or hire some poor students.
Have an extremely tricky front-end logic? Talk to your designer, and you might find a way to solve the problem with no code whatsoever. You just achieved the same result with no code — wonderful!
Designers, sales and project managers are working towards the same goal as you are. And yes, your users are crucial to a useful product. There is no reason not to respect these people as less technical, or less intelligent, or less anything than you — you’re a just tool for the job, as are your colleagues. So respect each other and be open to their input informed by their experience.
Your codebase certainly has something with no specific business value that you have spent some time developing. It might be a migration engine for some exotic database, , a front-end snippet or an algorithm. Talk to your boss and sse if you can publish it. Making it public does no harm (it wasn’t a secret know-how in the first place, just an implementation of something more or less trivial) and provides free marketing for your company. More globally: the more open source tools we have, the easier it is to make good software, fast.
On the other side, prefer open-source tools to the ones you wrote yourself. You won’t be the only user, so some problems that did not even appear to you are already found and solved. If the existing libraries do not satisfy you as-is, pick the closest one, adapt it to your needs, than propose a PR or publish as an extension.
Sometimes you’re using a website or an application and run into a bug. Report it to the team that made it. You are a tech person, and you will find your way around it, but others might not. If it’s not a real bug, just some tricky UX workflow, let them know anyway.
Don’t blame them too hard. Remember there’s a reason you use their particular service, so they’ve already made a reasonably fine job. Small teams will appreciate your input more — they have less users, so your help is more helpful. And don’t be too disappointed if they don’t fix it right away: they have more context to set priorities than you do.
I bet you have learnt something useful in your life. Know how to make good user interfaces, or how to design scalable back-end infrastructure, or how to manage software projects? Well done, congratulations! Now go out there and share this precious light of knowledge with others.
Write a blog. Answer questions on stackoverflow and quora. Talk on conferences. Get into education business a little bit. Check with your local schools and universities, ask them if they have an instructor position for such a professional. Check bootcamps and programming courses. These jobs might not pay as well as your normal one, but they are satisfying as hell. And they usually come part-time, so you’re likely not to harm your primary occupation.
Go and use these commandments for the better of the world. We all think how wrong and unjust the world order is from time to time, and I do, too, probably even more so than anyone, but we have to cut down on this crap as there is no realistic way for us to change the way things are right away. So go, and be responsible for your actions and decisions, and, no matter what you do, think of how you can do it better. Become a brick in the beautiful world of good software; fight the fight day after day; little by little we will see the world of software change. And please, please let me know if I have encouraged you even a tiny little bit — that would make me feel so much happier.