Pin Cing Do 編程道

A.K.A The way of pragmatic coding

I’m not in the camp that believes that websites can, or should last for long.

If something lasts a year it was probably OK. At that point, if the code base remains extensible you probably did a better than average job. If it’s proving to be problematic and everyone involved dreads working on it, it’s probably time to kick it down.

Even if human preference doesn’t instigate a change, a new wave of technology will often rush in like the tide and reduce your ‘best practice’ work to a mere memory.

Succinctly; at best, I think we build the equivalent of sand castles or ice sculptures.

This is OK. I’m fine with that.

Here are some broad things I believe about front-end web development:

• Our code won’t live forever. At best it’s helping one or more people express themselves on the web or sell something so they can eat.
• Our code isn’t art or poetry. It’s purposeful. It’s a solution to a problem. Nothing more.
• We should write the best code we possibly can. But write it that way because it helps us build faster, build smarter and build more maintainable projects. Not because there is any value in it, in and of itself.
• Websites and applications change. They always will. That’s not bad or an inconvenience, it’s our reality. We should build solutions expecting this, not dreading it.

Our role requires pragmatism

If the things we create and the tools and techniques we create them with are ever changing, we need to be pragmatic about the way we approach all facets of our role.

pragmatic |pragˈmatɪk|
dealing with things sensibly and realistically in a way that is based on practical rather than theoretical considerations

We need to be pragmatic about the way we learn, pragmatic about the way we build and pragmatic about the way we work with others.

Front-end developers face unique challenges

Learning

“The browser is the most hostile software development environment ever imagined”.

Things aren’t getting any easier; device and platform fragmentation, multiple input contexts (touch, mouse, game controllers, speech), widely differing bandwidth speeds.

Unless you’re superhuman, the traditional approach of learning something, start to finish, for every necessary facet of front-end development is an impossible task: there aren’t enough hours in the day.

Front-end development isn’t merely the mastery of one or two languages. It isn’t even a clearly definable set of skills. What one employer wants from a front-end developer might not be what another wants.

Our needs are that we must refine our capabilities constantly. We must judge and appraise new techniques with speed, analyse their usefullness and incorporate any benefits into what we do. Before we can evaluate new tools and techniques we need the confidence to know what we should pay attention to and what is expendable.

The crux of the problem

The web, its nature, capabilities and the very tools we build it with are constantly mutating.

Meanwhile, we’re all trying our best to understand and implement the latest and greatest techniques and languages but it often feels impossible. Feeling this way has bothered me for a long time.

What’s the answer?

Little Dragon

Bruce Lee was an incredible martial artist. Towards the end of his tragically short life, he moved away from the mastery of distinct, dogmatic styles and disciplines and promoted a philosophy he called ‘Jeet Kune Do’ which translates from Cantonese to ‘The way of the intercepting fist’. Here’s what he had to say about it:

I have not invented a ‘new style’, composite, modified or otherwise that is set within distinct form as apart from “this” method or “that” method. On the contrary, I hope to free my followers from clinging to styles, patterns, or molds. Remember that Jeet Kune Do is merely a name used, a mirror in which to see ‘ourselves’… Jeet Kune Do is not an organised institution that one can be a member of. Either you understand or you don’t, and that is that.

He looked at what other fighting forms had to offer. He analysed their benefits to him, quickly appraised them, and where appropriate, took component parts and plugged them into his own fighting style.

It was a fluid system. Never stable, never finished, constantly evolving.

I think the very same philosophy can be used in our quest to be better front-end developers. I think we can feel more positive about the reality of our situation if we embrace a mindset I’m calling ‘Pin Cing Do’, which translates roughly to ‘The way of pragmatic coding’.

編程道 Pin Cing Do

‘Pin Cing Do’ is nothing new. It’s probably what most of us do without even thinking about it. It’s just a name. A label to pin on something. I think it can be applied to both the learning of new skills and the manner in which we build things. Perhaps even in the manner we work with others.

Applying Pin Cing Do to learning

Be not afraid of growing slowly, be afraid only of standing still.

I think we can be more effective by mastering a couple of core skills and then seeking out only component parts of larger skill sets, making no effort to consume all they have to offer.
We should never seek to master many languages and skills because it doesn’t serve our purpose. We take only what we need and dispose of it when surplus to requirements. What is needed and what is not is a purely personal thing.

Core disciplines

I’m getting ahead of myself. To get to that first point, we need to intimately know some ‘core’ disciplines. They will become a base, a foundation. After all, our model here is Jeet Kune Do and Bruce Lee couldn’t have adapted things into Jeet Kune Do without the mastery of the Kung Fu style of Wing Chun to begin with.

I don’t believe that each of us can adopt our own personal style of Pin Cing Do without some base to mutate from. I’m not the sharpest tool in the box so I opted for the easiest: HTML and CSS. For you it might be JavaScript or interactive graphics like Flash, SVG and Canvas. It’s your foundation, start with whatever you gravitate to.

However, ensure your core skill(s) are solid before attempting to build your own unique repertoire.

Limiting Scope

I used to feel incredibly inadequate for not knowing a raft of computing languages. But the reality is there’s probably only a handful of people on the planet that really understand more than five or six languages. They are the savants of our industry. For the rest of us, aiming to know even three languages to an exceptional standard is a unsurmountable challenge.

If you ever feel like you’re drowning when trying to learn new things, it’s perhaps less about your ability to learn and more about the breadth of the scope you’re attempting to cover and master.

The man who removes a mountain begins by carrying away small stones

In that situation I’d suggest scaling back your aspirations. Indulge me in a huge tangent of why I believe this approach can be the most the most effective in the long run.

Victory

On the 21st October, 1805, Vice Admiral Horatio Nelson led Britain against the joint Spanish-Franco fleet in the battle of Trafalgar, just off the coast of Spain. It was a key moment in our great Nation’s history. Failure at this point for the British would have meant an invasion by Napoleon’s amassed invasion force.

Some key strategic points to understand. In those days, naval combat between warships largely consisted of one of two blows:

• The ‘broadside’ was when ships drew alongside one another and basically just ‘slugged away’, unleashing all they had at one another.
• Perhaps worse still was the strategy of ‘raking’. Here, if one ship could bring it’s guns to bear against an opponent down it’s length, the canon shot could tear through the entire length of the opponent’s vessel whilst they themselves were largely incapable of returning fire.

Just to be clear. Canon shot would literally tear people apart. If the shot itself didn’t get you there was a very real possibility that one of the hundreds of pieces of wooden smithereens would provide for you. It’s both hard and sickening to imagine the insanity and carnage that must have ensued. Just consider what those moments must have been like, knowing that you had been out-manoeuvred and the enemy was drawing up to unleash everything they had at you.

And we grumble about cross-browser testing!

In battles of the time, it was usual for boats to run parallel to one another and slug each other back and forth with broadsides. It was often a drawn-out affair and inconclusive for both parties. Bad enough to lose all those lives but to have to do it all over again would be even worse.

The genius of Nelson in the battle of Trafalgar was his audacity. A complete disregard for this convention. He rejected that accepted notion of battle and made his fleet approach the amassed French and Spanish fleet at a right angle in two columns.

For their entire approach they were drawing fire and were largely incapable of reciprocating. But this allowed Nelson’s master stroke, the ‘Nelson touch’.

The British columns were able to cut through the enemy line, effectively splitting the enemy fleet in two. As they passed through they were able to ‘rake’ across the enemy flagships, effectively ‘cutting the head of the snake off’. It wasn’t then necessary to engage every enemy warship – which was just as well as they were outnumbered. After enough damage was inflicted to key targets such as the flag ship, many other enemy ships ‘struck their colours’; surrendering themselves and no longer presenting any danger.

Aside: Whilst of no importance to our point, I’d like to tell you that the technique was certainly not without cost. Whilst Nelson’s tactics were incredibly decisive and successful, Nelson himself was shot by a musket ball from the rigging of an enemy ship (The Redoutable) and died at around 4:30pm that day, living only long enough to ensure that victory had been secured and invasion averted. I’ll also clearly state that I’ve over simplified the events here as this isn’t supposed to be a history lesson.

You are probably wondering why on earth I am telling you this? Given the seriousness of what we’ve just covered it seems a little poor taste to being this back to code. Forgive me.

Let’s scrub back. Remember Nelson’s amassed enemy fleet?

When faced with the enormity of things I need to do, I like to do this:

In terms of your challenge, what are the equivalent of flagships? Where can the line be cut through? How can we cut the head off the snake?

By dividing and conquering key objectives, others become less important or unnecessary. If the lion’s share of your coding work is in manipulating DOM elements, concentrate on getting really good at jQuery. If it’s building WordPress sites, go and master PHP. Be pragmatic: divide and conquer.

Knowing when you are ready to practice Pin Cing Do

So all that is a bit theoretical and I’m trying to promote pragmatism. If I’m saying that a core competency in something is essential first, we need some concrete measure by which we can gauge proficiency. How can we do that with so many different permutations of skills? How do we know if the code we write is actually good, maintainable, and something to show to your Mum?

I’ve decided there is actually an easy metric we can use to gauge whether or not we are masters of our own code.

Before I hit you with the soundbite, I’d like to offer an analogy for this. Are you familiar with the game Jenga? In case you are not, here’s an image to jog your memory.

The game begins with the blocks stacked. Players must then take it in turn to remove blocks, aiming to retain the structural integrity of the structure. The person who causes the structure to fail, loses the game. OK, we’ll be back to that in a second or two.

Here’s my soundbite on knowing when you are competent with code:

Competency with code is attained when the author can explain the purpose of each line

Back to Jenga. Imagine that the Jenga structure is a code base. When you see it in front of you, it’s easy to make a fairly sound judgement of how a block affects the overall stability of the whole. We can safely reduce the code base a block at a time because we understand the part each block is playing in keeping things stable.

Now imagine playing Jenga blindfolded. That’s what we’re doing when we try and optimise, adapt or improve code we don’t fully understand.

Let’s take this analogy further. Try building the tower up from nothing — blindfolded — with one hand. That’s the situation we’re in when we try and build something with languages or techniques we are not familiar with.

The takeaway here is simple, don’t play Jenga blindfolded. When you understand the code you are its master. When you don’t, you’re at its mercy.

Pin Cing Do applied to new tools and techniques

To practice Pin Cing Do, we must never grow attached to our existing tools, techniques and products. They exist purely to serve our needs. There will always be something better in the future. Be ready to embrace it. Failure to do so will see you superseded. The technology choices you make shouldn’t feel like picking sides in a Holy war.

Let me exemplify. I’ve found enormous utility in the Compass framework in the past. I spent 9 months of my life writing about using it alongside the Sass pre-processing language so my admiration for the project should be obvious.

However, my principle needs at the moment are making SVG image sprites/data URIs, enjoying fast Sass compiles and getting intelligent and frictionless prefixing of experimental CSS properties. All of which are better serviced at present by using Grunt or Gulp and their associated plugins. Cutting Compass out of my workflow, for me, has been progress, not something to be viewed as negative.

Chrome is another example. It’s been my go to browser for a couple of years but I’m finding it pretty ropey at present. I won’t suffer any crisis internally about ditching it. If another browser offers a more stable or powerful platform I’ll think nothing of switching: that’s as it should be. We should appraise and adopt wherever benefits present themselves; to do otherwise is folly.

These are my choices and mine alone. That’s the whole point. When others evangelise their products or personal choices by all means consider them but ensure you analyse them for your own context.

When tools in your armoury fail or get superseded, be ruthless about abandoning them for something better.

My personal maxim in this respect:

Be monogamous in your personal relationships and a philandering whore in your choice of tools and techniques.

Pin Cing Do and the way we relate to others

In eastern martial arts, it’s common to bow. On entering and leaving the Kwoon/Dojo, during training, to other practitioners, to Sensei/Sifu.

It’s not about subservience. It’s about respect: admiration for a fellow practitioner.

If, as front-end developers, we are to indulge in the idea of Pin Cing Do being akin to Bruce Lee’s Jeet Kune Do, his philosophy of learning martial arts, we may should take all that is good about it. I think that includes the idea of showing respect to others.

Let me exemplify. I can’t remember how many times in the past I’ve opened someone else’s code to work on and cursed it. Pissed and moaned about the way things have been done. Or looked at a composite, shaking my head at the laughably bad design choices that have greeted me.

I did this, in most cases, because I was an idiot.

If you are working with a fellow professional, they should be able to explain every decision made in their work in the same manner you can explain every decision in yours.

Often the features or implementations you may initially believe are flawed, extraneous or pointless are essential, ingenious and necessary.

If handed a composite to build by a designer, it is therefore imperative you code out the visual design as accurately as possible and to the utmost of your capability.

I think the same code of conduct and respect should be true at the other end of the pipe. We must accept that however humble the project, we are typically attempting to carry a vision, as undiluted as possible, through multiple people and teams. Each with their own confines and unique challenges. That’s never easy. So I think we should offer others respect and courtesy we would like reciprocated.

Back-end developers

Don’t assume the worst

If you hand your code off to others at the back of the stack, and months later wonder why so much has been changed by the backend folks, don’t assume the worst. They may have their own reasons for not implementing the code in the manner you had hoped.

When it comes to working with others, for me, I think this encapsulates my sentiment entirely. It’s from JavaScript guru Nicholas C. Zakas:

“Instead of assuming that people are dumb, ignorant, and making mistakes, assume they are smart, doing their best, and that you lack context.”

Helping fellow practitioners

To demonstrate our respect to fellow coders we can do some simple things.

Comment your code as much as possible. This is how we can communicate our Pin Cing Do to a fellow developer. For example, document why you have chosen a solution. Ensure you leave a note about any un-obvious choices. If you’ve put something like -webkit-backface-visibility: hidden; on an element, to a fresh pair of eyes it may seem extraneous but you should know and explain why it’s in there.

Don’t ever worry about writing too much. Seriously, even if no-one else does read it — you will the next time you come back to it. That alone may save you a couple of hours remembering what you did and why.

“Tell me and I’ll forget; show me and I may remember; involve me and I’ll understand.”

Offer a handover

Always offer other developers the opportunity for a hand-over of your work. In person is always preferable but if not possible via phone or perhaps just do a screen recording talking through the code base you have created. They may not be interested and that’s fine too but if nothing else they will likely appreciate the offer.

In all areas, you will never know how or if someone will reciprocate. Don’t expect them to. Do it because it’s the right thing to do. Regardless of what others do.

Can you do this?

Ever wonder whether you are in right job? Wonder whether you are mentally equipped to do well at this front-end malarkey?

I always feel, for the most part, like I don’t really know what I’m doing. Like a phoney when it comes to coding things. Like an impostor in my role. I think I’ll always feel that way but I’m beginning to care less about it. If you ever feel like that, here are a few points I’d like to make:

Don’t assume others are doing it ‘better’ than you. Big-shot ‘web celeb’ developers make the same mistakes we do. That’s not a dig at anyone, it’s just something you should recognise. We’ve all written z-index: 9999!important; at some point.

Who built Lego?

I loved Lego as a child. When I got a new kit, the first time out I’d build it from the instructions. Then I’d take it apart and I’d build it again. Perhaps different, perhaps bigger or with new features.

Dear reader. I know you enjoyed Lego when you were little. I know you really liked it; so much so that you probably asked for Lego for your birthday.

Derren Brown my arse.

This isn’t a trick. You think you make choices in life but you really don’t. You’re reading this because your genetic make-up disposes you to this line of work. You’re reading this because you want to build stuff. You get a kick out of solving problems, just like you did when you played with Lego; you’re trying to create something greater than the sum of its parts.

Don’t compare yourself to others. It’s not important what you can build now compared to this person or that. The fact is you’ll be able to build bigger, better and faster in the future.

And it’s my hope you’ll practice you’re own Pin Cing Do, whatever that is to you.

…Truth exists outside all molds; pattern and awareness is never exclusive… Jeet Kune Do is just a name used, a boat to get one across, and once across it is to be discarded and not to be carried on one’s back.