cpytel

Wax on, Wax off

In episode #8 of the Giant Robots Smashing into other Giant Robots podcast, Ben Orenstein is joined by Gabe Berke-Williams and Edward Loveall. Gabe is developer at thoughtbot and the product manager of the thoughtbot apprenticeship program, apprentice.io. Edward is a current design apprentice.

Gabe, Edward, and Ben talk about apprentice.io, how it works, it’s successes, and lessons learned. They also discuss how Gabe goes about mentoring new developers, and effective learning and teaching methods. Edward also gives his perspective on his apprenticeship how it went, his typical day as an apprentice, his advice for incoming apprentices, and much more.

To have us answer your questions on the air

Email your questions to info@thoughtbot.com or tweet to us @thoughtbot.

Notes & Links

Upcoming Events

Follow @thoughtbot, @r00k, @gabebw and @edwardloveall on twitter.

January 23, 2012

lukegriffiths-apprentice

Apprentice.io Three Week Retrospective

Over the past three weeks I’ve begun my apprenticeship at thoughtbot. The apprenticeship lasts until the end of March. I’m joined by designers Paul Webb and Edwin Morris, and fellow coder apprentice Alex Patriquin. Each of us is assigned to a mentor, who makes sure we absorb as much as possible of the thoughtbot way of doing things and achieve our specific goals. For me, the apprenticeship is a couple of things: it’s a chance to work in coder nirvana (TDD, heavy refactoring, bookshelf full of great literature, 5-minute meetings, pair programming, investment days, open source - the works), and it’s a chance to vastly increase my Rails skills in a bootcamp-style training environment.

My head is swimming with new knowledge. I entered this state the first day, and I’ve been there constantly for the past three weeks. Each evening I ride the T home with my poor neurons about to burst with new activity. At night while I sleep my brain indexes all this new knowledge, and the next day I dive in again. If you’ve ever read Ender’s Game, it’s sort of like Battle School for Geeks.

Let’s get specific. This list is long because I’ve been truly busy. In the past three weeks I have:

Mercilessly refactored my code two, three, even four times after writing it. The standards for code quality here are very, very high.
Learned to use Github pull requests for code review.
Responded to around 150 code review comments, most of which made me stop and rethink coding habits I’ve held unconsciously for years. My style is improving fast.
Participated daily in a morning company-wide standup that actually takes less than five minutes, and a team standup that takes another five. That’s only ten minutes of meetings per day!
Switched to using higher-level cucumber tests involving steps like “When I sign up as a new user” as opposed to “When I click the link marked ‘foo’”.
Achieved and maintained 100% perfect TDD discipline - not writing a single line of feature code until a failing test is present.
Completely switched text editors, from Textmate to Vim.
Became faster in vim than I ever was in Textmate.
Written custom functions for vim.
Learned other new tools including Homebrew, ack, ctags, New Relic, KISSmetrics, and kumade.
Forked thoughtbot’s dotfiles repo and started customizing it as my personal dev environment. The dotfiles repo contains bashrc, vimrc, git-config, alises, etc - I can now install it to any computer I use to instantly have my customized dev environment in place.
Watched an app’s user base jump from 100 to 10,000 in a matter of minutes as an article hit TechCrunch.
Gotten a crash-course in startup funding from the other coding apprentice, Alex Patriquin, who boasts, quite accurately, of knowing everybody.
Participated in discussions about new features in rails.
Made my very first contribution to an open source repo.
Been approved to give my first professional presentation - a lightning talk at at Boston.rb meeting.
Consumed 3,000 cups of green tea and a foie gras taco.

Did I mention I’ve been busy? That’s just the first three weeks - and I’ve got ten weeks left. I feel excited, involved, and challenged in a completely invigorating way. The team here is universally smart and helpful, and while I’m here I simply can’t help but get better by osmosis at what I do. This is the most fun I’ve had in an office in a long time.

For more information about this program, and to sign up to sponsor a pool of apprentices, visit apprentice.io

More later on,

December 14, 2011

dancroak

Internship or Apprenticeship?

What’s the difference between an internship and an apprenticeship?

Internship

An intern is someone who:

usually wants to explore many options for their next job, or career in general
may be unpaid
is probably in school

A company who hires interns:

often has special project work that is a good fit for part-time employees
knows it’s very likely the intern will work or study elsewhere after their internship

Apprenticeship

An apprentice is someone who:

knows what type of job they want next, or what kind of career they want
is almost always paid
is probably not in school

A company who hires apprentices:

has apprentices work side-by-side with expert employees on typical project work
usually hires them for craft work, such as software development
expects that the apprentice will probably work for them as a full-time employee after the apprenticeship

No value judgements

Neither an internship nor an apprenticeship is bad and the other good. I believe they’re intended for different people and companies.

Someone who isn’t sure they really want to be a web developer might feel overwhelmed in a rigorous apprenticeship. Someone who craves pair-programming with an expert may feel frustrated in an internship.

Similarly, not every company is able to provide the kind of one-on-one relationships that are necessary in an apprenticeship.

Who cares?

Well, I might be alone, but I do.

Lately, I’ve seen many many many interesting variations on the themes of internship and apprenticeship in web design and web development, probably driven by demand.

Setting expectations for everyone involved never hurts.

Written by Dan Croak.

November 4, 2011

stevehickeydesign

Climbing back up the mountain

Today is the end of my fourth week as a Design Apprentice here at thoughtbot and it’s been pretty crazy so far. Before I got started I was excited to start filling in all the minor gaps in my knowledge. My first week was spent looking at documentation and demos for new tools and languages and running through tutorials. It was exciting stuff, and all seemed pretty straightforward. All I had to do was jump onto a project and I’d be contributing in no time. I was confident that I could go from Photoshop jockey to front-end guru in a matter of days.

Then I started writing code that was actually intended for release to a client’s product. The panic set in pretty quickly. The “minor gaps” were quickly revealed to be “huge gaping chasms of inexperience.” I had worked with HTML and CSS plenty of times before, but the pace was leisurely, the deadlines few and far between, the complexity very low. Now I would go from discussing a new feature in the morning to the expectation of having it complete by lunch.

This was a pretty big wake up call for me. At my previous job I was considered the design team’s authoritative source of development knowledge. Questions came to me first and my answers were accepted as absolute truth. On the rare occasion that the designers were expected to write code (the horror!) the task would be assigned to me. I was pretty comfortable on the top of my mountain, so to be body-slammed off of it so effortlessly was a serious bruise to my ego.

It’s been two more weeks since then. Things have gotten better. I’m not blazing fast, and I don’t always do things perfectly the first time, but my confidence is back (tempered with a good dose of humility). I’ve learned a few important things about tools and process during this time. If you’re an apprentice, or a designer that’s new to the expectation of delivering front-end code, hopefully this will be of some benefit to you.

Vim

Vim will look clunky to you if you come from a background similar to mine. A few years of Dreamweaver, the eventual move to a better piece of software like Coda or Espresso, and then this? You want me to work in a text-based interface with a complete lack of familiar keyboard commands? It will seem insane, but there are some huge benefits and you should stick it out. Once you start to become familiar with it, the potential for amazing speed will become apparent. The hard part is making your hands learn all the new movements and commands. Once your muscle memory starts to kick in things will become faster. I wouldn’t say I’m great with Vim yet, but I’m at least as fast as I was in Espresso, and working hard to improve.

It’s important to note that I work in an office of Vim users. It makes sense for me to use it and I have a great support and learning network. If everyone in your office uses TextMate, or Espresso, or something else, you should probably use that too so that everyone’s on the same page.

Sass

Sass is amazing. If you know anything about CSS, just reading their documentation ought to get your blood rushing. My favorite part is the ability to nest selectors, which makes it incredibly easy to target elements correctly. Add in variables and mixins and you’ve got a very powerful extension to CSS.

If you want a set of great mixins, allow me to humbly suggest thoughtbot’s Bourbon.

Ruby on Rails

This was the hardest part for me to adapt to. I’m used to working on static sites, so finding where everything was located in the Rails framework was intimidating at first. Luckily, I get to attend workshops (for free, it’s a great perk) at thoughtbot and our Intro to Ruby on Rails workshop was incredibly helpful in teaching me to navigate an application.

Code/Design Reviews

Have someone else look at your work. A lot. More experienced people will be able to point out what you’re doing wrong and what you could be doing better. It’s important to correct these behaviors before they become habits. Don’t be timid about offering your own feedback either. Design is often a collaborative process, and talking about your ideas usually results in better work.

But what if you’re the only designer at your job, or a freelancer? Start by posting your work on Twitter or Facebook and asking other designers for some feedback. I’ve found that many people are willing to take the time to send you a short review. Dribbble can be another great place to get input.

Google

You can almost always find answers to your problems by searching for them online. The odds of encountering an issue that somebody else hasn’t run into and solved before are incredibly low. And in our industry we’re lucky to have a lot of knowledgeable peers who enjoy writing about their solutions.

You will improve

Most importantly, try to stay positive. You’ll have ups and downs, successes and failures, but as long as you’re moving forward you’ll be ok. I’m lucky to have people at thoughtbot who are committed to making me a better designer and a better front-end developer. Try to find people like that for yourself, either in your workplace or online. We’ve got a great community full of intelligent, helpful people. Take advantage of it.

August 31, 2011

hyperbuddha

How to make the most of an apprenticeship

Today is my last day as an apprentice at thoughtbot. I am incredibly sad to be leaving but, at the same time I am jazzed about all the new stuff I learned this summer. I thought I would share a few things learned about what my role was and how to get the most possible value out of an apprenticeship on my way out the door.

What is this apprenticeship you speak of?

Apprenticeship is a way to learn about being a professional software developer. Specifically, it is a way to learn to be like the most skilled software developers you can find. It involves seeking out good teachers, and taking opportunities to learn by working alongside them. It is the first step on the road toward becoming a different kind of software professional—one who wants to be more than just competent.

—Apprenticeship Patterns by David H. Hoover and Adewale Oshineye (a great book for any apprentice)

At thoughtbot my role as apprentice has meant that I worked on client and internal projects. It was nothing like most internships: the only time I got coffee it was for myself. Shipping code every day, even to production. I was able to learn about the real world problems developers face and how professionals like the folks at thoughtbot go about solving them.

But, I can’t get someone awesome like thoughtbot to take me on.

An apprenticeship doesn’t need to be formal. Go to developer events (if you’re in Boston checkout Boston.rb) and make friends with developers. Once you are close with them ask them to take a look at some code, ask if they’ll sit down and pair with you on something you’re working on. Contribute to open source and learn from the comments on your pull requests (thoughtbot has some great projects to get started on).

I have an apprenticeship; how do I make it awesome?

There’s no such thing as a stupid question, but google is your friend.

My first few days at thoughtbot I posted every question I had in the campfire chat. Why not? I had all these great developers around me I should ask them for help. Then one day my mentor Harold posted the guide to asking smart questions (I think lgtfy also showed up a few times). While it may be true that there’s no such thing as a stupid question don’t waste your mentor’s time, google it first.

Pair early, Pair often.

One day I asked Harold if I could pair with him. He responded, “Don’t ask just come sit down”. Ever since whenever I wasn’t sure what to do I would sit down and pair with Harold. I think that I will miss that more than anything else. I learned about some crazy vim keybindings, about elegant code, and about how to test drive development. Sitting next to Harold and watching him code led me to ask questions I didn’t know I had and taught me new things about Ruby and Javascript.

Code reviews save lives.

One thing they do religiously at thoughtbot is feature-branch code reviews. This meant that every line of code I wrote was looked at by other developers. This not only caught my mistakes, it also taught me about best practices and refactorings.

If you ever have an opportunity like the one thoughtbot offered me, don’t hesitate, take it. This summer has been amazing, every day I wrote code I couldn’t have written the day before. I also got an inside look at the way software gets built. I now understand user stories, TDD, wire-framing and a myriad of other things.

It’s been a pleasure working here.

Over and out.

giant robots smashing into other giant robots

Written by thoughtbot