Lessons Learned in Software Development
Henrik Warne (via Drew Crawford):
When you develop, and some tests fail, or a feature stops working, it’s much easier to find the problem if you only changed one thing. In other words, use short iterations. Do one thing, make sure it works, repeat. This applies down to the level of commits. If you have to refactor the code before you add a new feature, commit the refactoring first, then (in a new commit) add the new feature.
[…]
When developing a new system, one of the first things I do is adding logging and error handling, because both are useful from the very beginning. For all systems that are bigger than a handful of lines of code, you need some way of knowing what happens in the program.
[…]
Every developer should spend a portion of their time handling trouble reports from customers and fixing bugs. It gives you a much better understanding of what the customers are trying to do, how the system is used, how easy or hard it is to troubleshoot and how well the system is designed.
[…]
Sometimes there are several problems present that you know about. The different bugs can interact with each other and cause strange things to happen. Instead of trying to work out what happens in those cases, fix all the know problems and then see what symptoms remain.
2 Comments RSS · Twitter
Double post, Michael, should you not have noticed.
And for the off-topic news that caught my eye today, after approving iOS apps advertising Pebble support for years, Apple suddenly declared Pebble a "mobile platform", thus making those apps non-kosher.
10. Solve trouble reports. Every developer should spend a portion of their time handling trouble reports from customers and fixing bugs. It gives you a much better understanding of what the customers are trying to do, how the system is used, how easy or hard it is to troubleshoot and how well the system is designed.
0. Sit with your users, learning who they are, how they think, and what their job entails, even before you write a line of code.
...
Honestly, ever since I taught myself how to code, I've never been less than appalled at the sheer volume of supposedly professional programmers who regard teaching themselves about the actual problem domain to be completely and utterly beneath them.
I may not be a great technical coder, yet I can still run circles round such over-educated, over-paid jokers by this one simple trick of going up to users and just telling them: "I know nothing, you teach me."
Users are the real domain experts - programmers are merely dilettantes visiting that world - so why not exploit the crap out of all that pent-up ready-made knowledge and experience to create a solution that makes everyone pleased? Honestly, I will never understand other people... :/
