Posts

83% of Developers Suffer from Burnout

  The Covid-19 pandemic has led to a significant increase in burnout among software developers. According to a study conducted by Haystack Analytics , a firm that focuses on engineer productivity, 83% of software developers experience burnout. The primary causes cited for this exhaustion are excessive workloads (47%), inefficiencies in processes (31%), and ambiguity in objectives and targets (29%). Most areas of human activity have had to rely on technology to remain productive during the coronavirus pandemic, including implementing telework. For the most part, businesses saw significant productivity gains in 2020, directly related to the widespread use of telework. Some are even anticipating a total productivity gain of 17% over the next two to three years. In addition, through telework, 88% have realized savings on real estate expenses over the past year. Similarly, 92% expect further savings in the next two to three years. However, has maintaining or increasing productiv

Lessons for Young Programmers: What You Need to Know

 In the past 7.5 years I have supervised over a dozen programming interns and have seen hundreds of portfolios of students and graduates. In almost all of those I saw the same things that they needed to learn. One might expect that I think they need to learn specific techniques, algorithms or math, or other forms of specific knowledge. And of course they do, but in my opinion that is never the main thing. The main thing they need to learn is self discipline. The discipline to always write the clearest code you can, the discipline to refactor code if it becomes muddy through changes later in development, the discipline to remove unused code and add comments. Most of the time I spend supervising programming interns is spent on these topics. Not on explaining advanced technologies or the details of our engine, but on making them write better code in general. I always ask applicants what they think is important in being a good programmer and they usually answer that code should be cle

The Elephant In The Room

 One of the problems with being a consultant, and trying to help organisations change for the better, is that - bet your bottom dollar - the key barriers to change will sit with the people who hired you in the first place. Management are the root of 99.9% of obstacles to organisational excellence. Find a problem, pull the string and trace it back to its root cause and you'll normally find a manager sitting at the other end pulling in the opposite direction. But from their lofty perspective, all the problems seem to start at the bottom with the people who are supposed to implement the manager's vision. They don't do as they're told. They give incorrect estimates. They deliver late. Their code is buggy. They have low motivation and a surly attitude. And when the manager is the person signing your timesheets, it's all too easy to subscribe to their point of view and set about the developers with a big stick. But, as always, there are two sides to this

I Am The World's Greatest Software Developer

 I am the greatest software developer in the entire world ever. This is an extraordinary claim, of course. But I make it safe in the knowledge that nobody out there has any way of refuting me. If I said I was the fastest runner, or the best angler, or the quietest farter, then you could probably devise a way to test and disprove my hifalutin claims. But can anyone out there suggest a way to refute my claim to the greatest software developer of all time? For your argument to outweigh mine, you would need to find at least one other person who agrees with your test as to what constitutes software development greatness. Good luck with that one. In the meantime, I think I'll get a trophy made. Maybe even a crown.

Want To Scale Up Agile? Learn To Let Go.

 I keep hearing debates flaring up around and about the countryside on the topic of whether or not Agile values and practices scale up. Well, I don't get it. I really don't. With my limited understanding of what it means to be "Agile" - iterative & adaptive (i.e., evolutionary) problem solving, self-organising teams, emergent designs and so on - it rather strikes me that if what you're doing doesn't scale up then it probably  isn't  Agile. What makes me think that? Well, wherever I see these strategies being applied successfully in nature, they are being applied at the macro level. These are strategies for solving very complex problems, and I'm afraid I just don't buy into the notion that 20 Scrum teams is a fundamentally different problem - on a fundamentally different scale - to 1 Scrum team. They're both in the same very rough complexity ballpark. Frankly, I think it's the  lack of Agile-ness  (or should that be &quo

Can't Code, Won't Code - The Shortest Technical Interview

 It's shocking, isn't it? I mean, the nerve of some people! I just finished a technical interview with a self-proclaimed "build engineer" - apparantly expert in .NET, Ant/NAnt, CruiseControl, continuous integration and all that jazz. His CV claims he's been doing it since Year Dot, so you'd think he'd be pretty good at it by now, wouldn't you? So I hand him my laptop and ask him to write a NAnt script to compile a .NET project and run a suite of NUnit tests. That's kind of like the "Hello, World!" of build automation. I stay to pair with him, but, as it turns out, for nought. He didn't even try. Didn't know where to start. And that's after I pointed him to the dozens of similar Nant scripts sitting on my laptop that he could have copied from. Shocking! So I move on to the second part of the technical interview and tell him that I have a couple of C# development tasks I'd like him to try - just basic st

How Good Are Your Unit Tests?

 One question that really bugs me is: what is the average effectiveness of unit tests? Why do I want to know this? Well, because people are always asking me, that's why. I show them Test-driven Development as it is written (so mote it be), and demonstrate 100% code coverage, 100% path coverage, 100% constraint coverage and then use mutation testing to demonstrate just how really very bloody good my unit tests are. (And they are very bloody good indeed. Oh yes.) And it's usually around this point that someone in the audience puts their hand up and innocently asks: "So how far do people go on average projects?" (Because that's the level of ambition I'm up against, godammit! 90% of developers just want to not be worse than average.) And the truth is, I have no idea what the average level of unit test effectiveness is. None whatsoever. Diddly. You see, I'm a bit like the Queen. She thinks that the world smells like wet paint, because w