Coming fresh off Desert Code Camp, I signed up for a small event inspired by the Ignite movement, called Developer Ignite. The format is similar, 5 minutes, 20 slides, and a topic. The scope is a bit narrower however, as this event is aimed at the technical community. All technologies should be represented, from Javascript to C to Ruby. I’m eager to see what the other presenters have in store for us.

My presentation is dubbed HTML5 + CSS3 = awesome. I’m by no means an expert in either technology, so this will be a learning endeavor for me as well as for the rest of the attendees. I find that signing up to present topics to which I know little to nothing about really motivates me to learn something in a real hurry. It’s good for someone like me who tends to analyze many data points before proceeding.

Either way, this should be a fun event, even if it’s not as large at the regular ignite series.

Developer Ignite is being held at Gangplank on Wednesday July 22. Stop by and say hi!

I’ve been a fan of the Pragmatic Programmers’ Press books and other instructional material for quite a long time. While on the flights to and from San Francisco for WWDC, I was able to go old skool and read my copy of The Passionate Programmer. I’d like to share a few thoughts below.

I was interested in this book because while I feel myself to be a competent and mostly passionate programmer, I want to take my skills, and career to the next level. I was looking for a few pointers here and there more than any major career changing advice.

Let’s start with the obvious, the title. The Passionate Programmer started life originally as “My job went to India”. I, as I’m sure were many others, was put off by the title alone. It seemed the odd book out of the Pragmatic Programmers’ series of books. The last thing I wanted to read was that I should be working harder for less money in order to compete with lower wage programmers from other corners of the Earth.

The Passionate Programmer is not a cover to cover read. I found myself skipping through the book, stopping at essays that interested me at that particular moment. For instance, I’ve been seeking out a mentor for quite some time, and the essay on seeking out a mentor provided a few helpful hints on finding one. Not only that, it reaffirmed to me the reasons I wanted one, and offered other things to consider when choosing a mentor. And yes, you should choose your mentor, not the other way around.

Some of the essays are ones I could have used a few years ago, such as the essay describing the business from your manager’s, boss’ or even CEO’s point of view. I learned several of those lessons the hard way, and I found it reassuring that someone as esteemed as Chad Fowler also went through the school of hard knocks on occasion. We’re all human after all.

The overlying theme of the book, in my estimation, is that there is only one person responsible for your career: You. This collection of essays points the reader to many helpful follow up questions, tasks and todos to follow with at the end of each essay. The true passionate programmer will take the bull by the horns when the time is right, and be able to guide their career to whichever direction they so choose. There is no secret sauce.

Thanks Chad Fowler for authoring such a helpful book. I recommend this read to anyone, be them in a career slump, just starting their career, or just want to see how someone else has managed their career.

Getting Started with iPhone Development from casademora on Vimeo.

On June 13, 2009, I gave a presentation on the extreme basics of iPhone development at Desert Code Camp 5. This talk goes over what you need, and walks through some code with regard to building a basic Twitter Client for the iPhone.

This is going to be a whirlwind year for me. It was my first ever Railsconf, my first ever WWDC, and now it will be my first ever iPhone developer conference. While I was at WWDC last week, the guys who run 360idev" were running around with a few specials. One of which was a since 40% signup discount for WWDC peeps. I’m excited to head back to Denver yet again (my second home) and hang out downtown with more iPhone developers. It sounds like fun already! See you in Denver in September

Thanks everyone for coming to my presentations at Desert Code Camp yesterday. As promised, here are the materials for my presentations:

CSS Sucks

Slides

Getting Started with iPhone Development

Slides

Code

Gettting Started with Mac Development

Slides

Code

WWDC 2009 has been a blast, it’s a shame to see it end so soon. It’s definitely become an event which I will attend in the future. It’s awesome to see the mac developer community come together in such force. It’s been great to learn so much from Apple engineers, and if nothing else, has reinforced in me the idea that there is a place here for me, and doing so is a good thing.

My only regret is that once I leave the wonder of WWDC, this feeling will fade, and i’ll go back to being undecided about this path. I’m writing this now to basically send a note to myself in the future: KEEP GOING, DUMBASS! Make deadlines, work hard, ship a product, it’ll be worth it. With that, I resolve to try harder to

• transform some ideas from vaporware to shipping software
• become more involved in the mac developer community

Now, I was just at Railsconf, and was, and am, still truly interested in what is going on in the Rails development community. However, this direction just feels like a direction in which I need to go in the long run. It feels like a return to all the things that made writing software interesting and fun.

Granted, I’m probably in the WWDC reality distortion field, but I’m sure you’d get that at any conference. But, please don’t tell me, I’m having too good of a time hanging out in it :)

This has definitely been a year of firsts for me: first time to work at a startup company, first time to go to railsconf, first time to work on rails code. Now, another first, my first trip to WWDC. I’ve been wanting to go since I heard about this conference a few years ago, and last year I decided this would be the time to go.

While I work on ruby on rails full time at the moment, I have been dabbling in mac and cocoa development for a bit, and figured this would be another step in getting over that initial hump. There’s nothing like a full immersive experience to learn the topic you’re after. I h I’m not expecting a new hardware release, or anything fancy. I am going to learn, meet some other cocoa and mac developer, and try to have a good time.

If you’re there, feel free to say hi…I won’t bite…hard.

A couple of weeks ago, a colleague and I decided to give pair programming a try. Full stop, no holds barred, real-life, textbook (sorta) pair programming. This was the first time we had tried this experiment while I’ve been working as an Openrain ninja developer. My previous experience with pair programming comes from my time working on internal corporate web applications at Intel. We were both excited, eager and willing to give this experiment our full attention, in order to find out first-hand if the benefits could work in our particular development environment.

What we found over the course of one week of developing full time as a pair was interesting. Of course, our “findings” are based entirely on gut feel, although we did have a list of closed issues in our tracker that helped give us something to measure.

Our pairing time seemed to go through many of the typical phases of team formation, forming, storming, norming, and performing. Day 1 was a little uneasy, since even though we were eager to try it out, there was still a little uneasiness on both parties. And, while we didn’t argue, per se, I’m sure we found small things about each other’s work habits a tad annoying. However, at the end of the week, we found we were able to get to several tickets, and were quite amazed at our progress.

One key issue that wasn’t address was that of the common development environment. We had decided to use my system as the development machine. We also decided to use RubyMine, a new rails development environment with promise, and one which neither of us were familiar. We didn’t have an ideal workspace, as this would be one of the key things I would like to see remedied if we are able to pair more consistently.

One of my favorite features of pair programming while at Intel was the opportunity to learn the abilities and personalities of your entire team. My team had started off with 15 members, and was split in half after deciding it was too large. Even with 8 team members, I found pairing to be extremely rewarding and helped me to learn at far greater a pace than I would have on my own. Our current team is a bit smaller, consisting of me and my colleague. I still found our pairing time effective, however, the team member swapping will always be my favorite part of pairing.

One point of concern that seems to appear while pairing is the passenger boredom during certain technologies. We seemed to both agree that pairing while writing Ruby and Rails code was effective, fun and rewarding (my words, not his). However, when it came to CSS, Javascript or other non-ruby code, it was obvious that we had not found the most effective way to pair with that particular code.

Overall, I found it refreshing to be able to continually learn more subtle aspects of rails and how to author code the ruby way using pair programming. I hope that Openrain will be able to find more pairing opportinuties, and that we address these shortcomings, because despite them, I found that week to be very effective, productive and rewarding.

Yeah, just what the world needs, another blog. I guess I should put stuff here that can help people. Eventually, I supposed, but that’ll have to wait for another day.