As a software developer, it is reasonably common place that when you answer the question, "And what do you for a living?", it is sometimes hard to actually explain the essence of what we actually do. It is not uncommon for people to glaze over a bit as they are just thinking "oh, something to do with computers." It made me think, what is it that we enjoy and get a kick out of while we write code, and are there analogous aspects to other jobs? I reckon that the writing of code is simply the means for us to build something, and that is the crux of what we do and why we enjoy it.

Personally what I strive for each day is to build something and get the satisfaction of making something work and do a task. It just so happens that the end product is just not a physical, tangible item that you can touch and feel. I then thought about how I get the same feeling of satisfaction when I build something that is tangible and real. This has led me to try to explain what I do using an example of building something that everyone is familiar with: a table.

I try and explain that I build things and that software development is a creative task and that there are many trade-offs that need to be considered when designing and engineering it. For example, if I was asked to build a table, then I would need to consider that there are many types of tables and that the purpose or user requirements of the table will require decisions in regard to design and implementation. You could say that a table has fairly limited functionality and if its task is to simply hold drinks at a party then it might be completely appropriate to just get a sheet of plywood and some sawhorses. Job done. However, what if there is a possibility that someone might get up and dance on the table? Perhaps the original user requirements might have been incomplete in this regard, and it might be necessary to actually reinforce this sawhorse table with some screws and pegging down the legs. I think when building software we often have to read between the lines and think ahead a bit in order to add things that were not specified. I guess in a software sense this sort of a table would be equivalent to a bit of a hack, like a quick once off use of Perl script to do something, which may be completely appropriate depending on the purpose and who is going to use it.

Then, if you think of the other end of the scale further along this analogy of table building, you could, in fact, construct something that is much better. It could be better engineered, have beautifully lathe turned legs, and maybe even carved inlaid timber in the table top. You could make it super strong and look like a piece of art. This is also an appropriate direction to take if the requirements were for something permanent that would be on display in a home and be handed down through generations. It is true that this table would also work for the party scenario but might be considered a bit over-engineered in this case. You wouldn't build a table that could be considered artwork for a party and then put in the shed to use as a workbench because you have no room for another dining table in the house.

Those are examples of extremes of the quick hack and an equivalent full-on, do everything framework level software development. Both have their purpose in the correct context. I think that in most instances a normal software project will usually fit somewhere in between those extremes. Something that is robust and fits user requirements, and is attractive to look at, but maybe not quite at the level of a piece of art. I think that those design decisions are what we do all the time, trying to pitch the correct level of engineering that is fit for the purpose.

I also firmly believe that what gets us out of bed in the morning is the innate satisfaction of a job well done. Whether it is building something tangible like a table or a nice UX workflow, the personal satisfaction is the same. It is the creativity, engineering, and job satisfaction that I love about software development as a career.

So, next time you are at a party and someone asks what you do, try and explain why you do what you do, and try to align it with something that is not quite as foreign to them as writing code.