Yesterday, as part of a kick-off presentation for the year, I reminded my team: coding is less than half of an engineer's job.

An engineer's role is to engineer solutions. Writing code is certainly a part of that, but as a means to an end rather than a purpose in itself. If an elegant, scalable solution can be engineered without writing code, fantastic. Conversely, if code is written without exploration, reflection, documentation and validation, or if a solution is built to an imagined problem that doesn't really exist, we're in trouble. Communication, exploration, and collaboration are the biggest parts of the job.

Lots of people get into engineering because they love to work on code. The feeling of building something from nothing is exhilarating: I'm far from the first to note that it's similar to how artists manifest work. But that's programming (or hacking); engineering is a discipline unto itself. There's a popular conception of engineering as being a job you take if you don't want to talk to people, or don't like to write, but neither thing is true. The best engineers are highly social and write to a high standard, as well as having great coding skills. That's because engineers rigorously architect systems to meet their requirements; hackers understand the outcome of what they're trying to build, but their process is more artistic.

I think both spirits are worth embracing, but it's important to accept that they may be embodied in different people. Holding onto the joy of hacking is important; I lost it for a while, and it took literally years to get it back. But engineering requires a different kind of diligence and attention to detail. I confess that I don't think I was really, truly an engineer until I went to work for Medium - and maybe I'm still not one. I could certainly build software (Elgg, Known, Latakoo, a bunch of other things), but my process and discovery skills were underdeveloped. Some of the people I met there, and have met since, were not hackers - they built code rigorously and to a high quality, but had never really built something for the joy of it. For others, it was the opposite; some people fell in the middle. The two things sit side by side but are different.

The trick, I think, is to build the right processes such that engineers take bigger risks in their explorations, and hackers use more rigor. The goal is a creative, detail-oriented team that finds the best solution using the full weight of their diverse skills and creativity, and has fun doing it.