I will really miss the great people.

I will not miss the near constant, nagging anxiety of having just wrapped up a session of pair programming only to break something again, thinking: “Oh, holy hell, why the hell isn’t this working???  My ass is gonna get fired…”

While I enjoyed my time there, I found that I was often frustrated by the work (and myself)… the nature of their development process demanded results a LOT faster than I could port them out while 1) learning a new language/methodology and 2) struggling under the stress of having to be “billable”.  I couldn’t spend much time at work learning – I had to be producing something.

This works great if you have the ninja programming chops to back it up, but I don’t have ninja level programming skills yet – I have hot dog vendor programming skills.  You know, like Jack Black in Kung Fu Panda?  He was a noodle vendor before he became the kung-fu master.  With enough time, hot dog vendors can become ninjas, but in the mean time, they still get thrashed by ‘em (most often when they run out of hot dogs).

I tended to spin my wheels a lot.  I just couldn’t learn the things they wanted me to learn as quickly as they needed them and at the level of expertise they needed.  I feel like it was a personal failure, even though I know there’s not much I could have done differently.  It was a very frustrating, very humbling experience for me.

I’ve made it my personal goal to never show that level of ineptitude again.  In terms of programming, I think I chose the wrong career path… which is why I’m angling away from straight web development jobs in my job search.  I’m heading towards Marketing and Web Marketing in general.  It’s the thing that I live, breathe, and eat when I’m not at work – I have penchant for it.  Not only that, but out of all my classes, I enjoyed the Customer Relationship Management and other Marketing courses the best.  I might not be a ninja marketer yet, but at the very least I’m an apprentice in the dojo.

I’m confident I’ll be able to find a job by the end of the week.  That’s not to say I’m not scared shitless.  I am.  I just had an emergency open appendectomy – and the bills from that are not going away any time soon – not to mention rent, a car, and other pseudo-necessities when you want to avoid living in your parent’s basement… or on the street.

I’m trying not to think about that.  I know I’ve got a lot to offer any potential company… and I hope to bring some near-ninja skills to my next opportunity.

Speaking of which, if you know of any good opportunities in web marketing or web production, please do let me know.  Here are my resumes:

Click here to download my Web Developer resume in PDF format.

Click here to download my Web Marketing resume in PDF format.

There are a ton of methodologies, but the general idea of Agile Software Development is to quickly develop complex software projects by breaking them up into smaller projects and breaking those projects into tasks.  All the while, you’re increasing teamwork and communication to minimize roadblocks.

I started to look into the Scrum methodology (because who doesn’t like rugby!) and I discovered that a lot of the principles that programmers use to implement agile development could also be applied to any complex project.

Here’s how:

• Organize Your Project
  • Create a 2-week to 4-week goal (this is called a SPRINT).
  • Organize your tasks to be no more than 5-hour chunks of work.
    • Break down tasks that take more than 5 hours into smaller chunks.
  • Itemize a list of “wants” and “needs”.
  • Prioritize based on Return on Investment (ROI).  “Needs” that take less time than “Wants” have a higher return on investment.
• Create Realistic Expectations
  • If two projects will collectively take 40 hours, and you have 8 hours a day to give, but only 3 days, only one project will be completed.
  • You only have so many hours to burn, so maximizing ROI is key.
• Minimize Distraction and Increase Efficiency for Update Meetings
  • Allow only key players to hold the floor, but allow anyone interested to attend.
  • Limit the overall meeting time to 15 minutes.
  • Keep the discussion flowing – stay within the confines of these topics:
    • What have we done so far?
    • Where do we need to go?
    • What do we need to get there?
  • Stay standing – it energizes the participants and keeps the meeting short.
• Increase Communication
  • Real advocates of SCRUM meet for 15 minutes each day, but depending on the scope of your project, once or twice a week would be enough.
  • Nobody is penalized for bringing up problems – no problem is hidden.

This is by no means all-inclusive, but hopefully it gets you started.  Did I miss something?  Add a comment!