There are many subtly different twists on the job title that “people who write code for a living” might associate with – developer, programmer, engineer are the main three I see. Personally, I self-identify as an engineer. I’m actually from an engineering rather than computer science background, specifically I studied a branch of mechanical engineering, but at one point almost studied chemical engineering. The key distinction is that an engineer’s primary focus is on solving problems, often built on the foundation of the findings of scientists, whereas a scientist’s focus is more on research and theory. The two professions are intrinsically linked; without advances in sciences, engineering would eventually stagnate, but without engineering the advances in science would probably not make it into mainstream society.
For me, a “programmer” or “developer” identifies someone whose focus is on writing code; it’s all about the how rather than what or why. An engineer would think in terms of finding the best way to solve a problem – whatever that may be; a programmer or developer is likely to think in terms of fitting the problem into software. Sometimes, the best solution to a problem is nothing to do with code or technology! As an engineer, technology is a means of delivering a solution to a problem, rather than holding much intrinsic value. As a software engineer, I describe myself as “someone who solves problems, often by writing code”, rather than “someone who writes code”. While it’s kind of cool to write a particularly elegant algorithm or structure codebase in a particularly clean way, what really gives me a buzz is in seeing people gaining some time back (or more direct profit) from my efforts to solve a problem and streamline a process. That’s my inner engineer.
I’m very curious about new technologies or new methodologies, but, as an engineer, this is always framed by the question “how can I solve problems with this”. It doesn’t matter to me how “shiny” something is, I’m looking for things that can fit into problems I or my clients are actually trying to solve, or for things that I can “keep in my toolbox” for next time a certain type of problem comes up. The interest isn’t from the technology for its sake, but from how it can be used.
I enjoy working with lots of different types of business, and seeing lots of different types of problems, and I enjoy applying engineering principles to processes. My primary motivator is in finding effective ways to do something; I passionately hate following a process for the sake of it if I can see a more effective way to get the same thing done, and my instinct is to look for those ways. In exams at school, I was always the last to start writing, but the first to finish – instead of diving in, I would first take a moment to look through the whole paper and think about the most effective way to answer it. When I worked in summer jobs doing data entry, I would work out the absolute leanest set of keyboard shortcuts to get the outputs that mattered as efficiently as possible. I worked in a call center one summer, and I would hone my “script” and compete with myself to get through all the essential details in taking an order in the shortest possible time. The field of software engineering is great for me, because there are so many opportunities to apply this instinct. I can look at efficient algorithms or data structures, but I can also take a step up from that and look at the real-world process that the software system is there to facilitate. Recently I’ve spent most of my time looking at a different form of the same theme, looking at how software teams can deliver more effectively.
In the world of writing software for businesses, I think it’s vital that teams have at least some “engineers”. The role of these “engineers” in a team is to make sure the team are writing software for a purpose, and solving the actual problem at hand. The danger of entrusting the direction of a project to “programmers” – people whose primary motivation is technology – is that the focus can be misplaced. There can be a temptation to try to squeeze shiny technologies into a solution, or to put too much effort into parts of the stack that aren’t the real reason the team are there. There is value in this kind of research mindset; we all need people to be pushing the frontier of technology forward. However, the time and place for this is not in a business, it it’s to the detriment of achieving business goals. There’s a balance to be struck, because sometimes experimentation and new technologies can give a massive boost to a project, and too little experimentation has a high opportunity cost. It’s about making sure the split of time is right, and making sure that experimentation is scoped appropriately. It’s also important when experimenting to know when to kill off an experiment, like where it is proving more difficult than expected or showing less benefit than expected. Teams should discuss and set goals, and experiments should always support these goals. If it’s not a problem, you don’t get to solve it!
A great way teams can encourage an engineering mindset is by having discussions at the right level. If the team sub-divide into business/delivery, where the delivery team’s role is to unquestioningly deliver requirements that are handed to them, than the engineering mindset is suppressed. This is massively wasteful, because engineers can offer a great deal of insight into how to solve a problem, and if all the thinking is done upstream this insight is thrown away – which can also be a big demotivator to delivery teams, who will feel like “code monkeys”. The best products I’ve delivered have taken the business knowledge of the problem space that product owners bring, and combined that with the engineering knowledge and process design insights of engineers. If the product owners and business analysts are able to present a problem, still to be solved, and involve the delivery team in the design of that solution, then the outcome is normally vastly superior.
It’s also really important that engineers understand and are familiar with the problem they are trying to solve. I’ve worked with 2 large retail businesses: one of these had their warehouses 150 miles away from their development office, and the developers often spent less than half a day with the main business for their induction. This did include a whistle-stop tour of the warehouse, spending about 10 minutes with each department, mostly as a meet-and-greet of the managers, who were deemed to be the stakeholders. In the other, the developers were on-site, and had unfettered access to every area of the business; they were literally able to walk away from their desk and spend an hour packing boxes whenever they felt like it. The teams were both delivering very similar projects – software that managed the order fulfilment workflow – but the solutions that were designed were vastly different! The team who had no access to the business didn’t deeply understand the real-world flow they were modelling, and built software that went against the grain of what the real world users were actually trying to do. There are physical actions behind the things the system is modelling, such as walking around a warehouse picking stock from shelves, or preparing items for dispatch. Understanding how people actually do these things allows the software model to focus on the right things.
If you’re in a team who are too distant from the business problems to do a good job as engineers, a great “next step” is to try to find ways to bridge that gap. Ask more questions about why a feature is needed, about why it helps and what it helps with. Try and find a way to get direct contact with end users, and understand what they are trying to do. See if you can get involved earlier in the lifecycle of features, and shape the solution design above a code level. It can be very valuable to all involved, and open up a whole new way of thinking.