Have you ever changed something in your home and at work, expecting life or work to be much better afterwards, and then found yourself on a path of being forced to make several other changes – just to get the promised improvements to actually work, or to get back old functionality that mysteriously disappeared?
I have certainly experienced this myself on many occasions; but today I want to talk about one specific instance following an upgrade to new large monitors; I recently bought new monitors that support a higher resolution than I have ever used before: WQHD or 2560 x 1440. 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.
My house-move is coming up soon, and after a review of my technical books, I decided that some books simply had to be re-read. “Writing Solid Code – Microsoft’s Techniques for Developing Bug-Free C Programs” by Steve Maguire fell into this category. Originally published in 1993, it was a book I had strongly positive memories about.
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!
I recently purchased and installed a new boot SSD, and rather than worry about copying my installation, I decided to get Windows 7; and further; to move to 64 bit. I had actually previously purchased a 64 bit version of Vista, but been baffled by an issue with lack of support for VPN 64-bit software by Cisco, so I ended up overwriting it with a 32 bit install.
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.
The C# code-base I work on has hundreds of places where I have felt a boolean expression could have been used to simplify the code substantially.