The field of “computer science” is much lauded. In this academic domain are such heady topics as order of execution, computability theories, and even quantum computation. While I applaud the study of computer technology as both necessary and beneficial, I don’t see myself as a computer scientist. Rather, my field is software development; in essence, it is applied computer science.
The difference between computer science and software development is in goals. The ostensible goal of computer science is, like any science, to extend people’s knowledge and understanding. The code produced during these efforts is far less important than the knowledge it represents. By contrast, in software development, the goal is to automate or enable a business function, and the code one creates often lasts for years after the original developer has left.
As I am a software developer, I tend to view scientific efforts with curiosity and the tiniest bit of amusement. Firstly, I find it hard to understand a methodology or technology unless I understand its application. The idea that we have a body of knowledge which we can call computer science is hard to take seriously when you compare the field to more mature sciences like physics, math, or geology. If we are generous, we might place the age of computer science as it is known today in its seventies. Compared to other sciences, we’ve had only a fraction of time to mature our understanding. But I feel that as software developers, we want that prestige that comes from being scientists.
Of course, this is not meant to knock the science. The most important things I’ve learned about programming, I learned in school. I simply happened into a career that isn’t actually about programming. Perhaps it’s counter-intuitive that software development is largely not about writing code. But ask a seasoned developer how many hours a day they spend in meetings and compare that to actual time at a compiler. My experience has been that the former is quite larger than the later.
If we are to be successful software developers, we need to learn when and how to incorporate the lessons of computer science into our work, and to be diligent about increasing our understanding of what our field is really about.
Take for instance, the aforementioned meetings. If one is to be a good software developer, one needs to be good at meetings. What does this mean? How many developers have any sense of what is expected of them as pertains to meetings? These are questions that few degrees in the computer field will cover, yet they are as important as determining the O(n) execution time of an algorithm.
One of the reasons developers get paid so well is because the breadth and depth of knowledge the job requires. It goes far beyond the clerical task of writing code. Developers are expected to make assumptions, suss out requirements, troubleshoot production issues, suggest new features, and know the length and breadth of computer technology. And those are just the explicit responsibilities. The unstated ones include working extra hours the days before a launch, advanced writing skills (in e-mail, reports, and presentations), having a good sense of the market space their products reside in, and others too numerous to list here.
In my experience, the most harm in software companies comes from software engineers who want to be computer scientists more than they want to produce working code. These people have an interest in new frameworks, starting over, designing by configuration, “scalability”, adding code to support business models that the business doesn’t need, doing it “right” the first time, and implementing the latest cool buzzwords (“federated”, “cross-cutting”, “ISP” – anything that looks like they’ve read a computer-centric business magazine). Each of these is a fallacy large enough to deserve its own article.
These poor souls are deluded. They believe that if they can just write code perfect enough that they wouldn’t have to do all the other things that makes software development a difficult job. They often want to be architects for their business – a job role that I personally think should be abolished – because this has the dual benefit of getting to feel very smart and important and of never needing to be responsible for actually coding. But only by balancing our desire for well designed, highly performant code with the needs of the people for whom the code is intended (and who are almost uniformly not actually interested in the code) can we be successful software developers. Forget that, and one soon loses the very reason one is writing code in the first place.
Until next time,
Practice Makes.
You obviously don’t want to make money. Unless the ‘architect’ owns the company, they are there to please the owner and collect a paycheck. If having a brain wizard on retainer pleases the owner, so be it.