Code monkey versus Engineer?

In BelTech this year I had the pleasure of co-organising a section 'Software Engineering, not Coding' with Dave Anderson, Director of Technology, Liberty IT Belfast. It inspired the article below which encapsulates the theme of the session. What a joy it is to write code; it's not just about writing if statements and while loops, it's a thing of absolute and total beauty. Getting the perfect structure, good comments, bringing together the exciting technology it just fills us with a sense of satisfaction. Like a good painting, if we can sit back at the end of the day, take the headphones off and admire it, that's what it's all about. But is your code actually useful or is it more like a square peg in a round hole? Coding for the satisfaction of development and sharing your code with other developers is a great endeavor, but code is just part of a much bigger picture which really exists to facilitate a greater good, you're ultimately doing it for a user, a sponsor or cause. The expectation of users and industry today are changing at an almost exponential rate combined with a significantly more complex technical landscape. The services we're delivering make a real difference to business success/ failure, to individuals who depend on it for health reasons (e.g. Telehealth services) and everyday activities like communicating with friends. We cannot underestimate the challenge this presents; the pace of change and level of quality demanded is not easy to meet, and we know you want to meet it. Whilst the practice of Software Engineering is changing, the principles are more important than ever. We all love coding, but it takes more than coding skills to engineer great software and that's the really hard stuff. The reality is that there's no single approach which will magically result in code being translated into successful systems. But there are magic questions. Ask, be inquisitive, understand why and you suddenly multiply the probability of achieving real value. We have increasingly noticed that the hardest skills in Software Engineering are not technical. It's relatively easy to learn the syntax of a language, it's really hard to know when you should (and shouldn't) use that language. How you can make your product easy to maintain and extend. Will your solution fit your company business model? Will it even solve the correct business problem? You could mistakenly think 'my architect will solve those problems', but every Software Engineer must think about architecture. It also takes a huge amount of collaboration to learn these techniques. Often you learn them from a mentor in your team often this is not the team lead, it's a senior engineer with lots of scars. Coding is a solitary act, but Software Engineering is a team sport this is partly why Agile adoption has been so rampant. Team dynamics are always difficult and we need to get beyond the code to guarantee success. You sometimes hear non-technical people say 'this language will be faster as there's less of it to type in'. Well yes, it's a little like saying E = mc ? is simple because it's short. Anyway, having a north star is important in software engineering and it's usually a business problem that is not that clearly defined. There are many factors to consider and, unfortunately, writing the code is the easy part. "The hardest single part of building a software system is deciding precisely what to build." ??- Frederick P. Brooks, The Mythical Man-Month Here in NI we are a hub for some of the best software development in the world, this is all down to great engineering skills, with individuals taking ownership and being part of the solution. As the challenge and demands get bigger, as our community expands, it's key to keep applying that questioning mindset, collaborating and evolving solutions. That's really Engineering solutions, over coding. Thanks, Aislinn McBride (Kainos) and Dave Anderson (Liberty IT)