Category Archives: Elegance

Pull Requests improve Quality

A Pull Request, which might more sensibly be called a Merge Request, is the act of a someone asking another to merge his or her code into theirs.  It is all so civil.

It solves an age old problem of how to do code review, in a more effective less disruptive way.  The simple rule of thumb is “Nobody merges in their own code.”  You get someone else to do it.

That simple act of asking another to merge implies they sign off on it.   They may simply say, “Oh, Zac knows what he’s doing here, and he knows this code better then I do”, and accept the Pull Request and Merge it in to the main branch.

Or one might download the branch, test it out in isolation, ask questions about why the coder did this or that, suggest changes based on coding standards, convention, coding logic or point out bugs.

Either of the two extremes add value, improves communication and does wonders to improve the overall quality of the output of the team.

And Quality is the name of the game.

MVC is Overrated

The Model-View-Controller Pattern (MVC) is not the only game in town.  In fact it is awkward and cumbersome in some cases.

MVC is a Design Pattern, and Design Patterns show us how to solve common problems with common solutions.   However we should not just use them directly all the time – but rather learn from them and use them as reference points for solving problems.

The most worthwhile component of MVC is the Model, (or Data Layer).  It makes good sense to isolate it and encapsulate it.   It make for very robust and reusable code.  All your SQL related calls should be in one place.

Code above the Data Layer can express itself in more business friendly terms, ie.  book = Book(‘Moby Dick’), and not ‘select * from books where title like ‘%moby dick%’, and status_id = 1;’

In MVC the View and the Controller components are isolated and encapsulated.   I disagree — This can makes simple tasks harder. Views and Controller functionality should be able to commingle.  This is were a lot of the interesting and sophisticated coding happens.

For Web Applications its HTML, CSS, Javascript, and AJAX that we use to communicate with the User.  We should come up with our own patterns that best suite our needs.

What is in a Name?

What should we call it?   Call it whatever you like.

I hear that a lot.  As coders and builders of systems, we should take the time needed to come up with the best names for the systems, databases, tables, columns, filenamesmodules, classes, methods, functions, and variable names, we create.

To name something is to know it.

Good names means less confusion and better understanding.  It makes talking about the system more natural.  It improves dialog between business users and the tech team.  In fact we should think as the business user when naming our components.

It makes it easier for you and others to maintain your code.

So take your time,  step back, think hard about what something truly is –  and name it accurately.

Stitch in Time

A stitch in time saves nine, is a fundamental principals we should use to write code and build systems.   It might be said, a stitch in time saves you from being stuck forever with unruly software.

People just want to get the job done.  But any small mistake or short sightedness up front in critical parts of the system, will trip you up right away in the next wave of feature enhancements, and bug fixes.

An ounce of good design is worth a million dollars a few years down the road, for the people who will be depending on it later.

And good design — takes a little more time.

False Optimization

So often I hear tech folks talking about some implementation as being better than another because “It is more efficient“.   Efficient?   Efficient for who?  The computer?  Are we shaving milliseconds off processing time?   That’s ridiculous.

We should be in the business of optimizing human time, not computer time.   Human time is more expensive – while computer time is cheap.

We want code to be laid out clearly and easy to read.  We want code to be like a poem.  We want something that we can maintain over time without having to scratch our heads every time we come back to.

A simple example, have a look at,

   id, process_date, qty
   coalesce(units, '') not in ('K1', 'K2', 'K3')

What the heck is that coalesce doing in the where clause? If you think about it for a minute it make sense.  Oh, it’s more efficient for the computer that way. Who cares?  How about

   id, process_date, qty
   units is not null and
   units not in in ('K1', 'K2', 'K3')

Here the where clause is immediately easy to understand and to maintain.  It speaks to the essence of the problem in clear pseudo English.

PHP vs Python

$What is $easier to $read?  {A $document of $commands in a $pseudo $English $language $strewed with ($dollar $sign $symbols ($$), $French $Braces ({), and $semi-colons)?  Or a $document $without all $that?}

What is easier to read?  A document of commands in a pseudo English language strewed with dollar sign symbols ($), Flower Braces ({), and semi-colons?  Or a document without all that?


$logger = new Logger();
if ($error) {

4 lines.  70 characters.


logger = Logger()
if error:'Problemo')

3 lines. 50 characters

Elegance in Programming

Ask yourself, is it Elegant?   Is it a thing of beauty?

If this is some important piece of code that others will be using then it should be written well.

I read once in an old programming book, “Born to Code in C”, that first you need to make it work, then make it beautiful.   I code by this rule.   So often I find folks don’t spend enough time on the second part.