June Developer Challenge: Share the Knowledge

Note: This was originally posted to the Dynamo Blog.

Last month we leveled-up with Crush Your Achilles’ Heel. This month, it’s about helping your team members level-up with “Share the Knowledge”. This month’s focus is about sharing knowledge with your team mates. After years as a solo freelancer, one of the great joys I now experience working with a team, is the learning gained from my team members. I also love sharing what I’ve learned. However, we need to be proactive about sharing to allow others to benefit.

This month, your challenge is to take what you learned from last month’s challenge, and share it with your team members. At Dynamo, we have a number of avenues for sharing information with others. These include:

• Workshop Wednesdays: Lunch-time sessions for presentations and discussions
• Dynamo Central: A wiki hosted on GitHub to share process and procedures
• Dynamo Blog: This blog to share with the greater design and development community
• Dynamo Retreat: A yearly event to review what’s working, and what’s not

So choose something valuable from last month’s challenge to share. If you didn’t complete the challenge, I’m sure you have something else. Do you have a checklist or procedure documented in your notebook? Do you have a process that you’re benefiting from, but no one knows about it? I encourage you to share this knowledge as a presentation, a blog post, or simply as a checklist on the wiki.

Your Developer Challenge for the month of June has been issued! Please let us know what you attend to share this month in the comments below.

May Developer Challenge: Crush Your Achilles' Heel

Note: This was originally posted to the Dynamo Blog.

We all have it. It’s that gap in our knowledge that slows our development down. It’s your Achilles’ Heel. Every day we use the same tool, but we’re never really take the time to understand the fundamentals of how it works. This might be Git, SQL, or Regular Expressions. It might be a concept that we struggle with, but have never said, “OK, I need to dedicate some time to really understand this”. So this month, it’s time to crush it.

Inspired by RailsConf talk ”Nobody will Train You but You” from Zach Briggs, your challenge for the month of May is to identify a weakness in your development knowledge, and proactively train yourself in that area. Since the beginning of the year, I have been proactively addressing weakness in my development knowledge. Here are examples:

• SQL: After years of working with Rail’s ORM, ActiveRecord, I felt my knowledge of SQL beginning to wane. I went back to basics and completed Standford University’s course on databases. After this course, I had cleared out those SQL cobwebs, and back to feeling comfortable working at the SQL console again.
• NewRelic: Normally I use NewRelic in periods of stress, trying to resolve a performance issue. This means revisiting and learning the UI while I’m trying to solve a problem. By dedicating two afternoons to reading the documentation and reviewing a live application’s metrics, I feel much more prepared to dive in when there’s a performance fire.
• Performance Optimization: I’ve addressed performance in an ad-hoc manner in the past. To resolve this. I have dedicated time to review various resources on performance including the Scaling Rails series (which is developed a couple a few years ago, but still relevant). This resulted in a cheat sheet that I actively use to think about performance from day one.

But this challenge doesn’t end with passively reading a book or watching a screencast. It’s about reinforcing your knowledge by sharing with others. You really understand a topic, when you share it with others. So after spending the month learning, next month I encourage you to write a blog post, perform a workshop or write a test suite demonstrating what you have learnt.

So here’s the plan:

1. Take the week to identify your areas of weakness. As you go through your day, write down these areas as you experience them.
2. Pick an area at the end of the week to work on. At this point, you might want to consider how you will share your knowledge. Please share your topic in the comments below.
3. Develop a plan on how you’re going to improve your knowledge. Don’t try to be too ambitious, keep your goals realistic. Think SMART.
4. Work through your plan for the month.
5. At the end of this month commit to how you would like to share your knowledge. We will prepare to share our knowledge in the month of June.

OK, your Developer Challenge of the month of May has been issued! Please don’t forget to share your topic in the comments below. Good luck with crushing your Achilles’ Heel.

April Developer Challenge: Feature Development With Pull Requests

Note: This was originally posted to the Dynamo Blog.

This month’s Dynamo Developer Challenge has been inspired by our own Daniel Wright—more about that in the moment.

In a nutshell, for the month of April we will be experimenting across the studio with using Pull Requests to develop a new features. We are moving beyond simply using them as a Code Review tool, as we have in a past challenge.

Over the last few months, Daniel has been religiously using Pull Requests to push new features. As I’m a bit of GitHub stalker I love seeing this, as it gives me a chance to provide feedback on commits and putting Code Reviews into practice. However, these Pull Requests were created once the feature was deemed “done.”

After viewing Zach Holman’s slides from a talk titled GitHub: Behind the Feature, Daniel began creating Pull Requests at the start of a new feature. And I’ve been impressed by what I have seen so far! But I don’t want to get a head of myself; I’ll share some observations at the end of this challenge.

So, how does this all work?

Here’s some steps, based on the write-up Daniel did for his current project:

1. Choose a feature to implement, and create a new Git feature branch for it.
2. Once you’ve selected your feature to work on, you’d create a new branch for it: git checkout -b features/your-new-feature
3. Now do a very small amount of work, just enough that you can commit it. For example, you might create the view-template you’re going to use (e.g. app/views/pages/about.html.haml).
4. Now commit it! git add . && git commit -m "Adds about page template"
5. Push your branch up to GitHub: git push -u origin HEAD
6. Finally, visit the project page on GitHub and create the pull request. Since you just pushed the branch, the project’s landing-page should prompt you to create the pull request. Give it a descriptive title, and describe what you’re planning to accomplish with the PR. For a simple integration job, this should be fairly straightforward, but you can be as descriptive as you like.
7. Submit the pull request!

So, the April challenge has been posted for our Dynamo-Devs, but we encourage you to join us too. Are you up for the challenge? Please share you experiences in the comments along with our team’s.

For a little more background on this development strategy, checkout the slides below:

Developer Challenges: Helping Us to Improve Our Craft

NOTE: This was originally posted to the Dynamo Blog.

We’re sharing an initiative that we’ve been experimenting off and on over the last year called “Improving Your Craft”, a.k.a Dynamo Developer Challenges.

These began as weekly challenges to help the team members and the team as a whole to improve development practices and increase developer happiness. Admittedly, when I was first driving this initiative, I was infrequent in posting these challenges, and the weekly schedule was a little too ambitious. Based on feedback from the team, we reduced the frequency to a monthly schedule, and I’m more disciplined in posting challenges each month—a calendar reminder really helps!

Here are some examples of the challenges posted to date:

• Self-Directed Morning Code Review
  Inspired by Jason Fried’s post Morning tells the truth, this challenge asked developers to review their commit log from the previous day as a self-directed code review.
• Pull Requests for Code Reviews
  This time it was Zach Holman’s talk How GitHub Uses GitHub to Build GitHub. The driver for this challenge was to encourage developers to review each others code, pollinating knowledge across projects. If you’re not currently using pull requests, GitHub has some great documentation on the topic.
• In-Person Peer Code Reviews
  As an extension to the previous challenge, developers were asked to sit down with a peer for a 30-minute code walkthrough. It’s amazing how much the author of the code learns by just walking someone else through it.
• Automation
  A final example was encouraged developers to start thinking what they can do to optimize their workflow. Too often we run the same set of commands everyday, when a simple shell alias can save us from repetitive typing or making a time-consuming mistake.

Hopefully this gives you a feel of the type of challenges that the team has been working on. And we would love if you joined us! Previously, these challenges have been posted to our Basecamp account, but we will now be posting them to the blog. I encourage you to share your experiences in the comments and the team will be sharing their as well, either as comments or blog posts (hint, hint!).

Although I’m a little late this month for April’s challenge, please be on the lookout tomorrow.