I have a modest proposal for the state legislature: I think we should pass a law that requires doctors to wear a little badge on their shirt that says "Unclean" if they fail to wash their hands at least 12 times per day. Washing your hands is good! It's almost free! And any doctor who doesn't comply with the law is obviously evil for failing to meet our arbitrary standards. Doctors will probably object to this because it's silly and also because any doctor who doesn't meet the requirement (regardless of their reason) will look really bad with an "Unclean" badge on their shirt, but that's not really important because after all they're evil (see above). It's our right to have doctors with clean hands!
Polyphylla decemlineata or the Ten-lined June beetle is an interesting little beetle. Patrick saw one of these at school (and later one at home in the backyard) and was intrigued. After digging around on the Internet and searching through quite a few varieties of beetles, we finally identified it. The one we saw did not appear to have such large antennae as some of these specimens (or perhaps they just weren't unfurled). Ours looked a bit more like the picture on the left.
These things can get kind of large for a beetle and apparently they make a hissing sound if disturbed (although we didn't try).
Glory be to God for dappled things For skies of couple-colour as a brinded cow;
For rose-moles all in stipple upon trout that swim;
Fresh firecoal chestnut-falls; finches’ wings’
Landscape plotted and pieced—fold, fallow, and plough;
And all trades, their gear and tackle and trim.
All things counter, original, spare, strange;
Whatever is fickle, freckled (who knows how?)
With swift, slow; sweet, sour; adazzle, dim;
He fathers forth whose beauty is past change;
Pied Beauty by Gerard Manley Hopkins
My typical work day is a mostly mental exercise. Most of my work falls into these categories:
- Pushing or pulling ideas between various people ( normally we call these conversations but that's what it feels like)
- Attempting to create abstractions of concrete examples
- Attempting to make concrete examples of abstract ideas
- Designing optimized interactions and processes for defined workflows
- Implementing software applications that meet the design
- Thinking of ways that the implementation can be broken or hacked
- Outlining and documenting all of the above in a way that almost anyone can understand it
I'm a software engineer and that's what I do. It's almost entirely a mental exercise. There are very parts of the day where I just click through something or enter data over and over or do anything else where I can zone out. I think a lot of non-techies think that computers are all about following some steps in a process (e.g. "Push that button, then click here, then push the other button."). I'm sure to offend someone here, but I'll pick an example of a task that at first requires some mental exercise but then really doesn't: assembling furniture from Ikea. So, when you first get a box and pull out the pieces you have to apply some thought. Hopefully you skim through the directions, make sure you have the parts that you expect and then start on page 1. You look at the pieces, look at the drawing and start working. Two points to make on this: first, the thought is pretty basic. You've been given everything you need to work, you just have to follow the steps. Second, if you buy more than one item (or if your Ikea furniture wears out like ours does) you may find yourself assembling the second unit without even referencing the book. You essentially have to be smart enough to identity what object is in your hand and what parts in front of you fit where on that part.
Software engineering is almost never like this. To be sure there are processes and steps and flow in software. There is a typical software requirements lifecycle that is composed of Planning, Design, Development, Testing, Deployment, and Maintenance [although sometimes the order and categories are described differently, but it's still basically the same thing] but this just a huge framework that outlines the overall process. In fact, in many software methodologies the lifecycle is intentionally NOT a straightforward process but rather an iterative one. You start with requirements, do some design, write some tests, write code, do more design, refine some requirements, write more code, etc. Most of the process is up to you. Gathering requirements for a software project can be aided by good tools and by good frameworks. However, it's still up to smart people to ask good questions and translate sometimes misleading responses and then continue to ask questions that flesh out the real desired functionality. Software design has a number of tools and frameworks as well. Just as in real-world architecture, there are numerous design patterns that can be leveraged to achieve a solid and good design but no one but a skilled engineer can make the call on what design pattern is appropriate. We have great modeling tools like UML which can help in developing a [mostly] unambiguous representation of a software component but someone has to construct the diagrams. The coding or implementation itself is probably the least "mental" part of the work. Granted, there's a large amount of material that a developer needs to understand how to implement a design in code but most of the material is available easily from reference books or more commonly, the Internet. Even so, a developer must spend time understanding the design and ensuring that the code does in fact implement it. It's difficult to ensure that your implementation is in the line with the requirements so testing is necessary. Testing is hard. I'm not even for a moment suggesting that it is too hard and should be ignored. In fact, you can't really separate testing from implementation since there's no way of knowing if what you wrote works without testing. But good, solid testing can be quite difficult. Modern tools are wonderful for testing -- it's easy to write unit tests for code to verify that code does what it's supposed to do. The tools make life easier but there's still an enormous amount of thought that has to go into testing. Edge cases and complex use case scenarios are common; it's often very hard to have good tests that adequately cover all the requirements rigorously. Often software is written that supports an infinite variability of input. In order to write adequate tests, a developer must have intimate knowledge of the requirements but also the language, frameworks, operating system and other parameters that are part of the software environment. The tests themselves are easy to implement. It's knowing what we should test that's hard. Without even going into deployment, maintenance, and other related tasks, it's easy to see that most of this process is a thinking process. In fact, really good software can be nearly complete before any software has been written.
My point of all this is to indicate that software is a lot of brain power. And more than just brain power, it requires a lot of creativity. A lot of software has been written in the last 60 years. New software isn't just about reinventing existing software but making things work better than before. Perhaps this means finding a creative way to tweak more performance out of the same hardware, or maybe constructing a more efficient interface that humans can spend less time learning and more time using, or maybe finding a way to make disparate systems talk together smoothly and correctly. All of these are valuable but often we're not trying to find a solution but to find the best solution. Requirements have many non-functional elements that describe constraints on the system. We might be building a system that searches an airline reservation system for available seats but our constraint might be that we need to retrieve this data from the current system in less than 1 second. That part gets tricky.
This wears me out mentally. I find that by the end of the day I rarely want to spend time on the computer (unless it's doing something mindless). In fact, even on the weekends I greatly prefer activities that are manual. I enjoy do-it-yourself projects around the house that involve punching holes in walls and cutting down trees. That sort of thing is easy -- it takes some minimal thought and care but it's basically doing stuff not thinking about stuff. I rarely do work on evenings or weekends that's very creative -- I've struggled just to write on this blog let alone writing out some stories that I've had floating in my head for years. Any project around the house that requires a good amount of planning or preparation tends to not happen because my brain sees the looming creative task and tries to shut down.
So finally, one observation, and one idea.
In the last several weeks I've transitioned in my full-time work to doing very repetitive (even boring) work that's much more akin to pushing buttons and clicking the mouse. There's a large backlog of system configuration tasks that I've been working through. The work is easy in one sense. Almost all of it is well-defined and easily understood. It just takes time. Sometimes I have to chase down problems and troubleshoot things that aren't working, but it's mostly clicking, typing, waiting, and repeating. What I've observed is that after about 3 days of "time off" from the creative process of software engineering I had a large boost in creativity. During the day, in the evening, on the weekend -- I suddenly was interested in doing creative tasks. My brain had realized that it wasn't getting any action and started asking for attention. I spent a few late nights working on some tasks that I've wanted to do for a long time (including some software development for a personal project that's been on the back burner for literally years). All of it felt not only good, but great. I felt like I had time to think through things and although it's a little subjective, I think that the quality of my work was superior than it normally is. I've had more "ah ha" moments and more "outside the box" solutions than I normally do. It's been wonderful.
This probably isn't too much of a surprise to anyone who thinks about it. I'm sure there are studies and articles on the subject (I've seen some). However, I'm interested in the idea that there may be optimal ways of mixing work for professions that require large amounts of creativity. For example, it might make sense that the best activity for a group of software engineers isn't to have them spend an extra day each week on a project of their choosing (although I think it's better than nothing) but rather to have them spend time working on running cable in the corporate offices or doing rack wiring or adding components to computer cases. These are all worth-while activities and although they take some skill, most technically inclined people find these things to be fairly simple mentally (although not always physically). A company doesn't normally pay the same salary to people who do these tasks, but I think it could provide real value to the company in the long run. By turning off the creative process for a little bit, software engineers could [perhaps] be much more creative when they come back to their regular work. I'm not sure if there have been attempts to do things like this in a company that employees software engineers, but I'm curious to hear from my readers on whether they think that the idea has any merit. Anecdotal evidence as well as real studies on the subject are all welcome!
I’ve found this discussion a very interesting one… There’s a lot of conjecture out there that the iPad (and similar devices) shifts use of the Internet away from “creating” and towards “consumption”. To some extent, some of this seems obvious. Activities like music and video are clearly consumptive and these activities often are more convenient (and seem more of a probable use) for portable devices like the iPad. Also, in general, reading is quite easy with the iPad/Kindle but typing is harder than with a regular laptop or keyboard. I find myself definitely being a consumer far more on the iPad. Even with emails, I tend to read and mark for later handling far more with the iPad. On my desktop on the other hand, I tend to immediately reply to the emails that I can knock out in the next minute or two. I might look at pictures on my iPad but I definitely don’t any editing (although the Photoshop Mobile app is kind of neat for really simple tweaking)
So while I can agree with the observation that iPads and other smaller devices are currently being used for consumption vs. creation, I think that this may just be a phase. Computer users have used keyboards for a long time. In fact, the first keyboard appears to date to the 18th century and our current qwerty keyboard dating to 1873. In addition, the mouse, first created in 1963 but not in common use until the 1980's is also ubiquitous in modern systems. One could argue that it's a powerful device for manipulating interfaces, but I don't think it's the end-all of human-machine interfaces.
There will be something new. There always is. Touch-based computing has its strengths and weaknesses. There's an almost nauseating volume of interfaces that can all be summarized as "sort of like the interface used in Minority Report". With faster processors, better algorithms for processing inputs, etc. it simply seems a matter of time before a new breed of general purpose input devices will become standard.
Keyboard input (and to a slightly lesser degree computer mouse input) are currently preferred because they are precise. Learning to type is a relatively easy task and provides a very easy-to-control way of interfacing with systems. Using a mouse is trivial to learn although it is much slower to use for many tasks. Its strength is that it works very well in dealing with graphical environments that involve manipulation of elements that rely on eye-hand coordination. The combination of both in modern systems allows precise control when needed, and manipulation of complex interfaces when needed.
Touch input devices provide a more natural feel for the second type of interface, but not the first. Precise input is slow and painful The value gained is that the iPad and similar devices are instant-on devices that don't require you to sit, position yourself, or even use both hands. A user gains speed, portability, and convenience but loses precision.
Two things really interest me in this area. The first is motion-based systems like (to some extent) the Wii and more importantly the Kinect. Both systems use the concept of movement (one with a controller you hold and the other by simply viewing the user themselves). The second is voice-based systems like Siri. There have been many voice-based systems previously, but Siri seems to have attained a more natural level of interaction that I think finally makes voice control more practical.
The interesting thing about both systems is that both approaches reduce precision in the system and attempt to get at underlying intent of the input. You can ask Siri "What's the weather like", "will it rain today", or "Weather" and it will give the same response. The attempt is to map a number of inputs to the same output. It can handle heavy accents, variations in speed, pitch, and intonation and still give results that make sense. Kinect based systems are looking at standard or typical behavior and are all about averaging inputs to try to get an approximate value rather than working with precise values.
These new technologies can be leveraged in interesting ways. It's clear that games that involve more physical activity are fun and interesting. It's also clear that being able to speak to your phone to perform tasks that would take longer to do with the touch input saves time. But will anything ever replace the keyboard?
I don't have a crystal ball, but I think the important thing is that touch input, voice input, and motion-based input are really not trying to solve that issue. All of these inputs are inherently less precise (just as a mouse is less precise than a keyboard). Although there are some very interesting efforts to use a Kinect to write code in Visual Studio, it seems more likely that at best, motion technology could replace only the mouse or replace the mouse for specialized types of manipulation. Speech seems to be a good way of performing out-of-band or contexual tasks (say for example you're in the middle of a coding task and want to send the current file to a team mate for review without stopping what you're doing and performing this task manually.
Rapid but precise input is what's needed for devices like the iPad to shift the trend from consuming information to creating information. This could be accomplished by new types of one-handed keyboards (which have been attempted); I have a hard time seeing that we will be able to achieve precision with devices not controlled by the human hand. Another option is a radical change in the interfaces themselves. To give an example, instead of writing code using a complex written syntax like that in most modern languages, a special language could be developed that encapsulated the structure of the code but could be represented in a format that could be more easily parsed and understood audibly. Transitions like this have already taken place in languages like LabVIEW which attempts to represent programming code in a visual format vs. a a written syntax. I have a hard time picturing how this could be accomplished, but in theory, I can see that it may be a possibility. There will be naysayers. But there are naysayers now with regards to high-level languages which already abstract an enormous amount of "what really happens" from the user.
Any thoughts on input devices and human-computer interaction as it's currently evolving?
I was delighted to browse through this book recently. A fun read for anyone interested in language. It's not a long or complex book, but really just a nugget about some interesting developments in English with plenty of historical anecdotes and references as well as an interesting list of collective nouns.
The at-first confusing title is simple an example of one of the collective nouns or "terms of venery" that come to us from Medieval hunting tradition. Other examples include a "Murder of Crows" and a "Gaggle of Geese". These collective nouns were used by gentlemen at the time to refer to groups of animals. The terms themselves were somewhat a mix of an argot and an inside joke (as many of the terms are quite playful or imaginative).
The information is not particular practical or useful, but clued me into an aspect of Medieval life that I was previously unaware of.
I kind of like the interesting combination of modern aesthetic and functionality exhibited by this sink that I saw at a WalMart restroom recently. A single piece makes installation easy, the two levels make it easier for kids and adults to use, and the slope ensures that standing water drains off. Not the prettiest thing, but I was impressed by the effort that some design engineer put into it.
Took this a few weeks back on my way to work... The contrast was simply amazing -- remarkable brighter than this iPhone-snapped picture shows. I've never a seen a rainbow that just shimmered like this.
This is over by the Tacoma Narrows bridge on SR-16, headed North at about 6:40am.
O Lord, our Lord,
how majestic is your name in all the earth!
You have set your glory above the heavens.
Out of the mouth of babies and infants,
you have established strength because of your foes,
to still the enemy and the avenger.
When I look at your heavens, the work of your fingers,
the moon and the stars, which you have set in place,
what is man that you are mindful of him,
and the son of man that you care for him?
Yet you have made him a little lower than the heavenly beings
and crowned him with glory and honor.
You have given him dominion over the works of your hands;
you have put all things under his feet,
all sheep and oxen,
and also the beasts of the field,
the birds of the heavens, and the fish of the sea,
whatever passes along the paths of the seas.
O Lord, our Lord,
how majestic is your name in all the earth!
Psalm 8, ESV
I pray that I would be
effective in my work,
disciplined with my time,
loving to my coworkers,
forward-looking in my calling,
mindful of my family,
reflecting of Your grace,
throughout the day.
Trying to do a little brainstorming here for the church software. I did just a little research and found that sure enough there are tons of products out there. The problem I'm seeing is that the interfaces seem a little less than useful and many of them are somewhat pricey. What I'd like is a "roll your own" option for any of these. Don't sell me the service or the product, sell me hosting and management if I can't do it myself.
Some new ideas based on what I found:
Facilities Management: would be nice to add. Isn't really fundamentally different than event planning and scheduling but could provide checklists, reminders, inventory (for consumable products), that sort of thing.
Childcare: Could easily integrate a check-in system for the nursery with all the data that we have.
Background, user meta-information: Useful for programs like Reducing the Risk. Basically, the ability to look at things like when a member has completed some necessary training or certification. Sad that this is needed, but it is.
Financials: After working on the budget committee this year and looking at other software, I believe that this is pretty straightforward. The big deal would be incorporating a tracker for two primary things:
1) Incoming checks and cash. Allow a weekly input where a user's check is recorded (possibly even scanned), the amount is recorded even before it's deposited with the bank. (With newer banks, it might be possible to simply upload check images). It would be very nice if users could check their own contributions online by logging in. Alternatively, any church administrator would have the information available without moving/copying Quickbooks files.
2) Outgoing checks and expense reimbursements. At least at our church we have a fairly small amount of accounts for expense tracking -- this would be easy to import and manage. Granted, this information wouldn't be available immediately in a full-fledged piece of software like Quickbooks, but what we need week-to-week and month-to-month would be adequate. Would provide immediate feedback to accountable parties for expenses that are being made rather than waiting for an end-of-month report.
3) Both of the above lead to budget tracking. With each account, if we have a weekly, monthly, or yearly budget, we can easily track actuals against budgeted amounts.
Anyway -- this is all well and good. It definitely, hugely increases the scope of work.
As a first step, I'm looking at trying to start with
1) Authentication system
2) User management
3) Scheduling system (rotating assignments with exceptions, email reminders, rescheduling/adjusting by admin only)
For our church, this is the most critical need. I'm going to be working on some models and some basic system requirements and we'll see how far I get. There's nothing there yet, but I've set up a new website here: http://steepleproject.org/ The plan will be to start formal documentation there, code repositories, etc.
If you have any thoughts or suggestions, please leave a comment!