Software Development Is More Than Coding
“What language should I focus my efforts on?” It’s one of the most common questions I hear when talking to aspiring software developers. When the question is posed they are disappointed that most senior developers refuse to give them a clear answer. Basically, the language choice itself is relatively minor compared to all of the other things you need to focus on to grow as a software developer.
(To be fair, the question really boils down to “What language has the most demand (and therefore makes it easier for me to find a job)?” In that case, the answer is best obtained via a quick search.)
Frederick P. Brooks, Jr.’s classic essay No Silver Bullet — Essence and Accident in Software Engineering is one of my favorite essays found in one of my favorite development life cycle-related books, The Mythical Man Month. His fundamental argument is as follows:
There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity.
Technology, in the above quote, includes programming languages. There really is no “best” language to learn. Some are easier to learn then others; some are better suited to particular tasks; others suit programming styles in ways that please particular developers.
Dr. Brooks goes on to say:
I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation. We still make syntax errors, to be sure; but they are fuzz compared to the conceptual errors in most systems.
To put it another way: writing the code is the easy part. Specification, design, and testing are the real meat of software development. These are the tasks that are both difficult to teach and difficult to learn. Teaching to write code, in comparison, is relatively simple.
Dr. Brooks goes on to cover some of the hopes for the silver bullet. In one of them he even alludes to writing comprehensive tests (he calls it program verification).
More seriously, even perfect program verification can only establish that a program meets its specification. The hardest part of the software task is arriving at a complete and consistent specification, and much of the essence of building a program is in fact the debugging of the specification.
(Emphasis added.) Again, Dr. Brooks concludes that the “essence” of software development is in refining the specification.
What is the takeaway here for an aspiring software developer?
In my humble opinion, the best developers are good communicators. They may not know how to write a doubly linked list from scratch but they can take a incomplete specification and:
- Conceptualize how it will work
- Refine the specification to make it more… specific.
- Identify traps that may cause errors in communication
Don’t spend too much time deciding what language you should learn. The real meat of software development is problem-solving. Find a problem. Solve it. Doing so might even involve writing some code.
If you haven’t read it, Dr. Brook’s essay is online in it’s entirety. Even though it was written in 1986, it’s still very much worth a read. At 16 pages, it won’t even demand much of your time. Find it here.