Its even more upsetting when you see all these stories of people that only took them 'a year' to start making a good living with it. Typically, they show the most arrogance by asserting that they have what they have because of their merit, when really the company that hired them just couldn't get anyone else that had some specific knowledge in what they were doing, or the job description was wrong, as they always are, so it attracted the wrong people. I don't consider these individuals to be developers of any usefulness outside of their scope of work, because they simply haven't spent time outside of it, so they are not problem solvers, they just look up guides online and make the same stuff everyone else makes.
Being a good developer takes time, it takes a lot of failure, and it takes a continued effort to learn.
My current view (it changes every couple of years) is that as a skillset, programming is primarily based on planning and management, most akin to logistical management and orchestration. (we're just lucky our workers are CPUs and resources are memory/bandwidth vs workers you have to individually train, and physical resources that are permanently consumed)
The focus of a programmer's work, and the skills required include:
- domain knowledge and understanding of the work being done
- developing use cases and modelling a solution, often built from well defined and understood 'components' and relationships between them (eg. factory/production, shipping/freight, warehouse/storage, storefront)
- defining processes and procedures to deal with the various states throughout the project's lifecycle
- logic and control flow through these processes including synchronization and validation
In case it's unclear, I _am_ talking about writing code, and not software development in general.
I often think of my data model as a physical system, and its behavior in terms of real world systems. As a simple example, I visualize the function processing a FIFO queue as someone working a specific station in an assembly line factory: their job is to take incoming pieces of a known, expected type and do _something_.
I find this helps me "zoom in and out" mentally, grouping things in context with some understanding of what's going on internally, while still treating it as a "black box". (eg. you can still picture what's going on inside a "factory" when you're looking at it as a whole, with several inputs and the produced output)
That's how I feel as well. Maybe it's a by-product of the software we work on? I work on IT management software and distributed control systems.
When working with control systems, the "science" part typically is in the analysis and testing phases (since we have to come up with models of physical systems). For coding itself, however, it is closer to what you describe.
> I often think of my data model as a physical system, and its behavior in terms of real world systems.
I do this too, especially when programming in Erlang. When building software systems that are modeled as a large number of concurrent, message-passing actors/processes, it readily lends itself to this "physical systems" analogy.
If you're performing, it requires you to tap into some sort of "being in the moment" type of flow that is almost the opposite of deep-programming flow. You have to be aware of the present moment while also interacting with the present moment. Getting "into the zone" while programming, if applied to performing music, is a great way to lose listeners. And if you're performing with others, you'll screw up the ensemble.
If creating/writing, music requires a kind of delving-for-inspiration I almost never have to do while programming. Early 2016 I had to solve a programming problem that didn't fit any previous patterns and wasn't googleable, and I solved that in a kind of lateral-thinking flash of inspiration, so that's somewhat close, but it's still rare compared to normal programming practice... and even then, in programming those flashes are less personal.
Programming is enjoyable in the sense that it's like both solving puzzles/problems and sometimes tending a zen rock garden. You think, you solve, you clean. And to a degree, you express. I don't really think that clears the bar of artistic, but it is manifestation and it is satisfying and it is sometimes personal so that's good too.
The post you replied to seems to be using "art" in the very common sense like the phrase "more art than science" uses it: it's an art in that it requires some type of successful human judgment and subjectivity applied to the needs of a skill. If a fancy calculator can't give an official, right solution (or you don't have this calculator if it exists) somehow that became called an art. Technically, "art" applied to a skill or craft may be the oldest definition of the word. Obviously, these things are gray areas that involve both art and science. See Donald Trump's book "The Art of the Deal" for more info.
Just a question if you see this: Why and how would "delving for inspiration" be an art or artistry? Creativity and inspiration don't seem to be the same thing. Where does the control and art come in when delving for inspiration?
Likewise, in music you have the notes on the page (a computer can even play them). You also have accents and dynamics etc. on the page that require a higher level of subjectivity but instructions/descriptions can be written. Is there another level above that? Is there a part to performing a piece of music that can't be written? Is there a name for the unwritable part?
Your first question: I think delving is more about artistry when it's personal, perhaps when one's own answer would be different than anyone else's. It's easy to be pedantic about this point, but it being personal is on the right track for me.
As for your second, I think part of the artistry of music is intrinsically related to the human element. In other words, let's say there were two recordings of performances or even an original composition. One was composed/performed by a person who felt it as they went, and another was composed/performed by a computer program. Even though it's the same sequence of pitches and waveforms, and impossible to tell the difference from listening alone, I still see the human one as different than the computer one. And if someone says, ah, surprise we told you it was human but it's actually computer-generated, I don't think that makes any kind of deep point, it's more just a dirty trick.
Anyway, the difference between those two recordings, that's the other level above that. I can better respect the human artistry that heard those sounds internally before manifesting them, than the computer program that generated them with AI and statistics.
I was rubbish at maths, but fine at coding.
It's more art than anything.
Beginning painters tend to get overly focused on very small details without having a good understanding of how they are bringing the painting as a whole together. They spend too much time on these details, whereas advanced painters are able to move very quickly with faster strokes. It's pretty amazing to see a painting where the strokes don't make sense when you look at them one-by-one, but the overall effect truly reflects something from reality.
I found this to be true also with inexperienced developers. We focus on the latest trends, micro-optimizations, coding styles, and "small" details that are easier to master -- yet we struggle with the bigger picture things like delivering a product quickly.
Kind of like the saying "you can't see the forest for the trees". (You focus on the incidental details, but not the larger purpose)
On a slightly different note, I have several friends who are writers and I have found programming to be very similar to writing a novel. You have to construct a coherent world that "compiles", e.g. the characters interactions are consistent and make sense; each character has a role in the story like a component in a program would have; simplicity and directness tend to be more effective than ornateness; small changes in one part of a dialogue can have cascading changes across the rest of the storyline, much like a refactoring gone wrong.
When I finished grad school in computer
science I went to art school to study
painting. A lot of people seemed
surprised that someone interested in
computers would also be interested in
painting. They seemed to think that
hacking and painting were very different
kinds of work-- that hacking was cold,
precise, and methodical, and that
painting was the frenzied expression of
some primal urge.
Both of these images are wrong. Hacking
and painting have a lot in common. In
fact, of all the different types of
people I've known, hackers and painters
are among the most alike.
What hackers and painters have in common
is that they're both makers. Along with
composers, architects, and writers, what
hackers and painters are trying to do is
make good things. They're not doing
research per se, though if in the course
of trying to make good things they
discover some new technique, so much the
better.
"Good judgement is the result of experience and experience is the result of bad judgement." - Mark Twain
and
"To write a good program takes intelligence, taste, and patience. You are not going to get it right the first time; experiment!" - Bjarne Stroustrup
So many coders don't do that. It's really hard to just say "Done." and click 'release'.
Then wait for the criticism.
Absolutely. Excellent point.
> Nobody tells this to people who are beginners, I wish someone told me. All of us who do creative work, we get into it because we have good taste. But there is this gap. For the first couple years you make stuff, it’s just not that good. It’s trying to be good, it has potential, but it’s not. But your taste, the thing that got you into the game, is still killer. And your taste is why your work disappoints you. A lot of people never get past this phase, they quit. Most people I know who do interesting, creative work went through years of this. We know our work doesn’t have this special thing that we want it to have. We all go through this. And if you are just starting out or you are still in this phase, you gotta know its normal and the most important thing you can do is do a lot of work. Put yourself on a deadline so that every week you will finish one story. It is only by going through a volume of work that you will close that gap, and your work will be as good as your ambitions. And I took longer to figure out how to do this than anyone I’ve ever met. It’s gonna take awhile. It’s normal to take awhile. You’ve just gotta fight your way through.
That is, code a lot of stuff. And, while doing so, pay attention to how you feel. Sometimes it'll be exhilarating, or you'll be proud of what you done. Other times, you'll be confused, or afraid, or pissed off about how something you wrote earlier is now unmaintainable or hard to make work. This is how you actually learn the insights behind all the dogmas, rules of thumbs, heuristics, good practices, etc. That's how you develop taste - that intuition which will help you write good code.