I remember getting a book as a teenager that had all sorts of pseudo-religious platitudes about becoming one with the code.
And I thought it was cute, but laughable horseshit.
It's one of those classic programming texts that was circulating back in the early days of PCs, and most people into computers at the time remembers reading. Over the years, I've often misremembered it speaking about how a junior programmer struggles to produce any working code, how a senior programmer works hard and produces much working code, but the master deleted code and features sprang forth from the act of culling. Re-reading, I'm pretty sure this was never directly stated, but it was a take-away that stuck with me.
As I've gotten better with age (cough, cough), I've realized that writing less code that does more is a critical skill of a top developer: I've been asked to help numerous companies fix failing projects. A lot of what I end up doing is optimization. The simplest, most effective kind of optimization is to stop doing something. The next simplest kind of optimization is to do the same thing faster. There are limits to this approach, however. And then, the hardest kind of optimization is to do something differently. What separates a junior developer and a top developer is the instinct to know which is appropriate to apply in each situation.
Story of a Job Interview
I had a really interesting experience when I applied for a job at Electronic Arts some years ago. They apparently gave every programmer the same programming test, even to old hats like me. Grumbling a bit, I took to the test and was amused when it had a dozen or so simple programming problems to solve, a real compiler and code editor setup so you really had to write some code. There was a test harness to check your work quickly. It was a glassy smooth development experience, even if they were unfamiliar tools.
I stopped at problem #5 and glared at it. Estimating the complexity of the problem, I immediately skipped it and finished the rest of the test. By the time I was done with the other problems, my time was just about up. The manager returned to the room and I told him I'd skipped that question, because it looked ridiculous. He smiled at me, and told me I passed. He didn't bother looking at the test results. He said a lot of programmers find the problem curious and appealing, and will spend more days trying to come up with a solution to the problem, only to struggle and realize how difficult it is to get right. Sometimes, following curiosity instead of providing value is not a virtue. You will undoubtedly learn something, if only that some problems are harder than they are worth to solve.
A Different Job Interview Story
I sat in the offices at the Googleplex, at maybe my third interview room of the day. It was gorgeous, brightly lit, with friendly and clever people buzzing around everywhere. The interviewer was an extremely intelligent and technical woman with intense eyes. I felt like she could read my elevated pulse and was judging the voltage of the electrical discharges in my brain. She handed me a marker and sent me to the whiteboard with a programming problem... a relatively simple one.
I sketched it out, broke it down, and wrote what would have been an acceptable way to structure the problem. She gave more limitations, more restrictions. I made a few small changes. She rejected them, claiming it didn't solve the problem completely. I added a few more small changes, improving the solution slightly. She rejected them yet again, agreeing the solution was better, but not a complete solution. I turned to her after a moment of consideration and said, "What you are asking for is not possible, but this is the best you can do." She was very satisfied with that answer. Sometimes, you have to know what you can't do to know when to stop working on a problem.
The True Tao of Programming
Now that I'm officially old and am allowed to be crotchety, I have found some truth to the old Tao text. After you really grasp logic development as a way of life and have built complex and interlocking things, the effort of programming starts to melt away and you start to see intractable problems purely as Gordian knots to be cut rather than untangled. When you have attained that ability to size up the solution to a problem, what you're really measuring is time. I know now that I could solve many problems, perhaps any problem. The cost, however, is the time it would take to implement and verify the solution. A mediocre engineer will think of a problem as interesting and spend an absurd amount of time trying to solve it, and perhaps succeed. A top engineer can imagine the solution of the problem, then ask the seemingly basic question, "is it worth even bothering to solve this?" Because there is an opportunity cost in spending effort on one problem when another might be solved instead, that has greater value. I would posit that the best programmers are excellent at selecting valuable problems, not just writing great code. This skill requires looking outside the confines of the programming environment, constantly measuring value gained in the organization as a whole, in human time spent in a poor workflow, or making an error-prone task more correct or automated.
If you are a less-experienced developer, you should learn to ask your manager and more-experienced developers this question: "Is this the most valuable thing I can be working on right now?" Remember to ask why, and learn from their answers.
PS. For the curious, both interviews were successful, and I politely declined for various reasons.