Today I asked myself the question: Now that I've established the beginnings of a career in programming, what is my motive for continuing to devote time to studying computer science?
Here is my answer:
The joy in programming is about craft.
Craft is a deep topic in and of itself. For now, let's say that it has to do with the intrinsic reward of a thing done in it's own right. Craft relates to that universal appreciation for the beauty of a thing done well.
Depth
I think it's great that you can go a long way into the field of programming without ever touching the theoretical aspects. That makes room for bright, talented new people from all kinds of backgrounds to join in a fairly lucrative and deeply rewarding field.
However, to develop a truly justified confidence in one's software design choices, a developer needs to see past the surface of the field and into its depth. It would be impossible for any craftsperson to really enjoy their work fully without an informed degree of confidence in the the quality of the results.
One could learn the basic syntax of a dozen programming languages and work on a slew of different web applications over the course of a decade all whilst remaining eternally a novice. Depth is the precise difference between this person and someone who demonstrates authentic understanding and lucid competence in their design choices.
Tangibility and Abstraction
Many programmers get hooked into the field by the awesome reward of getting a simple program to work and produce a satisfying result. The tangibility and immediacy of this makes programming accessible and fun. It's a great help to us.
However, to really understand programming we also need to develop a taste for understanding it as a fundamentally abstract mental discipline. This is really the evolution from "coding" to "software design." The reward in that mental discipline is different from the fun of getting a neat result quickly. It's a much slower and more profound reward that is characterized by the feeling of truly grasping a beautiful or interesting idea.
A programmer engaged in software design (which is, by definition, any programmer) is a very interesting kind of craftsperson. This is a craftsperson whose design artifacts hang somewhere between the abstract and the concrete. The programmer both embodies theoretical models in concrete form (coding) and distills theoretical models from some less precise set of ideas (software design). The need to morph between different ways of thinking leaves the programmer with much to do and learn in this life, but isn't that kind of challenge exactly what we like?
Top comments (4)
Awesome point of view, i agree with it.
Arts, Music, Computer Science and others fields that involve craft made people remains by the satisfaction in the process.
I really enjoy programming, design data interactions, thinks about user perspective, improve older solutions.
For example i'm reading/studying an "Introdutory book" although already working with programming:
amazon.com.br/How-Design-Programs-...
Why ? Several posts, peoples talks very well of this book, top books of computer science incited my interest. Start read a little and the preface got me.
Really belive that it grow my computer science mental model more than only tutorials (this has your moment).
Thanks for your post. Made me more confident in the way guide my carrer.
Wow! I really like the approach this book takes. Thanks for bringing it up
I’m preparing to teach an introductory programming course and I’ve been looking for good resources on aspects of computational thinking and software design.
Thanks for your comment!
Nice post. I am studying computer science in college so as to get an in depth knowledge of the field and I can relate with this point of view. Currently I'm taking a Distributed systems class and I have been introduced to new ways of thinking about problems and also learning how the biggest companies solved their scaling problems!
Distributed Systems is a really neat field. I only know the surface of it from building microservices at work, but I’ve read a few papers that were useful for handling large audio processing jobs in parallel across multiple servers. Really great example; that class probably helps with thinking about system design and machine utilization in general. Thanks for your comment!