To make sense of the principle we need to pull it apart and examine the pieces. Each of the sections below examines the intent of one piece of the principle. Annotations are provided on the right hand side.
It's all about learning, but not just learning any old thing. You will often hear very capable programmers say that they will select the right tool for the right job. Such a notion doesn't just apply to preferring one third-party library over another, it also applies to things such as desgin patterns, architectural choices or even programming paradigms.
Top tier coders don't mangle their code to fit a particular pattern, they choose to apply a pattern if it provides the most appropriate solution to a particular problem.
This implies that a top tier coder has access to quite an extensively equipped mental toolbox, a fact that can be readily confirmed if you talk coding with them for an hour or more.
This involves learning, but with so much material to take in how should we identify what the right things to learn are? The answer to that comes from investigation. Like any trade, the best sources to learn from are the master craftsmen and women.
Fortunately for us in the various programming communities that build up around a language or a platform, the experts in their respective fields are happy to share their knowledge. Googling for a solution to a particular problem is fine, but pre-emptively learning from the masters of the craft can put the right answer in your head when you need it, rather than accepting the first answer on the first page of search results.
And that's putting it mildly. For sure, there are plenty of very good, very high quality resources out there but they are sadly outnumbered to an extraordinary degree by the quantity of resources that are either of a very poor standard, contain simply bad advice, are outdated or a combination of these. A significant number of them are downright dangerous.
As a case in point, as recently as December 2015 I came across a tutorial that showed the reader how to add an AJAX powered search box to their web site. At the server side, the SQL query was built up using $_POST values directly without any thought to preventing a SQL injection attack. Copy and paste hell for the unwary learner.
Googling for a solution to a particular problem may be fine, but it won't necessarily lodge in your brain for reuse. Putting yourself into a learning frame of mind, particularly if you do it regularly, extends your mental toolbox more effectively.
Learning properly will equip you with the knowledge to make decisions effectively, being able to weigh up the pros and cons of each possible answer before making the choice to apply them. For example, if you can talk confidently about the pros and cons of following the Law of Demeter, then the chances are good that you'll know where and when to apply it.
Copy and paste solutions from an ill-informed blog article may do more harm than good.
Nothing will drive your career forward faster than by learning from the masters. Identify the most respected writers in the community that surrounds your language(s) of choice and read what they say. Buy their books, follow their blogs.
But also avoid poorly curated communities that allow members to link their ill-informed blog posts. Here's a freebie, there is no good advice to be gleaned from joining a PHP oriented group on LinkedIn.
Much has already been written about software quality; millions of words spread across thousands of books, journals, academic papers and blog posts. It seems a little unfair to condense it all down to just a few paragraphs. Nevertheless, we must consider at least some aspects of software quality.
For the purposes of the principle, we are only interested in the key facets of structural code quality. Structural code quality is agnostic of what an application is supposed to do, but it does impact on how well the application can deliver the intended functionality.
Structural quality is measured against a number of key metrics, but for the purposes of this principle we are explicitly interested in the four key ones, which are examined below:
Code that is reliable is code that does what it is supposed to do in conditions both good and bad. Reliable code doesn't just execute correctly when the happy path is happily followed, it also responds appropriately to error conditions and exceptions. Graceful handling when things go wrong is just as important as efficient handling when things go right. Reliable code is also changeable code, it tolerates the myriad of change requests that come at it and doesn't crash or choke from defects.
Code is written for humans first and foremost. Of course it has to be syntactically correct so that the computer can process it, but the most important factor about code maintainability is that it is written for a human audience, even if that audience is just you. Code that is clean, clear and comprehensible will rank highly on the maintainability metric.
Maintainable code is also code that is tolerant to change, open to extension and modification, without requiring the developer(s) to jump through logical hoops.
Of course we want our applications to be as hacker-proofed as possible but security is much more than that. To understand the security metric, we must look to the broader definition of an application; something that collects, manipulates and stores data. To be considered secure, the application must keep that data safe and keep that data true.
Being hacker-proofed is meaningless if our own poorly written algorithms can mangle, mutate and corrupt our data.
Efficiency considers both the speed of execution and the utilisation of system resources when an application executes its various processes. An application that takes thirty-seven
minutes to complete the request-response cycle had better be delivering some vital information at the end of it. Even minutiae such as avoiding the use of
SELECT * will have an impact on an application's efficiency rating when all that you require is a column or two.
Once you have code that is reliable, maintainable, secure and efficient, you have code that is of high quality. The More Pub Time Principle is very much a proponent of high quality code.
The topic really is huge and it really could take more than a lifetime to read and digest all of the related materials.
For the purpose of this principle, we want to concentrate on crafting code that is reliable, maintainable, secure and efficient. There are a number of techniques available to us that will allow us to do just that.
Don't get tangled up in tightly coupled code, demand that your dependencies are injected instead. Honour the Single Responsibility Principle and avoid creating God Objects to put an end to those effects at a distance. Can that wildly branching conditional construct be replaced with a Strategy Pattern implementation? These are the sorts of things we are looking for here.
Write code in a legible fashion. Make it comprehensible. Good code is code that makes its intent clear, without requiring pages of supporting comments.
If you can't see the beginning and end of a function or a method without having to scroll, you're doing it wrong.
Write code primarily for your main audience; other humans (including six-month-older you).
Common bug prone scenarios are not the same thing as obviously buggy software, although they do certainly overlap. Bug prone scenarios can also include code that works perfectly well today but is hard to change for the requirements of tomorrow (Brittle code).
Bug prone scenarios can also include code that works perfectly well under ideal conditions, such as being provided with the correct data or being placed under light load, but will break under unfavourable conditions (Fragile code).
Armed with the right knowledge, a developer will know how to create flexible, extensible, malleable code that functions correctly under a variety of conditions. Code that ranks highly with those quality metrics that we explored above.
Code that is vulnerable to buggy scenarios isn't just code that doesn't have enough validations and assertions surrounding it.
Defensive coding is a good thing, but it's not the be all and end all. Defensive coding won't let you avoid that "Well, I fixed this bit but now that bit over there is broken" situation.
This is the more jocular aspect of the principle, but it's jocular in delivery rather than intent. But what is "Pub Time"?
Pub Time deserves its own definition and it goes something like this:
Pub time is that time expended in any manner more conducive to a happier and more fulfilling life than staying behind in the office hunting down and fixing software bugs that were entirely avoidable in the first place.
That might actually entail going to the pub with your friends for a catch-up over a drink or two but it isn't, by definition, limited to just going to the pub.
Pub time might entail taking your loved one out for a romantic meal. Or it might entail getting home in time to read the little ones a bedtime story. Then again, it might entail going to the gym for a workout. Or firing up your games console to blast the heads off of alien invaders.
In fact, engaging in any activity that improves the quality of your life and its enjoyment may be considered as Pub Time in comparison to hours wasted by staying late at the office to track down and fix bugs that could have been avoided in the first place.
And there are better things that you could be doing than staying late at the office trying to find that one last instance of
$class = new $className() because you
had to change the way that user models get instantiated.
Go outside. Go fly that drone that you got for Christmas. Be nice to your grandparents at all times, not just when you need a loan.
Last but by no means least: Drink responsibly