First, I need to continue developing a fundamental model of tasks and goals. Is each task implicitly both a piece of work and an outcome? If I say that I'm going to wash the dishes, and then the dishwasher breaks and I have to get it fixed, and then I break some of the dishes putting them away, how do I account for all of that extra work, like choosing a repair person, waiting for them, rescheduling, waiting again, giving up and learning how to repair dishwashers myself, actually repairing the dishwasher, and ultimately repairing or replacing the dishes? Is that part of the original task, since the desired outcome was to have clean, usable dishes, or a new task?
If this seems overly pedantic and pointless, or if the scenario seems far-fetched, consider it in terms of software, where this is pretty normal. You go to add a minor feature and end up, weeks later, having re-written half the system and upgraded your database and forgotten the original problem. How do you document this, so that you can build a historical baseline, predict when this will happen again, and maybe even control and limit it in the moment?
And the second track is, how do I make my website a little prettier and also add some nice AJAXy (AJAX is an acronym for some features that basically let web pages work more like apps), such as being able to re-sort my to-do list with drag and drop? And I really want to add card mapping and try making that a useful and integral part of prioritizing and the only site I could find that does card mapping is a pay site with no API, so I would basically have to rebuild it myself. And of course the recursive irony of all of this is that, because I haven't finished my task management system, I have trouble managing the tasks necessary to finish my task management system.
So. While it's humbling to realize that making prettier web pages will probably be harder than delving deep into the theoretical and conceptual and philosophical underpinnings of tasks and the essential nature of work, it's probably time to stop adding more features and instead get basic mastery of some new technologies.
This is the point where I learn just how bonkers the current "Web Stack" field is. The concept of the Stack refers to the set of technologies one builds upon so as to avoid re-inventing the wheel. At the bottom of the stack, where you have problems like "how should data be stored?" and "how will this program be made available to the Internet?", there are very solid, mature, stable, reliable, consistent, constant solutions like PostGreSQL and Apache. Only a complete fool, someone who thinks they are smarter than millions who have come before or that they have a unique problem that no-one has every solved before, tries to re-invent the database. But as you go up the stack, things get weirder. For example:
If you love Ruby on Rails, batman.js is the best, most familiar way to build rich web apps in CoffeeScript.The top of the stack is so weird that even the names of the layers are still in dispute. At the bottom we have Operating System and Database and Backup and things like that. But at the top we seem to have Grid and Mobile-First and Responsive. I am somewhat sure that the two most popular open-source packages at the top of the stack are Bootstrap and Foundation, but what do they actually do? Bootstrap is
the most popular HTML, CSS, and JS framework for developing responsive, mobile first projects on the web.and Foundation is
The most advanced responsive front-end framework in the world.Next post, we'll look at 10 Lightweight Alternatives To Bootstrap & Foundation just to see if we can figure out what this technology is even for.