SB apprenticeship: Day 2

Tools of the trade.

Tools of the trade.

Urrgggg, I am dragging this morning. Kevin helped me refactor yesterday’s kata at midnight, which apparently woke my brain up from its ‘coding is work’ haze, and it took me forever to get to sleep after that. Fortunately, I have caffeine!

Today’s questions:

  • What did you learn yesterday?
  • What are you going to do today?
  • What do you expect to learn?

Yesterday I learned the basics of how Smashing Boxes works, and attended a really interesting lecture by Sandi Metz called Nothing Is Something. She presented it at RailsConf also, and I think I understood more the second time, but it’s still going to be the type of lecture that I go back and listen to periodically as my understanding of Rails and Ruby grows. I think one of my frustrations with learning programming is that I’m surrounded by friends who have been doing this since they were kids. I have to internalize the fact that I can’t compare myself to them, I have to recognize that I’ve been doing this for less than a year and measure my accomplishments on that scale. Still, it’s hard, when Kevin just effortlessly refactors my code into like three lines and I’m left studying it. He’s an iOS dev, he doesn’t even use Ruby! *grump*

Today I am going to refactor my kata from yesterday and add a test suite. In order to do that, I expect to learn Rspec! Smashing Boxes added me to their Code School group, so I can take all the classes for free! I’ve heard really good things about the site, and I enjoyed the free lessons that I was able to do, so I’m looking forward to digging in.

I changed one of my login phrases to “you are a programmer” this morning. I’ve read about how repeating positive affirmations can help you maintain a good attitude, and help prevent frustration, so I figured it was worth a try.

One thought on “SB apprenticeship: Day 2

  1. One thing I found most useful was deliberate reflection, because I spent my first 10 years of programming alone.

    Whenever I fixed a bug, I would stop and ask myself, “OK, what could I have tried that would have found this bug faster? Try more inputs? Stepping through with the debugger? Did I ignore a clue? Run the individual methods with test data? Make a little script that would run the whole program in a way I know it’ll fail?”

    I learned a lot about debugging from this practice, and eventually I could start asking, “How could I have written this so the bug would never have happened? What if I’d used a map instead of an array? What if I returned an object instead of a hash? Did the name of something mislead me?”

    Having done that put me in a good position when I started seeing other people’s code. “Why did they do it this way? What are the tradeoffs? Could I use this technique in my code? If it broke, what bugs would I see?”

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s