We’re running full steam ahead as we build our team of the best teachers, developers and all-around Nerds we can find. To help us do that, we have added culture checks to our interview process.

The purpose of these checks isn’t to figure out whether a candidate can do the job, but rather to ascertain that he or she will work well with us. It’s no secret that Nerds need to be brilliant, but we’re also looking for folks who are hardworking and kind, and these checks help us find just the right fit.

The checks last 30 minutes and are completed by two interviewers. Instead of technical or experience questions, the interviewers ask questions that are aimed at teasing out a candidates’ values. We ask things like, “Under what kinds of conditions do you learn best?” and “How would your co-workers describe your work style or habits?”

After the end of the interview, the candidate is graded on how closely their values align with ours. At Big Nerd Ranch, we take our company’s culture very seriously, and the best way to preserve it as we grow is to bring on people who care as deeply about their work as we do. If you are interested in working with us, check out our open positions. We’d love to hear from you!

The post Culture Checks: Do You Belong Here? appeared first on Big Nerd Ranch.

I recently became our Developer Evangelist. In this role, my goal is to make the best developers in the world want to work with us. I constantly encourage developers to come out to the many events that we host.

In fact, we’ve got a lot of great things coming up:

• This Wednesday, Jan. 30, from 9 a.m. to 4 p.m., visit us at the Georgia Tech College of Computing Spring Career Fair.

• This Friday, Feb. 1, at 2 p.m., see Brian Gardner talk about Rails Engines at our weekly Tech Talk.

• Feb. 11, from 6 p.m. to 9 p.m., join us at our monthly Hack Night for dinner and the chance to work with other developers on fun side projects.

If you want to find out more about Big Nerd Ranch, especially if you are considering working with us, these events are a great way to learn about who we are and what we do. If you are new, let us know, and we’ll make sure you feel welcome!

The post Getting to Know Big Nerd Ranch appeared first on Big Nerd Ranch.

At Highgroove, we aim to be fast. When we jump on a project, we work with the client to understand their goals and begin delivering functionality on the first day. As the project progresses, we strive to increase the velocity of work on the project with each passing iteration.

Our ability to deliver high-quality work at an ever-increasing rate depends heavily on our process—specifically, the three things we do on every project.

Three things that get a project done fast

1. Test coverage: Full browser integration and unit testing is imperative to allow developers to spend time working on new features instead of fixing development bugs. Being able to trust your test suite gives you the freedom to make sweeping changes to a system quickly, without the fear of introducing error. It may take five extra minutes for us to write a spec before we jump into your feature, but the benefits of better design and fewer bugs save us hours in the long run.

2. Leverage the open-source community: By now, it should be obvious that if you are reinventing the wheel instead of using open source technologies, you are throwing development money down the toilet. What may not be as obvious is that you are also wasting time if you are not also contributing to the open source community. By releasing code that is not specific to your app, you gain the support of not only your developers at Highgroove, but also of everyone using your code. This can give you huge returns in code quality and maintainability throughout the life of the app, and it speeds up development.

3. Constant delivery and feedback: As we work on your project, you won’t sit and wonder what’s being built for months, weeks or even days. For most projects, the time between delivery of new features is on the order of hours. Because we embrace the agile method, you are able to play an active role throughout the process and make adjustments to your project as they are needed. With a commitment on your end to constant feedback, you are able to iterate on the requirements of the project without a large amount of rework.

Using these three methods, we deliver solid products that make our clients happy. What are the methods you use to meet client needs?

Image credit: Kroiz

The post How to get a Ruby project done fast appeared first on Big Nerd Ranch.

Last month on the 37signals blog, DHH wrote about testing like the tsa. In the article David argues for less strict test driven development and quotes Kent Beck in saying:

I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence (I suspect this level of confidence is high compared to industry standards, but that could just be hubris). If I don’t typically make a kind of mistake (like setting the wrong variables in a constructor), I don’t test for it.

At Highgroove, we feel this approach is not for everyone. Read on for more details on our approach.

While it may be true that after years of working with automated testing you may not need to aim for 100% coverage, your instinct for what needs to be tested and what does not comes from experience. Complete test coverage of your codebase may be overkill, but generally more tests are better than fewer.

For most of us, developing with tests is a process that changes over time. Less experienced developers should aim for full coverage using integration and unit tests. As a developer learns to write tests, they get a sense of when writing a test is too hard or is taking too much time. Nine times out of ten this will mean that the code you are trying to test is poorly designed and needs to be refactored, not that you shouldn’t be writing a test.

Test driven design is one of the most powerful tools in a developer’s arsenal and most of the time you are not testing enough instead of too much. Overall, developers need to experiment to see what makes them most effective, not just follow rules laid out in a blog post. 😉

Image credit: DaveBleasdale

The post Testing Like a Highgroover appeared first on Big Nerd Ranch.

Highgroove really likes Pry. It’s a great tool for digging into your code and seeing what’s going on with tons of great features. However, there are situations where using a standard binding.pry breakpoint will not block your program and allow you to inspect it. I recently ran into this situation when trying to debug an application that used Foreman to manage it’s processes. Luckily, the pry-remote project turned out to be a great solution.

When a process being run by Foreman hits a regular Pry breakpoint, the process will halt, but you will never be able to interact with the Pry session. This effectively freezes the app, forcing you to kill the Foreman process.

To work around this using pry-remote, you must first set it up in your project. First install the gem:

Once the gem is installed, you can now add a breakpoint in your application with binding.remote_pry. When the breakpoint is hit, pry-remote will block your app and open up a DRb endpoint that a client can connect to. Running pry-remote in a shell will then connect to the session and you’ll be able to interact with Pry as you normally would. Simply call exit in the Pry session to unblock the application.

Have you picked up any other tips or tricks while using Pry? Leave a comment below!

The post Debugging Remote Processes With Pry-Remote appeared first on Big Nerd Ranch.

Prior to working at Highgroove, I worked for a number of softare product companies. One of the best metrics I’ve found for measuring how great a company is to work for as a developer is the Joel Test, which is a list of 12 simple questions. I’ve worked at companies that have scored high and companies that have scored low, and please believe me when I can tell you that the issues on that list really do make a difference.

My only issue with the Joel Test is that it is really geared toward software product companies. While a lot of the ideals translate to a software consulting company, the specific questions don’t always apply when you are working on a lot of projects for a number of clients. So, in an effort the help measure what makes great software consulting teams so great I present…

The Highgroove Test

1. Do you give your customers access to their source code?
2. Do you document projects expecting that your developers will eventually be “hit by a bus” (no longer be on the project)?
3. Do you track results instead of tracking time?
4. Do you promote Test Driven Development?
5. Do you use and contribute to open source?
6. Do you use code reviews?
7. Do you use the best tools?
8. Do you only hire the best developers?
9. Do you require constant learning from your developers?
10. Do you favor simple solutions?
11. Are your developers your project managers?
12. Do your developers deliver code to customers at least daily?

Like the Joel Test, this isn’t meant to be the be-all-end-all list of what software consulting teams should do, but we at Highgroove believe that a team that can answer yes to these 12 questions consistently is a great team to be a part of.

1. Do you give your customers access to their source code?

A developer should never have to feel that their customer doesn’t have access to the work that’s being done. The source code is the client’s property and it’s important to be as transparent as possible.

2. Do you document projects expecting that your developers will eventually be “hit by a bus”?

With many of the developers at Highgroove biking to work though Atlanta’s busy streets this issue is almost more literal than figurative. Each project should have a README with all the steps needed to get the development environment up and running with no outside input. The issue tracker should have all the information on what has been done and what will be done in the project. To achieve this at Highgroove, we make our Pivotal Tracker projects the authoritative source for all information about the project. Nothing should live solely in a developers head.

3. Do you track results instead of tracking time?

Tracking time gives developers the wrong incentives. A software consulting team should push to work as efficiently as possible. Tracking hours pushes developers to stretch work to take an allotted amount of time, and forces them to focus on the clock instead of focusing on cranking out functionality. It’s inefficient and lowers the morale of the team. Your work place shouldn’t just be results only, so should your projects!

4. Do you promote Test Driven Development?

Consultants need to deliver well designed and bug resistant code efficiently and consistently. The best way to do this is having automated testing as a key part of your development workflow. This should be part of the team’s culture. If you are not worried about catching guff for not including tests in that last commit, then your team is not as serious about testing as it should be.

5. Do you use and contribute to open source?

If your team falls victim to the Not Invented Here Syndrome you are wasting your time and your client’s money. Period. Making use of existing, open software allows you to leapfrog ahead and crank out value for your clients. Contributing back to the community can get you great karma, but more importantly better code, great marketing, and the ability for developers to scratch an itch for projects they love to work on.

6. Do you use code reviews?

Code quality should be consistent across all members of the team. One of the best ways to ensure this is to have regularly scheduled code reviews from all different members of the team. As a developer you get yet another pair of eyes to guard against issues with your code and designs; As a reviewer you get to learn from all of the work your colleagues are doing. This is one of the best ways to foster growth in the team as a whole.

7. Do you use the best tools?

This is the only hold over from the Joel Test. This is amended a little because as a developer who uses VIM and Unix for my development environment it felt odd to say “Do you use the best tools money can buy?” A simple idea is encapsulated in this question. If you are a software development team and there is something out there to make your developers more awesome, why are you not using it?

8. Do you only hire the best developers?

I do not want to be the best developer in my team. To clarify, I definitely strive to be the best developer on my team, but I do not want to be surrounded by developers aiming straight for the middle. If a team is great and getting better, you as a developer have room to grow and get pushed to improve every day. Mediocre developers are a liability and can drag a great team down.

One key point about this question is that ability should not be confused with experience. A fast learning developer who is committed to improvement is often a much better addition to a team than someone who has been doing a less than stellar job for a few years.

9. Do you require constant learning from your developers?

Learning should be part of the culture of a great software consulting team. Your clients expect their developers to be up on the latest and greatest. Moreover, encouraging learning helps to keep developers engaged as they get the chance to tinker with new technologies and best practices. Learning is a huge part of what we do here at Highgroove, from our weekly tech talks to our new company book club.

10. Do you favor simple solutions?

While, as a developer, it is always tempting to engineer a bomb proof stats engine that can generate beautiful graphs of everything you could ever possibly want to know, sometimes all you really need is a CSV file that can be opened in Excel. Consultants should focus on giving the client what they really need, instead of what they are asking for on a specific day and give suggestions accordingly. Moreover, there are few bigger drags on morale as a developer than pouring hours into a solution that you know in your heart is superfluous.

11. Are your developers your project managers?

At certain scales having a separate project manager is unavoidable and can be very helpful. However, at Highgroove we’ve found that when we are able to break up projects very granularly and empower developers to manage their own projects, they are much more efficient. With developers interfacing directly with clients, there is much less overhead in communicating issues back and forth. This is more rewarding for the developer and creates more value for the clients.

12. Do your developers deliver code to customers at least daily?

There no longer any reason for a developer to collect requirements, go into seclusion for three months and then deliver code to the client only to have something to be a little off. Tools like Github and Heroku greatly reduce the friction associated with releases so that they can be done multiple times throughout the day. This allows clients to catch issues or change their minds very quickly with a minimum of rework on the developers part. The tighter the feedback loops is, the happier everyone involved with the project will be.

Here at Highgroove, we are very proud to be able to answer yes to all 12 of these questions. We believe that the way we work is a major part of how we do a great job for our clients and what makes us such a great place to work.

What else? Can you think of a better way to test for great software consulting teams?

The post The Highgroove Test appeared first on Big Nerd Ranch.

While getting to know the very sweet Github Api v3, I ran into a little bug when trying to page though results coming back from the service. While it was frustrating at the time, Github’s support and resolution blew me out of the water.

For a new in-house project, we would like to be able to grab the commit messages for a number of our repositories that live in Github. Using the octokit gem with the auto_traversal option turned on, this is trivially easy. Because of a bug in the Github api, when the gem tried to page though the results, the link it got for the next page was always the same. This caused an infinite loops of http requests, and me to try to pull all of my hair out.

Once I threw a few Pry bindings into the project and was able to track the issue, I was able to easily hunt down Github’s support for issues with the API (it was right on the docs page for the API). All that was required to get a fix deployed for the issue was a quick email with steps to reproduce the bugs and less than 24 hours of patience!

The fact that the Github crew was able to submit a fix to their live service before I could submit a pull request to octokit with a workaround reminds me why they stand out in my mind as a great web app. Not only is their site feature rich and easy to use, but they’ve got a great team backing the technology up. That’s why we at Highgroove trust them with our code and why we recommend them to clients.

The post Another Reason To Use Github appeared first on Big Nerd Ranch.

I’ll be honest. My reaction to my first morning in the Highgroove office was one which I thought I would not be sharing. After talking to a couple other Highgroovers, however, I realized it was a pretty common reaction. To us, our first day felt a little bit like Christmas morning.

I fully realize how cheesy this sounds, but showing up to a new desk covered in a goodie bag and developer treats must have brought out the giddy 10 year olds in us. My previous jobs have usually provided me with some inherited file folders, a pile of training and maybe a dying fern on the first day. With Highgroove, we got launched head long into developer bliss with a new macbook pro (!), luxurious extra monitor and all the amenities right off the bat.

Possibly more important to the new employee experience than coming into a sweet new workspace is coming in to a ROWE. There is no stressing out to appear busy on your first day, no waiting for someone to tell you when to go to lunch. There’s only learning about Highgroove and getting up to speed so that you are ready to work magic for your first client.

Our experience was that even on our first day, we knew we will only be judged by the results of our work and that we will be provided the tools to reach our goals. That has made being a new employee for Highgroove different from any other shop around.

The post Starting Off Right appeared first on Big Nerd Ranch.