Todd Sedano

Software Engineering, Improv, Craft of Software Development

Learning Test Driven Development (TDD) Through Katas

In my graduate course, “craft of software development” students created individual learning plans to accomplish their goals. Many choose to enhance their testing and design skills by focusing on Test Driven Development. (TDD)

While the data sample is low (5 students), it appears that doing katas followed by a project is preferred to just doing katas alone. By working through a kata, you practice the the skill in a very focused, tactile manner on a small problem. Once done, you can compare many posted kata solutions on the internet and use them for reflection. Then by working on a project, you can practice TDD while dealing with domain specific issues and complexities that arise from a larger problem. One student found that re-implementing a previous project was immensely valuable, as he was able to compare his new solution to his previous implementation.

Not all katas are created equal for the purpose of learning TDD. Some are too simple; some are too algorithmic in nature. (For these, creating the test suite is straightforward, yet improving running time is not.) Swapna Varghese ordered a set of katas for how easy they are to implement in TDD. Note that the ones at the end of the list are not necessarily better at teaching TDD, in fact, it may be hard to complete them using TDD.

A suggested path then would be to take an easy one (e.g. one of the first three) as a warm-up exercise to validate your test environment, and then move onto some in the middle. I’m partial towards Gilded Rose. Mars Rover was a definite favorite among my students. As with Goldlocks, it wasn’t too simple, it wasn’t too algorithmic, it “was just right.”

Exhibit 1: Katas sorted by how easy it is to apply TDD.

  1. Fizz Buzz
  2. Prime Factors
  3. String Calculator
  4. Gilded Rose
  5. Word Wrap
  6. Tennis Game
  7. Bowling Game
  8. Mars Rover
  9. Roman Numerals
  10. Coin Change
  11. Game of Life
  12. Potter

Not helpful in learning TDD: Weighing with Stones

Software Engineering Isn’t a Solo Activity

Often as engineers we like to go for it alone. It’s me versus the machine. Yet, involving others can be helpful with us in our career. In my course “craft for software development” I challenged my students to think of ways to add a social component to their software development experience. Here is some of their feedback: (list is unsorted)

  1. Ask a friend to review your code
  2. Pair program with a friend
  3. Pair program with a stranger (there are websites that do this)
  4. Attend a meetup or an unconference. Meet beginners, intermediates, and experts.
  5. Find out where people in your community hang-out (mailing list, IRC, etc)
  6. See who is around you that you might not be considering. (For example, students in a different masters program, PhD students.)
  7. Post to CMU SV facebook group.
  8. Contact alumni who might know working professionals with the expertise in the field.
  9. Posting code for review online. Post on a blog and have people comment on it.
  10. Attend a “hackathon,” “hackernoon,” or spend time at a software dojo
  11. Use linked-in to do a search on appropriate skill to see who is in your network
  12. CMU has a mentoring program in the bay area

Preparing Yourself for a Software Development Career

Sometimes people ask me, “what should I do to transition from my current career into a software development career?” Many have answered this question, but here are my suggestions.

Talk to people who are software developers. See if you will like doing what they are doing. One of my good friends entered the field not because they loved writing code, but they wanted to earn a great salary. We both finished the undergraduate computer science program at Carnegie Mellon University. He hated the courses and once he graduated, he continued to hate programming while in industry. Before you invest significant time and money into a new career check it out.

If you are going to be writing code, then you will also be finding defects. This can be a very annoying, frustrating, and unfulfilling part of the job. For example, there’s a new third-party library you will want to use (or a new language feature, or a new framework). You’ll read the API and write code that should work. But it doesn’t. How do you figure out what is going wrong. This is a hard skill to learn. Sometimes typing it into google will solve the answer, but it wont’ always work and it is clear that you don’t have enough knowledge of what is really going on. It will make you feel like an idiot. Debugging is part of the job. There are some who really enjoy figuring out why something is broken and enjoy the journey. I only enjoy the destination, working code. Teachers have to do grading. Nurses have to deal with blood. We fix defects.

Find a mentor. Find a friend who is good at software development and learn everything that they know. Write software with them. Do paired programming. If you don’t know anyone, find some one. Go where the geeks are hanging out. Search meetup.com for groups that meet in your area. If you still can’t find someone, it’s probably because you aren’t trying. If you already know a programming language, work with people in an open source project. Let them know that you want to help and could they mentor you. Several core contributors to projects began their journey this way. Learn the programming language that your mentor knows.

Learn an object-oriented programming language. Take courses at your local community college. Start going to meetups. Contribute to open source projects. If you skipped the “find a mentor” step because it is too hard, go back and do it. Working with open source projects can be a great way to find a mentor. Note that you don’t necessarily need to know an “object-oriented” programming language, but most people in industry will expect you to know the fundamentals behind object-oriented programming, so you might as well start here.

Learn the basics. Take courses at your local community college in data structures and algorithms.

While there are great books that will help you on your journey, reading will only get you so far. The easiest way to learn the craft of software development is by writing code with someone else. Once you start writing code and begin to get the basics, I would recommend checking out “Apprenticeship Patterns” and “New Programmer’s Survival Manual”

Improv Meets Software Engineering, What Might the Intersection Look Like?

When I first discovered improv, I enjoyed the creative play and sheer freedom it offered me. The basic tenets of improv gave me a safe place to unleash my creativity. The right side of my brain finally had an outlet. (I couldn’t draw or play an instrument. I did enjoy singing, but I knew not to do that in a public setting!) I enjoyed every improv exercise that was introduced to me. Finally, I had an outlet to be creative and to play.

For the longest time, I didn’t see how this could apply to software development. Deep down, I knew there must be a connection, but how could doing quick, fun exercises relate to software?

I did see how improv was affecting me and my style. My public speaking confidence was increasing. I was faster with responses to tough questions. My eye contact with others was on the rise. While I’ve been an active listener, I noticed areas that I could grow. I saw how those skills translated directly to my work. Brainstorming was more effective when we bypass the critical analytical components of the brain. Teams could be more effective if they could more readily accept ideas from teammates. (If we don’t agree with an idea, we tend not to accept it. However we can accept an offer from someone else without agreeing with it. Even with a ridiculous suggestion, good ideas can emerge.)

In preparing for the Applied Improvisors Network (AIN) conference of 2011, I reflected on software development and its intersection with improv. I came to a new realization, are not the agile methods aligned with the notions of improv? Let’s look at ideas from improv and see how they map into modern software development.

The whole improve troop owns the show. If a performer steps out on stage, they are committing to the team that they have five seconds worth of an idea and trusts that the rest of the team will help them the rest. Agile methods encourage “whole team” where the entire team responsible for ownership of software development and management. This encourage collective owning of the source code repository where any member of the team can make changes as well as the notion that the team can manage itself. Improvisators set out to make their partner look good. Scene work happens when the entire troupe is helping and working together. This includes knowing when to go on stage in order to further a scene along and knowing when not to go on stage because everything is going to work out fine.Software developers want their team to look good.

Change: Improv thrives in chaotic situations. Improvisers are trained to deal with change. When improvisers are operating at the speed of thought on stage, anything can happen, and improvers try to make sense of it all. Agile methods are more ideal than traditional methods in environments where the requirements are changing. Even Extreme Programming’s slogan is “embrace change”

Improvisers learn to be loose with their own ideas. In the dynamic environment of the stage, they need to be present in the moment, dealing with what is going on. If they are thinking too much about where they want the scene to head, they will miss out on where the scene is actually going. You can observe this when a performer says something that sounds like they weren’t listening to what was just said. The performer was “in their head” trying to plan ahead and missed the last offer from their peer. We see this flexibility in the agile principals. With Test Driven Development, software developers hold the code loosely. Code written yesterday might be refactored and improved today. There isn’t this notion of ideal or prefect software that never changes. As the situation changes, so does the code.

Improvisers work on actively listening. Extreme Programming’s on site customer provides a direct customer voice into the software development process. As the engineer understands in real time the requirements from the customer, software is developed and refined in quick coding cycles.

Improvisers have techniques to celebrate failure. This is imperative because improvisers will fail. In warm up games, improvisers that aren’t failing aren’t playing them too safely. Agile methods have quick iterations and rapid software prototyping that allows for (in a software sense) for features to be explored and “fail.” If something isn’t working right it is tweaked in the next iteration. Albeit the timeframe is different. Obviously improvisers fail numerous times during a warm up and might make unusual choices on stage, where as the timeframe on requirements churn might be the next iteration typically one week to four weeks. In a paired programming setting, ideas can be tried and experimented upon. Failure in this context may happen routinely during a coding session. Coder 1: Should this be a new class or should we modify an existing class? Coder 2: I don’t know, let’s try option 1. After a few minutes if option 1 isn’t working out, they can quickly switch to option 2.

Interestingly, the improv game “word at a time” maps into paired programming. In “word at a time” a group tells a story with each person saying only one word. This exercise teaches shared ownership and the frustration of planning ahead. Variants of the game include “one sentence at a time” or “1, 2, 3, 4, 3, 2, 1 words at a time.” In paired programming, developers work on the same code at the same time. Typically the code is shown on one monitor but there are two keyboards and two mice so that at any point in time, either developer can start typing what they are thinking. There are many benefits to paired programming including high quality product with less defects, a product that is ready to be shipped sooner, team ownership of the entire code based (as opposed to code silos owned by a single programmer), shared understanding of the code base (every line of code was written by two people, if one leaves the company someone else knows what that code was doing). Often in pair programming, developers may take turns. I’ll write a test case and my partner will make the code work. They will then write a test case, and I’ll then get it to work. This practice is called ping-pong paired programming. This is much like “A paragraph at a time” The emphasis is on the dialogue between the two engineers and the code is the artifact of the conversation that happened.

Today, I see many similarities between improv and software development. I suspect that there are new concepts in software development that might be explored given insights in improv. That is a topic of more future research.

Panel Feedback

What did you learn from the panel, and what are you going to do about it? Team Couch Potatoes / AppJour / ActiveMob Our experience with the panel this last Wednesday was of great help in preparing us for our solicitation of feedback from potential customers. One of the more important issues we addressed was that the customer panel had a difficult time, initially, distinguishing our application from that of our competitors. We will need to do a better job addressing what makes our product unique in future pitches if we want to keep listeners engaged. We also noticed that while not everyone was interested in using our application, those that were indicated that they would also be willing to pay for it. To us this means that there is a legitimate market for our application, especially for those that are already active. This was encouraging and should help us to focus our search for user feedback in the coming weeks. Team four of a Kind — In preparation for this week’s panel, Team 4 of a Kind planned a handful of new concepts for our pitch. We were looking to get feedback on both things that hadn’t been pitched in the past and to see if our older core features were compelling to new users. We introduced a name change on one of our core features from Quick Workouts to Fit Quests, a Virtual Buddy, and a pitch strategy that involved having the panelists actually go through a Fit Quest. Although the panelists agreed to do the Fit Quest, there was no feedback on how the quest felt or if the naming of the quest helped differentiate itself from the competition. A positive comment was given on the Virtual Buddy saying it gave an emotional and personal touch. This was also the first time several of the panelists heard some of the older features as well. One of the recurring pieces of feedback from first time viewers were that users felt our application had too much text, which suggests a lack of graphics. A few users also suggested the use of movies both as incentives and as tutorials to workout. Some of the same feedback that we had heard in the past that was repeated at the panel was that the fitness market already has a lot of competition and that this type of tool is too easy to cheat on. Finally, we also got feedback suggesting working out should be an individual activity and group challenges may just be a fad, which was one of our earlier discussions on deciding to emphasize quick workouts of group challenges.

Preparing for the First Panel

This is about class three (June 1st, 2011) from the course http://www.cmu.edu/silicon-valley/academics/new-course/silicon-valley-startup-experience.html

From the instructors, Scott Russell and Todd Sedano

It’s normal to be apprehensive about your first panel. It’s not clear where you are headed with your idea, and you haven’t had a chance to validate it with the marketplace. You are focused in the coding trenches trying to get something to work, it’s time to pop out and see what the market thinks of your idea.

When you meet with the panel, you’ve got to tell people how it is supposed to work. You are looking for their feedback reaction. Then you will learn how far off you are. Embrace expectation failure, you need this feedback. The panel knows that your product is “raw” and not finished. If you think you know who your target customer is, put that forward. If you aren’t certain, hazard a bold specific guess. “Our customer is film lovers in their early 20’s.” If you know the makeup of the panel, then you can see if the panel is your target customer. When you are speaking to an intellectual group in their 40’s, don’t be surprised if they don’t resonate with a product geared for Lady Gaga music fans. When presenting your product, don’t focus on what the product does, but what problem you are trying to solve. Be provocative. Tell them it cures cancer. If they don’t think your product does that, find out why. Find out how you are missing the mark. If you were selling an Recreational Vehicle (RV), you don’t sell the customer on the miles per gallon or the capacity of the septic tank, you sell them on the vision: imagine being at the lake fishing with your family. Put on your sales hat and BS about what the product does. Don’t tell them what the product is going to go. Avoid “we working towards a release one where …..” and “we think that the nominal market will be.” Instead be bold and clear. “Our product is facebook for the medical community.” Be laser focused. Be specific about the key core functionality. You aren’t going to release a product that works on every phone. “For the first release, our product works on the iPhone platform.” If people want more and more features, it’s ok to delay the features. You don’t have an infinite amount of time and money to build everything. The common user won’t understand technology. You can explain what it is and what it will do for them, but don’t get lost in Acromania. “We’ve done the hard work to build something special.” It was tough to do, but you are making it easy for them. It’s a defensible asset. Consider how you will end your presentation. What do you want from the panel? Ask them a question. You have just spent six minutes of your valuable time presenting to this panel, what is your ask? ask the panel a question. We’ve asked the teams to consider their strategy for their first panel. Here is a sample of their thoughts.

Team Coach Potatoes (Andrew Steele, Anooj Vagadia, Patrick Baumann, Henry Fung) As a development team working on an as yet unreleased product, we are looking to get as much out of Wednesday’s panel as possible. Most importantly, we will be trying to assess the feasibility of our idea and its potential worth. Part of our presentation to the panel will consist of a demo of our current features and discussion of upcoming features. We hope to gather feedback regarding which features are of value, which are not and which would be worth spending money to have. Our application is targeted specifically towards individuals who are active, which may affect the objectivity of the panel’s feedback if they are not active themselves. However, it is still important to gather feedback from non-athletes to determine if our application will be appealing or motivating to them. If the application is not appealing, we will ask if there are changes which can be made to make it more so. We look forward to Wednesday’s opportunity.

Team Four of a Kind (Alan Mak, Kevin Tsai, Matthew Lanken, Paul Wong) Our main strategy for the 4th week pitch is to focus on getting the panelists more involved with the theme and vision of the product. By doing so, the panelists would get a sense of why there is a need to use the product. Several past criticisms suggest pitches didn’t have a direct and exaggerative tone suitable for marketing, and were instead received as a simple explanation of the product. During our pitch, we plan to emphasize the magnitude and greatness of the application while being more direct in our pitch towards the panel. We plan to pitch to them as if they were the ideal target customers, and why they need to use the application. Aside from involving panelists with our tone, we will also introduce a few interactive gimmicks such as distribute four playable demos of the application, a tutorial that will guide users through a quick workout and allow them to follow along, and props to enhance the theme of fitness and quick workouts. We also plan to take this opportunity to get user feedback and weigh some of the other selling points of the application such as the virtual buddy and achievements.

Team Opinionize (Gaurav Sinha, Rob Engel, Phil Melzer, Vinay Prasad) Our strategy in the panel pitch next week is to get more feedback about the product, its use cases and reasons why people will buy or not buy it. The other important part of our strategy is to make the most of the experience the panel brings in the room. We need to understand our target customers. We believe that it could be anyone who has the problem of categorizing large amounts of data but we want to narrow down on our users. Adam mentioned that our probable users could be geeks who use / edit Wikipedia articles. For this reason, we will present a case for members in the panel to use the product, based on our knowledge of their interests. Their feedback will be valuable in determining whether the product is for everyone or not. We want to get feedback about what makes the product viral? And why? The panel consists of people who have the experience in the market and can judge what is going to hit or what is not. We plan to keep our description of the product at a very high level and at the same time we would explain the concept in simple terms, which a non-geeky person can understand. Keeping the description at a high level allows room for improvement based on panel feedback. At the same time we would like to explain the concept with daily life problems as examples so that its clear to the audience. We plan to do a live demo of Opinionize with these examples, which would help the panel get a feel of the product.

Real World Software Engineering for Entrepreneurs (a Startup Accelerator)

Preparing for your first panel – Class Three – June 1, 2011

From the instructors, Scott Russell and Todd Sedano

It’s normal to be apprehensive about your first panel. It’s not clear where you are headed with your idea, and you haven’t had a chance to validate it with the marketplace. You are focused in the coding trenches trying to get something to work, it’s time to pop out and see what the market thinks of your idea.
When you meet with the panel, you’ve got to tell people how it is supposed to work. You are looking for their feedback reaction. Then you will learn how far off you are. Embrace expectation failure, you need this feedback. The panel knows that your product is “raw” and not finished. If you think you know who your target customer is, put that forward. If you aren’t certain, hazard a bold specific guess. “Our customer is film lovers in their early 20’s.” If you know the makeup of the panel, then you can see if the panel is your target customer. When you are speaking to an intellectual group in their 40’s, don’t be surprised if they don’t resonate with a product geared for Lady Gaga music fans. When presenting your product, don’t focus on what the product does, but what problem you are trying to solve. Be provocative. Tell them it cures cancer. If they don’t think your product does that, find out why. Find out how you are missing the mark. If you were selling an Recreational Vehicle (RV), you don’t sell the customer on the miles per gallon or the capacity of the septic tank, you sell them on the vision: imagine being at the lake fishing with your family. Put on your sales hat and BS about what the product does. Don’t tell them what the product is going to go. Avoid “we working towards a release one where …..” and “we think that the nominal market will be.” Instead be bold and clear. “Our product is facebook for the medical community.” Be laser focused. Be specific about the key core functionality. You aren’t going to release a product that works on every phone. “For the first release, our product works on the iPhone platform.” If people want more and more features, it’s ok to delay the features. You don’t have an infinite amount of time and money to build everything. The common user won’t understand technology. You can explain what it is and what it will do for them, but don’t get lost in Acromania. “We’ve done the hard work to build something special.” It was tough to do, but you are making it easy for them. It’s a defensible asset. Consider how you will end your presentation. What do you want from the panel? Ask them a question. You have just spent six minutes of your valuable time presenting to this panel, what is your ask? ask the panel a question. We’ve asked the teams to consider their strategy for their first panel. Here is a sample of their thoughts.

Team Coach Potatoes (Andrew Steele, Anooj Vagadia, Patrick Baumann, Henry Fung) As a development team working on an as yet unreleased product, we are looking to get as much out of Wednesday’s panel as possible. Most importantly, we will be trying to assess the feasibility of our idea and its potential worth. Part of our presentation to the panel will consist of a demo of our current features and discussion of upcoming features. We hope to gather feedback regarding which features are of value, which are not and which would be worth spending money to have. Our application is targeted specifically towards individuals who are active, which may affect the objectivity of the panel’s feedback if they are not active themselves. However, it is still important to gather feedback from non-athletes to determine if our application will be appealing or motivating to them. If the application is not appealing, we will ask if there are changes which can be made to make it more so. We look forward to Wednesday’s opportunity.

Team Four of a Kind (Alan Mak, Kevin Tsai, Matthew Lanken, Paul Wong) Our main strategy for the 4th week pitch is to focus on getting the panelists more involved with the theme and vision of the product. By doing so, the panelists would get a sense of why there is a need to use the product. Several past criticisms suggest pitches didn’t have a direct and exaggerative tone suitable for marketing, and were instead received as a simple explanation of the product. During our pitch, we plan to emphasize the magnitude and greatness of the application while being more direct in our pitch towards the panel. We plan to pitch to them as if they were the ideal target customers, and why they need to use the application. Aside from involving panelists with our tone, we will also introduce a few interactive gimmicks such as distribute four playable demos of the application, a tutorial that will guide users through a quick workout and allow them to follow along, and props to enhance the theme of fitness and quick workouts. We also plan to take this opportunity to get user feedback and weigh some of the other selling points of the application such as the virtual buddy and achievements.

Team Opinionize (Gaurav Sinha, Rob Engel, Phil Melzer, Vinay Prasad) Our strategy in the panel pitch next week is to get more feedback about the product, its use cases and reasons why people will buy or not buy it. The other important part of our strategy is to make the most of the experience the panel brings in the room. We need to understand our target customers. We believe that it could be anyone who has the problem of categorizing large amounts of data but we want to narrow down on our users. Adam mentioned that our probable users could be geeks who use / edit Wikipedia articles. For this reason, we will present a case for members in the panel to use the product, based on our knowledge of their interests. Their feedback will be valuable in determining whether the product is for everyone or not. We want to get feedback about what makes the product viral? And why? The panel consists of people who have the experience in the market and can judge what is going to hit or what is not. We plan to keep our description of the product at a very high level and at the same time we would explain the concept in simple terms, which a non-geeky person can understand. Keeping the description at a high level allows room for improvement based on panel feedback. At the same time we would like to explain the concept with daily life problems as examples so that its clear to the audience. We plan to do a live demo of Opinionize with these examples, which would help the panel get a feel of the product.

From the instructors, Scott Russell and Todd Sedano It’s normal to be apprehensive about your first panel. It’s not clear where you are headed with your idea, and you haven’t had a chance to validate it with the marketplace. You are focused in the coding trenches trying to get something to work, it’s time to pop out and see what the market thinks of your idea.
When you meet with the panel, you’ve got to tell people how it is supposed to work. You are looking for their feedback reaction. Then you will learn how far off you are. Embrace expectation failure, you need this feedback. The panel knows that your product is “raw” and not finished. If you think you know who your target customer is, put that forward. If you aren’t certain, hazard a bold specific guess. “Our customer is film lovers in their early 20’s.” If you know the makeup of the panel, then you can see if the panel is your target customer. When you are speaking to an intellectual group in their 40’s, don’t be surprised if they don’t resonate with a product geared for Lady Gaga music fans. When presenting your product, don’t focus on what the product does, but what problem you are trying to solve. Be provocative. Tell them it cures cancer. If they don’t think your product does that, find out why. Find out how you are missing the mark. If you were selling an Recreational Vehicle (RV), you don’t sell the customer on the miles per gallon or the capacity of the septic tank, you sell them on the vision: imagine being at the lake fishing with your family. Put on your sales hat and BS about what the product does. Don’t tell them what the product is going to go. Avoid “we working towards a release one where …..” and “we think that the nominal market will be.” Instead be bold and clear. “Our product is facebook for the medical community.” Be laser focused. Be specific about the key core functionality. You aren’t going to release a product that works on every phone. “For the first release, our product works on the iPhone platform.” If people want more and more features, it’s ok to delay the features. You don’t have an infinite amount of time and money to build everything. The common user won’t understand technology. You can explain what it is and what it will do for them, but don’t get lost in Acromania. “We’ve done the hard work to build something special.” It was tough to do, but you are making it easy for them. It’s a defensible asset. Consider how you will end your presentation. What do you want from the panel? Ask them a question. You have just spent six minutes of your valuable time presenting to this panel, what is your ask? ask the panel a question.

We’ve asked the teams to consider their strategy for their first panel. Here is a sample of their thoughts. Team Coach Potatoes (Andrew Steele, Anooj Vagadia, Patrick Baumann, Henry Fung)As a development team working on an as yet unreleased product, we are looking to get as much out of Wednesday’s panel as possible. Most importantly, we will be trying to assess the feasibility of our idea and its potential worth. Part of our presentation to the panel will consist of a demo of our current features and discussion of upcoming features. We hope to gather feedback regarding which features are of value, which are not and which would be worth spending money to have. Our application is targeted specifically towards individuals who are active, which may affect the objectivity of the panel’s feedback if they are not active themselves. However, it is still important to gather feedback from non-athletes to determine if our application will be appealing or motivating to them. If the application is not appealing, we will ask if there are changes which can be made to make it more so. We look forward to Wednesday’s opportunity. Team Four of a Kind (Alan Mak, Kevin Tsai, Matthew Lanken, Paul Wong)Our main strategy for the 4th week pitch is to focus on getting the panelists more involved with the theme and vision of the product. By doing so, the panelists would get a sense of why there is a need to use the product. Several past criticisms suggest pitches didn’t have a direct and exaggerative tone suitable for marketing, and were instead received as a simple explanation of the product. During our pitch, we plan to emphasize the magnitude and greatness of the application while being more direct in our pitch towards the panel. We plan to pitch to them as if they were the ideal target customers, and why they need to use the application. Aside from involving panelists with our tone, we will also introduce a few interactive gimmicks such as distribute four playable demos of the application, a tutorial that will guide users through a quick workout and allow them to follow along, and props to enhance the theme of fitness and quick workouts. We also plan to take this opportunity to get user feedback and weigh some of the other selling points of the application such as the virtual buddy and achievements. Team Opinionize (Gaurav Sinha, Rob Engel, Phil Melzer, Vinay Prasad)Our strategy in the panel pitch next week is to get more feedback about the product, its use cases and reasons why people will buy or not buy it. The other important part of our strategy is to make the most of the experience the panel brings in the room. We need to understand our target customers. We believe that it could be anyone who has the problem of categorizing large amounts of data but we want to narrow down on our users. Adam mentioned that our probable users could be geeks who use / edit Wikipedia articles. For this reason, we will present a case for members in the panel to use the product, based on our knowledge of their interests. Their feedback will be valuable in determining whether the product is for everyone or not. We want to get feedback about what makes the product viral? And why? The panel consists of people who have the experience in the market and can judge what is going to hit or what is not. We plan to keep our description of the product at a very high level and at the same time we would explain the concept in simple terms, which a non-geeky person can understand. Keeping the description at a high level allows room for improvement based on panel feedback. At the same time we would like to explain the concept with daily life problems as examples so that its clear to the audience. We plan to do a live demo of Opinionize with these examples, which would help the panel get a feel of the product.

Career and Software Craftsmanship

Students in the craft of software development course read Sections “Walking the long road” and “Draw your own map” in the Apprenticeship Patterns book. We then discussed whether their notions of their career had been affected by the course and the readings. During our conversation, some students talked about the idea that people can’t stay technical their entire careers. (I see this as a misperception, and discussed several people I know who are still programming late into their careers.) My full time students are actively interviewing for jobs when they graduate. Most had not considered looking for a job that would enhance their software craftsmanship skills, while salary, prestige of the company, and projects they were working on dominated their searching process. From my Improv for Software Engineers course, I have noticed that my master students who are in their 20’s and 30’s have a hard time picturing their future in great detail and will actively refuse to consider life later on unless coached carefully to do so. They lump ages 50 to 80 in one bucket, the distant future. In my improv exercise, I have them walk around the room and I ask them to picture life as it was when they are a certain age. For the most part, they are able to recall and relive life at the age of 7, 12, 18, 23. However, as we get into the future, it’s harder for them, and after the age of 60 most stop the exercise and resort to comedy to deal with the tension of thinking about the distant future. We discussed two hypothetical job offers. One pays $20,000 more money, the other allows them to grow their software development skills. Which one would they pick? While the conversation was enlightening for the students, I wonder how much of this will stick when they are in the throes of making job offer decisions. (Action item) It would be interesting to survey the students the students once they are in their jobs to discover how many offers they had and what was their decision making process to get to the final offer. In other words, did our intellectual conversation about their careers have an immediate impact on their choices a few months from now? Here are the responses from each of my students:

  • The reading made me think about my short-term and long-term vision of my career. I have not reached an answer, but I definitely have to think about which of the following is most important: a) advancement for position and salary b) enjoying the work and working on what I want and what interests me.
  • Before reading the Apprenticeship Patterns, I didn’t think about actively trying to improve my skills as a software engineer / craftsman. It was all about doing just enough to get the job done!
  • The reading has made me realize that there is a huge learning curve before I could reach anywhere near to being an expert software developer
  • Thinking about where I want to be 10+ years down the line is hard; planning so far in advance is a bit undesirable. Staying technical my work like is an interesting idea.
  • Made me think long term about my career options and whether or not to stay a developer the entire way or to take other options that open up later on
  • Made me think of where I want to be in 15 years. I don’t want to be a programmer for life.
  • The reading makes me think about whether I want to be a fully technical guy or not. It’s hard to coordinate your interests and job requirements
  • Dream about myself 10,20,30,40 years. What if my manager asked me to fill in a management role? Should I pass for the sake of programming?
  • I always hear that you can not continue coding for living! even after I reach 40s of age. How I might change my mind about that?
  • The reading talks about setting long term goals. This led me to reset my current goal (which is short term.)

Code Readability Process

Rationale

As software developers, we want to create clean code, code that is easy for other software developers to read. Ironically, we often don’t receive much feedback on our code when we are writing it. Some companies will do code reviews, and the code review feedback may help us write clean code, but we may not understand how other developers are confused. This process allows the programmer to see first hand, what is causing another developer difficulty when they read the code.

Process

Preparation) There are two roles, a Programmer (someone who has created code) and a Reader (someone who will review provided code). I am an observer of the process.

The Programmer will select recent production code that they have produced. I do not need to see the code and would prefer not to see it. I’d prefer for you to select the most recent code you have created because then you won’t be tempted to pick “perfect” or “ideal” code. We’re just looking for typical code and presumably whatever you wrote recently is typical.

I’ll prompt the Reader with some open ended questions. The job of the Programmer is to simply receive the feedback.

Step 1) Programmer, provide some context by explaining the user story (or story card) behind the code. Describe the requirements at a high level in business terms. The Reader should have some notion of the problem the Programmer was trying to solve and the added business value.

Step 2) Reader, read through the code and think out lowd about your initial reaction and your thought process for understanding the code. If things are clear, mention that. If something is confusing, mention the questions that you are thinking. Reason outlowd. There are no wrong answers, this is an opportunity for the Programmer to see how another developer interacts with their code. Provide them with your first impressions.

Do this until you’ve walked through the code and think you understand it.

Step 3) Programmer, thank the Reader for their invaluable input. Please just say “Thank You” — there is no need to defend your code

Step 4) Reader, do you see ways to refactor the code? Are there opportunities to make it more dry?

Step 5) Reader, if the Programmer left the company and you had to maintain this code, could you do it?

Step 6) Programmer, are there any clarifying questions that you have for the Reader about their comments? (For example, is there something may be very clear to you, but wasn’t clear to the Reader. This is your opportunity to better understand how you could make it more clear.)

Step 7) Programmer, reflect on this experience and describe what was the most useful aspect of it?

Step 8) Programmer, was this worth your time?

Step 9) Programmer, please fill in the survey response to this exercise

History

While teaching “the craft of software development” to my masters students, one of my students wanted to write more readable code. I challenged each student to come up with metrics to see if they were improving. The student couldn’t think of any. I realized that he would need to show his code to another developer to find out if the code was readable. He could track the feedback as a metric as seen in the comic: http://www.osnews.com/story/19266/WTFs_m

Craftsmanship Class 2

Question for group: what did you like about the kata? Random drawing on Kata implementation Random drawing on maiden speech Question for the group: how did the reading about estimation of our competence relate to this course?

Responses include

  • The kata was simple enough to let us explore our tools. Never did TDD in C++ before so it gave me time to try that out. I also liked it because it was complex enough to allow us to try complex ideas like recursion.
  • The Kata had the right level of difficulty. It was a good programming (algorithms) exercise and a good TDD exercise
  • Helped to start working towards the goal “refresh ‘java programming skills’ ”
  • It helped me learn a new testing framework and helped get me back into programming mode after taking a few months break.
  • Learning TDD in java
  • Program was simple so I could concentrate on the practice
  • Got me introduced to the testing framework
  • Once setup was completed, it showed my that TDD is language/platform agnostic, which should be obvious but was surprising
  • Learning how to do it in java using eclipse, it was easy
  • first time doing TDD in Java
  • learned how to use git with eclipse