I've been surprised at being able to draw parallels between programming and music performance, writing and more. I think there's plenty in common at a high level when working on a creative project of any kind, such as your attitude to improvement, dealing with setbacks, analysing results, and the joy of when it all comes together!
Yes. The point of this article is not that you can learn something about programming by doing stand up comedy. You cannot. The point is that you can learn something about programming (by doing it) and make it memorable via analogy. In this case the analogy is comedy, but the actual topic does not really matter.
"Whenever I catch myself wondering whether this function I’m writing is going to crash or not, I remind myself to just run the tests or the app."
One lesson that often comes later in one's programming journey is that there are surprisingly, shockingly, many bugs that won't be found by just running the code. Like you're debugging one thing, and you find this other thing that has been in the shipped code for a year, intermittently causing crashes, but no one was the wiser. The "how could this possibly be working?" moment.
So, I fully embrace the idea of of incremental ground-up development, but running the code just to see if it crashes is too low a bar. Beginner versus craftsperson. I would suggest a high-value compromise is to single-step through any function that you just wrote. This has revealed a huge number of logic errors to me, even without writing additional tests. It's super low-hanging fruit that a lot of people don't even pick. I think that suggestion came from Code Complete, which although old, is still a great resource for beginning programmers. I also recommend The Pragmatic Programmer.
EDIT> Liked the article. Am also interested in standup. Also just recently had a very productive couple of evenings kit-bashing together some wood scraps where the tactile nature of holding a battery here, there, trying to orient it etc. seems to have been vastly more productive than sitting down with Solidworks or overthinking the early design.
> Whenever I catch myself wondering whether this function I’m writing is going to crash or not, I remind myself to just run the tests or the app. The terminal and the browser will always have the answer.
This is not generally true. It works if you program for fun. It does not work on critical software. It works for more programming projects than it should.
When I was a junior, I was trying to debug a piece of software. I was attaching my .NET debugger to the thing and just running line by line like a madman trying to catch a race condition.
The technical team lead had a sit down with me where we just inspected the functions and reasoned about them. It was eye opening just how fast we found the fault and the understanding I had after actually reasoning about the system.
this is great. I have actually met 3 developers in the course of my career who went from standup to programming. Those are also the only 3 standups I have ever met!! Never understood the connection until now!
10 comments
[ 0.26 ms ] story [ 31.7 ms ] threadIf Michelangelo iterated studies (in marble!) and drafts to work out mistakes and what he was doing, surely I can too.
BTW Seinfeld showed his (long) development of his "pop-tart" joke: https://youtube.com/watch?v=itWxXyCfW5s
Perhaps more important is the act itself of pondering your occupation - doing it long enough is bound to yield insights.
Zoom out far enough and any activity can have parallels to programming. Almost every activity requires concentration, planning, fear of failure, etc.
Zoom in close enough and programming in Go is nothing like programming in JavaScript.
It's all perspective.
One lesson that often comes later in one's programming journey is that there are surprisingly, shockingly, many bugs that won't be found by just running the code. Like you're debugging one thing, and you find this other thing that has been in the shipped code for a year, intermittently causing crashes, but no one was the wiser. The "how could this possibly be working?" moment.
So, I fully embrace the idea of of incremental ground-up development, but running the code just to see if it crashes is too low a bar. Beginner versus craftsperson. I would suggest a high-value compromise is to single-step through any function that you just wrote. This has revealed a huge number of logic errors to me, even without writing additional tests. It's super low-hanging fruit that a lot of people don't even pick. I think that suggestion came from Code Complete, which although old, is still a great resource for beginning programmers. I also recommend The Pragmatic Programmer.
EDIT> Liked the article. Am also interested in standup. Also just recently had a very productive couple of evenings kit-bashing together some wood scraps where the tactile nature of holding a battery here, there, trying to orient it etc. seems to have been vastly more productive than sitting down with Solidworks or overthinking the early design.
This is not generally true. It works if you program for fun. It does not work on critical software. It works for more programming projects than it should.
The technical team lead had a sit down with me where we just inspected the functions and reasoned about them. It was eye opening just how fast we found the fault and the understanding I had after actually reasoning about the system.