I finished my last article on the project management topic with the thought:
It is common to measure the cost of what we do. But how do we measure the cost of what we don’t do, or don’t do differently?
In essence, it’s a question of how to measure the relative advantage or disadvantage of doing things one way or another.
To exemplify, I’d like to metaphorically use the notion of a trekking leader. (In many ways, a trekking leader is a good metaphor for a project manager, I believe.)
I’m talking about the kind of “project” defined purely for administration purposes, and otherwise lacking the immanent properties of a real project, such as, and most importantly, a defined goal, and a limited time.
You may have noticed that there are no categories on my blog (except the default one, which I renamed from “uncategorized” to “assorted”). It is so by purpose.
So, instead of “guessing” my categories, I decided to undertake a small experiment: I’ll wait until I’d have written enough articles, and see what categories naturally arise with my writing. My first checkpoint is at 10 posts, with an option to defer decisions for other 5-10 posts.
I’ve already used a smaller variant of this picture in my previous post, but it fits just so nicely into the whole simplicity topic, it simply must be shown in big again.
With no further words – here it is:
In my prior articles, I wrote about my views on simplicity, my objections to putting diffuse concepts into seemingly straight rules, and the risk of unintentionally sending the wrong messages therewith. Since then, I seem to keep stumbling upon stuff that somehow adds to my position.
In two recent posts, I wrote about the notions of clever and dumb code, and the possible implications of their usage in their every-day language. There’s a particular point of interest related to these posts:
A common – and very understandable – motivation for requiring code to be “dumb” is the reasoning that if the code was dumb, then less skilled – and less paid – programmers could take on software development.
This is anther example how doing (or thinking) the “obvious” is a clear sign of shortsightedness.
In a recent post, inspired by an interview with Kirk Pepperdine, I’ve presented my view about the notions of “dumb” and “clever” code. Kirk’s reaction to it prompted me to think about the topic once more.
While I’m perfectly aware that in it’s origin, the notion of “dumb code” has been meant as synonym for “simple code”, and “clever code” as a synonym for “unnecessarily complex code”, I still see issues with the adopted terminology.
Read more >>
Reading an interview with Kirk Pepperdine, I came accros the following statement:
Dumb code tends to be more readable and hence more understandable.
Every now and then I stumble upon the assertion that everybody has his special, unique gifts and strengths. Identifying them, and finding a “niche” of own, equals the discovery of a gold mine, and opens the path to a life full of success and self-fulfillment Read more >>
When I started setting up WordPress1, I came across the need to adjust the CSS. I felt immediately that messing with the theme’s
style.css would be wrong.2 Instead, I felt there should be an extra CSS file for customization separately included via a plug-in.3
I’m a skilled programmer, so I was about to quickly write the plug-in myself (I figured it wouldn’t be too hard to do it). The names that came to my mind were
MyCSS for the plug-in, and
my.css for the style sheet. But before I set out to coding, I attempted a search for it on wordpress.org.
Read more >>