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.
Archive for the ‘Human Behaviour’ Category
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’. (more…)
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. (more…)
(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?
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!”
I’m moving soon! So, for various reasons, I am doing a whole load of painting-and-decorating to prepare to rent out my current flat. Today I was putting the final coat of enamel onto a radiator, and while doing this I was really noticing the remnants of old paint-drips that I had not quite sanded away in my preparation. Now, overall, I know the radiator will look a lot better tomorrow than it did a couple of days ago… but I still find those historic drips bothersome!
Last week, we had a heated discussion at work about encryption. We want to encrypt some data in our database, and I proposed that we go with a single private-key encryption mechanism (ignore which exact one for the moment), and my colleagues were pretty-much unanimously suggesting a ‘key per row’ approach. In this post I am going to attempt to explain the rough background, and why I felt their mechanism might not be best.
I’ve just worked on a little support problem that was quite interesting – although not in a good way – as unfortunately it demonstrates failures at so many stages of the specification and development process that I am quite disappointed to be associated with it. Associated, but not the cause of it, to be clear