I'm working on a new talk which aims to address some of the issues that face developers when it comes to running automated tests. Please take my super-scientific survey so that I can take a look at the real issues facing developers, and structure my talk around them. Thanks!
As developers, we all know that code reviews are a good thing in theory. They should help us:
- Find bugs and security issues early
- Improve the readability of our code
- Provide a safety net to ensure all tasks are fully completed
The reality is that code reviews can frequently be an uncomfortable experience for everyone involved, leading to reviews that are combative, ineffective, or even worse, simply not happening.
Here is a quick guide to help you to create an effective code review process.Continue reading "Code Review Best Practices"
Yesterday I walked into the kitchen to see how lunch was going and my boyfriend handed me a knife, a part-chopped hard boiled egg and said "finish this, I need to have a shower". As you do. Apparently there were two things that needed doing - "this" needed finishing, and I needed to keep an eye on the fish.
One of the most obvious differences I faced when I moved from LMAX to 10gen were the working conditions. I don't mean like being deep underground in some dangerous situation vs being pampered by beautiful slave boys and girls. What I mean is that the working practices at one company necessitated being in the office for core hours, and at the other flexible hours and remote-working are practically mandatory.
After attending a number of conferences and events, and performing numerous interviews, I'm starting to hear the same things again and again. Since Dan North challenged all my assumptions at QCon, I'm reluctant to outright ridicule them, but I will put forward my personal opinion.
Note: these are things I have heard from multiple sources, so with any luck I am not breaking the sanctity of the
Last week I went to get my hair cut (yes, sorry, this is a story about hair). I had thought long and hard about what I wanted. I researched, checked styles online, and bought a magazine so I could show my hairdresser exactly what I was after and there would be no confusion. I was determined I would not be spending that ridiculous amount of money on something I was not going to be happy with. I was even bold enough to ask for some changes to it at the end, which I have never ever had the courage to do before.
As a survival trait for living and working in the cites1 of London, I have a set of rituals to avoid hangovers. If you are not a single person living in a city like London, you might not understand how vital this is. Most networking, particularly in the financial services industry, is done in the presence of alcohol.
So preventing the inevitable hangover is quite important to the other part of the job – the actual working bit. I'll let you into a secret and tell you my nightly ritual:
Last Thursday I was fortunate enough to get a place on the FogBugz and Kiln World Tour. I booked it before I moved jobs, and I'll be honest I had no real interest in the software. I've been reading Joel's books and blogs since my friend Brent bought me Joel on Software and made me read it (he had the foresight to know I'd want to hang on to his copy if he'd lent it to me!). I wanted to see the man in the flesh and hear what he had to say about his software. Because really, do we honestly need yet another bug-tracking / project-management tool?
I think the statement that struck me the most when I was on the Certified Scrum Master course was:
The start of the project is when you know the least about what you're doing
Which of course is absolutely true.
So why do we come up with extensive requirements, detailed design, and fixed plans at this point of time? We haven't put anything into place yet, we haven't played with the code, the customer hasn't seen anything of what we're promising to deliver.
After the acquisition of a company with offices in New York, I pestered my company outrageously until they got fed up and finally relented – they agreed to send me to the US.
To ease the transition, I chose to move onto a project which would allow me to start working in London and continue on the same team after I had moved to New York.
In the extreme over-excitement that followed my relocation, it took me a little while to realise that effectively I was an offshore resource, no different really from any of our Indian test team, and the team needed to manage this appropriately.
I learnt a number of lessons whilst playing this game. Some of these points are also valid for teams with remote resources (e.g. people working from home).