In short, it depends! At Elastic Mint we take experience seriously. It’s one of the things that informs everything we do. We find that a good developer with a wealth of experience will make better decisions. They will reflect on things they have seen and done, learn from them, and then use that knowledge as and when appropriate. Although it’s a bit old now, Peter Knego makes this point in his blog here, where he analyses reputation statistics on Stack Overflow.
On 19th March Gordon and I attended a 2 day agile coding retreat in St Austell, Cornwall. Hosted by Kevlin Henney and Jon Jagger the retreat was organised for developers to discuss, practice and improve their software craftsmanship, communication and creativity. Having personally never attended such an event before I was interested to see if there was an opportunity for me to hone my programming skills to ultimately improve my performance as a developer.
I was working with a company recently where we were using Xunit as our test framework, NSubstitute for mocks, stubs etc and we ran our tests using NCrunch whilst developing in Visual Studio. At one point during the project we noticed that some of our unit tests were failing intermittently. This is more common in longer running integration tests but not so common in unit tests. When we do see this behaviour in unit tests the cause is often shared state being accessed when unit tests are being run in parallel.
I first learnt about writing unit tests following a project where we missed the deadline and spent far too long fixing and then refixing the code. I became frustrated that we would fix one thing and then something else would go wrong. When I saw how tools like NUnit and Rhino Mocks gave me the confidence to fix bugs and refactor it genuinely changed my working life. On my next project I determined to write tests as I went along and to be honest I’ve never looked back.
Like me haven’t you at times been frustrated by software that has been delivered late and not made the business impact you expected. A lot of time and money had been wasted due to assumptions being made with inadequate requirements; poor communication of team objectives and an overall lack of understanding, focus and misalignment with the overall business goals. As a developer I use interative delivery and this places emphasis on integrating learning from delivery and refining the scope and requirements.
Over the years I’ve worked on lots of teams. Some good, and some not so. But what is it that makes a team successful? There are the obvious things like the kind of people you have on the team. If the team members just don’t get on, if they don’t have the skills required to do the job, or they just aren’t interested in working hard then it’s clear the team will suffer.