We needed to come up with some nerdy conference room names, so in hopes that we would find inspiration within, we sent a quick survey to our Nerds, asking them to list the “10 nerdiest things of all time.”

We now have a list of several hundred things that are all pretty nerdy, and some contenders for conference room names. While we can’t share those just yet, we can share the data.

Among the more obvious contenders like Star Trek and Star Wars, there was some ballot stuffing for Dwarf Fortress, along with a slight affinity for pants (khaki pants, pleated pants, short pants) and shirts (short-sleeved plaid shirts, silk dragon shirts, Dragon Ball Z button-up shirts). Who knew?

We’ve opened up the survey, so let us know your top 10 list. We’ll keep the result data open and let you know what we find out.

So tell us, what are the 10 Nerdiest things of all time?

The post The Nerdiest Things of All Time appeared first on Big Nerd Ranch.

Highgroove requires everyone to attend a conference every year, and begrudgingly I agreed to head to Hawaii for Aloha Ruby. The flight was long but well worth it, the weather was amazing, and the conference was packed with useful information.

Performance is Key

The reccurring theme for the two-day event was performance. Some of the big takeaways for me were:

We’re all used to hearing that “Rails is slow,” but that’s just a quick jump to a “root cause” that doesn’t tell us anything. Rails 4 (which is creeping towards its release date) has several performance-related fixes, but slowness in an app is almost always the result of poor choices in data structures or algorithms:

• Are you requiring tons of files and gems? In MRI, Ruby’s ‘require’ compares each file you load to all the previously loaded files, making the problem exponentially worse with every file you add. This is why your Rails app takes so long to start.

• Are you using set operators in Redis without understanding their performance implications? Is there a good chance that the data you are sorting is already sorted? If you haven’t thought about the big-O impacts of your code, you’re probably doing it wrong.

Specific performance tips, including some from Richard Schneeman:

• Don’t queue web requests, as this only scales while your request is lower than your available concurrency. As soon as you hit that number, everything will fall apart.
• Set config.active_record.auto_explain_threshold_in_seconds to get details about slow queries in your log so that you can address them.
• Use the ‘cache_digests’ gem in Rails 4.
• Set config.static_cache_control = "public, max-age=2592000" to let assets cache properly.
• Set config.asssets.digest = true to fingerprint files for better caching.

Videos you should watch

There were many more interesting talks than I can talk about here, but all the videos will be up on Confreaks soon enough. Here are a few I specifically recommend:

• For some of the gritty bytecode aspects of various Ruby interpreters, make sure to watch Konstantin Haase talk internals in “Message in a Bottle.”
• Find out about building a service-oriented architecture from James Rosen in “Carson: On the Path from Big-Ball-of-Mud to SOA.”
• See how easy it is to do Bad Things with Ruby gems in Benjamin Smith’s “Hacking with Gems.”
• Watch Matt Aimonetti’s talk on mruby to find out why we need another Ruby interpreter.
• Learn 101 neat things that Ruby can do from James Edward Gray II.
• Get convinced that legacy code is good and what you want to write, after watching Chad Fowler’s “Legacy” talk.
• See what makes a Ruby library great in Mitchell Hashimoto’s “Building a Ruby Library: the Parts No One talks About.”

More than code

Lastly, were reminded that it’s not just about the code. Being a great developer means growing into new roles to build something bigger than just your own interests. What starts as contributing to open source grows into creating or maintaining a major open-source project, which grows into enabling other people to maintain the project for you (see Wesley Beary’s talk “Maintain Less, Mentor More”). Or pulling things together for designers turns into learning some key design fundamentals and getting to a minimum viable product sooner (see Glenn Gillen on “The Designers are Coming”).

I also learned that mai tais are good, and while Aaron Patterson’s cat has a twitter, cats are getting pretty played out, and several speakers chose to include photos of dogs and sharks instead. The hotel had an awesome daytime and nighttime view, and I got to sneak in some touristy things too, from sunrise on Diamond Head hike, to a luau, to ziplining.

Aloha Ruby gave me a lot of insights to new knowledge and helped me rethink things I already knew. What about you? What have you learned from the conferences you’ve attended lately?

The post Aloha Ruby appeared first on Big Nerd Ranch.

We run our business the way the we develop software: we practice “small-a agile,” meaning that we follow the core agile values and iterate on features as our needs change and grow.

As we’ve gone from two developers to 20, things have gotten a little more complicated. A traditional company might have started off by hiring a full C-level suite, but we’ve taken the approach of planning positions with very specific roles, sometimes even making up titles as we’ve gone along. Some of these jobs are pretty familiar, like “marketing manager,” but there are some more unusual ones like “developerer” (more on that in a later post) and my role: “methodologist.”

So what does a methodologist do?

Officially, a methodologist is someone who studies and practices methodology, which is usually a guideline system for solving some kind of problem. Since that doesn’t actually tell you anything at all, here’s a look at what I do day to day to improve processes at Highgroove:

• One-on-one meetings: I sit down with each developer weekly to talk about how his or her projects are going. These talks take only 5-20 minutes, but we are able to look at development progress, the developer’s communication with clients and their usage of internal tools. We also identify what resources the developer might need in order to make clients happy.

• Things That Suck: In the one on ones, I ask everyone to tell me about something that sucks at Highgroove. The answers can range from a shortage of double-shot espresso cups to a feeling that Highgrooves’s current direction doesn’t reflect our core values. After talking to everyone, CBQ and I go through the list, turning every response into something actionable. We buy more espresso cups, resolve issues and identify next steps to keep developers happy.

• Project kick-offs: I help get new projects off to a good start by getting developers and clients on the same page and ready to build awesome things. Sometimes we talk about project tracking tools or specifics, but only enough to identify and eliminate any barriers to a successful project.

In addition, I also translate company goals to actionable projects, iterate on our new-hire boot camp and identify ways to improve sharing of information among the team.

Oh, and I get to come up with and execute fun things like getting Fitbits for Highgroovers and arranging an office-wide trip to the beach this week.

Making jobs to fit the company

When we have meetings, CBQ and I sometimes realize that we need to hire another person to join our team, and sometimes we create a new role that’s never existed before. As I said earlier, we don’t try to make Highgroove fit into traditional ideas of job roles; we plan what we need to accomplish, and then we find the person who can best help us reach those goals.

When I started at Highgroove, I was building Ruby on Rails applications, but I now help run the business as we grow. Instead of focusing on code quality and test coverage, I’m focusing on keeping our clients and developers happier than they could be anywhere else. I’m not a developer, a scrummaster, a manager or a director of engineering; I’m our methodologist, and I’m here to help!

Do you make up jobs at your company? Could yours use someone like a methodologist?

Image credit: Leo Reynolds

The post Methodolowhat? appeared first on Big Nerd Ranch.

This past weekend, Highgroove and Mailchimp helped Collective Idea bring Finish Weekend to Atlanta.

Instead of a ‘Startup Weekend’ which is a pretty common occurrence where people bring ideas to start something with, everyone showed up with projects-in-progress and the goal of launching something by the end of the weekend. For me, this meant a big backlog of updates to a rack of servers and updates to some Rails and Drupal sites (as well as pairing with someone else here to beat Diablo III on Normal difficulty), but for other people it meant everything from a brand new company website, to migrating old PHP code to a new Ruby on Rails backed site, to a minimum viable product release of hydrogen: a command line tool for managing WordPress installations.

Much food was eaten, and a lot got done. The schedule planned for presentations of what everyone finished to take about an hour on Sunday, but we spent almost 2 hours seeing all the cool things that everyone accomplished. Like everything Highgroove does, this was the first round of an experiment and we think it was pretty successful.

That said, we learned a lot that we’ll use to make future events that we host even better. First up, some Accountability would have helped: Defining what ‘finished’ actually means and checking in with everyone a few times through the weekend would have helped people stay on track. Agile development encourages re-prioritization and changing scope when faced with challenges or deadlines, and a lot of people were so heads down in their projects they didn’t think about re-scoping things so they could launch Sunday afternoon. This meant less people were able to ‘finish’ than how many could have.

A bit more structure would have built a bigger sense of community and gotten more eyes on problems instead of just leaving everyone to their own devices. Connecting the Node.js person in one room with the Illustrator in another room at the right time could have led to even more awesome things. Little schedule things like enforced (short) time limits for all introductions and presentations, as well as timed breaks and activities would keep things moving and effective. Even things as simple as “every time we ring this crazy bell, talk to someone you haven’t talked to before for 5 minutes” could have led to more awesome things.

Lastly, better marketing and exposure during the weekend would have been great. A live stream of some sort, blog posts and tweets with what is going on, and ways for people to participate remotely would all have built more momentum and led to more things getting done.

The concept of a ‘Finish Weekend’ is one we like, and look for another one of these in Atlanta in the future!

The post Finish Weekend Finished appeared first on Big Nerd Ranch.

As you’re probably very well aware at this point, Highgroove is a Results Only Work Environment which means that it doesn’t matter when or how we get our work done, as long as we get it done. This means that working from the beach is okay! Awesome!

While working from the beach seems like a great idea, we’ve iterated a bit on working vacations and have some things you should read if you’re considering combining a vacation with getting some work done. Read on for the details.

Most companies have a strict vacation and holiday policy. You get some number of specific holidays off per year, and a set number of vacation days which you slowly accumulate and get to spend on being completely disconnected from work. At Highgroove, we have mandatory unlimited vacation, and ‘optional’ holidays. If you’d like to work on New Years Day and take 2 weeks off in February to take the longest nap ever, that’s completely ok and your paycheck will be the same.

That said, taking time off is weird! We’re all here to be super productive and we do keep everyone’s schedules pretty booked, so if we take time off it means pushing back some deliverable that a client is waiting on. This is almost always ok, and most of our deadlines are estimation based and not need based, but the temptation to ‘get some work done’ while on a family trip is pretty strong. NPR did a story a while back: Unlimited Vacation Time Not A Dream For Some which included a common thing we hear:

Some critics worry that in a culture of workaholics, unlimited vacation might really mean no vacation; that without a specified time to be “off” employees might feel pressure to always be “on.”

Especially in our field, this is a common feeling because people have smartphones or laptops with them most of the time, and everyone on the team is working a different schedule so 24/7/365, at least one person on the team is delivering value to a customer.

The answer to this is planning to work while on vacation! We tried this out, a handful of people have done ‘working vacations’ and the almost universal feedback is that this is a Bad Thing. Some thoughts:

Working while on vacation is a bummer: When you get somewhere and have the intention of working, something else you want to do always magically appears. You can’t just go do it and say “Tomorrow I’ll work twice as much.”

My trip was just weird because my girlfriend was trying to get me to do stuff during the day, but I just had to work.

Don’t think it’s going to be easy, Because it’s not. It will diminish the enjoyment of vacation, until you get comfortable.

Everyone that has taken a working vacation has gotten less work done than they planned, and it’s negatively impacted what should be a time of relaxation. That said, there is a way to make this work which involved being more structured and setting lower expectations. If you plan ahead for everything you need (quiet, space, time, internet, etc) and can ‘draw a line in the sand’ and block out specific blocks of time, there is a pretty good chance you can take a slightly longer trip and get some work done. Plan to work for 3 hours in the afternoon each day during the hottest part of the day, between a morning at the beach and happy hour. Let everyone you’re with know what this means and make sure that they’re off having fun without you or reading a book on the porch.

You can probably make a working vacation work, and over six days of your vacation you might get done as much as you would have in three days in the office, but when it’s all said and done, it’s probably better for you to just take the time off and relax. You’ll be more effective when you get back! ROWE puts you in control of how you get work done so you’re welcome to experiment, but I know I’ll be going off-grid on my next trip.

The post Working Vacations appeared first on Big Nerd Ranch.

You’ve read our blog, had Highgroove do work for you, watched our Tech Talks, attended the Atlanta Ruby User Group which we host, and all around think we’re great.

Now, you’ve decided that what you really want to do is hire one of our developers full time to work for you. Maybe you’re a recruiter looking to fill an ‘awesome position at a big company in the Atlanta area,’ or maybe your startup is ready to take the next step and hire an in-house developer.

We get a lot of e-mails and calls from recruiters, and to be honest, most of them are absolutely terrible. Read on for some tips on how to recruit Highgroovers to come work for you instead. Seriously. Please. We’re not telling you to not try and recruit our developers, but please stop wasting your time and ours.

First up, it’s Highgroove’s job to make our developers happy and to be the place that all developers want to work. We have a great culture, great benefits, and a bias towards making awesome anything which is not yet awesome.

Everyone’s motivations for choosing to work at Highgroove are different and our turnover rate is extremely low, but there is always a chance your ‘opportunity’ is the one that someone has been waiting for. When people do choose to leave and go somewhere awesome, we all give them high-fives on the way out. We’ve had people leave for Twitter, GitHub, startup incubators, and even a law firm.

Before you get in touch with anyone, do your homework. Everyone at Highgroove has different skill sets, so read their profiles on our About page and find out what their technical skills are and what they are interested in. One developer might be a good fit for LAMP development in Antarctica, while someone else would be much better for Erlang in Brooklyn. Your chances of hiring one of us become greater than 0% if you have a perfect fit for someone. Hint: If you contact several people at once here, you’re probably doing it wrong.

When you’ve narrowed it down to the perfect fit, don’t pick up the phone. Developers are trying to get work done, don’t like being interrupted, and universally hate these kind of phone calls. Send an e-mail, and make it good. If you want a response, your e-mail must be personal (not a form letter) and include the following:

• Company: If we don’t know who we’re working for, we’re not interested.

• Location: Do we have to move or does remote work? Where?

• Salary: “Based on experience” doesn’t cut it. You’re e-mailing us. Give us a range.

• Office: Online photos or video of the office somewhere is ideal. A cube farm with the lights off is only appealing to a small set of people.

• Answer: What would I be doing? “Rails” isn’t enough. What does the job actually entail? Head over to our Jobs page and look at each job. We lay out what it is that we expect our people to accomplish.

• Answer: Why would I be a good cultural fit? Coffee? Beer? Bicycles? Boats?

This gives someone enough information to find out if they’re a good fit. Hopefully, you’ll know before you send the e-mail (or get all the way through this list of requirements) if someone will be a good fit and your response rate will end up being pretty high.

Don’t ask a developer if they “have any friends who might fit this position.” That screams “I didn’t do my homework and am just grabbing anyone I can find.”

Do you really really want someone to work for you? Have someone important contact them instead of a recruiter or someone in HR. All of these are good choices: the person that wrote a programming language that is on your team, someone who is a popular speaker at conferences, someone who wrote “the book” on something.

And that’s it! It doesn’t seem too hard, but of the 36 e-mails I’ve personally gotten from recruiters this year, only one of them has met most of the criteria above. The phone calls (which, by the way, all get automatically sent to the voicemail box on Google Voice) all get ignored.

Most of this applies to other tech companies, but if they’re not as awesome a place to work as Highgroove, you might have an easier time recruiting. So good luck! We look forward to your e-mails.

The post How to recruit developers away from Highgroove appeared first on Big Nerd Ranch.

Highgroove Studios is proud to be helping Collective Idea bring Finish Weekend to Atlanta this June:

We’ve all heard of startup weekends. Many of us have participated in one. Coming up with a new idea is easy, so is getting started. Finishing is hard. Finish Weekend helps you get it done. Come finish those projects you’ve put off to the side. Maybe you just need a bit of web help, a logo, or some code written. We’ll help you finish.

Head on over to finishweekend.com to register, and then come join us the first weekend of June to get your project launched.

The post Finish Weekend ATL appeared first on Big Nerd Ranch.

Read on for why you should be using a combination of Sublime Text 2 and Vim instead of Textmate…

LOLJK. The tool you should use is the tool which is best suited for you to solve the problem at hand. There is no one right tool that everyone should be using. We could go on and on about different editors as that is something that developers are very passionate about but the fact is that each developer at Highgroove has a different set of software that they use to get their job done. We have a recommended list of Software for Developers that can be pretty useful, but to each their own! Part of everyone’s job description is:

Buy any tool that you think might be useful, Highgroove will reimburse you, and you must present to the team how your experiment works out and if the tool makes you more productive.

Software aside, Highgroove has a policy of buying the best tools available for developers, and there is a short list of things that we think are absolutely crucial for keeping developers happy and cranking out high-quality software. Some people argue that you should penny-pinch in every aspect of your business, but with our goal of developer happiness, we disagree.

Physical comfort comes first! While our personal trainer goes a long way, we have an office full of Aeron chairs and adjustable height desks. An ergonomic evaluation is happening in a few weeks, and we’ll be figuring out how to make our sitting and standing desks more comfortable. Every desk has a laptop stand and a big external monitor (Currently 24” Dell 1920×1200 displays, but we have one Apple Thunderbolt 27” display that everyone is trying out), and everyone gets an external keyboard and mouse or trackpad of their choosing.

Also very important to productivity and happiness is a top-of-the-line laptop. SSDs and maxing out RAM are both great for running huge test suites and working with Big Data, and while it seems most of us end up with 15” MacBook Pros, we’d let someone scoop up something else if it works better for them. Laptops enable working from anywhere, and we’re all pretty used to seeing photos from people ‘ROWEing’ it from decks, patios, the beach, etc. Just yesterday I was on a Skype call with someone that was working from their bathtub at home. If WiFi doesn’t reach, we have a Clear Spot 4G and pay for iPhone tethering as needed.

We know we can’t think of everything, so when someone at Highgroove wants something to help them work, we make it happen. Legos get added to the grocery list and show up the next day, hundreds of tiny buckyball magnets are stuck all over the place, and we have some super-nice condenser microphones for clearer conference calls and podcast recordings. And the sharks with lasers attached to their heads? We’re not supposed to talk about those.

Did we leave anything out? What non-software tools help your software business be awesome?

The post Essential Developer Tools appeared first on Big Nerd Ranch.

Refactoring is a something we spend a bit of time on at Highgroove, so much that David recently wrote about refactoring and related tools in Red, Green, Refactor and I’m writing with even more on refactoring and the ‘Refactoring Rabbithole’.

“When refactoring, it’s easy to see 10 other things that probably should/could be refactored”

Spending time on refactoring is a tough sell to clients: by definition, the ‘backend’ can be completely re-done without any visible changes in an application. As the complexity and size of a project grows, refactoring can be necessary to keep things as simple as possible, keep the code quality high, and keep the number of bugs low.

Refactoring should be done to address needs, but due to the huge number of patterns, developer habits, and differing intentions, it’s easy for developers to get carried away. In the worst possible case, you end up with ‘the rewrite’ where part or all of the backend of an application is rewritten from scratch. This is typically not cost-effective, but is actually needed occasionally.

More frequently, a developer will be implementing a small feature and see ‘one small thing’ to fix. Then they see a related method that could be more readable, some inconsistent naming, and before you know it they’ve spent the entire afternoon going down the rabbit hole and touching every file in the project.

A recent project that Highgroove took on to get in ‘launchable’ shape looked like it was going to just require a little bit of polishing and a ‘new sign-up flow’, but ended up not having any test coverage and had a lot of code from it’s previous development team that was overly complex (some of which was intentionally obfuscated to make it harder for ‘hackers’). Our customer wanted to launch their product ASAP, but there were some features they needed that weren’t yet built.

We explained their current situation, testing, and refactoring, to the customer and outlined several options:

• The “Nuclear” option – Redoing the application from scratch, and doing it in the Right Way following industry standard best practices.

• The “Cross Our Fingers” option – Building the new sign-up flow, but sticking with the pattern of the rest of the system and not writing tests because we couldn’t adequately test new features independently without touching the rest of the system.

• The “Refactoring” option – Identifying parts of the system that we would need to interact with, writing tests for them, and refactoring them as needed to enable clean integration with the new features we’d be developing.

Hopefully you can guess: they chose the last option. We spent several iterations adding tests, improving code quality, and once we got the point where we could start adding the new functionality, we stopped. There were still random abbreviations, huge swaths of untested code, and things that we didn’t understand, but our client had a time budget that we needed to stick to. This was hard! As developers, we like doing things the Right Way which means shipping high-quality, well-tested applications. In this case, we had to settle for something much less than perfect.

For every major issue we identified, we updated the README with suggestions for future development, and for every issue regardless of size we created stories in pivotal tracker, anywhere from “Refactor the Foo model to replace all occurrences of SOS with SaveOurShipMessage or save_our_ship_message” to “Figure out what the baz method does, give it an appropriate name, write tests, and refactor for readability.” Some of these things got done as we wrote code that interacted with them, and many more are still in their backlog, hoping to be eventually done.

Just like any new functionality, for any refactoring ideas we make stories for each one. We keep these stories as descriptive and simple as possible, and they get prioritized by the client like any other stories. Seeing these stories pile up in the backlog and knowing that the issue won’t be forgotten is usually enough to keep me from taking refactoring further than I need to.

How do you control your insatiable urge to rewrite everything? How do you sell refactoring to customers?

The post Refactoring: where to draw the line? appeared first on Big Nerd Ranch.

ROWE means getting results done and not worrying about when it happens or how long it takes. This is a great way to get things done, but the amount of time spent on tasks can be an extremely useful metric.

At Highgroove, we’re strictly ROWE: it doesn’t matter what hours we work or how much time we spend on things, as long as the work gets done and the customer is happy. Some people work the 9 to 5 while others work off and on 24 hours a day. Some people manage how they get things done with tools like paper or Things.app, and everyone has a different workload and different set of customers they interact. This is great because tons of work gets done and we don’t have to continually interrupt ourselves to track how much time we are spending on projects.

That said, tracking time comes in very handy for us in two ways. First up: new hires that are new to ROWE and not used to having the freedom and flexibility to work however they want don’t always pick it up right away. Imagine that you’re used to someone telling you what to do every minute of your day and suddenly:

• The office is regularly half-full due to people working crazy hours and/or working remotely (from home, other cities, and other states)
• All meetings are optional and people regularly skip things that feel they don’t need to go to
• Someone leaves work early because they got a beta invite to Star Wars: The Old Republic and want to start playing
• Beer is poured right after lunch on Friday

Sounds like, uh, time to just go sit by the pool and read comic books! That works for a day or few, but when your project falls on it’s face and your customer is unhappy, you probably won’t have a job for long.

Until new developers at Highgroove feel comfortable that they have ROWE figured out, they are encouraged to track their time with Freckle or TicToc or something similar. This isn’t used for firing people or judging performance or billing, but when combined with good metrics like customer satisfaction it’s extremely useful: 20 hours a week and your 100% project’s customer is happy means that you get more responsibilities if you want (and more pay). 60 hours a week and an unhappy customer means that something isn’t working right, and that something (project management, responsibilities, development practices, customer communication and expectations, etc) needs to change.

Once developers get a feel for how to get work done where only results matter, the time tracking can go away which tends to make people happier more and productive.

However, the second useful case for time tracking is that developers track their time because they want to and they find it to be useful for gauging their efforts. For some, knowing that 40 hours of work done makes it easier to skip out early on Friday. For others, it’s a handy way to divide up effort between multiple projects.

A handful of us have started using RescueTime which sits in the background and figures out if your computer usage is productive or not. This is a fantastic tool because it requires no effort or data entry and gives you similar metrics about time spent on projects. I was able to see that those two weeks that I spent playing what seemed like far too many hours of Kingdom Rush may have affected other things, but didn’t prevent me from spending the usual amount of time on work and getting all of my work done.

Do you track your time even if the numbers are only for you? Is the mere thought of time tracking enough to send you running in the opposite direction?

The post Tracking Time the ROWE way appeared first on Big Nerd Ranch.