Many a time I find others struggling to understand my job as a Software Developer. It seems that for outsiders Software is some opaque concept with some impassable level of knowledge required to understand it.
This is so far from the truth, it's frustrating.
Often I can be found coding something in the lounge of my suburban London shared house; it could be a project or my personal website, for example. Sometimes my housemates will glance at my screen full of code and make comments in passing such as, "it's all <insert foreign language here> to me!", which is fine in jest of course. But the subtlety that gets lost in translation is that Software can be incredibly simple and in fact simplicity is a goal that developers should aim for.
The simplicity I'm referring to is conceptual; the Software's representation (code written in some language) may give it an air of impossible complexity and diving head-first into the code of a complex system would leave most developers with only a vague (if any) understanding of the system's inner workings. Conceptually, Software should be easy to describe [to new developers] if there's to be any chance of it being maintainable.
The more I think about this, the more I ask the question "what is X to outsiders?" for a given domain X. There are many examples where a domain is so commonly exposed to society through entertainment or tradition or otherwise that it becomes common knowledge what being a domain expert means. For example, everyone knows what Baking is and most can probably say that they've even done it at some point in their life. As another example, most people can probably have a good go at describing a day in the life of a Lawyer. But most outsiders of Software I've talked to know only the bare minimum, that is we "make" software.
This same problem has at some point affected my working life. There was a time where I was tasked with developing such a vague system with so little time in which to do so that the end result turned out to be not very useful. The clients who asked me to develop the software gave me very little specification of either problem or system; I was very much in the dark. The only problem description to go on was "analyse trends in the data". A few assumptions were made in the process of outlining the project including misinterpretations of both Data Analysis and Big Data. This is a classic case of domain non-experts loosely defining a system.
This experience taught me a lot about what is expected of the Software Developer and importantly how to manage the expectations of outsiders. It was my honest opinion that a potential solution in this scenario was to use an existing system (and probably change my own job description to that of something closer to Data Analyst). I told the clients this up-front, but the constraints on the project were concrete so we met half-way.
To summarise, the issues here were:
- Incorrect assumptions [of Software Development] embodied in the project description
- Lack of clear picture of the final system
- Unclear purpose of the final system
The question I ask myself is how many of these can be solved in the process of developing the software? Furthermore, should the Software Developer be responsible for defining the clear picture or the purpose of the final system? Do these questions depend on context and would a clearer understanding of Software give non-experts the ability to better define work to be done?
Perhaps this was a simple lack of communication between the domain experts and the clients. Even so, the ability to communicate the boundary between project description and project seems to be something gained through experience.
This is my take, what does the dev.to community think? 🙂
(Feedback on this post in general appreciated, this is my first - I'm open to criticism)
Top comments (0)