Hello, my name is Ben and I have just joined as the Technical Lead at Perago. I know what you’re thinking; leads are already pretty technical, isn’t that title something of a tautology? Well, I’m going to talk a little about me and hopefully by the end of this you’ll have completely forgotten about that question.
I graduated from Swansea university in the late nineties with the painful realisation that a degree in philosophy was not going to be a big money earner and it was time to learn a marketable skill. Quickly dismissing ‘becoming a hobo’ as a viable career plan, I embarked on an MSc in Computer Science which I discovered I have a real aptitude for. All those classes in formal logic were finally paying off and -to my considerable relief- I found myself in a field where right answers exist.
In the twenty-something years since then (I know, I’m as surprised as you are) I have worked full time writing software for the web, for mobile devices, even for industrial systems. I have worked at small agencies, local authorities, independent sofware vendors and for much of the last decade I have been self employed as a contractor. I enjoy contracting – the independence suits me, the money is good and the work is interesting and varied. I have worked on internal and external tools, large and small for customers of many sizes. There’s a fair chance you have used a website that I have worked on.
A programming generalist- I have deployed code professionally written in ten programming languages across many different platforms- I also take a deep interest in development process and what makes a team work. Those right answers I so enjoyed at university were available because programming is the application of logic to build complex systems – if you construct the system accurately it will return absolutely predictable outputs for a given set of inputs. Most of the biggest challenges developers face arise because in the real world our software is used by people and humans are inconsistent and easily confused. All too often we end up with carefully built and complex structures that – like the walkways on the Death Star – are desperately in need of some handrails to prevent us from accidentally plunging into the abyss. Understanding how people will use the tools we create and finding ways to think about them like a regular user is an essential part of our work, and one that is overlooked or treated as an afterthought far too often. Finding ways to do this needs to be a thread through all our work, through team structure, acceptance testing and ongoing support. People (programmers more than anyone) like to think that software development is about constructing grand new projects and sometimes it is, but much of the time it is about making existing projects better, finding ways to smooth out corners and improve users’ experience. Once we frame our thinking around the things we are building in those terms, we can start organising our teams and process around what we need them to do and look at ways to keep that work interesting and enjoyable for the members of that team. Sooner or later everyone is a user, developers included.
As you can possibly tell, that philosophy degree is still in the back of my mind helping me to analyse problems, search for deeper understanding and consider the ethics of the system as a whole, which means that of course I can’t resist the observation that putting handrails on the Death Star is still working on the Death Star.
So what would persuade me to go from hotshot independent mercenary of the contract world to a regular job? Contract customers have often offered me the chance to move to a full-time role and none of them changed my mind. The difference with Perago is that there is a vision here that I find very appealing – although English-born I live in Wales and I have a great affection for this country. I want to see the people of Wales thrive and joining Perago gives me an opportunity to use my skills and experience to contribute to that. The opportunity to join the company early and to help shape our technical direction was simply too good to miss.
Now that I am part of the company we are able to bring more of our technical operations in-house- my architectural and implementation experience mean that I’m well situated to help design tools that are practical and pragmatic for customers and their users. I can also build prototypes to help clarify the kind of tools that might be useful and refine design approaches ahead of implementation. I can work alongside in-house technical teams to evaluate current platforms, explore ways to make development processes more practical and help find ways to smooth their operation. That doesn’t mean that we’re becoming a technology company- often the best way to address a challenge is through people and process- but it does mean that our multi-disciplinary toolbox got a little deeper. When the territory gets technical, it helps a lot having someone to help lead you through it and here I am.