I am a technologist at a large IT consulting group where I have a generic title, ‘Senior Practice Consultant’, which is shared by many others and doesn’t match what I endeavour to do – so I have embarked on a subtle (and possibly fruitless) campaign to get my title changed to ‘Technology Shit Stirrer’ in an effort to, well, stir things up a bit. I have both a lot of experience and an interest in the latest shiny new technology and use this as a platform for the stirring, encouraging people to think differently, assert their views and learn something in the process (myself included). I have been fortunate to work with some really smart people that have helped me understand the fundamentals and I use my knowledge of how things currently, and used to, work to push against the drivers behind the latest technology. The reverse is just as important by trying to understand what the new stuff is trying to change and why. For example, I like to see how traditional SQL systems and DBA’s are pitched against the recently fashionable non SQL databases to better understand the benefits of the ‘new’ and what we need to consider from the status quo.
While it may be interesting some of the time, stirring shit as a full time day job is not really in demand and would probably be tiring, lonely and not very lucrative if I were to give it a try. So I spend my days and get paid building various large and small business oriented systems on top of the .NET stack in and around London in the UK. When I lead teams I work with developers, define architectures, deal with the customer, interface with project management and try to code as much as possible (at the very least to feel the pain of architectural decisions). Sometimes I help out existing teams with some specialized aspect or to help fill in a gap that is being missed. In either case I find that I get to work with some great developers that have been able to focus on specific aspects of software development and it gives me the opportunity to learn something from them.
Software development is ridiculously complex and broad, making it impossible for anyone to be considered an expert – the moment you have the time to be considered an expert on something then someone else is spending time elsewhere, on some other aspect, and learning for than you. At the same time developers tend to be elitist and competitive, often feeling that their lack of mastery on the latest thing is a threat to their careers and standing. Trying to get technical people to challenge and criticise each other and themselves, in an effort to learn and further their craft, is part of day to day shit stirring that needs to be done with care and consideration. Personally, I am comfortable that I have reached the point in my career to acknowledge that there are some things that I am good at and others where I am weak, but rather than feeling threatened, I seek out those people that I can learn from and endeavour to exchange knowledge.
While furthering the craft of software development may be valuable and personally fulfilling, ultimately I am paid for delivery of solutions that are in production and (usually) core to the business. So it is necessary to continually focus on delivery and anything new being learned needs to be done in the context of delivery and value (both current and future) for the customer. So in both the new technologies that I am learning as well as the day to day implementations I focus myself and the developers around me on delivery using various techniques, both tried and tested as well as new – the process of delivering software is as important as the technology and both affect each other, so new technologies require revised processes and existing processes have a possibly negative impact on our technology and implementation choices.
Currently I am getting more involved in the cloud and when it started I saw that I have something to contribute. I noticed that the cloud hype wars were (and still are) driven by vendors selling something, anything, with a newly attached cloud label and by promising how easy and fantastic their products are neglect some core issues. Some of the issues being neglected relate to application architectures and how we build applications (there are other issues, such as security, which are not solely in the application domain). The cloud requires that developers and application architects look at solving problems in an unfamiliar way that demands the learning of new skills and development of new approaches and frameworks – despite how easy it may initially seem. Most developers don’t have the base skills to engineer solutions that are massively distributed and scalable and are short of base techniques, such as message oriented communication, data inconsistencies and so on. I only have a smidgen of those skills but reckon I am able to spot what is needed and make an effort t try and figure it out.
This blog will reflect, in the coming months, that process of learning and communication that began on my corporate blog (which I will still post to). Some of the content will be loosely formed ideas, some current and journalistic in nature, but most will be free of editorial constraints and will be entirely my own, with all the disclaimers that apply.
I hope you find something interesting here.