Category Archives: Uncategorized

Quasi-Editorial corrections of DIRTI by @ircmaxell

IRCMaxell, a fellow PHP developer and Freenode user, wrote an article on his blog, entitled Beyond Clean Code.

For me, the good point in this article is about re-thinking how much investment to make into trying to make better code, which I think is very important for a software developer to learn, so that they are able to create the highest ROI possible for their employer. No question this is an important lesson that we all need to be reminded of often. As often as every week, really.

I’ve had the opportunity to talk to IRCMaxell on ##php on Freenode IRC before. I think that he is a cool guy, with interesting depth of experience and laudable focuses on security and writing code that delivers business value. Here’re some corrections I would make to the article:

  • Dirty and Clean code are not absolutes. In my experience, some code can produce low business value specifically because it is poorly written, even if it addresses a problem that would have otherwise brought good business value. Of course, any code that manages to avoid failing to deliver the business value because of how badly it is written, is by definition good enough. At the same time, perhaps there is opportunity to maximize ROI by investing into teaching the developers how to produce better code in the future, through minimizing technical debt.
  • He understands and defines TDD as “understand the code you’re trying to write before you write it”, which is not actually TDD from what I understand based on the clarifications in places like TDD as if you meant it . In that article Keith Braithwaite calls the approach IRCMaxell describes as “Pseudo-TDD”. It seems to me that DIRTI is basically TDD, except with unit tests after the code. I would venture a guess at the choice for doing it after the code because he does not really get unit testing. I am also not very good at unit testing, and it seems extremely hard to get good at, and there is a lot of misguiding material out there, and not a lot of good material.
  • He calls TDD and Pair Programming “Methodologies”. They simply are not methodologies, because they are tools, or rather practices. An example of a “Methodology” that incorporates ( and birthed ) those two practices is eXtreme Programming.

Global Day of Code Retreat 2013, or “It’s fun to pretend people ask me questions frequently”

Hello. Welcome here, and thanks for coming. I presume you’re here to learn something about Code Retreat. Good for you. Here’s a list of questions that I am going to pretend someone asked me:

How did it go?
Great. Thanks for asking. Unlike other years, I experienced a very low level of frustration, and there are not many things I would do differently. I had fun and I learned a lot even in the previous years, but I felt that I could have prepared better, and I was always disappointed that I did not come out with a finished program from any of the sessions. This time I made a finished program before the event.

What is your hope with writing this post?
This was my third code retreat. I want to recommend it to everyone else who wants to get better at programming. At the same time, I’ve experienced significant frustration during the previous two years, and this year, I did not. I want to share my findings with people who will go, so that they can know what to expect, and maximize the amount of learning that happens.

What is a code retreat, anyway?
A code retreat is essentially a learning opportunity. More specifically, it is a learning opportunity to get better at developing software. In my opinion, it is suitable for anyone from people who do not know how to program to people who have programmed most of their life.

It is a full-day ( 9-5 ) event that is broken into six 45-minute sessions. In each session, you pair up with another attendee, and you try to learn to develop software better together with that person. The developed software is secondary, but it provides a problem to try to solve through software. We were implementing Conway’s Game of Life. After each 45 minute session, you pair up with another attendee, get rid of the code you wrote in the previous session, and start over.

Why do you go to a code retreat?
I go to learn from my peers how I can get better at developing software. I go to make myself available to my peers to learn how to be better at software development. I go to learn how to facilitate a code retreat so I can perhaps facilitate my own when the time comes.

What did you learn?
I learned many things. The answer I offered to the gathered group at the end of the day was that I learned that the best question to ask after each coding session is “What did you learn?” A nice open-ended question that places emphasis on what the point of the day is. This is contrasted to a question like “How did that go?”, or “What did you think about not being able to use ‘if statements’?”

What surprised you?
How many PHP sessions I did. How little frustration I experienced during the day. That there were only 11 attendees at the event. I was also pleasantly surprised by the open-mindedness David Wesst displayed during our session. I guess I had some prejudice about him :).

What will you do differently?
I can answer a few different questions based on this question…

What do I regret about this code retreat? I snapped at someone during the event. I wish I hadn’t. I’m sorry.

What will I do differently at the next code retreat? I can’t think of anything. I am very happy with how I prepared and what I did at the event. I feel like I seized all the learning opportunities I could have.

What will I do differently at work based on what I learned at this code retreat? I hope to continue increasing the number of ways in which I do not limit the freedom of choice of those who interact with me at work. For example, I hope to not push Test-Driven Development onto people who do not want to do it. I also hope to give up on more of the excuses I use to not do my best work daily. I hope to find more ways in which I can change my behavior to encourage more collaboration at work.

OK, but what can you tell me to help me as a future code retreat attendee?
In one word: Prepare.

It is very hard to actually finish the implementation of the game of life in just 45 minutes. You can pretty much do it only if both of you have done it before exactly the same way including algorithm, language and testing tools. If you have even one circumstance that will make it harder, it pretty much becomes impossible, so you might as well give up on that, and think about what you actually could learn. Things that make it harder are things such as:

  • You or your pair not being familiar with the programming language used, or the testing framework used, or even the editor used. Instead of trying to learn how to finish an implementation of the game of life, focus on learning/teaching about the cool features of that language.
  • You or your pair not being familiar with ideas in Test-Driven Development. Instead of trying to learn how to finish an implementation of the game of life, focus on learning the mechanics of how to do TDD and what benefits of TDD the more experienced half has seen in practice.
  • You or your pair is not deeply familiar with the Game of Life. Instead of trying to finish an executable implementation, focus on exploring what a finished program might look like, and explore the algorithm with which one could implement the game of life.

The purpose of the event is to learn from your peers. What you learn is open-ended, so don’t limit yourself if you see an opportunity to learn something you or your pair thinks you should learn. In each session there are multiple things you could pursue trying to learn, but if you’re paired with someone with considerable experience with something, you should probably take advantage of that. In each pairing, it might be good to learn what are some of the strengths of the person you’re paired with, so you can focus on those things. From the other side, knowing what you’re good at can help your partner for the session understand what opportunities are available to them.

Another thing to consider is that you’re learning how to be good at pair programming, not just programming. Pair programming brings in the social aspect, and because of that, social skills are also available to be learned.

So the common things available to get some hands-on experience with at a code retreat, and meet someone who has considerable experience with it, are:

  • How to develop software in a pair?
  • How do my skills compare to my peers in some aspect?
  • How to program?
  • How to program with a specific language?
  • How to do unit testing?
  • How to do acceptance testing?
  • How to use a particular testing framework?
  • Why does a particular activity exist as part of a code retreat? What is it trying to teach me?
  • What does a program that implements the Game of Life do?
  • What are different ways one might implement the program for the Game of Life?
  • And many more…

I’m sold! When’s the next one?
You can reply to this tweet one of the organizers sent out:

Im organizing a code retreat. Would you like to come out?
Yes, I’d love to! Just leave a comment or get in touch.

I’m organizing a code retreat. Can you help facilitate it?
I’d be honoured to! Thanks! Just leave a comment or get in touch.

Can I ask you a question ( about the code retreat )?

Absolutely – whatever is on your mind. Comments are open, so ask away, or get in touch in another way.

WTF? This post is toooooo looong!
I’m sorry. You definitely won’t want to read this collection of questions and answers that did not make it into this post.

Global day of code retreat 2013 pt. 2, or “simply TMI”

Was there a retrospective?

Yes. There was a retrospective at the end of the day, and there was conversation in between sessions. The three questions below were asked of each attendee at the end of the day. I personally think that having more retrospecting as part of the event could be beneficial to the goal of maximizing the learning that occurs. I find that I always want to have a longer conversation in between the sessions, but the facilitators often interrupt it – perhaps that’s why they’re the facilitators, because they know better. I’d like to try that each attendee answers all three questions after each session, and then allow for others to tell us what they can think of based on our answers.

What programming languages did you use this year?


To my surprise, I used PHP in all but one session. Previous two years I did not use PHP in any of the sessions I did. This almost certainly contributed to the very low level of frustration I experienced this year compared to previous years. PHP is generally laughed at by programmers who do not program with it, undeservedly in my opinion, so that was also why I was surprised. As for a reason why more people were interested in using PHP, I would be interested in the premise that WordPress deserves the credit. Perhaps I will ask the people I paired with to hear why they chose PHP for our session.

Can I see the code you wrote?


The direction given at code retreat is to delete the code after each session. I prefer to keep it around, so yes, you can see the code here. Though it probably will not be very useful to you.

What activities would do you think would be cool for code retreats?

Each session is often characterized by the “activity” that is being tried out for the session. The facilitators pick an activity that is intended to teach the participants something about creating better software. This is the activity catalog from the official code retreat website.
Through my explorations of software development as it is done by various people, I think the following would be interesting activities:

  • No implementation — all the code written is not taken to the point of actually being executable. This is designed to get people to think about expressive code, how algorithms should be written down in software, while freeing them from having to think about how must I write this in order to get it to “compile.”
  • Procedural code only / No objects — People often think of their use of object-oriented code as something inherently good. Procedural code is often thought of as inferior. I have not learned this yet, even though I’ve been trying to. Another way to say this is the way a famous software developer, Martin Fowler put it: “The OO community may have ‘won’ in the sense that modern languages are dominated by objects, but they are still yet to win in that OO programming is still not widely used.”
  • Outside-in — You have to start at the outermost part of the program instead of starting at some internal part. To understand this, you have to think of what does a finished program, that implements the Game of Life, do. I’ve come to think it accepts an initial ( seed ) pattern, and then returns all the states the game goes through. I think this would be useful to allow people to think of the exhibitable behavior of the program instead of spending all their sessions talking about some internal implementation details.

What did you listen to while writing this post?


I listened to:

You can find both albums on iTunes – Kendrick Lamar, Substantial.

Why did you bring a silver suitcase with a sticker that says “Important” on it?


Because I’ve experienced the benefits of “getting yourself out of your comfort zone” many times.

Sounds like you had a good time. Do you wanna take this opportunity to thank anyone?


Yes! I definitely had fun, I learned a lot, and I am grateful to everyone involved. Specifically,

I would like to thank the sponsors:

I would like to thank the facilitators:

I would like to thank the people I paired up with. I know I am not the most easy going person often, and tend to manipulate conversations without letting others contribute as much as they could:

Is the Yellow Dog Tavern a good place to reflect on a code retreat?

Absolutely.