What is a developer?
Introduction
In our world these days we interact with advanced machines, machines that are the result of centuries of human tool development. They are complex and require careful configuration to ensure that they operate in the way we intend them to do so. There are many ‘configurations’ with varying levels of complexity. Take the software that runs on the machine, that is a ‘configuration’ that is instructions that tell the machine what to do, and yet that has a ‘configuration’ too, a set of values associated with the particular operational functionality of the software, the settings. Hopefully that configuration you can manage yourself from the information provided to you by the developer (or via a technical writer) on what each setting does. But what of the actual software? How is this created? What is this mysterious person ‘The Developer’?
Disclaimers
Names / logos can be trademarks of their respective owners. Please review their website for details. I am independent from the organisations mentioned and am in no way writing for or endorsed by them. The information presented in this article is written according to my own understanding, there could be inaccuracies, so please do undertake your own research. The featured image is my copyright, please don’t use without my permission.
An overview
To describe the whole process of software development would take a long time, one far greater than the scope of this post. Thus on a very simplistic level it is the process of taking an idea, a problem to be solved and solving it such that others can use the solution without needing to understand the complexities of how the solution actually works. This is perhaps true of other problems solved by professionals for others, such as Artists where we admire a painting, Chefs where we enjoy the meal, Engineers where we traverse on a train across a viaduct to get to our destination. All, I believe, follow a common process of the requirements (a set of needs to be solved), architecture / design of the solution, the implementation of the solution, testing of the solution, delivery and finally maintenance if applicable. The latter over time could be improvements and / or replacement.
Software engineering is a creative process wrapped in a framework of structure. A computer will and does perform the instructions you give it regardless of if they are correct or not. A ‘bug’ is simply a result of an instruction that we consider to be incorrect. The machine does not strictly know it is a ‘bug’, it only then performs different instructions because we in our programming of it have instructed it to do so when a value is such that it represents a fail state, a failure. Humans are not perfect, humans program and create machines and therefore no machine or piece of software is perfect. Intelligence is all about understanding the information around us and making decisions that then become actions, a process by which an outcome can be determined before it happens. Thus a human can understand the software that has been written and predict the outcome, and if that outcome is a bug, then do something about it. But how and what?
The how and what of a given element of a piece of software, code, the knowing, is attained through learning and experience, experience of success, but more of failure. To have created code, tested it, observed it failing and then analysed why it failed. The fix to a bug can be as small as a single character change. One that has taken several hours of analysis to determine the cause of the failure. Code needs to be that precise, machines are unforgiving in that respect.
With that in mind, the actual development of the software needs to be undertaken with care. We want to get things correct the first time and avoid the repetition of going back and correcting the same thing over and over again. Thus what may seem straightforward could have taken many hours to create and test. Even the testing process can be code that automates the process so that verification can be repeatedly applied. By its very nature, repetition is something we as humans don’t do well, we’re dynamic and adaptive to the environment around us.
Each developer has their own style, one that’s attributed to them. Little nuances that define that person’s creation. The style from a computers point of view doesn’t matter. It does matter to others though as often it needs to be understandable as they may need to maintain it in the future or help you fix a bug that you can’t solve. It happens, we stare at a problem and then need a fresh pair of eyes to see what’s right in front of us all of the time. When writing code for or in a group, there can be a coding standard or style guide for all to follow, such as Moodle’s ‘Coding style‘. Using or being constrained to such can alter the developers own style. For instance I have noticed that since writing Moodle code I have gone from placing the opening scope curly bracket ‘{‘ on the second line of a declaration to the declaration line itself. I do find it frustrating at times not to be able, generally, to use camel case but less so as the quantity of the Moodle code I write increases.
Therefore a developer is a creative problem solver, one that is both artistic and at the same time constrained by the very nature of a machine. The little details really matter, otherwise there is failure.
When you interact with software, consider this. Behind every single element is a person. Somebody somewhere has thought about that element. Indeed the element is likely to have been thought about by many people. Even failures are a part of thought, just an unexpected outcome of one.
With this all in mind when learning how to use software, think about what the developer was thinking at the time. What are they communicating with you, the user, how you interact and use their creation? That will then help you to understand and use the machine as a tool in your life to solve your problems.
Me
I have been programming / developing ever since I first got my hands on a computer in the early 1980’s, a Sinclair 16K ZX Spectrum, a birthday present from my Mum. With exposure at school to a Commodore Pet and a Sinclair ZX81. Since then I’ve gradually accumulated skills, knowledge and qualifications. I’ve witnessed the progress of technology. One that given its speed can be difficult at times to keep up with. I’ve gone into and exited teaching. All the time finding and returning to what I enjoy doing. It frustrates me at times, and yet the rewards and feeling when it works is great. That you’ve achieved something, it works! You have climbed that mountain and seen the view from the top.
I don’t share all that I create, especially what I’m not happy with, hasn’t been finished, or is there as a part of my knowledge reference specific to me. Though what is the point of creating something if it is put to good use by others?
I’m tend not to be put off or scared by computer problems, but rather attempt to understand in a calm manner what is going on. If you fear something then that only clouds the issue preventing you thinking clearly. But feeling fear is a warning to you that caution should be taken before proceeding, and have learnt to be cautious with certain tasks.
As a developer there is so much that you know, more so than often can be coherently explained in a concise manner. As such, I’ve discovered that I’m far better at answering questions than attempting to guess what I think you need to know. With that being really a perception and understanding of the journey I have undertaken to get to a given point, but as concisely as possible. The material I’ve created and presented. Perhaps other developers are the same? Given the adage ‘There are no stupid questions if you don’t know the answer’, then when you don’t know, ask. I do, I don’t know and never can know it all so I’m not afraid to ask.
Conclusion
Developers are not that mysterious after all, just with a set of knowledge and skills that appears to make no sense to others. But then that could be said of any professionalism that has its own terminology and processes.
I hope what I’ve written has helped you to understand what a Developer, a ‘Software Developer’ actually does.
- Debugging SCSS – 16th November 2024
- Settings transfer – 16th October 2024
- Added value – 16th September 2024
Wow – so cool to read these perspectives !
So much discussion about job roles, experts, and AI these days.
I tend to relate it to my music.
Years ago when drum machines became common, no-one really cared about drummers – everyone (most) said “Cool, I’ve got some technology that makes it easy to have drums now.”
Synthesizers did the same for keyboard players, and with some skill and technique one can have a symphony orchestra or a Saxophone – completely convincing. Guitars have been harder, but possible now.
And so we come to all the debate about AI “singers”. And now so many people are complaining. But popular music consumption has been dictated by record companies, and now streaming services anyway.
Things change. People adapt. But all too often we adopt technology without very much thought, like the people who say “I don’t care if Google or Facebook spies on me, I don’t have anything to hide.” But that was never the issue – the issue was “When did you give them permission to do this?”
I think the EU is doing well, in fighting back against the tech giants.
Anyway, I’m kinda glad I’m not a developer 😉
Thank you. Interesting point with AI, in that its now writing code solutions. But then I believe that you still need the human in the loop with the depth of knowledge and understanding to know that what has been created is viable and correct, to ‘verify suitability for purpose’.
Privacy is another matter though, and I would imagine (I’m independent so make my own decisions) that the developers implement what has been specified by the respective company. Thus that is more of the commercial elements of the business rather than the technical.