Teach Me To Code Podcast

Miles is a great guy. We had a terrific time talking about podcasting, work, life, and programming. One major theme that keeps coming up in my life and came up in this podcast was the discussion over doing what you love to do. I met Miles at RailsConf 2009 and at Mountain West RubyConf in March. We discussed doing an interview and in this episode, we wound up interviewing each other. I think my favorite part of the discussion was the explanation Miles gave of how he formed the Ruby Brigade in his local area. I'm not really sure how to summarize the content of this interview, so I'll just let you enjoy it. Download this Episode

This week's episode is an interview I did a few weeks ago with Kevin Rutherford. Kevin is the author of Refactoring in Ruby. He's an agile coach, and blogs at http://silkandspinach.net. Finally, he has written the reek tool, which identifies code smells in your code. Kevin is a big proponent of project automation like build scripts, deployment scripts, etc. He recommends Ruby and several of the tools that are built in Ruby to provide this functionality. It turns out that Reek came out of the Refactoring in Ruby book, which stemmed from his recommendation that people use Bill Wake's Refactoring workbook, which is Java centric to people he was simultaneously recommending Ruby to. Kevin did explain that measuring cohesiveness across multiple classes or files is difficult and is something that he hopes can come into Reek. We also learned that each team needs to identify and figure out how to solve their own problems. He specifically mentions these practices: Test Driven Development Continuous Integration Mature use of version control Team Working Pair Programming Regarding TDD, there are lots of different ways of writing tests and a lot of different ways to write code to pass the tests. Kevin gives us a few examples. He also reminds us that there are four steps to TDD, not three. Write the test Write the code Refactor the code Integrate Code Metrics should be part of your integration and should be publicly visible. Teams also should publish their bug count. If you're embarrassed about your bug count, you should do something about it. You should be comfortable enough with your bug count that you wouldn't mind publishing it on the company website. Cycle time is also important. It's the metric that drives everything. How long does it take from request time to implementation time. When you get to under a week, you've truly achieved agile. Experienced programmers really understand the importance of customer satisfaction and needs over the perfectionism in your code. Your code should be solid, but your business needs to be agile too. Kevin recommends The Goal: A Process of Ongoing Improvement as reading on this topic. When asked what difference it makes in using these practices, Kevin told me that the amount of test coverage goes up, the number of tests increases, development speed grows, and class sizes decrease. Monolithic classes indicate a lack of Object Oriented design. Little value objects like currency, dates, or times can be strings or ints, but the data representation of the concepts are scattered through the code and can introduce problems depending on how the string or int is later interpreted. Code coverage does not actually represent bug free code. It makes more sense to have a team culture to write tests for each surprise or bug that you encounter (as well as writing new tests for new features.) Download this episode

Dave Thomas of the Pragmatic Programmers explains the genesis of the publishing company, Agile software, learning new programming languages, and building your own business.

Dave Thomas is one of the founders of the Pragmatic Programmers. He is a signatory of the Agile Manifesto. He's written several books, including: The Pragmatic Programmer, Programming Ruby (The Pickaxe Book), and Agile Web Development with Rails This discussion covered a wide variety of topics, including how he picked up Ruby, learning new languages, and building businesses. I think one of my favorite parts were his description of how he came to write his books Programming Ruby and the Pragmatic Programmer. For me it was valuable to get that type of view into some of the early documentation on my primary programming language. I also appreciated his insight into building code better, rather than building better code. He offered insight into code that is appropriate to the task that is being built. He offered the following questions as qualifying whether you're building code better: Does it do what the customer wanted? Can it continue to provide value so in the future? This sort of purpose driven development is really the whole point of what we do as programmers. Thank you Dave for pointing out that the important thing is keeping the practices that allow us to adapt to changes in the ecosystem our applications run in. Dave also shared with us that talent in programming is important. Like musicians, you need talent to be able to perform. You can only get so far pushing your way through programming. Can you think about things as explicitly as a computer? More importantly, rather than the introverted programmer who doesn't communicate, a good programmer has the ability to translate the customer's requirements into computer instructions. You need the ability to communicate clearly and represent the computer and its capabilities to the customer. One of the most important things you can do is find a good set of mentors. Someone who can teach you what you're doing right and what you're doing wrong. Dave shared a terrific example where he said the right thing in the wrong way and explained how his mentor approached him and what to look for in a great mentor. Here is what Dave recommends in looking for a mentor: Spend some time getting to know them. Look for people around you. Look at what they do, since you'll be modeling yourself after them. Ask them to be your mentor. If they're not willing, they're not a good mentor. Oddly enough, the person I approached after this podcast is also named Dave. If you want to know where the Pragmatic Programmer came from, Dave tells us toward the end of this episode. We pick up the discussion next week talking about his businesses and entrepreneurship. Download this Episode Here are some affiliate links to Amazon for Dave's Books:

The DRY principle is a guiding principle behind frameworks like Ruby on Rails. It's basic tenet as provided by the Pragmatic Programmers is: Every piece of knowledge must have a single, unambiguous, authoritative representation within a system. This basically means that between your database schema, code, architecture, etc. you should only have one representation of each piece of knowledge that applies to your system. This goes far beyond your basic avoidance of Copy/Paste Programming. Your code does not have to be identical to be duplicate. For example, you may have code that tells you how to build an address. This may use as business name, address fields, city, state, and zip. You may also have code that builds an address for a user, using the user's name, address fields, city, state, and zip. This is a simple example that shows code duplication. But what about mathematical algorithms. Or, an example that I just worked through at work, we're using flash and HTML authentication. Both systems need to be able to authenticate. So, how do we consolidate our code so that authentication knowledge is only managed in one place? I've also seen instances where duplicate code is hard to generalize to match all cases. In those circumstances, I ask myself the following questions. Do all of these processes need to be maintained for consistency? Or in other words, if I change class A's behavior, do I need to change class B's behavior? Is this the same process in both cases regardless of dependencies? Is there a case where one process will need to be modified to significantly deviate from the other? Am I creating more work by combining these processes than I would by simply maintaining them as they are? I'm fully aware of that after making my decision, I may not get back to modifying this code, so I have to make the best decision I can. The main concern I have is maintainability. If I can maintain things in one place, for example building code generation off of a configuration file that fans out to multiple parts of the system, keeping the implementation details in the config file. (Think about a SOAP WSDL file.) Or if I can build a configuration off of some code implementation. Or I can generate some documentation from the code. I can avoid circumstances where I can break my code in one place by changing it in another. That's the true power of the DRY principle. Download this Episode

This is take II of the Pair Programming episode. The first take wasn't what I wanted to communicate about pair programming. Please give it a listen and check out the show notes on the original recording. Download this Episode

This week's episode on pair programming discusses where you might see pair programming, HashRocket's pairing setup, perceived and real disadvantages to pair programming, its advantages, and what it takes to do good pairing. Pair programming is usually associated with Extreme Programming. It is sometimes seen as a mentoring practice, but is actually a collaboration practice, not a mentoring practice. This is because both programmers participate equally, not one leading and the other following for long durations. Pair programming is done with 1 computer and 2 programmers. I've never seen it work well with 2 computers and 2 programmers unless one computer was being ignored or under-utilized. Obie Fernandez shared HashRocket's pairing setup and much more on his blog. The setup is not cheap. It's envied by many a programmer. Some of the disadvantages of pair programming (some of which are only perceived disadvantages) are: It ties up two programmers. It would appear that you're wasting at least one person's time. They programmer not actually programming. The problem with that statement is... which one isn't programming? They both are. They're both doing the same job. And in the end, I've experienced about 1 and a half times the work done in a pair as I or the other programmer could get done on their own. So, doesn't it cost more if two of you only accomplish 1.5x the work? Maybe. The quality of the code produced by pair programming is decidedly higher. This doesn't mean that pairs can't produce bad code, but it usually reduces the chances, which leads to higher productivity later on due to mistakes that were not made. Does this account for the other half of one person's work? Like I said, maybe. It's inconvenient and reduces flexibility. Sometimes it is inconvenient. I really enjoy working on something until it's completed. If I have to switch pairs and tasks, it really bugs me that the other task wasn't finished first. You also have fewer pairs than people, which means fewer tasks being worked on at the same time. The advantages are: Flexibility: If you pair on everything, then you can contribute to anything. This is a huge advantage. My friend and co-worker measures this depth of expertise in buses. "If I get hit by a bus, we lose all of our expertise in X." Pairing and sharing increases your bus-depth. (I still haven't been able to pair with him.) Code Ownership: If you worked on each piece of the application, then you bear some responsibility when it breaks. If you spread this across the team, problems get solved very quickly. Collaboration Nothing builds team unity like solving problems together. You also get the benefit of gaining your co-workers' expertise when you code with them. Here are a few things that are critical to good pairing: Communication: How many times did Chad Fowler mention communication? If you can't communicate well your intentions either verbally or through code, then you have one guy coding and another watching. This is where you validate at least one of the disadvantages to pair programming. Ability to work together If you can't stand the guy, or stand to sit next to the guy, you can't pair with him. His odor or personality will overwhelm your ability to communicate and concentrate effectively. Skill Level The company I work for has a strong mentality for "We don't hire idiots." Weeding out the idiots or not hiring under-qualified people really makes the team stronger and pairing easier because you don't have to spend time explaining, you can spend it working. Setup Read Obie's article. He really summed it up best. It's hard to work where it's hard to collaborate. Download this Episode

Chad talks about breaking out of your comfort zone, the ebb and flow of passion for what you do, development practices, and ways to get involved in the community. He also offers great advice for new developers. Leave feedback in the following ways: 801-753-8279 podcast@railscoach.com http://twitter.com/railscoach

This is the first part of my interview with Chad Fowler. He talks a lot about the Ruby and Rails communities and about how to enhance your career as a programmer.

Test Driven Development and Behavior Driven Development can be terrific tools in defining your code and ensuring the highest quailty software. In this episode, we discuss the differences between TDD and BDD and what the advantages are to doing them.

These questions are answered in this episode: Why should we write tests? Isn't that Q.A.'s job? What should I be testing?

Understanding our customer's needs help us write code that will better serve them. Understanding how the business works and where its money comes from helps us grow the business and become valuable assets to our clients and employers.

There are 6 major tenets to enjoying your work. You should consider each of these before taking a new position. They are: Passion, Purpose, People, Progress, Projects, and Pay.

In this interview with Pratik, we discuss several things, including: Cramp - A web framework in Ruby (the repo on github) Practicing coding - Write more code Reading other people's code Rails Core 37Signals Freelancing Submitting patches to Ruby on Rails Rails 3 (the repo on github) Arel Learning to Program Adapting other people's code Testing Best Practices (the Basics) Code Organization Shoulda Webrat Download this Episode

Here is the link to my blog post about coding exercises. Here's a short list of the coding exercises that are out there. Project Euler My Project Euler Solutions Ruby Quiz Code Katas http://www.knowing.net/index.php/2006/06/16/15-exercises-to-know-a-programming-language-part-1/ http://www.knowing.net/index.php/2006/06/16/15-exercises-to-know-a-programming-language-part-2-data-structures/ http://www.knowing.net/index.php/2006/06/16/15-exercises-to-know-a-programming-language-part-3-libraries-frameworks-and-mashups/ http://programmingpraxis.com/ http://codingkata.org Here's an awesome example of a code kata: http://charlesmaxwood.com/8-lessons-from-corey-haines-performance-kata/ Programming exercises are terrific with a mentor. Check out the episode on mentors. Download this Episode