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)
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.
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.
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.
This is about class three (June 1st, 2011) from the course (Real World Software Engineering for Entrepreneurs (A Startup Accelerator)
Preparing for your first panel - Class Three - June 1, 2011
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:
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.
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?
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).