Learning how to make computer software is hard. Not fundamentally hard: lots of people can do it, and even more people do things that are functionally equivalent to programming though they wouldn't think of it as such. But teaching people how to write good computer software is a challenge, and one that I'm generally interested in exploring more.
For a long time, I've been interested in this problem from the outside: I didn't really know how to program in any meaningful sort of way and I was interested in deconstructing the process of making software. Then something clicked and years of tinkering with systems administration and reading about programming languages and practices clicked and while I think I have a lot left to learn, I've started thinking about the problem from the other side.
We accumulate many skills and kinds of knowledge in an incremental sort of way: you study and practice and little by little our brains (and bodies) form new connections and we "learn." Other kinds of learning follow a more "step-based" approach: we practice and study for a long period of time without much discernible change in understanding or skill until at some point we experience some sort of larger improvement in ability.
At least for me (and perhaps you as well,) things like dance, knitting, writing, and most structured/classroom-based topics tend to be incremental, mostly. Other things, like programming (at least initially) and singing/music tend to be step-based.
This isn't to say that step-based areas of focus don't require regular ongoing practice, just that the observable markers of progress may lag inconsistently behind effort and pedagogy.
When I was doing more non-professional writing, I was fond of the school of writing advice that said "the way to learn how to write (fiction) is to have a good story to tell;" when I think about learning to program I think the first step has to be a need to automate something on a computer.
I've even written up something on the topic
Hackers describe this as the "scratch your own itch" method (from CatB and elsewhere.)
Neither the idea of step-based versus incremental learning nor the notion of using a personal need to drive learning are new, but I think they illuminate eachother well.
Since I stopped being a student somewhat abruptly in 2007, I've become increasingly glad both that my education and personal development has continued and I've had the opportunity to explore things in ways that didn't make sense in a structured context (e.g. "I want to learn about how databases work without formal CS/systems training," or "I want to learn how to sing and withouta lot of music theory.")
For most of the past year I've been pretty heads-down on the "learning to program" project, and I've had a number of interesting problems that I've used to help explore the topic:
generalized `Sphinx <http://sphinx-doc.org>`_ publishing toolkit.
This is both a work project and a personal project.
Sphinx is a great tool for producing text, and I'm quite fond of it. At the same time, I'm not a fan of its architecture (and have a number of approaches to optimize the build process,) and there are a number of tasks: dependency resolution, version management, theme management, and deployment that any reasonably complex Sphinx-based project needs to address.
While this project requires ongoing development and improvement, it's basically feature complete, and it's given
I've had a couple of personal side projects that I've used to explore different kinds of programming problems, with greater and lesser success.
Buildcloth, which is pretty cool and needs more work but I fear may be too complicated for the use-case.
csc, which isn't fully off the ground and may not provide a significant improvement upon Sphinx for most cases.
dtf, which is a decent idea, but I've not had time to really implement and exercise the program and I fear that the core code quality isn't great.
More recently I've begun working on a dependency analytics package with a co-worker/friend to help him and his teammates understand and untangle a larger C++ project.
It's been nice to be able to actively work on a project with another developer, and to be able to focus on performance and architecture issues while someone else focuses on feature prototyping and use-cases.
In a lot of ways this is a good "capstone" project for me because I've gotten to use and apply many of the things I've learned from writing concurrent/parallel Python, as well as moderate sized Python programs comes together well here.
Most of the projects that had been open and on my plate for the last few months have mostly wrapped up. There's more work to be done on them, I could do a lot more work, and I think I will, but none of them are lacking a feature that I really need in order to accomplish something that I want to do.
I'm interested in learning more: about writing (documentation, science fiction, etc.), about software development and computing.