Blog index

Posted by parsingphase, 2017-05-17 08:42
“So what are you looking for in your next role?”
Much like “So what is it you do?”, this is a question that tends to make digital workers wince a little whenever they’re asked it; a certain amount of hand-waving tends to follow as if we’ve never been asked it before, or never expected to be asked it again. Do recruitment consultants feel the same wince when they ask it, given how essential the answer is to them? Shouldn’t we be ready with a more useful answer?

Perhaps the problem is that few people’s life motivations are driven by the minutiae of technical work- Maslow’s Hierarchy doesn’t exactly have a level for “using Framework X”, but deals rather in the abstract of self-actualization. For most of us, particularly as we get older, that actualization consists of external experiences- in my case, the chance to spend quality time with friends and family, getting out into the countryside or onto the water, travelling and exploring the beauty of the world.

Does this help answer the question? While there may be beautiful novels, paintings and photos sharing the beauty of the mountains, as far as I know it’s never inspired rugged and elegant code. But it can of course help with cultural fit, in placing a developer somewhere where they can make wider contributions to the company’s activity.

Something I’ve done for a long time — even longer than I’ve worked with technology — is study foreign languages. There’s an interesting idiom in French of the “Violon d’Ingres” — from the virtuoso painter Jean-Auguste-Dominique Ingres, who could also play the violin at an outstanding level; it means a passion or particularly important hobby. At the risk of mixing metaphors, it can also mean “having a second string to your bow”. For me, language — both English and foreign — plays that role. My A-levels were Maths, Chemistry, Physics and French, and my degree was Electronics — studied in Southampton, Karlsruhe and Paris. A few years back, when looking for an additional mental challenge, I also studied Japanese for a couple of terms, because it exercised a part of my mind and interests that I’d not been able to incorporate into my career. It’s in a similar vein that I enjoy reading well-written fact and fiction in various languages, and the occasional chance to write essays and technical guides myself, both absorbing and sharing information.

Language learning — and indeed languages themselves — have changed a lot since I first started studying French in primary school. There was no word for “World Wide Web”, “Internet” or “Email” in my vocabulary until around the time I entered university. When I studied for the TEF recently I didn’t buy a lot of books, I logged into Duolingo and bought several issues of Sciences et Avenir on my iPad as reading practice. Site and apps like Duolingo, iKnow and similar are an incredible enhancement to the learning of languages and an area I’d love to get into — I’m not sure there are many developers around that could check their work in five languages — but all forms of online learning interest me. I’ve previously worked on financial training tools, for example, and while it was far from my domain of expertise, creating the tools was extremely interesting work. Ultimately, the whole domain of sharing information and learning is very much “my thing”.

So — there’s a few ideas about the sort of sites and tools I’d like to work on — but on what platforms and technologies? To be quite honest, I’m not sure I care! Yes, I’ve worked with PHP, JS and MySQL for 15 years, so I’ve got some pretty solid skills in those areas, but I’m also inherently a lifelong learner. I taught myself those key skills, and because I believe in doing things properly I taught myself to do them well and never stopped studying. On the side, however, I taught myself enough Objective C (it was a while ago!) to create the prototype of the Bletchley Park iOS app and enough Node.js to work on the network data collection daemons for LINX — my key skill isn’t a particular language or framework, instead it’s adaptability, rigour, the ability to learn and to fill in the missing skills, processes and tools on client projects.

That’s not to say I don’t have an affinity for particular tools — I’ll choose Symfony and Angular when appropriate, for example, but I don’t define myself based on their use. So the “right project for me” is one where I can both learn and share what I’ve learned, and solve problems which some developers might consider “not their job”, whether they sit anywhere in the full LAMP/JS stack or in the domains of DevOps or project management. This means that my skills and mentality are particularly well suited to small to medium teams where they either need a multi-skilled, adaptable worker to handle a variety of tasks, or a synthesist to fill in the gaps and smooth out the processes before getting back to high-quality, hands-on work.

In the future, of course, there are new technologies I’d like to work with. I’d really like the chance to work with iOS professionally (Swift, while not flawless, is an intriguing language) and in the shorter term expand my skills in JS frontend frameworks. Pending an opening in those areas, though, I’ll keep doing what I’ve done for years — solve client problems with high-quality code and the ability to effectively fill whatever gaps need filling in skillsets, communication and tools.
Posted by parsingphase, 2017-01-17 20:41
“So what is it you do?"
- A bad enough question in a social situation where the answer “I’m a software engineer” causes your correspondent’s eyes to instantly glaze, but even worse when you’re talking in a technical environment, or job hunting.

The thing is, whatever it is I do, I’ve been doing it for just short of 20 years, and like most developers I’ve my own unique trajectory through my career. I’ve had 6 permanent roles and about 10 contract clients. Both the industry and the languages I’ve used have changed immensely during this time.

Trying to bundle that down into a snappy answer is nigh-impossible, hence this longer attempt to find one.

One way of starting might be to run through a few of the job titles I’ve had during this time:

- Graduate Engineer
- Software Engineer
- Web Developer and Server Administrator
- Contract Frontend Developer
- Contract LAMP Developer
- Technology Manager
- Technical Manager
- Technical Architect
- Senior Contract Developer

not to mention several contracts that didn’t come with a job title.

About all that’s clear from that though is that most technical job titles are pretty vague.

I could run through the technologies I’ve used, which always leads to an impressive jumble of alphabet soup:

PHP, Javascript, Perl, C, MySQL, Linux, Apache, nginx, MongoDB, Angular, Node.js, PHPUnit, Composer, Zend, Symfony, Doctrine, Git, Mercurial, Subversion, GitHub, Stash, Kiln, Jira, Trac, FogBugz, Jenkins, Docker,, AWS, VMWare, VirtualBox, Bind, Postfix … I could continue, but it mostly just illustrates a breadth of experience rather than a clear direction or theme.

So what do I do on a daily basis? Well, that varies between roles - I’ve worked as both a frontend and backend developer, and in roles with sysadmin responsibilities. I’ve worked as a Team Manager, team member and as a single developer. But there are some common themes in what I’ve done:

- Anywhere I work, I try to ensure that the right tools and processes are in use, because this helps me to produce quality work in a low-stress environment. Beyond the simple belief that professionalism requires doing good work, I do this because:
— I only want to write any particular piece of code once
— I don’t want my code to fail on live systems
— I want to make sure my code is as readable and re-usable as possible
In other words I want to do a good day’s work 9-5 without having to continually break flow to fire-fight, and then go home and be able to concentrate on my family life in the knowledge that I’ve minimised the risk of anything failing out of hours. I want to have a low-stress, productive, even enjoyable environment both for myself and my team.

This means ensuring the presence of:
— A good code management, approval and release process
— Decent automated testing, run automatically on all changes without interrupting developer flow, with an expectation of zero failures.
— Common coding standards that ensure both that code is automatically familiar to all developers, and that automatic tools can be used to ensure code quality and consistency where manually-written tests might not reach
— Quality logging and monitoring tools to catch live issues and oddities early
— Powerful, complete and consistent development environments with tools like loggers and profilers available to all engineers without requiring significant setup or maintenance time
— Readable, accessible and complete documentation

I’ve found that, if you give developers the right tools, they write good code. If you give them tools, on the other hand, that are hard to operate or maintain, they won’t use them.

The target of my process design is always: "Make it easier for developers to write good code than bad code, without making the process a drag”.

I do this from a realisation years ago that in, for example, a team of five, spending 100% of my own time just “writing good code” could only ensure that 20% of the code was good. But by spending some of my time, as a Lead Developer, manager, or senior team member - on processes and mentoring, I could help ensure that almost all code produced was good - even if I was writing a bit less of it myself. Best of all, the payoff on that investment over time means you have less stress, higher quality code, and more time to devote to either further process improvement or more hands-on development.

This attitude to changing processes has earned some happy employers, clients and teams, but also some unofficial job titles that have never quite made it onto a business card, along the lines of “Troublemaker” and “Professional Nuisance”. As it happens I’m quite fond of these, as they've reflected the fact that I’m generally wiling to stick my oar in and make changes for the better, and won’t usually grant special dispensation to cut corners. Fortunately clients and colleagues tend to understand why this is, and generally accept even as they make the case for a shortcut that it may not be the best approach.

Of course, there’s a certain approach required in being a Troublemaker. You can’t just walk in and say “we’re doing it this way now”. There’s a phase in every job and contract where you have to work inside the existing system, understanding that particular team’s needs and producing the sort of code, advice and feedback that gains people’s respect; you can affect change either aggressively through force of will and then try and work through the resentment, or you can first prove to people that you know that you’re on about, can produce quality work, and that the changes you propose are in their best interest.

You generally have to prove, too, that you can work across and between teams, whether it’s getting approval for new servers and services, helping to build tools that traditionally fall more within a DevOps than pure developer mandate, or making a business case for commercial tools and services. You can’t generally do this work if you’re happy to sit in exactly the slot that people have conceptually made for you, you have to be a trusted connection between existing groups, and you have to show that you can provide enough support to ensure that new tools & systems won’t add to existing workloads.

Building up adequate trust and reputation to have space to be disruptive in this way can take time and feel difficult, but I’ve always found it the best approach for long-term success. I like to think this is borne out by the fact that, since I last left permanent employment over 4 years ago, every one of my clients has offered to extend my contract when it came up for renewal (although I’ve obviously not always taken up the offer).

I tend to refer to this sort of work as either Process Engineering or Synthesis (or simply “Problem Solving”); it’s not generally full-on DevOps, and it’s a bit more than run-of-the mill development. Suggestions for a concise description or title are welcome.

Apart from this “Synthesist” role, though, I’ve obviously done a lot of hands-on development over my career. In particular, I’ve done a lot of work on older code. Partly this reflects the fact that I’ve been doing this for a long time - I’m familiar with the technologies that were used a dozen years ago as well as those of today, and I’ve gained a deep understanding of the underlying grammar of development, of what works and how to bring older projects up to standard. Partly, too, it represents that fact that I’m just plain stubborn at working out how older systems work, and have thereby gained a good reputation as a “Code Archaeologist”.

This can, unfortunately, be a bit of a two-edged sword. A familiarity with a myriad of coding techniques means that you can generally pick up new technologies both rapidly and successfully, but a reputation of working well with older code can put off employers and clients looking for 18 months’ experience in “this year’s thing”; framework specialisation is often seen as the domain of those who have been developing for fewer years than the framework has been around, and I’ve complained before) as to how that limits flexibility. By definition, as a Synthesist, I have to be a jack of many trades, but that increases, rather than decreases, your ability to master new ones.

So what does this all add up to? Where am I at now?

As ever, looking towards the next role - but this one’s going to have to be outside London - having married last year and living in a London box-sized flat we’re looking to move to somewhere with more space and better access to outdoor activities. My wife’s American but right now that’s not somewhere we’d want to go. Canada would be a consideration but their points-based immigration system considers that you stop accumulating experience 6 years into your career and start losing points to age instead, so I’d need an approved job offer to get in. Dublin’s a temptation but the possibility of a hard Brexit and the loss of freedom of movement makes that uncertain in the long term. The most tempting locations in the UK now seem to lie somewhere between Bristol and Cardiff, but few places come close to London’s tech industry. Thoughts on the practicalities and availability of both permanent and contract roles in any of those locations would be greatly appreciated; drop a comment below or find me via twitter at @parsingphase.
Posted by parsingphase, 2015-03-12 22:05
Availability update
I'm coming to the end of a fixed-term contract and looking for new clients, to start May 4th. I'm trying out flagd to manage CVs and availability, so search for me there - or just drop me a line for rates and the latest CV.
Posted by parsingphase, 2014-09-28 22:00
TDD site & Enigma Simulator relaunched
I've updated & re-released my site on TDD, TDD Deciphered, and the Enigma Machine simulator on which it's based. There's still plenty of work to do but the code's modernised, self-testing & open source.
Posted by parsingphase, 2014-09-17 16:15
PHP as Framework
Revising a CV (or if you'd rather, a résumé) is generally seen as one of the great irritations of leaving one role and seeking another. But it also gives you the chance to look back and see not only what you've achieved over the last few years, but what's changed in the industry you work in. For PHP developers, the last three years have been particularly interesting. Thanks to the development of composer, the maturation of a second generation of high-quality frameworks, and the work of the PHP Framework Interoperability Group, we now have a feast of high-quality, interoperable components available to us, with a trivially easy installation process.

To my mind, that means that we can change how we look at the idea of a "framework" in PHP. The definition has always been pretty loose, but let's think of it as "a set of software components, designed to work together, from which we can pick and choose the functionality we need". That used to mean selecting a framework or CMS like Zend Framework, Symfony or Drupal, downloading an archive and picking the bits we needed of it, usually with a maze of require statements. Extending behaviour meant searching down third-party libraries, downloading and incorporating those, and hoping that the versions of the various libraries you happened to have played nicely together. This wasn't always particularly easy, reliable or enjoyable, and so it was often considered easier to write the required functionality in-house. And we've all spent more years than we want to think about in maintaining that type of application than we really want to think about.

Now, though, a number of inventions and initiatives have come along that give us an alternative. Distributed version-control systems such as Git and Mercurial, and broadly-available, trusted DVCS hosting providers such as Bitbucket and Github, mean we have a standard way of making source code available to end-users. These also give us a standard mechanism for collaboration and contribution of code via wikis, issue trackers and pull requests. Composer and Packagist give us a common vocabulary and resource locator for specifying dependencies and versions according to semantic versioning rules. Together, this means that we can specify our top-level requirements in a composer.json file, sit back and let composer serve us up our own custom codeset.

Of course, while all PHP code can be interoperable, some code is more interoperable than others. However this too has improved over the last few years, through two main mechanisms. The first is the emergence of widely used and reliable libraries and frameworks like as Symfony2 and Doctrine, which now underpin a wide range of projects, providing an implicit compatibility. The second is the work of the PHP Framework Interoperability Group to make compatibility explicit. So far they've normalised autoloading, code standards and logging, and look to be in the process of defining standards for documentation, caching and HTTP request and response access. Collectively, these mechanisms help extend the "Pick and Choose" mentality of a framework across the whole of the PHP ecosystem, and break down the silos that separate different named projects and frameworks.

To make the best of this, however, we also need to stop putting ourselves, and other developers, into silos. Companies and agents advertise for "Drupal Developers", "Symfony Developers" or "Zend Developers", and I'm not sure that either they nor I understand what those terms mean. These projects are all a combination of MVC framework and library; the model should be a matter of the company's own business logic, the view's usually based on either Smarty or Twig, the persistence layers tend to be fairly standardised, and the controller should really be lightweight and keep itself out of the way. If the libraries are well designed and interoperable, then the only things that should be specific to the framework in use should be configuration and routing (or hook mechanism). Once the project has passed its inception phase, the time or expertise needed for either of these mechanisms should be minimal, and we should be looking not for "framework specialists" but once more for "PHP developers".

It's for this reason that this site doesn't use a heavyweight framework such as Symfony2 - although it does have the flexibility to use all of the Symfony and Sension components. Adze, a minor extension to the lightweight Silex microframework, needs only minimal setup to give me a caching Twig-based View layer, a very lightweight Controller, and an adaptable persistence layer via Doctrine DBAL that let me quickly use tools from the entire PHP ecosystem to build whichever custom models I need, in much the same way I'd build them into any larger framework or project. And the flipside of the flexibility afforded by the new interoperability is that I, or anyone, can easily share this code for others to use via my github page and for installation via composer. It may be simple as yet, but by developing it in the public eye and with a mind to wider use, if it does grow, it'll grow in the most useful way possible.

Anonymous user



Contact Richard

On Github