> I write an average of five new programs every week. Poets have to write poems. I have to write computer programs.
It seems more obvious now that I read it. A lot of programmers out there, including myself, are looking for ways to improve their skills and I never thought to myself to write more programs. And not just programs for the sake of programs, but programs that force you to explain to the computer that you understand certain concepts. This man is and will continue to be a huge inspiration.
>The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality. His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the "quantity" group: fifty pound of pots rated an "A", forty pounds a "B", and so on. Those being graded on "quality", however, needed to produce only one pot - albeit a perfect one - to get an "A".
Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the "quantity" group was busily churning out piles of work - and learning from their mistakes - the "quality" group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay.
Ha! I had the same experience in my art evening classes. One evening our teacher told us that we had to produce three paintings in the 2.5 hour lesson. It is challenging enough producing one in that time period. It was a fantastic learning experience in letting go. The first picture I did was OK, the second was better and the third was great - all because I'd given up thinking at that point and was just doing.
Sometimes I get the same feeling when coding, when really in the zone with the magical feeling of flow.
On the other hand, I took a few semesters of elective photography courses in high school, and there’s a certain essential amount of time it takes to make a good photo print and run it through all the chemicals. It can’t really be compressed down shorter than about 35–40 minutes for the whole process with only limited ability to parallelize the work while maintaining quality, which makes it tough to make more than 1 or possibly 2 good prints in 1 class period.
All of the students I knew who focused on making 1 good print every day ended up learning more and making better images than the students who constantly tried to rush.
Apples to oranges. Painting is a purely creative process with style being valued over correctness. While there is artistic decision during manual film development, there is definitely a wrong way to develop a print. If you rush the chemical process, it will end up bad. Film is more like baking in that regard while painting is stove top cooking.
I guess my point is: the important thing to learn here (in my opinion) is that regular deliberate practice with focused attention is helpful, not that people should try to rush out as much sloppy work in as short a time as possible.
Even the highest quantity of practice is not necessarily essential. My impression is that its spacing out over time is even more crucial.
I have a 3.5 year old, and I’ve been watching him learn all sorts of skills (learning to understand and use language, walk, run, jump, ride a balance bike, solve logic puzzles, build with construction toys, draw, ...), and it’s amazing the kinds of leaps he will make in balance, coordination, speed, understanding, etc. at some specific skill over the course of 3 or 4 months, even if we only practice the skill for 20 minutes once every few weeks.
Somehow the brain is churning on it in the background, and there are sudden leaps in ability which can’t be obviously explained based on direct practice time.
The art of a good film photograph isn't printing lots of pieces it's taking 10 shots, and choosing to print two of them.
There are parts you can't rush, there are clear steps to taking clear photos, well exposed photos.
Being able to look at the negative, and know if it turned out well is the shill you learn.
The students who focused on one good print had a lot of prep work. Getting the final step right (for software, shipping and deploying to production) isn't something we should rush.
Learning all the steps which lead up to that final one well makes a tremendous difference
Is this maybe then analogous to the essential and accidental complexity premise that Fred Brooks put forwards?
It may be that in painting the cost of accidental complexity can be reduced greatly but in photography due to necessary post-processing there is less on an opportunity.
That doesn't mean there isn't an opportunity here. Being neither a photographer or painter I am most likely not the best person to comment however!
Resonates with the rise of USA. A few books about electricity mentionned that Europe was caught in a neverending debate about ideal theories while US was applying simple tricks and improving understanding on the way.
I'm also wildly guilty of the analysis paralysis... I did try to set up schedules and goals to iterate but it always die before I did any real progress.
Oh and btw, some dude said Wright bros. won the race to flight because they approached it with low cost engineering/lab mindset, rapid prototyping fashion. Other companies with more resources tried the moonshot approach, did 1 so-called plane in 2 years, failed to fly, ran out of resources and died.
Reminds me of SpaceX. everytime I see their BF metal tank blow up, I’m like “yasssss progress”.
I absolutely believe that SpaceX will land a human on Mars in our lifetime. Not sure how long they’ll survive and whether a colony is possible but they’ll definitely make it way cheaper to send shit to mars/moon than it is today.
Also I’m bullish that we’ll make big breakthroughs in DNA and protein folding/interaction understanding. Building with the same molecular machines of life opens up so many possibilities.
So, I have now put /War of Art/ and /Art and Fear/ in my queue. I also have a physical of /Art of War/ somewhere. I'm assuming that is a different thing, though.
I wonder if there has been a proper psychological study on this. It makes logical sense and corresponds with my real-world experience, but that's not how science works.
That's a repetition of the same claim, not a source. He doesn't mention simple information like who or where the class was, which there is no reason to be secret about.
Also, it doesn't pass the obvious sniff test, that a teacher would spend a whole semester giving half of his class a terrible experience that uttery failed to teach them anything, leaving them with "a pile of dead clay" as the author claims.
If I were graded solely on quantity, I would produce stuff that only just barely passes the bar of being a pot. (If you take a clump of clay and stick your finger in it, you basically have a pot.) Therefore, I think the story is false.
But then you'd get sick of making such shitty pots, if you liked pottery as an art form enough to want to learn it, and you'd start trying to make better ones because just passing the bar probably wouldn't be enough for your sense of aesthetics/craftsmanship (or maybe it would, and then you would have learned something as well)
It depends a lot if it is a voluntary art class, or you are forced to take it. (Or it is the only job you could get, and you are not to interested in it.)
True if all you care about are grades (which are what? A badge?). I'd probably knock out what I needed to pass (make it through the gate) and then focus on improving.
Something that I found useful is taking the concept of katas from martial arts. Writing the "same" program multiple times, but trying to refine the parts I didn't like in the previous iteration (e.g. try writing in less code, with smaller functions, with less libraries, in a more testable way, etc).
It's specially rewarding to do this exercise with utility libraries, as it teaches you about the nuances one abstraction level below (both in terms of learning what is possible but not exposed by the abstraction and in terms of learning what pitfalls exist). Many times I find that it's more elegant to drop down one abstraction level to accomplish something than to add more abstractions on top due to lack of understanding outside my primary abstraction level.
I think what he has in mind are small programs that do some kind of nontrivial computation without much in the way of IO or UI. For example, [1] is a program from December 2019 that "finds n-bit binary squares that are palindromic".
A great way to get into this kind of thing if you're stuck for ideas is to go through the Online Encyclopedia of Integer Sequences [2] and just write little programs to print out the first n entries or whatever for a particular sequence. As other comments have suggested, don't worry about making them perfect, just get the numbers right and then move on to the next one.
> is a program from December 2019 that "finds n-bit binary squares that are palindromic".
No dis-respect for Donald Knuth (who of course I found orders and orders of magnitude above programmers such as myself) and no dis-respect to people that found those types of programs interesting, but there are also programmers (like me) for whom those programs are just simple riddles, with almost no interest whatsoever.
They're like sudoku or crossroads, interesting and somehow intellectually stimulating but they don't help shape/change/modify the world around us. And I got hooked on programming when I realised how it could help me change the world around me and most of all how it could help me (and others) in trying to make sense on said world that surrounds us.
The question was about the sort of little programs someone could write daily, and the answer resembles crosswords or sudoku, which many people are in the habit of completing once a day.
Would completing one integer sequence algorithm (brilliant suggestion btw!) change the world around you? No, of course not.
Would it make you a better programmer, though? Certainly it would. Which would mean, when you settle down, crack your knuckles, and start changing the world, you'd do a better job of it.
Your objection strikes me as that of a hunter who won't go to the range, because when he fires his rifle, he wants to put meat on the table!
> They're like sudoku or crossroads, interesting and somehow intellectually stimulating but they don't help shape/change/modify the world around us.
I don't think this is accurate: sudoku and crossroads have deterministic known solutions. Solving them is a mostly mechanical feat and indeed somewhat useless beyond the joy of solving.
In contrast, the challenge of creating these sorts of programs is creative and open ended. It is very well possible that someone will come up with an even more efficient algorithm. Or a much simpler one. Or just a completely new strategy.
As to the usefulness, these little toy programs are a constant source of inspiration for solving actual real world problems. A perfect example of this is Algorithm X. One of Knuth's toys that solves Sudoku puzzles. The same algorithm is easily adapted to solve scheduling problems and actually is a major innovation.
No one was holding their breath for a program that finds n-bit binary squares that are palindromatic, but this kind of mucking about can be useful as exercise and as a source of new insights, both of which will aid the programmer in achieving more ambitious goals.
The musician doesn't noodle around randomly or repeat uninteresting exercises with the ambition that that in itself is going to constitute a meaningful and memorable work.
I think others have already done a good job of describing how programs like that help make you a better programmer, and can be inspiring.
I'd like to add that something that I find interesting and inspiring about programming is managing complexity. That's something that's not as easily explored with programs like the above. But for example, you could try to create as much of a spreadsheet program as possible in a few hours. Do that 4 times starting from scratch. How can you organise the code in such a way to make it easy to read, performant, maintainable, and fast to write? What language features will you take advantage of? Maybe try making a part of a word processor, an IDE, a raytracer, an HTML viewer, an FTS engine, a relational database, etc. Try implementing mvc, or reactive, or two way binding UIs. I would consider these sort of a different genre of poem, that let you explore a different problem space. Maybe this might be the genre that you're more interested in?
Checkout his latest fascicles on applications of zero-supressed binary decision diagrams to all sorts of problems. From beautiful tiling problems to travelling salesman.
His latest fascicles are bleeding edge when it comes to a general algorithm that solves a wide variety of problem instances very efficiently. (much similar to his Algorithm X, but superior in almost every way)
When the very adjacent sentence is “Poets have to write poems”, I think this question is like asking “what kinds of poems, not for the sake of poems, can you actually write…”, then ask about how they change the world, etc.
Even poets don't write poems just for the sake of poems — they write because it gives them pleasure, because they are moved by some strong feeling or because they have some irresistible urge to say something, etc. (And sometimes because they're being paid for it, or hope to be.) Anyway, here are some reasons (in no particular order, and not mutually exclusive—there's some overlap) for Knuth to write programs:
1. Because it gives him pleasure.
2. Because he wants to find out the answer to some question — for instance, how many knight's tours are unchanged under a 180° rotation?
3. Because he wants to experiment or gain more experience with some algorithm(s) or method(s) that he's learning or writing about.
4. Because he wants to collect data on their performance, so that as a scientist when he makes a statement like “a program using this algorithm finds the answer for N=13 using only 0.3 billion memory accesses”, it is a correct statement.
5. Because he wants to understand something better (e.g. his program for linear programming where he says he understood the simplex method clearly only after implementing it).
6. Because he wants to "debug" or interactively see what sub-components of some algorithm do.
7. Because he has encountered (or been posed) a hard problem and wants the challenge of solving it.
8. Because he has seen a beautiful program and wants to translate it to his preferred style, as he'd like more people to appreciate its clever ideas. (E.g. his reimplementation of the original "Colossal Cave Adventure" game of Crowther and Woods.)
9. Because he wants to provide this program as an illustration of some idea or algorithm mentioned in his books.
10. Because someone has asked him for the program.
One can easily imagine more reasons. Though at the rate of five a week it would be more than 7500 programs over the last 30 years, he has given a few examples on his webpage: https://cs.stanford.edu/~knuth/programs.html (Many of them are in CWEB so to help people who don't have `cweave` installed, I typeset them in 2017: https://github.com/shreevatsa/knuth-literate-programs/tree/m... — I ought to update the repository sometime.)
Is this your way of saying you're a programmer not a computer scientist? Because his job is as a scientist.
Calling his exercises simple riddles is disrespectful. It's like calling doing a 5km run every morning, simple walking.
The proof is in the pudding, he has impacted the world in a profound way.
But on a more positive note. Which non-cs programmer heroes exists today? I'm thinking John Carmack.
Yeah, of course I have never thought as myself as a computer scientist, I like my job/title as a programmer, I don't see any downside in that, manipulating data is fun.
I don't personally have "programmer heroes", maybe it's because I'm 39 years old and as such I haven't believed in cowboy-like programmers for almost a decade now. I did strongly believe though in what Aaron Swartz used to do and in what he used to believe, i.e. an open internet and open data for almost everyone, but that dream died in the late 2000s - early 2010s and I don't think we'll ever going to get close to anything like that ever again.
Many people praise Fabrice Bellard. Not sure if he's counted as a non-scientist, but his achievements are astounding.
Although I think that many heroes are hidden behind corporations. Those people who contributed most to Google Search or architectured Chrome. Those people who built systems everyone relies on. For example almost every Java project uses Spring Framework, but I'm sure that it was founded by one or few very talented people. And those examples are many, but not very public or exposed.
I don't really know much about other fields. Do architects recognize those who architected outstanding projects, like huge bridges and tallest skyscrapers?
So is the blog "Programming Praxis". Its author has been posting short and interesting programming exercises at least once a week, but often more, for years.
Of course the answer for OP is reading and working through taocp, that practice makes you better which is why Knuth spent his life writing these books even if technically, they are as the Knuth states just a study of 'alg a compared to alg b' the byproduct is more practice that OP is looking for.
I feel like solving leetcoe problems would fall somewhere in the category of programs you're describing. (They seem like small problem solving programs.)
You can write "meta" programs that help you maintain existing applications.
Whenever I start at a new company, before I get thrown into the heart of things and become "too busy" to write these kinds of programs, I like to write things that automate the boring stuff.
Some recent examples:
- a cli for inspecting, adding comments to, and updating the status of JIRA tickets. because our hosted JIRA instance was god-awful slow and their web interface is a mess.
- a tool for monitoring things and pinging me with macos native notifications when things crash or complete.
Was my net productivity positive for writing these tools? hard to tell.
There are some companies full of engineers whose actual job is to write tools like this; I'm not sure what they would do for fun :P
> There are some companies full of engineers whose actual job is to write tools like this; I'm not sure what they would do for fun :P
I think there are a lot of organizations that would be better served devoting more resources to the meta work given the labor and infrastructure costs. I would go out on a limb and say the capital expended on the majority of projects I've worked on in my career had a smaller ROI (because it was negative in most cases) than would have been the case had the organization just invested in improving internal tools and processes of their existing systems.
I totally agree with you. I think that most corporations are in a state of suspended myopia.
We’d rather direct engineers to improve the effectiveness of a single system by 200% (even though it impacts 1% of revenue), than to impact all (or many) systems by 5%.
Yet, most of the impressive software we admire today was built in the environment you prescribe. C and UNIX, famously, but also git, Go, Rust. I imagine many others.
How much has C improved productivity, over Assembly and COBOL? How much has Borg or BigTable?
The issue, IMO, is that no ambitious manager wants to invest the social capital in defending and advocating for these teams, because they don’t look good until they look exceptionally good.
I find lots of little utilities fit the bill. They are oftentimes sufficiently narrow in scope to be of little use to anyone but the author, but that shouldn't necessarily eliminate their use.
For example, here is a Gist with a shell script I wrote that, given a set of Maven coordinates, works with a few other tools to build out a docset for use in Zeal / Dash.
I find myself writing debugging tools all the time. For example, our logs are overwhelming because our developers use them for debugging and then never remove their logging statements. So finding anything in them is next to impossible, and it's often interleaved with a bunch of other junk that's meaningless to you. And fixing the logging system we use would to make this work better would also be a huge task.
So a little while ago we needed to log some info to figure out where 2 parallel sets of calculations were going wrong. So I wrote some logging that output the info to a file instead of the main log, and then wrote a simple parser to read them in and display them side-by-side in a nice hierarchical tree structure. It made something that normally takes us a week to work out only take a few hours. It's something we'll never ship to customers, but helps us enormously.
I'm finding myself writing more and more stuff like that these days.
You might also try to get your QA process to require removal of debug print messages or at the very least an "off" flag as an environmental variable or config file element
We're business application/infastructure maintainers, not programmers. It's a different world from Knuth's expressions of mathematical ideas.
Outside of work, it's easy to write whole programs. Project Euler, LeetCode, etc. These are the kinds of programs Knuth is talking about -- example programs to illustrate algorithms from TAOCP.
I'm a frequent user of SO, but I find leetcode [1] much better when I just want to practice coding / problem solving. Their free account is more than enough to have some fun ;)
I disagree. Leetcode and related sites have problem descriptions that are often vague or nonsensical. Just figuring out what the author is trying to say is more of a challenge than the actual program sometimes.
After Michelangelo died, someone found in his studio a piece of paper on which he had written a note to his apprentice, in the handwriting of his old age: “Draw, Antonio, draw, Antonio, draw and do not waste time.”
As obvious as it seems, the advice really does apply to everything. I'm okay starting a bunch of projects and never finishing them, because I'm always learning something. When I do start a new project, I usually try ten or so different programming languages and environments to see which one is a good fit for the project. That said, there's certainly something to be said for finishing projects that you're proud of and getting to know one toolchain very well. A mix of both is good.
Remember that Knuth is/was a professor in mathematics and computer science, so he didn't spend his day coding, so for him it was beneficial to do something that complement the teaching and keep him grounded. What would complement yours? Maybe more of mathematics instead? Or design? Or economics?
I have a folder named "proofs" on my machine which is just this. About 1500 and counting little programs that demonstrate or prove that something works some way or another. The class name expresses the proven fact. When I find out I am wrong, I change the name of the class to reflect the correct understanding. I read through the names in my IDE when I need to know some detail about something I've forgotten.
I misunderstood how to use git before college and used to commit everything to master, on GitHub you get this fancy flame graph when you do this and so it acted as a kind of “gamification” for me. I don’t think anything else has so dramatically improved my abilities as a programmer.
It's the same with almost every creative endeavour. Painting as well as poetry and programming. Practice makes you better, even if the result is sometimes poor in isolation.
It seems more obvious now that I read it. A lot of programmers out there, including myself, are looking for ways to improve their skills and I never thought to myself to write more programs. And not just programs for the sake of programs, but programs that force you to explain to the computer that you understand certain concepts. This man is and will continue to be a huge inspiration.