If you didn’t get yourself a 2012 Software Craftsmanship Calendar, I hope you’ve at least been following along with my blog posts. My favorite of the months is finally here. In the 2012 Software Craftsmanship Calendar, we included our own variation on an anti-pattern. December is Calendar Coder month.
Jesse Williamson had a spectacular tweet that confirmed exactly what we were looking for when we came up with this idea.
Just got trolled by my 2012 Software Craftsmanship calendar. Well played, inanimate object, well played.
Yes, that’s right. After you’ve followed along with the calendar all year, accepting guidance as the calendar turns anti-patterns into jokes that make you rethink some bad practices, the calendar turns on you. I really think that the calendar is useful, but there is no substitute for thinking. Make sure that what the calendar says makes sense. Blindly following everything the calendar says to do is just silly.
Do you recognize from which anti-pattern we derived this one?
It’s called by many names: cargo cult, angry monkeys, etc. If you’ve ever heard the story about needing to cut the ham in half before you bake it, that’s the same story. It is the practice of following along without knowing why you’re doing something. If you read the calendar and don’t know why you should do what it says, you’re a Calendar Coder. If you learn why, agree with the reasoning, and it’s applicable to your situation, then you will want to follow what the calendar says. Don’t just blindly follow along though.
I hope everyone enjoyed the calendar. If you did, the new ones for 2013 are on sale right now.
Buy your 2013 Software Craftsmanship Calendar today!
One of the most well known anti-patterns is copy paste programming. I am sure that every programmer has done some copying and pasting of code. It’s easy to do and can make writing code a lot faster than just writing new lines for everything.
You might have done something very similar to what you need now. All you have to do is copy the previous code and update it to fit your current needs. What could possibly go wrong?
I don’t think I need to explain why this one is bad. I think it’s easiest to just say that more code means more maintenance. It makes things messier, harder to read, and harder to change.
The month of September 2012 is the Copy Paste Programming month in the NimblePros Software Craftsmanship calendar, so consider this your reminder to stop copying and pasting code. You should know better already.
I loved how well this image turned out. I’m sorry though, it’s not OK to copy and paste your code. No, it doesn’t matter that you’re making slight changes each time you copy it. Just don’t.
One of the agile communities mocking terms of the old-fashioned Waterfall development technique is, “Waterfail”. It is called this, because the community credits this technique with being part of why a lot of projects fail.
The main difference between this technique and most agile techniques, is that waterfall does one big flow of everything. It does not loop through the process as most agile techniques do. It attempts to have everything planned out so that you’re just going through the motions toward success.
I’ve been posting each of the topics from the NimblePros software craftsmanship calendar as we get to the month. With each of these, I am mentioning that you should work on trying to follow the good practice or avoid the anti-pattern. Since this year’s calendar is on anti-patterns, it included Waterfail as something to avoid.
So for the month of August, I am going to recommend trying to move away from Waterfall. I’m not saying that you should suddenly move from a Waterfall project to some form of an Agile project. At least start looking into the possibility. Read a book on agile, go to an agile or software craftsmanship user group, access online resources for learning agile techniques, or attend a conference with an agile track.
I really liked how well this image turned out, and if you didn’t notice, we wrote “Waterfall”, but we cut part of the first “L” to make it appear to say “Waterfail”. Just one of our subtle little tricks in the calendar.
Go here for a more thorough analysis of Waterfall.
Almost three years ago, Steve Smith, Rich Henning, and I founded the Hudson Software Craftsmanship Group (HudsonSC) in Hudson Ohio. We scheduled our first meeting for August 19, 2009 and we had plenty of people show up. Since that time, similar groups have sprung up in NE Ohio and other areas around the country. It’s really neat to watch as the software craftsmanship community grows. There are other groups, dojos, workshops, etc. all over the place.
Our group has been a model of other groups around the area as well. Brian Friesen attended one of our meetings as a bit of research before starting the Knoxville Software Craftsmanship Group. Brian Friesen is quite dedicated, because the drive up to HudsonSC is over 8 hours. What that means is, if you’re in that area and want to attend a meeting with a dedicated software craftsman, check their website regularly they’ve always got their meetings posted.
Our number of attendees fluctuates between highs of 20-30 people down to lows of 5-10 people. We’re usually somewhere between 10 and 20 attendees. These numbers are great for a group like ours. If you get much larger than this, it becomes nearly impossible to have a discussion.
How Software Craftsmanship Groups Stand Out
We’re not eyes-front, pay attention to a speaker kinds of groups. If that’s what you’re looking for, HudsonSC is not for you. There are plenty of groups that meet every month across the world that have this format. We focus on discussions and self-organization. Our members suggest topics they want to discuss. We try to get everyone contributing instead of just taking notes on someone else’s “wisdom”. Everyone in our group has something to bring to the table and adds value to the community as a whole. You can take notes after the meeting.
HudsonSC’s Agenda:
- Introduction
- Lightning Talks, Show and Tell, and Opening Discussions
- Open Spaces and/or Group Discussions
- Exercises (usually programming)
Our members bring laptops to the meetings so that we can write some code and pair with other people. Our group is not buried in their laptops nor is it tweeting away. When you attend a software craftsmanship group, you participate in the event. You are the speaker!
Third Anniversary
As I mentioned at the beginning of this post, it’s been nearly 3 years since we founded the group. Our third anniversary meeting has been scheduling and you can sign up for it now. The event is going to be held on August 15, 2012.
To celebrate this event, we’re going to have a spectacular evening or talking, discussions, and programming exercises.
I look forward to seeing you at our next HudsonSC. If you’re not in the area, go check out your nearest software craftsmanship group!
Sign up for HudsonSC here!
http://hudsonsc0812.eventbrite.com/
Programmers are talented, smart, skilled professionals. We put in lots of our own effort to educate ourselves and stay up on current technologies. We work hard and we feel great satisfaction in our achievements. We donate our time to charities when the opportunity arises. We give back to our local communities. All things considered, there are a lot of really great programmers in the world.
I lead a team of software developers. Does that mean I am the “best” programmer on the team? Certainly not. It just means that I lead the team. As the leader of the team, it is my job to: inspire, encourage, trail blaze, and motivate my team to be the best they can be. So who is the best programmer on my team? I don’t know, and I don’t care. There shouldn’t really be a “best” programmer on the team. Everyone on the team is great and working hard.
A team that really meshes and works well together doesn’t let egos get in the way. It doesn’t matter if you’re a rock star developer. When you’re on the team, you’re part of the team. You might be the JavaScript expert, the master of SQL queries, or the guy who can refactor anything. When you’re part of the team, you should try to use your strength, but don’t let that interfere with the team’s flow.
Sometimes it makes sense for a more experience developer to work with a less experienced developer. A common first instinct is that the senior person is mentoring the junior person, but it’s actually going both ways.
Each of the two developers is bringing a lot to the table. Their different experiences and views allow them to each approach the problems differently, ask different questions, and apply different, existing knowledge.
If either person’s ego gets in the way, it would prevent the 2-way knowledge transfer in addition to creating friction between them.
<p><a href="/images/files/WP_000541%5B5%5D.jpg"><img style="background-image: none; border-bottom: 0px; border-left: 0px; margin: 4px; padding-left: 0px; padding-right: 0px; display: inline; float: left; border-top: 0px; border-right: 0px; padding-top: 0px" title="WP_000541" border="0" alt="WP_000541" align="left" src="/images/files/WP_000541%5B5%5D_thumb.jpg" width="300" height="225" /></a>One Developer and one Junior Developer can pair on a task and share knowledge. Does one act like the other one is just along for the ride? No. </p> <p>Your pair partner, is watching your back, guiding the team, and keeping the pair honest. Which one does that job? Both. If you had one person drive the whole time, you’re not going to see the benefits of pair programming. </p> <p>If you let your ego get in the way, you might not let the junior developer write any of the code. They may not know every library, every design pattern, or even the intricacies of the language they’re using, but those guys can write some great code.</p> <p>I don’t know how the Junior Developers are on your team, but ours write great code and show a high level of professionalism in their work. </p> <p><a href="/images/files/RichAndEric.jpg"><img style="background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; display: inline; float: right; border-top: 0px; border-right: 0px; padding-top: 0px" title="RichAndEric" border="0" alt="RichAndEric" align="right" src="/images/files/RichAndEric_thumb.jpg" width="300" height="225" /></a>And sometimes you get a Junior Developer pairing with the Developer Intern. How the pairs split up doesn’t really matter. Who is working with whom doesn’t really matter. Each and every member of the team is bringing something to the table, and it is this interaction that is making the team as effective as it is. These two are as productive a team as any other pairing that we’ve got. </p> <p>Someone is probably reading this and thinking I am crazy for letting a Junior Developer and a Developer Intern pair together. They’re good though, and they really get great stuff done.</p> <p>We can accomplish a lot of stuff when our team works individually, however, we can accomplish a lot more as a group. You might be the “best developer” on your team, but if you keep thinking and acting that way, you’ll be missing out on a lot. I learn a lot when I pair with <em>any</em> member of my team. It doesn’t matter how much experience the person has. Everyone knows <em>something</em> I don’t, and no one approaches the problems exactly the same way I would.</p> <p>There is no “Ego” in “Agile Team”, so don’t bring yours to an agile team and expect good results.</p>
