I haven’t watched the video yet, but I was instantly reminded of the Alan J. Perlis quote he and Abelson used for SICP’s dedication:
> I think that it’s extraordinarily important that we in computer science keep fun in computing. When it started out, it was an awful lot of fun. Of course, the paying customers got shafted every now and then, and after a while we began to take their complaints seriously. We began to feel as if we really were responsible for the successful, error-free perfect use of these machines. I don’t think we are. I think we’re responsible for stretching them, setting them off in new directions, and keeping fun in the house. I hope the field of computer science never loses its sense of fun. Above all, I hope we don’t become missionaries. Don’t feel as if you’re Bible salesmen. The world has too many of those already. What you know about computing other people will learn. Don’t feel as if the key to successful computing is only in your hands. What’s in your hands, I think and hope, is intelligence: the ability to see the machine as more than when you were first led up to it, that you can make it more.
I’ve learned that aiming for perfection is how some people have fun. I think the tragedy is when fun, energy, and mental health aren’t part of the conversation about how work gets done.
“We in computer science”! I interpret that as people doing research, not the rest of us who mostly do bean counting programs. For those that pay our salaries, not losing any beans is way more import than how much fun we have, or how much we stretch the possibilities.
I produce my best work at my best productivity when I'm having fun, so those that pay my salary should appreciate that. This is a case where my values and the values of the beancounters are aligned.
If I'm not having fun, then I'm in the wrong position and need to move on. Life is too short to have my day job be a grind, and I won't produce great work in that condition.
I think the act of coding is fun, even if the domain is not.
I think the goal should still be fun. It’s not fun to lose the beans.
I think when the coding becomes overly fearful is when bugs and problems happen. Maybe you don’t have much leeway around the bean part, but you have a lot of room to test and validate that system. How do you make that system as fearless to work with as possible?
It’s a difficult goal, but achieving it is a worthwhile accomplishment. A difficult puzzle that some might find fun.
You’re describing nothing more than having the programmer be able to stay in the “fun/challenging” zone, above the “boring” zone and below the “stressful/helpless” zone. This is obviously very personal: What is boring for you may be challenging for me. Further, all learners of any subject are trying to stay in this zone. Professional educators are very aware of this and refer to it broadly as “student engagement”.
The goal of a software project, however, is not optimal individual learning about programming, it is usually something else.
> The goal of a software project, however, is not optimal individual learning about programming, it is usually something else.
Sure. It’s my goal. Not my project’s. My project doesn’t care about anything really.
The name of the game for me (the programmer) is maximizing my output without getting burned out. To that end, my intermediate goal is to find fun where I can. That’s the game.
the sad thing is that the organizations that dont have any fun, that are focussed on the serious, soul crushing business of making sure no beans get dropped, are generally really awful at keeping track of the beans.
"Hey Mr Customer... don't worry that all your data is corrupt or you lost access to your disks ... you have been set in a new direction and we're just making your day job 'fun'"
They're not Bugs ... what you have here are little balls of 'fun' /s
"this is your first step on an incredible journey to fully appreciate how humans ascribe meaning and significance to words they have typed or photographs they have taken..."
Not much in the DOM, just a <form> element and 2 sibling <script> elements.
Console logs show 2 identical errors:
> Refused to execute a script because its hash, its nonce, or 'unsafe-inline' does not appear in the script-src directive of the Content Security Policy.
Maybe the average technologist, but for anyone who understands Apple's culture and history, your claim is not just inaccurate, but opposite of the truth.
Steve Jobs addressed this exact point during a 2011 keynote [0]:
> It is in Apple’s DNA that technology alone is not enough—it’s technology married with liberal arts, married with the humanities, that yields us the results that make our heart sing.
Blocking out the sound and sights of real life with something digital is not what I call a thoughtful commitment to the human experience.
Hardly anyone seems to remember how the iPhone used to be small enough to fit in one hand or in any pocket. As people became increasingly addicted to phones to the point of having them outside the pocket more often than not, bigger phones made more desirable, but Steve Jobs insisted on keeping it small. He said nobody wanted a big phone, but since it was obvious users did want it, I'm wondering if there was another reason. He died, then a few years afterwards, Apple released the larger iPhone 6.
https://youtu.be/pLgpUEpaUVs?si=WXciPD8BuEgP5nMe
reply