Responsified and updateified

That old proverb about the cobblers children going barefoot is true. For too long this site has been neglected and unloved. Well, no more! I’ve realigned (not redesigned) this site to take advantage of modern web development techniques. Of course, I’m talking about responsive design.

It’s not a radical departure from what was there before, and talking advantage of the excellent Bones starter theme meant the whole thing was done in a few hours. And even though I haven’t paid too much attention to performance I’ve still ended up with a respectable payload for the homepage:

Homepage payload

And even YSlow gives me a B grade:

YSlow grade B

I’ve also updated to WordPress 3.7, named in honour of the great Count Basie. The update was, it has to be said, not as slick as usual. I had “out of memory” problems which weren’t that hard to fix, but did cause me some stress.

WordPress 3.7 is the first version with auto-updating built in, so hopefully my installation will keep itself up to date and in tip-top condition while I’m asleep.

Missing the important stuff

A few days ago I found out a very good friend of mine had died several months ago. I hadn’t heard about it and, of course, I had missed his funeral. It was very upsetting news, especially because I had found out so long after the fact.

His passing had been announced on Facebook, but as I hardly go on that site (in fact I wonder why I have an account at all) I missed it. In just a couple of weeks those messages had dropped off my timeline, replaced by reams of banal tripe. The important things, in this case literally life and death, drowned out by the noise.

I can’t rant too much about this, I’m as guilty as anyone for posting (to Twitter, mainly) more than my fair share of trite nothings. It’s easy to be shallow online, and really hard to be genuine and heartfelt. For true relationships you need, at least occassionally, physical interaction. Words on a screen are a poor reflection of real life.

I’m not sure what the answer is. If I come off Facebook entirely then I may miss important news. But if I stay I may miss it too, unless I dedicate my life to keeping up with the firehose of messages.

Gah. I guess I just miss my friend.

Bad, good and great programmers

A recent tweet by Cory House started my brain a-twitching:

One of my new favourite interview questions: What is the difference between a bad, good and great programmer? Which are you and why?

I’ve worked with all three kinds, and thinking about the question of what the differences are I realised (not for the first time) that pure coding skill is nowhere near all the story. This blog post explores what else may put you in one category or another. First some assumptions:

  • As this is an interview question I took “programmer” to mean “one who works in a software development team”
  • The basics of being a decent employee – turning up on time, dressed appropriately and at least partially sober – are a given
  • The programmer can actually code to a decent level, “decent” being whatever is appropriate to fulfil the job requirements
  • The employer doesn’t just want a code monkey. I hope and trust that there are very few companies who want programmers to just “shut up and write the code”, and if you find yourself working for one of those then get out as soon as you can.
  • I’m talking to traditional programmers (C#, PHP, Python, Ruby, JavaScript etc) rather than front-end (HTML, CSS) but many of the points are applicable for any type of developer

Bad programmers

Generally, bad programmers are easy to spot. They write code that generally works (if they didn’t they’d be out of a job), but suffer from many or all of these issues:

  • They have a bad attitude towards non-geeks, whether non-technical colleagues or users
  • They have a bad attitude towards other programmers whose views don’t closely match their own
  • They know it all, or at least everything that matters
  • They are opinionated about tech; either wanting to use cutting edge stuff because it’s cool (whether or not it gets the job done) or they only trust very established things and refuse to look at new tech
  • Their communication skills are poor, and they have little desire to improve
  • They may fulfil specification requirements but don’t go any further than coding for exactly what is written
  • Their sense of humour is non-existent, or is harsh and rude
  • They don’t ask questions, and don’t make suggestions

It’s important to take all these points on balance. Some people may be shy, which could mean they don’t ask questions or make suggestions. But a good manager or lead developer will help staff to fulfil their potential, for example by encouraging the quieter members of the team to contribute.

The code from a bad programmer may also have these hallmarks:

  • Lack of comments, or comments that state the obvious and don’t tell you *why* they coded something a particular way
  • Obtuse, gnarly, over-abstracted, over-complicated architecture (at any level: method, class, subsystem or app)
  • Inconsistent or otherwise poorly-considered naming of variables, methods and classes
  • Lack of attention to detail, such as proper sanitisation of inputs for security
  • Copy-and-paste-itis. Bonus points if it’s clear they didn’t understand how the copied code works.

You get the picture. We’ve all written code like this at some point and we should be careful not to think of a programmer with less experience, or one who is struggling with a complex task, as a bad programmer. Bad programmers have a bad attitude, and even if they can mask that attitude for a while, eventually the mask will slip.

Good programmers

Good programmers, like bad, are known by their attitude as well as their technical skill. Note that a good programmer may not have as powerful code-fu as a bad programmer, but their attitude and “soft” skills more than make up for any technical shortcoming. (This is not to say that someone who doesn’t know XML from XTC can be classed as a good programmer; the basics mentioned above still apply.)

You’ll know a good programmer because:

  • They have a good, helpful and professional attitude towards colleagues and customers/users
  • They have respect for other programmers and are willing to listen – and when necessary respectfully disagree – to other points of view
  • They have a good sense of humour and contribute to a good atmosphere in the team
  • They exhibit attention to detail, and can spot the holes and inconsistencies in a specification
  • They are respected and liked by other members of the team
  • They don’t make rash decisions and have learned to weigh the pros and cons of different technologies
  • They can put themselves into the users’ shoes and make good decisions about how their code affects the user interface and experience
  • They have good communication skills, and avoid jargon wherever possible when communicating non-technical people

These kind of people make a team better, and so help an organisation to be better. But it’s not just soft skills, they also have a good grasp of technology:

  • Their code is readable and well-formatted, adhering to any coding standards adopted by the team
  • They choose sensible, descriptive and unambiguous names for classes, methods, properties etc
  • Their comments are actually useful: not just telling you what a method does, but why it is used – and any non-obvious things you may need to watch out for
  • Their architecture choices (at method, class, subsystem or any other app level) are clear, well-abstracted and only as complicated as it needs to be. My rule of thumb for “good” architecture: either you would have written it the same way, or you see why they did it their way and don’t need to change it much.

No doubt anyone with a bit of experience working in a development team can think of several more hallmarks of good and bad programmers. But what about great programmers?

Great programmers

While many people would roughly agree what makes a programmer good or bad, deciding what criteria to use to distinguish the greats ones is much more subjective. Here are a few points I can think of that, in addition to everything I noted for a good programmer, would class a programmer as great:

  • They are aware not just of the users’ needs and the specification, but the organisational environment. They can guide the development of an application so that it serves wider organisational purposes: in the case of a business to serve users and be commercially successful.
  • Their communication and “people” skills are highly developed; for example they can explain complex technical concepts to non-geeks in an understandable, even entertaining, way
  • They are known in the team as the person who will help you out with a problem: partly because they have the experience and knowledge, but also because they make themselves available to help others
  • They keep themselves up to date with technology – not just their own area of expertise but the wider world of development, UI, UX, project management and business
  • Their thinking in terms of abstracting code takes into consideration not just the next 3 months but the next 3 years (that *almost* means they can tell the future)

In short a great programmer has an expansive view of technology, of people, of the future of the organisation and applications they work on. They are part psychologist, part entrepreneur, part designer, part storyteller.

A couple of years or so experience and taking pride in what you do will take you from being a bad programmer to being a good one. But to be a great programmer takes a special kind of person. The kind that, eventually, will do something really special. Like write a great book, start a great company, write an amazing Open Source project.

There’s lots I haven’t mentioned here (such as writing testable code).For more on this subject check out these links: some are articles and essays, some are great programmers.

A note to myself

Nothing to see here, please move along!

Wakefield Cathedral:



Bible GeoCoding:

May the Lord,
Mighty God,
Bless and keep you forever.
Grant you peace,
Perfect peace,
Courage in every endeavor.
Lift up your eyes and see His face,
Keep His grace forever.
May the Lord,
Mighty God,
Bless and keep you forever.

CMS Architecture: Before you begin

It’s important to plan any large-scale software development. Fail to plan, plan to fail as the old saying goes. So before a single line of code is written, before even any architecture or technology decisions have been made, I’m going to define what I want my CMS to be.

Firstly, and most importantly, the CMS needs to be extensible. In the same way that CRM (customer relationship management) systems became XRM (entity relationship) systems this CMS needs to be an XMS.. This will. mean that the system can be used as much more than just a system for managing pages, and instead can be used to manage any kind of data.

Content is generally thought of as pages and files. but just below the surface the vast array of types of content is easy to find:

- Property website have pages which represent houses
- Band websites have albums, which have songs
- E-commerce systems have products, which have alternative versions (like sizes) and related products
- Magazine sites have articles, which may be several on one page or longer articles spread across multiple pages

Forcing users to manage and – more crucially – conceptualise their content as just “pages” will lead to confusion and badly maintained data.

WordPress handles these different types of data through Custom Post Types, and does it very well. All post types share the same basic properties, and can be extended by adding further metadata. Relationships can be defined between posts using the taxonomy system.

This capability is crucial to the power afforded by a CMS and needs to be baked in from the very beginning.

Secondly the CMS needs to be easy to work with by developers (ease of use from a front-end user perspective goes without saying). There are three traits of well-designed systems that make them easy to use by developers.

1) Consistent

If the system is not consistent in its approach every line of code has the potential to trip the developer up. Consistency is not just about ensuring class and method names follow a pattern, but about the ethos behind the architecture of the system. If the user has to instantiate a helper class in module X, but in module Y there is a static manager class then consistency is broken.

Also having two – or even more – ways to achieve the same thing without clear direction on which one to choose puts. doubt in the developer’s mind.

2) Discoverable

Following on from the system being consistent is making it discoverable. It may not be possible to create a system where developers never need to check the documentation, but aiming to get as close to that as possible is a worthy goal.

This can be achieved by applying standard patterns that developers will recognise, and by carefully thinking through each architecture decision to ensure it is as intuitive as possible to use the system.

3) Sensible

If just one of these traits is followed, make it this one; make the system sensible. Have sensible defaults, sensible naming conventions, sensible use of existing patterns, sensible architecture decisions. The moment the system forces developers to do something non-intuitive, a little bit crazy, then a battle is lost.

Better to spend a little time now ensuring the most sensible decision is taken than spend a lot of time later reversing a crazy decision.

Thirdly the system must make as few assumptions as possible. Setting hard limits, such as the number of properties an entity may have, is a recipe for disaster – even if you think those limits are really high. Assuming that users will always need to be authenticated by a username and password will fail the moment an organisation needs users to enter their membership number as well.

Assuming that particular HTML output will always be used is also a sure-fire way to ensure the system will get outdated quickly. And assuming that your users will never want – or need – to use a different database system will also limit future development. Designing a system this flexible is hard work and requires a lot of thought, but when the alternative is painting yourself into a corner the choice is clear.

Many of these system attributes can only be properly verified as the system is being used. And there’s no better way to verify a system can be used than actually build something. So it makes sense to build the entire front-end system, including a default theme, using the API. This has proved to be a successful approach for several companies, and ensures a level of internal testing beyond the usual unit and functional tests.

Bearing in mind these principles we’re ready to start making actual technical decisions. That will be the subject of the next post in this series.