Tag Archives: design


Playing in communities of practice

I love playing in communities of practice. Not many things light up my brain more than the sort of flow I can achieve when I’m embedded deeply enough in a community of practice that I can smoothly follow a technical discussion, or better yet, anticipate some-but-not-all of the structure and details of a discussion, or better yet, enter into a creative dialog with another practitioner, or better yet, achieve actual artifacts of note within the field. A minute of that stuff is worth days of small talk and regurgitated opining, to me.

(By the way, the book Communities of Practice is pretty cool, from what I was able to read before someone else recalled it.)

At a recent Ames MakerSpace meeting, we were talking about the mission of the group. There already exists a mission statement, but if I were to state my personal mission as a member of the group, it would be something along the lines of: to facilitate growth within, and connections between, local communities of practice. I suppose that sounds pretty generic, but there’s a reason: any community of practice is fun to interact with if my interlocutors bring passion*.

It also might sound strange that I didn’t mention the tools and the space. That’s because the people and connections have a lot more value to me than those. But, I should add that tools and shared space are an important part of the process by which a community of practice forms and deepens its intimacy. These, and the artifacts and works-in-progress created by the community, embody a level of sharing/communication/expression that can’t be achieved by talk alone. It’s amazing what even just a sprinkling of that stuff adds to the interactions.

Seeing and helping others succeed is a great joy for me (I assume that’s true of most other people, too). Aligning myself with appropriate communities of practice helps to ensure a somewhat steady stream of such experience.


* In my time with the MakerSpace, I’ve heard people express their passion for, among other things: web development, sewing, miniature cattle, wire sculptures, storm doors, coffee brewing, rapid prototyping, bicycles, recycling electronics, gardens, metal fabrication, alternative currencies, fish, GIS, CNC, radio protocols, ecology, intranet collaboration, solar cells, robots, CAD, image analysis, power tools, winter dress systems, … I’m just scratching the surface, but that’s already a pretty great list. As measured in units of passion-diversity-intensity-per-hour, it’s been a good investment for me.


Buggy software

Should I love or hate buggy software?

I mean, the hate part is somewhat obvious, in that it interrupts work and takes one out of flow and dammit I paid $apple and I should get orange performance, etc.

But the love part comes from the following facts:

  • in cases where I’m paid by the hour, I make the same amount of money for struggling for a hour with OPB as for doing, ya know, some real work.
  • I learn things from struggling with bugs. Not only “this crap doesn’t work in this situation” (which is commercially valuable knowledge), but also things about the technologies involved, theoretically things that transfer to other contexts. Wasn’t it Heidegger that had a whole theory about how tools are invisible until they fail to work?
  • (third entry because a list of two things is weird.)

Teaching programming

Someone (I don’t really like to mention a lot of specific names on my blog) asked me today what suggestions I might have to someone who’s about to start teaching a university course in programming in MIS. I had some fun hypothesizing about it; here’s what I wrote:

[I have to preface all my remarks with: I’ve never taught anything bigger than parts of a three-day course in the architecture of a specific application, and even then I didn’t try any of the blue-sky ideas I’m about to mention. But, if I did try to teach something like a college course, I would try them.]

My first thought is that the most important thing to emphasize is that programming is about structuring thinking and activity, and not really about the structure of computer programs, so I think a project-based approach seems like a good idea.

I’m going to just go full-hypothetical here and give a transcript of the first monologue I’d give :-). Hopefully people would interrupt me…

“Contrary to what you may have been told, programming is not really that much about languages and syntax and stringing together a series of canned solutions. Well, good programming is not about that. Mediocre programming is about that, and you can get by in the commercial sphere being a mediocre programmer, so if anyone is truly satisfied with that, we can have an independent study course where I assign you a textbook and you do problem sets and tests.

However, what I’d rather we all do is learn good programming, and by the method that I think makes most sense, which is to actually build something together and enjoy building it. Good programming is about structuring thinking and activity, both on your own and with others. It’s really just a particular discipline of problem-solving and communication, both of which I assume you all know a good deal about.

The project we’ll be doing is the software for a POS system. You might think “that’s boring”, which I hope to convince you doesn’t have to be true, and you might think “that’s quite practical”, which is true but not all that relevant.

What is relevant is that it’s something big enough that it will take the whole semester. Today is the last ‘lecture’ of the class. I mean, there’ll be plenty of opportunities to take notes if that’s your thing, but what I’ll be doing is not lecturing; I’ll be participating in the discussions that come naturally from the project, and bringing in whatever I can from my years of experience when the need arises. You’ll want to take notes on what you and your classmates say more than on what I say.

If you’re thinking about grades, and it’s OK to admit that you are, I think everyone will be graded by classmates. I won’t let you be too hard or too easy on one another, but other than that, you’ll be deciding grades. Inherent in the structure of a complete software system is some sort of assurance that what you’ve built is high-quality. So, for example, there’ll be people making test systems that will test modules that other people are making. It will be clear to both of those teams how well the other team did. You’ll be giving grades at the end of the second, fourth, eighth, and sixteenth weeks.

Speaking of teams, let’s start talking about the pieces of the system and the workflow for building them. I think we can accommodate everybody’s interests and talents somewhere in here.”…

[Some pieces of work/ideas I might bring up if they didn’t come up: user interface/ease of use, network protocols, language and coding style decisions, source control (use SourceForge and get the added effect that ‘anyone in the world might see your code’), error handling, exception handling, auditing, security, existing code and libraries, storage and redundancy, issue tracking, performance, testing, data formats (i.e. floating point is not necessarily good for financial data), customization/branding, data mining, what happens if the whole thing ‘crashes’, legacy system integration, self-check systems, …]



Fun site to put in your feed list. It’s “a daily filtration of ideas+aesthetics+amusement” inĀ  “picturebook” form.



Bars of soap slipping?

I was going to lament the slow demise of the basic bar-of-soap cell phone design, but it’s not really as bad as I thought. Surveying three top wireless providers’ phone selection, I see that 10 of 59 are in this category. So I don’t have to worry yet that by the next time I want to get a new phone, I’ll be forced to live in flip-phone hell.

Actually, that survey showed me that there are still some cool things going on in phone design. This thing from Nokia will be really interesting two generations or so forward.