In a recent assessment of people applying for graduate and intern positions at my work we wanted a way to quickly assess them as a group. Ideally we wanted to see their individual skill at work, how well they worked with others and all in under an hour for groups of up to five. So I suggested we get them to do some Mob Programming on a Kata exercise. It wasn’t something we tried before but the idea wasn’t completely out of the blue.Continue reading “Pair and Mob Programming for Interviews”
My go to tool in coaching is to ask a question. I used to try and give people advice but I learned that no one listens to uninvited advice. Telling people want to do can work in a position of authority but they wont take the time to ask why you want them to do it differently and are happy to abandon it all when you leave. So I take a different approach and ask them about what they are doing already.Continue reading “Dumb Questions”
My team has a challenge that I haven’t run into before. We all want the code to be better quality that it is now. However we don’t agree on what “better” is.
Even simple things can lead to long discussions and debates so it was a struggle to get some serious progress. Reviews could get bogged down because a refactoring someone did triggered a debate on its merit. We needed a format to allow us to work through some of the fundamentals and find where there was consensus. So I booked us in to do some mob programming together except we were not going to write new code. We were going to focus on only refactoring.Continue reading “Learning Refactoring Together”
It’s been interesting over the last year for me as I explore where coaching for software teams and coaching for sports people overlaps. This year I got to be coach for a Roller Derby team which is the first time I’ve called myself a coach for more than a brief workshop. In my day job I’m involved in many activities that have nothing to do with coaching so I rarely call myself an Agile Coach. But to that sports team I am the coach. And while I’ve been involved with Roller Derby for 5 years I have very little training in coaching sports teams so I started applying all the things I’ve learned coaching software teams.Continue reading “Coaching is a Transferable Skill”
We had a discussion at work after watching the excellent Kelvin Henney talk about good unit tests. And it helped me clarify the many roles tests play and why people get a habit of complaining about their tests getting in the way. So here is the four categories a test is trying to balance:
- Refactoring guide
Last year I got to attend a workshop on the Toyota Kata by Hakan Forss and I could immediately see how it could be useful but I didn’t have an obvious place to apply it until recently. We got some good experience with the concept using jigsaw puzzles in a group.Continue reading “Applying the Toyota Kata”
and why you should organise one too!
How lean coffee works: A few people from work got to take part in one at Agile Australia but I missed it myself. So I just got online and read everything at http://leancoffee.org/ I grabbed a bunch of index cards and texters and was ready to go.Continue reading “Things I’ve Learned from Running Lean Coffee”
I spend a lot of time working closely with programmers on the software testing process. Much of my career mission is to get more people embracing techniques like Test Driven Development. As I push more and more of the testing demands onto the developers I sometimes run into people who say they need a tester for “independent testing”.Continue reading “Can Programmers Test?”
Do you do any of these? Do you see these habits in others. Clean code is when you look at code and think “of course you would do it that way”. It’s simple, elegant, and straight forward. Once you look at it you can’t think of a better way to do it. It seems ‘obvious’ but only with the power of hindsight. But it’s not something you’ll get much of from these programmers
- The Hoarder – “I’ll add/leave this function because it may come in useful” litters your code with commented out code and unused functions that rot and bloat your code
- Over-Complicator – “I’ve built an xml like nested config value loader to read in my three values instead of using a constant” yeah thanks. And when it turns out to have a bug we’ll spend weeks trying to figure out how it all works and why you wasted company time (and money) writing it.
- Rewriter – “This 3D library doesn’t quite fit my needs. I think I’ll write my own and call it DirectY” and you waste weeks on it, it turns out buggy, has very little hardware support but by the time we find out the entire company is building on it and feels committed to keeping it.
- Obscurer – “MiscValues init function runs ReadStream to setup the CoreFactory” this is not abstract this is waffle
- The Secret Recipe – “Oh it crashed because you have to call unloadAllSettings before you let the class run the deconstructor. But make sure you call close first” so basically no one can use your code without mysterious and random crashes. Thanks for your contribution.
Programming 101 states:
Don’t copy and paste code. If you find yourself doing something repetitive then do it right so you can reuse the same code. Functions, classes and even separate files all serve this end.
Now that I’m writing tests all the time I often find myself creating Mocks. Mocks are where you tell code to use a pretend version of some functionality instead of the real one. It could be because the real one does something you don’t want in your tests (writes files, reads a database) or it could be that you’ve got some messy legacy code you can’t to pull into your tests (yet). There’s other reasons too but you get the idea.
So if I make a Mock version of a class it makes sense to try and share that with everyone else that might be trying to test with that same class. Or does it?Continue reading “Are mocks/fakes reusuable?”