We normally expect and look for simplicity in the use of a product. If it is difficult to use, we might exhibit frustration, not buy it again, or similar. As a possible example, I was recently given a small pack of anti-histamines from Canada.
Initially I was baffled by the blister packs; they appeared to be strongly resistant to pressing the tablets through the foil backing. It took a moment to understand that there is an extra step necessary with these packs, which I had not previously seen with packs in the UK:
A Partially-used Blister-pack of Anti-histamine Tablets
Today I wanted to report on my latest experiment; using a dishwasher to help me clean a Microsoft Comfort Curve Keyboard 2000. There are many posts on the internet about this, and after some research, I decided to give it a try, as I had just inherited my keyboard from work.
First decision was; How much should I dismantle the keyboard? Some people have tried running the whole keyboard through the dishwasher, but this typically seems to be followed by letting it dry for days afterwards, and involves some risk because the electronics get wet. Some suggest stripping the electronics out of the keyboard, and washing all the rest. I decided to prise off the key-tops and dishwash those, but leave the main frame safe and dry. Continue reading
Although I generally consider email spammers – especially phishers – pretty evil, it is occasionally enjoyable to receive a spam email or comment which demonstrates how dumb they can be. In this case, I received a comment on this blog which demonstrates nicely how some messages are created.
Last week I posted about Solving Problems Indirectly… and today I have a similar topic; saying, or communicating things indirectly.
It’s best told with pictures: Continue reading
More and more of late, I have noticed that the solutions people arrive at for problems are often very indirect. I have started to suspect that it may be a characteristic of human behaviour, but perhaps it is just a characteristic of my current management at work. Also, there may be room to consider this ‘procrastination’, and maybe in some way, people have got it into their heads that problems always need creative solutions – when often the opposite is true – there is a simple and obvious next step that once taken will improve the situation.
The rest of this post will outline a number of cases in my own recent experience where actions and projects have been undertaken that seem to have been quite ‘indirect’. Continue reading
I’ve written before about technical interview questions, especially of the tricky Brainteaser Interview Questions, and I wanted to take a moment to recount some recent experiences hiring a couple of DBAs.
We’ve had a technical phone interview for some time, written by a colleague, but I think mostly trawled from an internet search of database technical questions. This undoubtedly has some value, with questions on technical details on the difference, say, between a Primary Key and a Unique Key, or perhaps what ACID stands for. The problem I find is that day-to-day, a term like ‘ACID’ is almost never referred to, because it is simply (and in some fundamental way) is just expected to be possible and true of a database such as Sql Server – or we might even say prohibited by developers not using transactions. We needed more structure for the face-to-face bit, and I was fearful about hiring someone who could not even do the DBA equivalent of the FizzBuzz programming exercise.
So for the last year or more, we’ve standardised our face-to-face interview questions to focus on three areas:
- A practical Normalisation question;
- Simple SQL queries;
- Performance Investigation.
In each case, I have taken a practical example of real-world situation from our code-base as the inspiration… and it has been fascinating how helpful the approach has been to better understand the capabilities of the candidate. I hope it also introduces the interviewee to practical examples of what the role entails. Continue reading
(but please still be enthusiastic)
I have enjoyed and been very interested in several of Troy Hunt’s blog posts on security, and having had my attention drawn to one the other day, I found his post titled ‘The ghost who codes: how anonymity is killing your programming career‘. I think his assertion is unfair. In fact, my first criticism of his post is that it is somewhat tabloid in nature; compare that title with his ultimate conclusion:
Ultimately, complete lack of public profile doesn’t make someone a bad programmer. On the other hand, a rich track record of engaging with the community, asking questions, demonstrating enthusiasm and actively participating in the industry gives you a bloody good head start on the ghosts.
This seems a far more reasonable statement, and an alternate headline on a broadsheet newspaper might have been: “Engaging with New Media could make new Job Searches Easier”. Or something like that – which has less punch but might reflect the whole post more fairly.
But as much as anything else, I would like to engage in this post with the broad idea of the use of Blogs, Question/Answer sites, Twitter, and so on. Is it necessary for a programmer (or other IT professional) to engage in such activities?
I have never worked in an environment that practices Test Driven Development (TDD), but the little that I have read suggests that there are three phases: Red – The Test is written, and checked that it will fail properly; Green – The test code is rewritten so that is passes ‘by any means possible’; and finally Refactor – the code under test is refactored to produce the desired end-results for real.
The picture was taken in my office a few weeks ago. It is not faked. The output of an automated build system (Team City) is reporting how many days there have been problems with the build for; and the number of days is 42.
When an individual makes the same mistakes repetitively, you might ask why they do so, why they don’t learn (and of course; ‘Why don’t they improve?’), and so on. When the same thing happens within a professional organisation, we need to ask why the business doesn’t learn, and why the business allows the individual to continue on that path. I think I have a couple of suggestions why this might be.