2014 Prairie Dev Con’s Free Code Retreat – Registration is open!

I’m very excited to let you all know that registration is open for the code retreat organized by Prairie Dev Con. Go register here.

I always get excited for code retreats. If you have time and want to know more before you sign up, you can read my previous posts about them here and here, or get in touch and I’ll try to convince ya 🙂

WinniVote Rspec Feature Tests

I spent several hours today creating the specs for WinniVote’s signup feature.

I feel it is a valuable investment of my time for several reasons:

  • WinniVote’s current tests do not feel high quality, so hopefully my examples help other WinniVote devs.
  • I’ve been thinking about what quality tests look like for a while now, but have not had a chance to get feedback from other developers, so I’m interested what others think about my style.
  • I look forward to the further evolution of my style based on the feedback I might receive.

Winnipeg Scrum Experience Update

Another inspiring and fun meeting and conversation with Jeff tonight under the excuse of The Winnipeg Scrum Experience, Scrum Learning Series pt. 2 – The Backlog.

Caught up on the end of his internship, and what he has been up to with Rails, then chatted about people we’ve looked up to over the years, and then watched the second video of the ScrumTrainingSeries.com – The Product Refinement Meeting. I would mention that it was another opportunity for me to try to listen more than I talk in a conversation, but I am still far from being good at it! 🙂

We left excited about intention of picking an app/product to build, then creating a backlog for it. I came home to a cool suggestion from Jeff for the suggested app.

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.