Practicing free throws at thoughtbot
Everyday I remind my son that the reason someone is good at something is usually because they’ve practiced. The reason he swims like a fish and I sink like a rock, is because of weekly practices. The reason he can play the piano, wrestle, and draw airplanes is because he devotes time and effort doing those things. Some people are just naturally gifted at things but most of us have to work at it.
Coding is no different. So, last weekend, I attended thoughtbot’s Intro to Rails workshop. Did I need a Rails Intro class? It depends. Every ounce of Rails knowledge I can glean from great sources, I want to do it.
It’s no different than a basketball player practicing free throws. They’ve probably taken tens of thousands of free throws in their careers, yet even elite NBA players practice their free throws. Yeah, I’m “talking’ bout practice!”
Some of the key takeaways from thoughtbot were:
But my biggest “get” was refactoring through method extraction. The principle is simple. If you duplicate code twice—-question it, if you repeat it thrice, then it’s definitely time to pull it out and put it in a method. Nothing earth shattering, but something I don’t readily do. So, was it worth it? Yeah, it was worth it, because I learned a different perspective. A refresher that will only make me a better programmer. Yep, I’m “talkin’ bout practice!”
On the road to Ruby and that Rails Bling, programming lets you build real things. Learning all I can is the song I sing, programming lets you build real things
The Mascot @thoughtbot
“Goose” aka Matthew Mongeau
Be like Mike
The difference between experience and inexperience is sometimes sharp and crystal clear. Case in point, several times this week I became stumped by problems. On several occasions, I could move the solution close, but not really over the finish line. I twist myself into mental knots, trying different approaches and even wondering whether the approach I’m taking is correct in the first place. I had to call for assistance from Obi-Wan to set the right course. With this, I can’t help but be a wee bit discouraged by my coding youth and inexperience. But when I do, I think about my all time Nike commercial from back in the day:
“I’ve missed more then 9000 shots in my career. I’ve lost almost 300 games. Twenty-six times, I’ve been trusted to take the game winning shot, and missed. I’ve failed over and over and over again in my life. And that is why….I succeed.”
If it take 10,000 hours of dedicated practice for mastery of a subject, then by my very rough estimates, I have 88% of my learning ahead of me. A lot of work to do to become Obi-Wan in my own right.
Two hundred and One
176 days. Exactly 176 days ago I stepped into a GA for the first day of WDI2 with dreams of coming out the other end as a web developer. Before then, my typical day was
wasting working 8 hrs a day for a institutional pharmacy, scraping together whatever time was left over in the day to learn web development. Outside looking in. That was my typical week.
Here was my week, this week
Train (by) Reading
(you would think that with all these books I would be better at programming)
One of my goals is to upgrade my Ruby programming skills and the Well-Grounded Rubyist by David Black is an awesome Ruby book. Unfortunately, like many of the books I possess, it was falling in the partially read category. I’d start reading, but would taper off when things got too dry. It had been opened far too little since being brought in Nov. 2012.
Since commuting to the city, I utilize that time to get in some “extra” studying in. It’s surprising how much quality reading can get done on a 50 minute train ride. Round trip, that time amounts to over 1.5 hours of relatively quiet Ruby study a day. Added up over a week’s commute, that’s seven and a half hours of learning. Over the course of a month…you get the point.
Yet, even though the WG Rubyist is reader-friendly for a technical book, it’s a technical book nonetheless. In order for me to understand what I’ve read, sometimes I have to digest small, deliberate chunks. Thus, when I read…
The class Class is an instance of itself; that is, it’s a Class object. And there’s more. Remember the class Object? Well, Object is a class—but classes are objects. So, Object is an object. And Class is a class. And Object is a class, and Class is an object.
- The Well-Grounded Rubyist
…re-reading is necessary for things to sink into my brain. Ultimately, I’m making progress. I’ve gotten further into the book this time than my previous attempt. At this pace, maybe I can make another pass at and finally complete jQuery in Action.
As for work…
The most interesting thing probably this week is that our CTO is visiting for two days (Fri/Sat). We’ll meet (in person) for the first time and code together as well. This week is similar to many of the previous…part episode of “Coding Wars” with a little “Dog Chases Tail” bloopers mixed in for good measure.
Tool of the Week - http://365psd.com
A new psd of *something* each day. But, the real value is to use the site as UI/Design inspiration, plus it can help you sharpen your css skills by replicating some of the ideas for your projects.
“Bout that Life!” - The FinTech Hackathon
Arrived at Alley NYC. Thought I would get there early to stake out a spot. No such luck. Chilled in the lobby waiting for my team on a comfy couch.
The space start filling up, bagels and strawberry cream cheese for breakfast.
Idea still not pinned down.
1. a social media aggregator that matched stock price to volume of tweets
2. crowd funding platform for businesses with a social mission.
Company intros, API demos, standing room only…The place is packed
While the API demos were being presented, I couldnt help but be distracted by the professional. First, he came in to the hackathon with a full fledged suitcase, apparently fully stocked with wires, computers and other gadgets. He spent the next hour setting up(toolbelt on hip!), mini-screw drivers set in hand, and generally making enough commotion to call attention to himself. I thought he was going to build an actual computer on the spot.
The TakeAway: Don’t be that guy, or people will write about you.
After light quibbling, the idea is settled. The crowd funding platform.
We begin setting up administrivia: create project, github collaboration setup, screenhero setup, etc. This took about an hour, which wasted an hour of coding. But overall, we gelled quickly.
The TakeAway: Have your idea decided, your individual responsibilites loosely mapped out, and the administrivia completed, before you arrive.
12:00pm to 1:00pm
Awesome Lunch: Plate full of grilled chicked, wraps, rice and guacamole for Qdoba
2:00pm to 5:00pm
Dinner: Chicken wraps for days, still full from lunch though.
7:00pm to 8:00pm
Darkness falls; literally and figuratively. Devise is on our brain, screwing
up things that ultimately will not be needed. A little self-doubt starts creeping in. Then we get re-energized by progress on the front-end
9:00pm to 11:00pm
Start to refocus our thinking to only work on what will be show. Sign up/in process, see ya.
The TakeAway: Be flexible in your ideas, approach and give up on technical difficulties (aka “just hard code it” as Aiden told us in the prep meetings). Dont build your demo around your app, build your app around your demo. Create a layout of your presentation, build only what you will need to show.
Crowd thins out. More than half of the people are gone.
1:00am to 2:00am
Starbucks run, streets still crowded, fresh air…revived.
Only the true warriors remain, and Jamal says it’s because we have a grinding, hustling, get it done mentality because we are ‘about that life” So, we informally become “Team: Bout that Life!”
Uh Oh, in order to use the Dwolla API we needed a real URL. We were only going to work from localhost. Now we need a live site. So, we switch databases from sqLite to postgres so we can throw it up on Heroku. We get most of the basic functionality complete. The Dwolla API is working and we pass a penny back and forth like it was gold.
4:00am to 6am
Now we just cruise, doing styling stuff and generally joking around.
Test, Test, Test. It works every time.
We play a joke on Christienne (she left at 1:30am) that she would have to redo the styling of the home page because we lost it with github issues. For 5 minutes, we had her going. She also brought each of us mini-tooth brushes to freshen up, but I carried my funky breath like a badge of honor.
9:00am to 11:00am
Christine managed to get someone to review our presentation and we met with him in a private room. He happened to be relatively influential VC in the start-up community. As soon as we began, he immediately interrupted, giving pointers, rephrasing our words and breathing life into our essentially boring and dry pitch. As we practiced our pitch, we loosened up and laughed, laughed, laughed. It made a world of difference. Although, we didnt have the best technology, I feel we had the most engaging 3 minutes of all the presenters.
The TakeAway: Your pitch is almost everything - Lighten Up Champ! Engage the audience, show what it does quickly and have fun. Be different in your presentation. Dont be to serious. Drink before you go onstage.
We get our presentation order:
Yay, we go fourth. Our other GA team, goes 23rd.
Highfives all around!
My goal for this hackathon boiled down to three things:
This hackathon was a great experience.
Ideas going forward for a hackathon prep
git == gtfooh
Ok. I’ll admit it - my Git game is laaaaammme! Don’t get me wrong, on my personal projects (read:alone), I can git commit, merge, stash like nobodies business. But introduce other people into the mix, and I palms get sweaty with with every push, pull, blah, blah, blah. I just don’t trust
myself git. When working with multiple people, things can get really confusing, really fast.
The way we use git (and try to minimize errors) while working is mostly having one person (out of two) responsible for the commits, creating branches, etc. Using Jira (project management) we create tickets for features and use those tickets numbers to “hook” into Git/GitHub. Even using this approach, sometimes issues will arise. Learning more about git workflow best practices adds another item to my ever-expanding checklist.
Which is why this week’s FinTech Hackathon may != a barrel of laughts. My adventures with Git notwithstanding, I’m excited about the experience. Our GA sponsored teams are formed. We’ve had two prep meetings. Of our four team members, all are new devs and only one has participated in a hackathon before.
My hope for the 24hrs is to build a functional, decent looking app and present a good pitch. We have good two ideas on the board but, most importantly, we just want to have fun.
So, depending on how we do reaching those goals, next week’s post will either be: Anatomy of a hackathon or Autopsy of a hackathon.
Tool of the week: DevTools Autosave
Credit: Saw in a NetTuts tutorial
Sometimes you eat the bear; other times, the bear eats you.
The first part of Monday mornings usually involves finding where we left off and where to start. We possess a wide range of freedom of what we can work on. When establishing our initial workflow with the CTO, we decided we would rather work on larger chunks of the site figuring it out as we go, rather than him issuing small tickets that we complete.
We work from an MVP outline, which list the basic functionality of the app. The advantages are obvious: we control our time, what we work on and it feels entrepreneurial. Yet, there are disadvantages. Being on a small distributed team can create bottlenecks and challenges. Deciding what to work on sometimes depends on other team members. At times, we can only go so far until we hit a wall that involves another members responsibilities. In that case, we go as far as we can, then we move on.
Trying to understand someone else’s code can also be difficult, especially if it is the first time you’re seeing the code being deployed in a way you’re not familiar with. Get stuck and there’s no easy, lean-your-chair-back-and-ask-a-question method of unsticking yourself. And while, using gems like Devise offer huge advantages in setting up your auth process, as oppose to rolling your own; if you are not familiar with it (me), then lord have mercy on your soul when you need to customize it. Time to get cozy with the documentation.
Yet, after all is said and done, the advantages of this workflow outweights the disadvantages.
Tool of the Week: apigee.com/providers
Explore different apis in a console
Credit: Aiden Feldman
We are still getting use to the dynamics of working remotely. On our first “face to face” meeting with the dev team (through Google Hangouts), we established a little more formally the communications between us and the other developers. We have an open chat line for more immediate questions for the CTO, email and the weekly scheduled Google hangouts (although we will have had 4 by this weeks end.)
Had lunch with the CEO & CTO on Tuesday, which was excellent. Their passion for the product is contagious and, the fact that we are really core members of the team gives us a huge advantage and huge responsibility. She even suggested we may get a chance to fly out Michigan to meet the rest of the team.
The week coding-wise started a little slow. As I’m learning, sometimes you just can’t move as quickly as you like. Development can be a slow process and your day can melt away because of technical and debugging issues. However, in the latter part of the week, we started gaining momentum and got that small sense of achievement that comes when you achieve those incremental goal. The CTO is suprised (happily) that we have been able to hit the ground
running walking. He figured it might have taken 3 weeks before we actually did something.
For me, now is the time to continue to kick my dev skills up a notch. I’m looking to step my problem deconstruction and Ruby game up (through Project Euler), enhance my front-end skills (GA Front-End study group), and continue to upgrade my personal projects (Code-Crew/Hacker Hours).
Tool of the Week: ChromeDev Tools (video by CodeSchool)
Just started watching this course and although I’m still at the very beginning, I’ve already learned several new awesome tips from the first video alone.
Week 1: Closing Chapters
My first week working for The Start-Up marks the end of me using the term “aspiring” in front of “developer”, as I describe myself. Truly, although I called myself a web developer (as per my business cards), I sorta felt like a fraud. Without real experience, I had a hard time calling myself a developer and feeling honest about it. That chapter in my life has closed. I am a web developer. The term is slowly and comfortably settling into my mindset. I like it.
Indeed, the closing of one chapter in your life can mark the beginning of another.
On Sept. 14, 2012, I resigned from my job after getting accepted to the Web Development Immersive program @GA. The file containing the resignation letter is called “I quit my job to start my life”. Thus, one chapter closes, another one opens.
On December 15, 2012 the WDI program ends, and on March 11, 2013, I begin a Jr dev apprenticeship at a start-up. Again, one chapter closes, and another one opens. No longer only building my personal apps, I’m getting real-world, ground floor, start-up experience. This is for real. Awesome and a little scary at the same time.
The first few days included getting to know the purpose of the site, the team and basic administrative stuff done. Getting access to the repo (private), getting a feel for the workflow as a distributed team (and working with a new dev partner), meetings & greetings with the team (good people, all), signing confidentiality agreements (
yikes! awesome). Hurry up and wait, plus a few fits and starts, as we get ramped up were part of the process. Yet, at the first weeks end, if someone asks me what I do, I say “I’m a web developer at a start-up in NYC”. Yep, that fraud feeling is gone.
Tool of the week: Screenhero
Introduced to me by Alex, Screenhero is a very cool collaboration tool we use to pair program.
We will always love you….
Mary Lannaman (8/12/1926 to 3/10/2013)