Cutting Corners
I place a big value on personal improvement. Software engineering isn't just about making better tools, processes, and organizations. Those things are important, but at the end of the day nothing works right without talented people, and we as engineers have the responsibility to improve ourselves.
I've made a couple observations in my years of programming:
Engineers can bang their heads on problems for days or more only to discover that the source is one class, one function, one line, or even one character defect.
A commit often has a very small size when considering the amount of time an engineer works on a feature. The end result of 3 weeks of work may result in a depressing diff of 200 lines of code.
What, at the end of the day, is the boiled down end result of these situations? If you are a black box, and we put a spec and time into the black box, what do we get out?
The code changes in the commit
Hopefully the engineer gained knowledge about the system
Granted, there are a few more less quantifiable outputs. Perhaps the engineer reduced technical debt while implementing a feature, other engineers gained knowledge while helping architect the new system, or processes were improved as a result of the debugging scenario.
But I have to imagine, wouldn't it be nice if the programmer cheated and already had the diff ahead of time? Maybe they googled "C++ code for sparse AI graph" and somehow google knew their files and line numbers and instructed them where to put them. Well, this is great, we just need to give our programmer enough time to type in the lines, or better yet, just use copy-paste, and they will be ready to commit. Skip the two weeks of white-boarding, writing and re-writing functions, compiling and running over and over to test, peer reviewing, and all the time that programmer spent spacing out on Reddit, the task is done!
It's too bad that programmers SUCK. They can type so fast but they have to spend all this time THINKING to make their commits useful.
In the 1980's, John Searle came up with a thought experiment called the "Chinese Room Experiment". There are many interesting discussions that have originated from this in the AI space; however, I've been especially intrigued by its relationship to how we humans work and create. I can produce the same end result of a genius by duplicating their code or algorithm from a textbook, or following their described train of logic without original thought. In grade school, copying test results is cheating, but in the real world using the fundamentals of physics or science as discovered by past geniuses is a prerequisite for many careers. What power we have by sharing information!
Thinking about this sometimes I get lost in questioning what ownership of knowledge really is. In algorithms, creativity is often sub-optimal when an existing solution is already known and exhaustively tested.
Following this thought, I believe you should continuously question if what you are doing is truly valuable. Is your time well spent right now? Are you either producing more worthwhile code OR gaining useful knowledge about the problem? If not, you are being unproductive. Be hyper-critical of yourself and watch out for your mind tricking you into seeing value in waste.
I found it profoundly insightful to record my screen when coding and record audio and speak aloud when brainstorming or white-boarding. After solving the problems to my satisfaction I could go back, replay the recording, and notice the inefficiencies. When I write code then quickly delete it. When my cursor is blinking, standing still in the middle of your screen. What am I doing, thinking about the problem? Thinking about the right solutions? Wrong solutions? Drifting off? Why do I stop coming up with ideas when I am brainstorming? What's blocking my brain from moving onto the next idea? How many times did I re-compile only to get hit with errors? How long did I spend building? Testing? Correcting?
If you do this too, you will find many minutes of yourself doing important things. You ARE designing good functions that will be more maintainable in the future. You ARE seeing flaws in ideas that looked good at first glance and discarding them, making your commit better than it would ever have been from jumping in too quick. You ARE correcting mistakes when testing your code.
But at other times you are doing a bunch of… nothing. You weren't perfect, you re-wrote a single line of code 10 times because you kept forgetting how it worked. You stumbled on syntax. You considered an architectural decision that you really should never have even thought about because there was an obvious choice there all along. You spaced out for 7 minutes thinking about your dog at home. You used == instead of != and had to compile and test 4 times to realize your mistake, in fact you've done that same thing a half dozen times this year. You just blanked out.
It's impossible to clean out all the crud. Most of the time, you aren't replicating A Beautiful Mind, solving incredible architectural puzzles and creating a masterpiece of new code. A painful amount of time is spent walking down dead ends and finding your own mistakes.
Yet, gradual, focused improvements do pay off. If 30% of your time was truly attacking a problem productively and getting your code to production, that means you have space to be 3x more the programmer simply from improving on this sub-problem.
This is about working smarter, not harder. Focused practice is integral for athletes, e-sports competitors, artists, and professional thought workers as well. The difference is, an athlete will focus their practice to get 10% more strength, whereas for a thought worker, doing the right thing is far more important than how fast you can type. Spending time wisely is the dominating factor in your productivity, and it is in your control.
