Today a colleague was looking for a TDD poster that showed Red-Green-Refactor with detailed emphasis on Refactoring. We found a diagram that simply said "refactoring = removing duplication". This got be thinking about a post by JB Rainsberger in which he said: "...if you master removing duplication and fixing bad names, then I claim you master object-oriented design." (If you see this, JB, do you still make this claim?)
There are lots of kinds of duplication, and JB's assertion makes sense to me especially when I think about the kind of informational duplication (as opposed to code duplication) that DRY is intended to avoid.
Thursday, November 17, 2011
Sunday, September 25, 2011
After Agile Coach Camp 2011
I spent this weekend at Agile Coach Camp in Columbus, Ohio. It was my first open space conference, and I loved it! Learn about Open Space unconferences on Wikipedia. I won't even try to explain it.
Friendship, community, sharing, equality, questions, suggestions, personal revelations, self-examination, laughter, fun - I received all these things and more. Zee Spencer summarized some of the sessions here, and I'm sure there will be others. There's a picture of the sessions board showing most of the Saturday sessions.
You can get a small taste of the amazing energy of the event by reading the #accus hashtag on Twitter.
In 2012, Agile Coach Camp will be in Minneapolis. If you can, you owe it to yourself to go.
Friendship, community, sharing, equality, questions, suggestions, personal revelations, self-examination, laughter, fun - I received all these things and more. Zee Spencer summarized some of the sessions here, and I'm sure there will be others. There's a picture of the sessions board showing most of the Saturday sessions.
You can get a small taste of the amazing energy of the event by reading the #accus hashtag on Twitter.
In 2012, Agile Coach Camp will be in Minneapolis. If you can, you owe it to yourself to go.
Friday, September 9, 2011
Advice for someone wanting to get (back) into software development
I was talking to a friend today who was doing software development several years ago but has been unemployed for a while. He asked if I had any ideas about what he might to to get back into software.
(An an aside, Patrick Welsh already wrote a great piece about why people should consider a career in software)
Here are some of the thoughts I gave my friend on how to get (re)started in the industry:
- If you don't have work experience to show on your resume, create relevant non-work experiences and structure your resume to show them.
- If you're not already on Twitter, set up an account and use the search function to find experts in the areas you are interested in. Follow them.
- Attend groups/events where people who do what you want to do gather. Ask people questions about what they do. Ask what blogs they read and who they follow on Twitter.
- Start learning web programming, throw up a website, publish the code on someplace like github, and keep updating it. One place to start might be: http://railsforzombies.org/
- Expose yourself to new languages and technologies: ruby, scala, functional languages, automated testing, continuous iteration ...
- If you're not currently working, ask about an internship someplace you'd like to work at, even if it has to be unpaid.
- Be helpful - volunteer for anything related to your targeted field. People remember/like you better if you've helped them. Less cynically, it gives people a chance to see who you are and what your attitude and skills are.
- Don't get hung up on getting/finishing a degree if you don't already have one, especially if it would take away from getting real life experience.
- Read this book about managing your software career:
"The Passionate Programmer: Creating a Remarkable Career in Software Development" by Chad Fowler
- Consider reading this book about agile software development:
"The Art of Agile Development" by James Shore
Finally: Don't follow my advice without deciding for yourself if it makes sense for you. Ask other people about it as well.
(An an aside, Patrick Welsh already wrote a great piece about why people should consider a career in software)
Here are some of the thoughts I gave my friend on how to get (re)started in the industry:
- If you don't have work experience to show on your resume, create relevant non-work experiences and structure your resume to show them.
- If you're not already on Twitter, set up an account and use the search function to find experts in the areas you are interested in. Follow them.
- Attend groups/events where people who do what you want to do gather. Ask people questions about what they do. Ask what blogs they read and who they follow on Twitter.
- Start learning web programming, throw up a website, publish the code on someplace like github, and keep updating it. One place to start might be: http://railsforzombies.org/
- Expose yourself to new languages and technologies: ruby, scala, functional languages, automated testing, continuous iteration ...
- If you're not currently working, ask about an internship someplace you'd like to work at, even if it has to be unpaid.
- Be helpful - volunteer for anything related to your targeted field. People remember/like you better if you've helped them. Less cynically, it gives people a chance to see who you are and what your attitude and skills are.
- Don't get hung up on getting/finishing a degree if you don't already have one, especially if it would take away from getting real life experience.
- Read this book about managing your software career:
"The Passionate Programmer: Creating a Remarkable Career in Software Development" by Chad Fowler
- Consider reading this book about agile software development:
"The Art of Agile Development" by James Shore
Finally: Don't follow my advice without deciding for yourself if it makes sense for you. Ask other people about it as well.
Saturday, June 25, 2011
Coding in the Clink IV - my second coding retreat at Marion Correctional Institute
On Saturday, I attended Coding in the Clink IV at MCI. It was great to see the inmates again. We all agreed they have made great strides in their learning since the last time we worked with them in March.
This was my second time spending a day programming with inmates at MCI. The first time in, I got to have my stereotypes blasted. As I said in my previous post about Coding in the Clink, one thing that struck me most was how similar the day was to a full-fledged CodeRetreat on the outside.
This time, I was reminded all day of just how careful I need to be when pairing with or coaching a less experienced developer. If I'm not careful, it's easy for me to press ahead with my own ideas and simply explain to my pair what I'm doing. That doesn't always leave my partner room to struggle with ideas, and in that moment I'm not letting them succeed in solving a problem or explaining something to me or probably other ways.
On the outside, while pairing in this way is not what I strive for, a little bit of it isn't necessarily a disaster. Unless they are in way over their head, most devs I pair with will assert themselves and claim their role a partner, even when I'm not sharing well that day. When that happens, I often "wake up" and start "playing nice" again.
But in prison, inmates are predisposed to not assert themselves to outsiders. Dan Weibe mentions it in his post "But-but there are CRIMINALS in prison!":
To some extent, I let myself fall victim to that this weekend at CitC IV. I still think the inmates that I paired with had good experiences this time, but I would have liked to offer them more. Looking back to my first visit to MCI, I was better pair/coach that day, doing a good job at things like:
This was my second time spending a day programming with inmates at MCI. The first time in, I got to have my stereotypes blasted. As I said in my previous post about Coding in the Clink, one thing that struck me most was how similar the day was to a full-fledged CodeRetreat on the outside.
This time, I was reminded all day of just how careful I need to be when pairing with or coaching a less experienced developer. If I'm not careful, it's easy for me to press ahead with my own ideas and simply explain to my pair what I'm doing. That doesn't always leave my partner room to struggle with ideas, and in that moment I'm not letting them succeed in solving a problem or explaining something to me or probably other ways.
On the outside, while pairing in this way is not what I strive for, a little bit of it isn't necessarily a disaster. Unless they are in way over their head, most devs I pair with will assert themselves and claim their role a partner, even when I'm not sharing well that day. When that happens, I often "wake up" and start "playing nice" again.
But in prison, inmates are predisposed to not assert themselves to outsiders. Dan Weibe mentions it in his post "But-but there are CRIMINALS in prison!":
...The program is seen by the prisoners as a very good thing, and any attack on it ... could get the whole program ejected ... [and] life would immediately become very dangerous for the offending prisoner. Everybody knows this...Here's the part that illustrates why I have to be extra-careful to be a good pair in the prison:
... in some cases the normal give-and-take of pairing can be hamstrung when a volunteer and a prisoner pair together because the prisoner strains to be pathologically accommodating.
To some extent, I let myself fall victim to that this weekend at CitC IV. I still think the inmates that I paired with had good experiences this time, but I would have liked to offer them more. Looking back to my first visit to MCI, I was better pair/coach that day, doing a good job at things like:
- meeting the man where he is
- inviting him to try things
- asking him some questions that he knows the answer to
- asking him harder questions so he has to stretch himself to come up with an answer
- making small suggestions when he's stuck rather than giving answers
- putting aside my desire to make progress in the code in favor of getting to know my partner a little and facilitating his learning
Monday, March 28, 2011
Coding in the Clink - CodeRetreat III at Marion Correctional Institute
Since Dan Wiebe already did a great job of summarizing today's "Coding in the Clink - III" CodeRetreat at Marion Correctional Institute (MCI), he suggested I blog specifically about the two sessions I participated in.
I paired with Wes in the first cycle. He has programming experience "on the outside". Not only was he disappointed that we had to use Eclipse instead of IntelliJ, he was further disheartened that we had to work on a generic workstation that didn't have his Eclipse template(s) on it. But he got over all that quickly and we had a blast (and got some work done). Wes and I were yukking it up so much that another insider asked us to keep it down. (Wes is known in the group for his loud enjoyment.) Wes did most of the driving. I mainly suggested ways for the tests to drive the code and offered ways to break his ideas into smaller TDD steps . Wes was great about this. He feigned frustration at my suggestions while making it clear that he appreciated me keeping him "honest". It seemed to help him take a break from the all-too-common block of "I've already got it designed in my head, how do I write it with tests first?" I did occasionally contribute to our design, mainly by suggesting tests that I thought would cause interesting problems. One suggestion I made seemed to lead us down a rabbit hole, but Wes and I made the best of it by turning it into real refactoring practice (when our tests were green).
After our first session, the inside guys and we outsiders pulled our chairs into a rough circle and discussed the morning. The insiders really seemed to appreciate the learning that happens in both directions, even in pairs that have significant skill differences. One said he liked being a triple because he had the resources and perspectives of two other programmers instead of just one.
A quick anecdote about lunch: we were served "brunch" food (eggs, sausage, English muffin...) and a couple of the insiders made a point to say that we shouldn't think they eat like this all the time, that this is a nicer meal than they usually have. And overhearing them, a nearby corrections officer ("CO", never "guard") answered something like: "Don't listen to them, this is no better than what they always eat". I'm not sure what was behind this exchange. It was the only thing I heard the whole day that could even remotely be taken as playing for sympathy. Otherwise conversation was just about like what goes on at CodeRetreats on the outside: insiders asked us about what other languages we've used, they told us about their past computer experience, and two told me at lunch about a job they both worked on with a private company in Arizona from inside MCI. (I tip my hat to those guys - telephone was the only way they were allowed to communicate with their civilian colleagues, and one of the colleagues didn't initially want to work with men in prison.)
During the second (and last) cycle of the day, I was in a triple with Larry and Dave (I think). Dave was much more comfortable than Larry, and seemed to have more experience. This cycle, I was especially aware of being a coach, maybe because Larry wasn't as quick to see where Dave was going and was less assertive with his ideas than Dave was. I found myself pulled in two directions - on the one hand, I was drawing Larry out by asking him to suggest tests or suggesting that he implement code to make Dave's new test pass. On the other hand, I wanted to encourage Dave's enthusiasm and ideas. The conclusion I drew from this cycle is that I think inexperienced developers probably shouldn't be in triples unless they are very outgoing and ready to take risks. If I'm coaching someone who is shy or inexperienced or both, I'd like to be able to give them my full attention as a paring partner.
It seemed like everyone, insiders and outsiders, had a great experience. More than one insider spoke of what he learned. We worked about 9:30 to 3, so if you figure we had 30 minutes for lunch, we only had about 5 hours. Most people seemed to think that this was too short a day. Apparently, they usually have until 4:00 but were cut short today because of scheduling of other outside programs.
Many thanks to Dan, Jo Dee (Dan's "prison boss"), the COs that accommodated us, the insiders and the other six volunteers. I'd very much like to do this again.
I paired with Wes in the first cycle. He has programming experience "on the outside". Not only was he disappointed that we had to use Eclipse instead of IntelliJ, he was further disheartened that we had to work on a generic workstation that didn't have his Eclipse template(s) on it. But he got over all that quickly and we had a blast (and got some work done). Wes and I were yukking it up so much that another insider asked us to keep it down. (Wes is known in the group for his loud enjoyment.) Wes did most of the driving. I mainly suggested ways for the tests to drive the code and offered ways to break his ideas into smaller TDD steps . Wes was great about this. He feigned frustration at my suggestions while making it clear that he appreciated me keeping him "honest". It seemed to help him take a break from the all-too-common block of "I've already got it designed in my head, how do I write it with tests first?" I did occasionally contribute to our design, mainly by suggesting tests that I thought would cause interesting problems. One suggestion I made seemed to lead us down a rabbit hole, but Wes and I made the best of it by turning it into real refactoring practice (when our tests were green).
After our first session, the inside guys and we outsiders pulled our chairs into a rough circle and discussed the morning. The insiders really seemed to appreciate the learning that happens in both directions, even in pairs that have significant skill differences. One said he liked being a triple because he had the resources and perspectives of two other programmers instead of just one.
A quick anecdote about lunch: we were served "brunch" food (eggs, sausage, English muffin...) and a couple of the insiders made a point to say that we shouldn't think they eat like this all the time, that this is a nicer meal than they usually have. And overhearing them, a nearby corrections officer ("CO", never "guard") answered something like: "Don't listen to them, this is no better than what they always eat". I'm not sure what was behind this exchange. It was the only thing I heard the whole day that could even remotely be taken as playing for sympathy. Otherwise conversation was just about like what goes on at CodeRetreats on the outside: insiders asked us about what other languages we've used, they told us about their past computer experience, and two told me at lunch about a job they both worked on with a private company in Arizona from inside MCI. (I tip my hat to those guys - telephone was the only way they were allowed to communicate with their civilian colleagues, and one of the colleagues didn't initially want to work with men in prison.)
During the second (and last) cycle of the day, I was in a triple with Larry and Dave (I think). Dave was much more comfortable than Larry, and seemed to have more experience. This cycle, I was especially aware of being a coach, maybe because Larry wasn't as quick to see where Dave was going and was less assertive with his ideas than Dave was. I found myself pulled in two directions - on the one hand, I was drawing Larry out by asking him to suggest tests or suggesting that he implement code to make Dave's new test pass. On the other hand, I wanted to encourage Dave's enthusiasm and ideas. The conclusion I drew from this cycle is that I think inexperienced developers probably shouldn't be in triples unless they are very outgoing and ready to take risks. If I'm coaching someone who is shy or inexperienced or both, I'd like to be able to give them my full attention as a paring partner.
It seemed like everyone, insiders and outsiders, had a great experience. More than one insider spoke of what he learned. We worked about 9:30 to 3, so if you figure we had 30 minutes for lunch, we only had about 5 hours. Most people seemed to think that this was too short a day. Apparently, they usually have until 4:00 but were cut short today because of scheduling of other outside programs.
Many thanks to Dan, Jo Dee (Dan's "prison boss"), the COs that accommodated us, the insiders and the other six volunteers. I'd very much like to do this again.
Sunday, February 20, 2011
#RubyOnRails and partial forms
I'm working on some exercises in the Ruby on Rails Tutorial book. I noticed a lot of duplication in my new and edit views, so I thought I'd try and make it more DRY. I knew I'd need a partial, but I hadn't written one for a view yet.
I'd heard good things about the #RubyOnRails IRC channel, so now was a good time to try it out. I had to download an IRC client for my MacBook, and chose Colloquy. In almost no time, I got enough help to implement my partial. (If you aren't familiar with it in Rails 3, you can see my solution here.) I don't know why it tripped me up so much. I finally got the second argument right in the form_for correct and used it as a local variable in the submit line so that the button has the right text. And all my rspec tests pass.
I'd heard good things about the #RubyOnRails IRC channel, so now was a good time to try it out. I had to download an IRC client for my MacBook, and chose Colloquy. In almost no time, I got enough help to implement my partial. (If you aren't familiar with it in Rails 3, you can see my solution here.) I don't know why it tripped me up so much. I finally got the second argument right in the form_for correct and used it as a local variable in the submit line so that the button has the right text. And all my rspec tests pass.
gist vs pastie
I started another post (which I'll finish at another time) about using the RoR channel on IRC to get help with creating a form partial to eliminate duplication in my new and edit forms. I started writing about gist, saying it was like Pastie, and then I started looking at the difference between the two. There are enough similarities and differences to be worth an entire post, so here it is.
Gist is associated with your github account. Gist allows public and private pastes. Other gist users can clone or fork your code using a url that is created for each paste.
Pastie doesn't require a login, so it's nice for quick-and-dirty. Pastie claims to have a bot that you are supposed to be able to access right inside IRC. You send it a public message, it private messages you a link, you click the link, paste your code, click OK and the bot is supposed to announce the link to your paste to the channel. Unfortunately, I'm told it's never worked.
Pastie does have a nice feature for Rails developersthat gist does not: Ruby on Rails syntax highlighting. Apparently it has C# syntax highlighting too, but it's only mentioned in the blog.
I plan to stick with gist for now, because of its connection to guthub.
EDIT: I didn't realize that gist not-only has syntax highlighting for lots of languages, it will auto-detect based on the filename extension that you give your paste (for example, this partial that I will discuss in my next post.) Now I'll stay with gist for sure.
Gist is associated with your github account. Gist allows public and private pastes. Other gist users can clone or fork your code using a url that is created for each paste.
Pastie doesn't require a login, so it's nice for quick-and-dirty. Pastie claims to have a bot that you are supposed to be able to access right inside IRC. You send it a public message, it private messages you a link, you click the link, paste your code, click OK and the bot is supposed to announce the link to your paste to the channel. Unfortunately, I'm told it's never worked.
Pastie does have a nice feature for Rails developers
I plan to stick with gist for now, because of its connection to guthub.
EDIT: I didn't realize that gist not-only has syntax highlighting for lots of languages, it will auto-detect based on the filename extension that you give your paste (for example, this partial that I will discuss in my next post.) Now I'll stay with gist for sure.
Subscribe to:
Posts (Atom)