Todd Sedano

Software Engineering, Improv, Craftsmanship

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

Increasing Discussion With a Quiet Group of Students

Every group of students is different and has it’s own “feel” — sometimes they are connected, energized, quiet, inquisitive. It may not be obvious what it is until the next group of students come and I realize that I like some aspects of the new group and miss some aspects of the older group(s).

I’ve been following a particular group of students through a curriculum and I know that they are “quieter” than previous groups. In the past, my attitude has been, “if they don’t want to discuss this, that’s ok, we’ll move on, or we’ll end early.” However, I’m challenging myself to try a different approach with the goal of raising my game and being a better teacher.

Main idea: prose a question to the group and have each person answer it on a sheet of paper. Put all the sheets into a hat. Select one member randomly (I like to use my fire dice) and have them draw the question from the hat. That person then leads a conversation around what was written on the paper. Note: you can have the students write questions on the paper, if this is the case, the person drawing the sheet out of the hat is not responsible for answering the question, they are responsible for getting the group to answer the question.

Possible Questions

Here’s my initial brainstorm list for possible questions for the group:

  • What are some fears you have about this class?
  • What is software craftsmanship?
  • Who is a software role model for you and why?
  • What are you strong in, how did this happen, and how can you continue to improve?
  • What is something that you want to work more on? How will you improve, how will you know if you are successful?
  • What is necessary to become an expert?

The technique in action

I choose this question for the students. “What are some of your concerns about this course?”

Here are their answers. * regain lost powers in terms of java programming (covered) * finding a good mentor (covered) * mentor does not agree to coach * I fear running out of ideas for learning areas I wish to improve * getting too caught up in the course * first time the course is offered, so it might not work out as planned * how much will it help me in the long run? * didn’t have any real fears up until you mentioned it! * one fear is not meeting my goals at the end of the semester. I allowed a student to lead a discussion about the selected slip of paper. The class and I had a great conversation about the student’s concern and what were some things to deal with it. I found this approach to be more engaging than going through a syllabus. After using this technique for a course, I noticed that most of my students didn’t meet my expectations for a facilitator. Some would jump into giving their own answer. Others would ask a very good opening question, but then not probe for great details. In these situations when the student stopped leading, I would ask more detailed questions and explore subtle nuances.

All in all, I really enjoyed using this technique.

Two More Weeks Until Craftsmanship Course Starts

I must be having the butterfly jitters before offering a new course, Special Topics Seminar: Craft of Software Development. I sat down with a google document to review everything that I wanted to do with the course. In a moment of feeling that I must have been missing something, I reviewed my original blog post about the idea. To my surprise, the ideas in my original blog post were consistent with my current ideas and still at the heart of the course design.

I’m using Keith Johnstone as an inspiration for this course. While I have some course structure, I want to be flexible with the delivery and reflect after each session on how the course can be better serving this particular group of students. I’m also wanting to try some crazy in class exercises. At times, I feel that actors getting on stage is an easier art form to work with than software developers writing code. Perhaps I’d feel differently if everyone would be working with the same programming language.

Sitemap Powerpoint Presentation

I tried an experimental presentation technique today, which I call “Sitemap Presentation.”

When I was asked to do the talk “Entrepreneurial Opportunities in Silicon Valley” for Carnegie Mellon University at the Pittsburgh campus, I drew out on paper my talk outline. My drawing reminded me of Kent Beck’s notes when he was presenting at Rails Conf 2008 (?) — its much like his drawings at the beginning of his book.

When I was creating the slides, I wanted the ability to hop around to different parts of my presentation. Yes, I could do one ordering of the topics, but I wanted to be flexible with my talk and respond to what the audience wanted. So I scanned in my diagram and used the diagram as my agenda slide. I duplicated the diagram throughout the presentation. I found that the drawing was more to my liking. I’ve never been fond of doing an agenda slide, they always feel so boring, but this really livened it up and allowed me to see quickly where we were headed.

In my ideal version, each part of the sitemap would be clickable. Thus I’d have a title slide followed by an agenda slide. Whenever I clicked anywhere on my diagram, it would go off on that thread and then return to the agenda slide. If I clicked on a different part of the agenda, it would take on a different thread. I’ll have to figure out how to do this in powerpoint / keynote.

Rethinking Regex

What if regular expressions were easy to write?

While attending the Golden Gate Ruby Conference 2010, I attended a session about Arel and how Rails was changing their ORM layer to make it easier to incrementally build the query.

Old: Article.find(:all, :order => “published_at desc”, :limit => 10)

New: Article.order(“published_at desc”).limit(10)

It occurred to me that this concept of simplifying could be applied to regular expression.

While I have time, I’ll continue to build up examples of what the syntax could look like.

Random thoughts:

What: not a number

  • ie a string that can’t be convert to a number
  • A string that contains at least on character
  • Regex: /^.\D+.$/
  • Positive examples: 113t23io10908-113
  • Negative examples: 13431