Posts tagged with 'project management'
Arthur Doler talks about retrospectives and how to make them better.
Note that this was recording at the Indy.Code() conference in a hallway, so the audio may be a bit noisier than usual.
Also, SPECIAL THANKS to the great David Giard (who has been on the show before: Episode 6 and Episode 15, and he's also the host of the excellent Techology and Friends show, of which my podcast is a pale imitation) who gave me some new podcasting equipment that I used in this episode. I am extremely grateful, but I'm still trying to figure out how best to use this equipment (which may be obvious in this episode).
Show Notes:
- Book: Thinking, Fast and Slow by Daniel Kahneman
- Hidden Brain by Shankar Vedantam
- Hidden Brain podcast on NPR
- Hidden Brain book
- Book: You Are No So Smart by David McRaney
- Arthur was kind enough to give his email address in the podcast if you want to contact him.
Want to be on the next episode? You can! All you need is the willingness to talk about something technical.
Theme music is "Crosscutting Concerns" by The Dirty Truckers, check out their music on Amazon or iTunes.
Welcome to another "Weekly Concerns". This is a post-a-week series of interesting links, relevant to programming and programmers. You can check out previous Weekly Concerns posts in the archive.
- The EFF is trying to make emails to Congress more effective. Traditionally, hand-written letters have always been seen as more effective. Let's see if this has any effect.
- WatchMojo's Top 10 Business Killed by the Internet.
- 8-bit maps of cities.
- Some rants about potentially inflammatory words or phrases when talking about software, from Jeremy Miller
If you have an interesting link that you'd like to see in Weekly Concerns, leave a comment or contact me.
Having been almost a month gone from Zimbra (aka Telligent), I'm starting to remember and notice some things that I've previously taken for granted.
One of the axioms that was drilled into me in my early days at Telligent was "no ticket, no work". Which is to say, if it's not work that's been defined and entered into the backlog and approved for work and ready to be tracked, then don't do it. There are several benefits to this approach. One is that it tends to address gold-plating and adhoc features (since I have to take the time to think about something and communicate it to the team).
But one of the things about this approach that I definitely took for granted was how this helps with tracking. For every commit I did to source control, I had to put the ticket number in the commit message. The tracking system we were using just happened to have the ability to integrate with source control, which was nice. But even if it didn't, as long as I know the ticket number, I could very easily search the commit logs and see what code changes were made for the ticket in question. This made code reviews, retrospectives, conflicts, documentation, bug fixes, etc so much easier.
It doesn't cost you but a few seconds to put the ticket number in your commit message, and a few more seconds to put in a decent commit description while you're at it.
