Gray Soft / Non-codetag:graysoftinc.com,2014-03-20:/categories/92014-06-28T15:10:28ZJames Edward Gray IIIPSC 2014 Postmortemtag:graysoftinc.com,2014-06-26:/posts/1202014-06-28T15:10:28ZA "Thank You" note to the IPSC for all that they retaught me this year.<p>I decided to give the <a href="http://ipsc.ksp.sk/">Internet Problem Solving Contest (IPSC)</a> a go this year, with a couple of friends. I've done it in the past and enjoyed it. I like how it only eats a few hours one day and I like how the variety in the problems they give you keeps things interesting.</p>
<p>That said, my performance in the IPSC this year is probably best described as, "Three strikes and you're out!" I did terrible.</p>
<p>I solved one very simple problem. I spent the rest of the contest chasing after a much harder challenge that I couldn't complete in the time allowed.</p>
<p>The worst part is that I made some silly mistakes that I've learned to avoid in the past. As penance, I offer up this article, mainly as a reminder to myself, but hopefully also as a tool that could save others from some of my folly.</p>
<p>Let's start with a simple mistake I made…</p>
<h4>Not All Problems are Programming Problems</h4>
<p>The IPSC does a great job each year of reminding us that <strong>some problems are trivial to solve without programming</strong>. It's a good thing they do too, because I seem to need a lot of reminding.</p>
<p>A great example of that in this year's contest was <a href="http://ipsc.ksp.sk/2014/real/problems/l.html">the problem that had you listening to sound files</a>. The goal was to get a simple number out of what you heard. In <a href="http://ipsc.ksp.sk/2014/real/problems/l1.mp3">the easier case</a>, a digitized voice is reading ones and zeros for the listener to transcribe.</p>
<p>While you <em>could</em> solve this problem with programming, that's a lot of work. You would need to process the sound data and search for patterns.</p>
<p>Of course, the obvious non-programming solution also has problems. You can just listen to the file, writing down what you hear. But the file goes on for almost 15 minutes and I don't trust my ability to maintain focus and accuracy for that long. It's too error prone and takes too long.</p>
<p>What I really wanted to be able to do was to <em>read the sound</em>. Sadly, I didn't realize until after the contest that I could do exactly that. See for yourself:</p>
<p><img src="http://graysoftinc.com/images/l1_sound_wave.png" alt="L1 Sound Wave"></p>
<p>That's right, open the sound file in most any sound editor and it will show you a graphical representation of what you are hearing. You can play it for a few seconds to spot the shape of the ones and zeros, then stop the sound and literally <em>read</em> the number out of what you see.</p>
<p>I'm super sad that I forgot this because <a href="http://www.devreps.com/">Mandy Moore</a> talks about how she can spot an, "Um," visually, while editing <a href="http://rubyrogues.com/">the Ruby Rogues podcast</a>. I knew better.</p>
<p>The point I want to remember here is that I should be using every tool in my arsenal, not just programming, to solve problems.</p>
<h4>Quitting is a Valid Move</h4>
<p>As I said earlier, I blew most of my problem solving time on <a href="http://ipsc.ksp.sk/2014/real/problems/f.html">a problem that was obviously too much for me</a>. I knew this about an hour into working on it. But I have this problem: I can't quit. This is a disease. Please don't be like me.</p>
<p>I'll give a non-IPSC example to drive this point home. I've been working on some code that displays a grid of images. Items in this grid have some connections drawn between them and other little images drawn around them. These extras kind of break the grid concept, since they can be in multiple cells.</p>
<p>Now I had to write some code to select these cell-spanning extras. This proved pretty challenging, again because of the complexities of the grid they are in. The code got hard. I kept hacking. It got harder. I pushed harder.</p>
<p>My problem, in both of these situations is the same: <em>I keep telling myself that I'll get it.</em> The worst part is that I'm right. I will eventually break through and land on a solution.</p>
<p>However, and this is the super critical realization for me, <strong>that's totally not the point!</strong></p>
<p>I blew about four hours in that contest chasing a problem that I knew was hard. I've blown about two weeks of free time banging my head against this grid selection code. Even if I solved them both right then, I lost.</p>
<p>Let's go back to thinking about that grid problem. I figured out that there are nine special cases that I need to solve. Then I started attacking them. I had six handled at last count. While I can probably get the current approach working, eventually, I don't want to maintain that code! What am I going to do when the first bug report comes in? Pause for three weeks to get back into this code enough to debug the issue? Fail.</p>
<p>The contest is the same. Even if I had scored the solution before the buzzer (which I did not), I would have still been creamed by anyone who went after two or more easier challenges. Their tasks would have been simpler and more rewarding. I was pushing through the pain for less gain. That's just silly.</p>
<p><strong>It's far better to quit.</strong></p>
<p>I've had plenty of time now to re-architect the grid problem to remove the grid itself, which clearly doesn't fit, in favor of a better abstraction. In the contest, I could have quit when I noticed the depth of the problem and still spent three hours solving other problems.</p>
<p>It's so important to learn <a href="http://freakonomics.com/2011/09/30/new-freakonomics-radio-podcast-the-upside-of-quitting/">the value of quitting</a>.</p>
<h4>Teamwork: It's a Thing</h4>
<p>If I had been smart enough to give myself back all that time I wasted, I sure could have made better use of it. One way I could have done that would have been to remember that I was on a team.</p>
<p>The three of us just picked problems and worked pretty much in isolation. While that can be a valid approach, it may not be ideal in all cases.</p>
<p>I've already mentioned that I got hung up on a problem, but my teammates did as well. One spent time <a href="http://ipsc.ksp.sk/2014/real/problems/g.html">trying to work out all of possible scenarios for a simple game</a> while the other was <a href="http://ipsc.ksp.sk/2014/real/problems/k.html">building a crossword solver</a>.</p>
<p>I'm not sure if I could have helped with either case. The game may have been mostly about getting your head around how it works and adding another head to fill may not have made that any easier. Then again, talking out ideas may have.</p>
<p>The crossword didn't look too tough overall, it just had a fair bit of busy work in it. You had to build handlers for each of the clue types. I likely could have contributed there, just by offering to handle some of those types.</p>
<p>But here's the real kicker: <strong>I never asked!</strong></p>
<p>Talk about a rookie mistake. How hard is it to say, "I'm clearly spinning my wheels over here, is there anything I could do that would help you?"</p>
<p>Lessons learned… again… I hope…</p>James Edward Gray IIAre We Teaching the Best Things?tag:graysoftinc.com,2014-05-28:/posts/1182014-06-05T18:36:20ZThese are my thoughts on what really matters when we teach programming.<p>I'm in Denver right now, mostly to see family. Being the geek that I am though, you know I snuck a little time for the local Rubyists. One of those Rubyists that I was lucky enough chat with is Katrina Owen. </p>
<p>I always love getting a chance to talk with Katrina. She's so thoughtful that she raises the level of discourse and makes me feel smarter. Plus, it turns out that Katrina and I have been thinking about similar things lately. </p>
<p>For my part, I've been thinking about the various students that I've taught to program over the years. I have taught many and because they all learned from me, they learned roughly the same way. What's interesting to me is how different the results have been from that technique. In some cases my students were all set after our lessons and they just began coding up a storm. Other students didn't seem to feel they were ready yet though. They had more of a "Now what do I do?" attitude at this stage. </p>
<p>Katrina raised a similar point from her time teaching in a developer school. When they would get to teaching language basics, they would show several constructs and how they are used. This is similar to how I teach. Just as I have observed, this works for some students. They can just take what they know and run from here. But they also found other students felt a little lost at this point. </p>
<p>The best news is that this isn't the end of the story. Katrina's team does not just give up on these not-quite-there-yet students. Instead, they switch tactics. </p>
<p>This is the key insight, that I feel both Katrina and I have separately arrived at: these students can still be taught program. There's nothing wrong with them. It seems much more likely that our instruction is somehow failing them. Katrina observes that using different teaching methods (which they have incorporated into the initial lessons, of course), they can reach a significantly higher number of students. </p>
<p>What's the huge secret to reaching these other students? I'm not going to promise that I have this 100% figured out, but I feel I've reached a point where I can make educated guesses based on what we are seeing. </p>
<p>I have written in the past about how I feel the Ruby language is a combination several useful programming paradigms. Well, I think a good programming education also needs to pull from multiple areas. </p>
<p>When I have taught programming in the past, I've focused heavily on the language and how it works. Looking back, this seems silly to me. Programming languages are, generally speaking, pretty simple things. Ruby has around 60-some keywords, if I recall correctly. The operators you use at early stages are generally pretty common sense, like simple math operations, or easy to understand needs for what what you are trying to accomplish, "How do I jam these two strings together?" Sure, it'll take some time to learn all of the functions/methods in the core of a language, but you can make decent progress with a small subset and you probably don't need a teacher's help to pick up most of the rest when you're ready. I do realize that languages have plenty of rabbit holes you can get lost in, but I think most of those can, and should be as much as possible, avoided at the earlier levels. In summary, these language concerns obviously play a role, but this may not be the most significant piece of the learning to program puzzle. </p>
<p>I would say there are two more significant challenges to picking up our particular craft. First, you have to spend quite an effort to learn how think like a computer. Let's face it, computers are really dumb. When I was in school we had to do the exercise of writing down a set of instructions for making a peanut butter and jelly sandwich, which our teacher would then execute as literally as possibly. If you wrote, "spread jelly on bread," the teacher might grab the still-closed jar of jelly and roll it back and forth over a bread slice. Experienced programmers know that teaching machines is exactly like that. They don't make any intuitive leaps and they always do precisely what we told them to. Learning to program is, in part, a process of learning how to specify all steps algorithmically at a ridiculous level of detail. This is the only thing machines understand. I suspect this is the major reason long-time programmers can pick up new languages so quickly. Once you've dumbed yourself down to the level of the computers, putting a communication layer on top of that process is fairly easy. </p>
<p>There's another element that I suspect contributes heavily to the differences we see in students. It's common to hear claims that programming involves a lot of math. This use to bother me because I felt it gave the impression that you would need to be pretty sharp with trigonometry or calculus to build a Web application. This is just not the case. However, there is a very important concept that math and programming do share: how to solve problems. This is a big deal. Knowing how to break down a challenge into manageable chunks, knowing how to select a good starting point for your efforts, knowing how to work your way from where things currently are to where you need then to be, and knowing how to validate results are key to what we do. This is the beating heart of programming and I rarely see it taught with our languages. Some students come to us already familiar with how to do this stuff from other training so it doesn't hurt them as much when we gloss over it, but it's still a shame because we probably miss good opportunities to put programming specific twists on this process. </p>
<p>There are almost surely other key skills tied to programming that I haven't listed above. These are just some I feel pretty confident that we need and that may not be receiving enough instructional focus. I believe one thing is pretty certain at this point: programming isn't just about learning a language. I highly doubt that's even the most interesting part of learning to program. Our lesson plans should reflect this.</p>James Edward Gray III believe in Rubytag:graysoftinc.com,2007-02-17:/posts/302014-04-04T21:44:59ZThis is just a fun little note I put together for a blogging contest.<p><em>For <a href="http://on-ruby.blogspot.com/2007/01/blogging-contest-february-challenge.html">the contest</a> and all you Bull Durham fans…</em></p>
<p>Well, I believe in blocks, iterators, closures, that everything should be an object, the power of reflection, garbage collection, exception handling, that multiple inheritance causes more problems than it solves. I believe interpreters should be totally free. I believe there ought to be a constitutional amendment outlawing pointers and verbose syntax. I believe in a strong standard library, green threads, that a language should trust the programmer rather than restrict his efforts and I believe in sheer fun of coding that truly is possible to achieve.</p>James Edward Gray IIDoing It All!tag:graysoftinc.com,2006-11-07:/posts/232014-04-03T22:50:02ZHere's my best non-programming tip for all programmers.<p>I'm not really in the habit of putting non-code content on this blog, but more than one person asked me the same question at RubyConf. If people really want to know, I'll try to answer. Paraphrasing, the question was:</p>
<blockquote>
<p>How do you keep up with so many Ruby projects?</p>
</blockquote>
<p>First, this question surprised me. Do I really do that much? If you just said yes to that, I would like to introduce you to <a href="http://www.zenspider.com/">Ryan Davis</a>. He easily doubles my output and his projects are wicked complex compared to mine.</p>
<p>That doesn't answer the question though.</p>
<p>In short, I do as much as I possibly can with the time I have. The truth is that I would like to do a lot more. I turn down at least as many damn cool Ruby projects as I accept because I'm a wimp and not willing to give up my sleep. There are so many crazy cool Ruby projects out there that I would love to be a part of. There just aren't enough hours in the day.</p>
<p>I guess I still didn't answer the question.</p>
<p>The question was "How…" and the answer to that is actually trivial. Masayoshi Takahashi summed it up with a single slide in his presentation at RubyConf:</p>
<blockquote>
<p>Passion Matters</p>
</blockquote>
<p>Definitely.</p>
<p>If we were talking about working in a coal mine for sixteen hours a day, I would probably be a lot less capable. It just so happens that I love what I do. If anything gives me extra energy to devote to Ruby projects it's that. Love what you do. I can't stress that enough.</p>
<p>Beyond that, don't hesitate to get involved! I can't tell you how often I see people say things like, "I'm not really qualified to do that," or similar excuses. Oh hell, neither am I, but I wouldn't let a little thing like that stop me! You learn as you go, you drag in the help you need, or whatever. Passion will conquer so care enough to have some. Be the driving force and the rest will take care of itself.</p>
<p>That's all the advice I have to give, I fear. My secret formula probably seems bland, but if I <em>accomplish the work of ten men</em> (someone said that to me a while back), the reason is that I'm passionate and fearless.</p>
<p>Oh, and I have the most understanding wife on this planet. Get one of those too.</p>James Edward Gray II