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).

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.

What if regular expressions were easy to write?

Postgresql doesn’t marshal data types like MySQL does. For many of my tables, I store year as an INTEGER. In one of my tables, when I did the migration, I specified it as a VARCHAR. This generated this error.

Please see this file