What does it mean though? What programs? I can't write new programs at work where I maintain existing applications for the most part.
What kind of programs, not for the sake of programs, can you actually write almost daily?
What kind of programs, not for the sake of programs, can you actually write almost daily?
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.
[1] https://www-cs-faculty.stanford.edu/~knuth/programs/squarepa...
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!
Depends on the sequence, of course. I hear a lot of people would be interested in a fast algorithm for computing membership in OEIS A000040.
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.
You can try to make text-based games.
You can make a bare-bones browser.
You can write a simulator for ..say.. classical mechanics.
Are none of these interesting for you?
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.
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.)
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.
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.
Do you guys think programmers don't recognise each others work as much as in other fields?
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.
Maybe you are your own hero?
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)
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?
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
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.
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.
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.
https://gist.github.com/michaeljmcd/5564758537946963e946806e...
I had to dig into some corners of Maven I didn't know well to pull it together and it formalized some random bits of minutae.
Nothing elegant or crazy, perhaps, but it is a bit of coding apart from the normal day job that taught me a couple of tricks.
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.
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.
Under that category, I imagine something where the resulting program itself is of any, however minuscule, use to me.