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.
The problem: Take an integer column with a value like 123 and output it as four digits, prefixing with zero if necessary, i.e. 123 gets output as 0123. You get situations like this if, for example, you store e.g. the last four digits of a card number as an integer-type, and then try and output it. As some cards will end 0xxx this means you have to be prepared to recreate the leading zeroes when displaying the value later. Here are two approaches to solve this problem.
A couple of years back I was given a set of Dicken’s novels, and have been reading them intermittently over that time. I’ve just started reading ‘Our Mutual Friend’ – which has been harder-going than several of the other books I’ve seen so far… but there have been a couple of nice little sections which I thought I would note here.
There is an apocryphal tale that goes something like: A man has a problem with his boiler that continues for months and causes him no end of bother. Finally, an expert comes to see the boiler, and the expert taps the case a few times, tweaks a fitting… and then charges the man a large sum of money. The customer is surprised and exclaims: “But you only did 2 minutes of work!”, to which the expert replies: “You are not just paying me for my time today, but the ten yeas of experience that I have!”