Code: Selfish11th Nov '18 • 3 of your Earth minutes
I want to talk about coding selfishly.
This isn’t what you think.
Coding selfishly is about assessing your motivations, your joys and coding in a way that brings you the most long-term value. It’s really a form of self-love.
I believe coding selfishly will change your approach to programming.
What it’s not
Coding selfishly is not about coding perfectly. It’s also not about coding quickly. One is (arguably) unattainable, the other is completely short-sighted.
It’s not about getting so buried in the exercise of coding that you lose sight of the goal: write a big-free program that serves its users. Coding selfishly gives you the power to know what “Done” is and to finish your work with satisfaction.
It’s not about coding without consideration of others. Coding without thinking about other developers (even future you) is not very self-serving.
It’s not about self-preservation. Coding in a way to keep position or privilege is short-sighted and will actually harm you in the end.
What it is
It’s pragmatic. It’s agile. It’s MVP. It doesn’t always do what it doesn’t need, but it also doesn’t get hung up on what’s waste and what’s not.
Coding selfishly is really nothing new. Ultimately it’s about being practical and reasonable with your coding — setting attainable goals and expectations, achieving them and moving forward.
It’s a concept to apply line-by-line, class-by-class, project-by-project and to your entire growing base of knowledge.
It’s a summary of ideas compiled from years of practice and absorbing many concepts from other great developers and learning a lot of lessons the hard way.
During our careers as developers we experience a variety of different situations; some of which we love, others we loathe.
One situation I have loathed most often is that of building something hastily, with the constant itch in the back of my mind that says “this ‘solution’ will come back to bite you sooner or later”.
This can cause you to spiral into the sinkhole of technical debt and the increasing waste of mental energy keeping track of that.
Conversely, it can force you into the completely opposing direction to engage sadistically in premature optimisation; trying to cater for every eventuality – many of which may never occur.
Another situation I loathe is lack of trust in your fellow developers. If you can’t trust your peers to work with your code as you instruct/intend you will end up coding defensively.
This doesn’t serve anyone, least of all you.
And finally, you will refuse the lure of best practice with the clear head of pragmatism as you balance expectations with your own sanity, realising that these so-called ‘standards’ can and do shift like the sea. You steer your vessel so as to ride these waves to your destination, not merely carried along by them to wherever they lead (heads up: it’s a whirlpool of insanity.)
Coding selfishly will give you the confidence and the freedom to set these concerns to one side and get on with the task at hand.
You will build the right way from the start or not build at all because you know that this serves you best whilst also ultimately serving your client/users best too.
You will not be sucked into any mire of tech debt, because it will be, at best, only a shallow puddle of murk.
You will not however be forced out of fear to spend needless hours checking for micro-optimisations in defence of your best practice strategy – you will apply your experience to build what works and have the fortitude to accept that refactoring is a welcome necessity.
And you will not fear your fellow programmers because you will trust them to do their job. If they simply cannot, you trust yourself to be able to teach them how.
Do it. For yourself.