Blog index

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, Quay.io, 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.
Posted by parsingphase, 2014-09-15 15:45
A certain sort of style
Well, as you can see, this site is now somewhat less "white-labelled" than it was when the last blogpost was written. It's now got an actual identity and some of the styling of the old phase.org site. Critically, this is all built on top of the white-label layout mentioned previously; the styling is all held in a private composer-managed module which adds custom templates to the Twig stack and holds all CSS and images in a resources directory. Thanks to the flexibility of composer and Silex, the difference between the white-labelled and styled branches is one extra module required in composer.json, and one line to register a ServiceProvider in index.php.

This site is now built from 4 custom modules:

parsingphase/adze-base-site: "wrapper" project of under 200 NCLOC including configuration and build tools, serving as an example functional deployment of the Adze framework.

parsingphase/adze: A very lightweight framework built on Silex, combining various open-source libraries to produce something more "out-of-the-box", with working persistence, templating and user services, and default white-label templates.

parsingphase/blog: A functional blog module built on top of Adze.

parsingphase/phaseorg-styling: A private module containing the styling and resources specific to phase.org. Not required for a "white-label" site.

Anonymous user

Login

Blog

Contact

I'm currently available for contract work in London as a Senior PHP Developer. Contact me for a CV, rates, or a chat.

Twitter @parsingphase
Email richard@phase.org
Github parsingphase
LinkedIn Richard George
Flickr parsingphase

On Github