Hi, my name is Gabe Berke-Williams. I’m going to kick off this apprentice learning series with a couple of git-related things I’ve learned from the thoughtbot crew recently.
git log --name-status will show the status of each file in the commit. So if you’re looking for deleted files in commit ABCDE, you can do
git log --name-status ABCDE | egrep '^D'.
git commit --amend a lot to fix typos, and I learned from this Stack Overflow post that I can also use
git rebase --reword. It only allows you to change the commit message for a commit:
It does the same thing ‘edit’ does during an interactive rebase, except it only lets you edit the commit message without returning control to the shell.
First, let me introduce myself, my name is Alex and I’m an apprentice here at thoughtbot. You may recognize me from this, this or this.
As an apprentice I get to immerse myself in the world of thoughtbot. I sit next to amazing developers and designers, and do work on the exciting projects that come through the door. As a result I’m learning crazy fast, every day I write code that I could not have written the day before. However, even bigger than the knowledge I’m gaining about how to write code is what I’m learning about process of developing software. One of the things that’s really important is the way people work.
I had heard words like XP, agile, and scrum used to describe software development but had never seen them in practice. After 5-plus weeks here I can tell you that the way they do things works.
Every morning at 10:00 am the entire team gathers in the conference room. We each go around the room and say something along the lines of the following:
Alex: Yesterday I worked on ______, I implemented ______ I had to do ______ to make it work. Today I will be working on ______. I am blocked on ___________.
Someone else: Yesterday I worked on ______, I did ______. Today I will be working on ______. I have no blockers.
These standups are the lifeblood of thoughtbot. They improve communication internally and provide accountability. If I say I’m gonna do something in standup then I do it. It ensures that if someone is blocked on a problem that someone else can solve, then that problem gets solved.
We work in teams. Each team usually consists of one designer and 2 to 3 developers. Each team dedicates its time to one project. Once a week each team meets with the client to discuss what was done during the week. As part of the retrospective each person on the team as well as the client goes around the table describing how they are feeling about the project and airing any grievances they may have about the way the project is progressing. These meetings make sure that the team is all on the same page and that we are doing work that our clients approve of.
Airing of grievances
Before we work with a client we ask them to pitch to and converse with the developers and designers (not just the management) on their product. We want to know:
The reason we do this is simple. People do better work on projects that they’re excited about. By having potential clients pitch the product to us we can choose products that we want to work on.
Before I started at thoughtbot I was of the opinion, like many others, that testing your code is a waste of time.
It was part of my job as an apprentice so I did it. But I was not as exuberant about it as most of the other people here.
But then something changed.
I began to write cleaner code that solved real problems and when code introduced breakages I knew about it right away.
Now I get scared when I see code without tests and I am test driving all my code, even the stuff I work on outside of thoughtbot.
We practice what we preach and use Trajectory to manage product development. What this means is that there are no emergencies. If a client finds a bug or needs a feature developed, they simply put it in Trajectory and prioritize it. The developers and designers are able to take the top story off the stack and have a discussion around it. All from within the app.
We use Campfire extensively. We have a bunch of rooms:
These Campfire rooms provide a non interruptive internal dialogue. People can look into the room when they want to and ignore it when they’re busy coding (or designing).
One of my first days here, someone was explicitly told not to work on a client project on the weekend. This threw me for a loop. Shouldn’t a company want its employees to work all hours of the day? The thing is that thoughtbot understands that the best code is written during bank hours. This doesn’t mean that thoughtbot employees don’t code at home. Everyone is encouraged to work on open source and side projects at home; however, all client work is done during bank hours when we are writing our best code.
One of thoughtbot’s informal mottos is there is a better way to build software. After 5 weeks here I can tell you that the fine folks here have got something right. They write great code in a great atmosphere with no stress.
We’re looking for both designers and developers who are students, recent graduates, or more experienced candidates making a techology or career change to come on as Apprentices. If you are interested in applying, please visit our jobs page. If you know someone who might be a good fit, please pass it on.
The paid apprenticeship lasts for three months and during that apprentices will work alongside members of the thoughtbot team on actual shipping software and be paired up with individual developers and designers at thoughbot who will act as their mentor. They also get to take any workshops we offer during their apprenticeship at no charge.
At the end of the apprenticeship we may offer them a position as a web designer or developer at thoughtbot.
We’ve had interns, particularly in the summer, for several years now. Over the past few years we’ve increasingly been contacted by more experienced developers who are just getting started with Ruby and looking to find a place where they can be effective, while still learning.
At thoughtbot, we also don’t have different levels of developers or designers. Everyone should essentially be capable of operating at the level of senior developer or designer (or be able to soon after starting). We do this to ensure that we can operate effectively without project managers or salespeople. However, from time to time we interview people who we think may be a good fit eventually, but need more experience. In the past, we’ve sometimes offered these people an internship as a chance to learn on the job and potentially quickly grow into the developer we need them to be.
When offering these people an internship, it never quite felt right to call them “interns” but it was the best word we had. Additionally, over time we refined the internship program to really be a path to potentially getting an offer to be a full web designer or developer at thoughtbot.
With this in mind, along with some other lesson’s learned from the previous interns, we sought to have a more structured program in place. Out of that emerged our new Apprentice program.
We think that the changes we’re making now should make the Apprentice program worthwhile to everyone involved, and we’re looking forward to the first batch of Apprentices joining us in May.