The core business of Terrible Labs is to help our clients design and develop great products that solve real problems. In order remain a top consulting shop, our job is to know the best practices and the right technology to leverage when it comes to design and development.

Since starting Terrible Labs nearly three years ago, we’ve struggled to come up with the right strategy to balance the learning required to remain a top design and development shop and billable client work to keep the lights on.

We recently updated (technically “re-keyed”) some of our clients’ SSL certificates in response to the Heartbleed Bug announced last week. The process isn’t all that complicated, but it demands referring to the docs of the web host and the certificate provider in order to get all of the steps right. Getting this process wrong can result in an ugly untrusted certificate message on the site.

Oftentimes we work with a client who has already established an account for DNS, and it’s simpler for the client to stick with that provider when purchasing an SSL certificate. Oftentimes this provider is GoDaddy. Say what you will about GoDaddy, they are a very relevant player in this space and it’s important to know how to work within their system, even as we may steer clients to preferred providers such as DNSimple or NameCheap.

And as is common with our Rails apps, we’re hosting on Heroku.

We found ourselves jumping back and forth between Heroku’s SSL endpoint docs and GoDaddy’s SSL certificate docs. The following is a roadmap between the two sets of docs, with some extra screenshots and clarification on a step that isn’t explicitly covered in either.

As part of our goal to create a culture of learning, we’ve started sharing useful things we’ve uncovered during our daily stand-up meeting.

But why stop there? Each week we’ll share a tidy little compilation of our best discoveries with the community, starting today.

There’s a brief moment during the first round of user testing that I absolutely love.

The very first subject is scanning the screen and thinking out loud, understanding, dissecting, validating or rejecting. I sneak a peek at my client, and catch a tiny smile, eyes wide and eyebrows raised.

The experience we’re witnessing is invaluable, and he knows it.

This is the moment where he realizes that iterating on a product in the design phase is not merely uncovering a few blemishes, but qualitatively improving his product. Had he attempted this during development, the cost in both time and dollars would have been orders of magnitude greater.

How do we do it? After an intense week of discovery and rapid collaborative design, we create a fairly high-fidelity prototype and we use it to test our riskiest assumptions. Armed with the results, we’ll improve and re-test, refine and re-test, and in a matter of weeks we’ll be ready for technical development with a high level of confidence in our design.

There’s no terrifying unveiling of a mockup I’ve been designing in a cave for weeks, headphones on, making my best guess at what will work and praying it will be accepted by the client. No dog and pony show. No crowd-goes-ahh (or crowd chases me out with pitchforks). In fact, the whole process is relatively (and refreshingly) surprise-free.

Designing and refining a prototype collaboratively is an incredibly powerful process. We have buy-in throughout the process from key decision makers, the development team, and even potential customers. We often significantly improve upon the original concept. And most importantly, our clients avoid the potential for a costly investment in a product that no one will use.

And that’s exactly what that tiny smile is all about.

Terrible Labs is excited to announce that we are growing our design team and looking to hire! If you’re a UX/UI designer with experience in all stages of the user-centered design process, we’d love to talk to you.

We’re looking for someone who has experience hosting stakeholder and end-user interviews, moderating requirements workshops, developing user personas, and creating flow diagrams, wireframes, prototypes, and high-fidelity, production-ready deliverables.

For all of you who care about design, have a proven track record of turning ideas into products that ship, and want to help shape the future of design at Terrible Labs, shoot us a note to: jobs@terriblelabs.com.

We are not interested in engaging with a recruiter, so don’t waste your time or ours!

What you’ll do:

• Lead and manage projects through all stages of design.
• Plan and conduct requirements gathering and analysis, competitive research, conceptual modeling and usability testing.
• Run focused, collaborative design sprints with cross-functional teams to help explore, select, and deliver best solutions.
• Produce requirements specifications, personas, user flow diagrams, wireframes, prototypes, and high-fidelity, production-ready mockups and design specifications.
• Articulate research findings, conceptual ideas, and detailed design rationale to clients and internal team members.
• Estimate project timelines and help define scope and product roadmaps.
• Pitch project proposals to potential clients.
• Work with an interdisciplinary team of talented developers and designers.
• Influence and help shape the future of design at Terrible Labs.
• Meet lots of interesting people and learn about many different problem domains!

What you’ll need:

• A portfolio of representative work in user experience, interaction, and visual design.
• At least 5 years of experience designing user interfaces.
• At least 1 year of experience in client services.
• Experience designing web and mobile applications.
• Solid understanding of responsive design principles.
• Ability to understand customer needs, motivations and behaviors and translate them to actionable deliverables.
• Strong self-management skills as well as ability to work as a contributing member of a multi-disciplinary team.
• A passion for creating a great user experience with pixel-perfect attention to detail.
• Mastery of a wide range of design tools (Photoshop, Illustrator, Sketch, etc.).
• Strong understanding of the best-practices and constraints of designing for different platforms.
• Familiarity with HTML, CSS, and client-side scripting a plus.
• If in addition to the above, you have experience in branding and identity, consider yourself an illustrator or have experience with animation, that’d be terribly awesome.

About Us:

Terrible Labs is a small team of senior level developers and designers who are passionate about creating great products. We’ve been working with established companies and startups over the past few years to help them design and build applications that solve problems.

You must have a strong appreciation of design thinking, and understand how it integrates into the process of creating digital products.

This is a position for an experienced designer, who is comfortable working independently, and has a strong sense of ownership of his or her work, but values a collaborative environment.

We look forward to hearing from you!

A recent Forbes article paints a grim picture of employee happiness. Even though the US is doing better than much of the world, only 30% of people are happy with their work. Given that a happy programmer is a productive programmer, you’d hope that managers in the software world would be doing whatever they could to keep their fingers on the pulse of employee happiness. Talking with my peers continues to prove that this isn’t the case. Most of their managers have no idea how unhappy their employees are.

At Terrible Labs, we’re invested in the happiness of our coworkers. Jeremy and I recently spent an afternoon building a simple Rails app to help us gauge the mood of the company.

This iPad lives in the kitchen. The background cycles through popular nature photos from Flickr and prominently asks “Are you happy?” You simply tap “Yes” or “No” and your answer is recorded anonymously. You’re rewarded and inspired with a random Star Trek or Simpsons quote after answering. If you’d like to be even more anonymous, just load up the web app in your local browser and answer without a crowd.

According to the first few weeks of usage, we’re happy 81.7% of the time. That’s promising, but we’re going to look at the data over time to get a sense of mood. Are we improving? Are things getting worse? Are people happier on different days of the week, times of day, or times of year?

This data doesn’t answer the question of what we should do differently – that’s where the hard work starts. It also isn’t a substitute for regularly meeting with employees and asking them how things are going. The metrics here are only another data point to be considered with the whole.

30% of Americans may claim to be happy with their job, but some portion of that percent is probably just happy to have a job in this recovering economy. In the world of software, your employees are spammed by recruiters several times a day and could trip over three more jobs on the way home from work. We have to try harder. Good developers already have the bottom sections of Maslow’s Hierarchy of Needs under control and are looking for esteem, achievement, and self-actualization. If you can’t keep them engaged and help them achieve those things, they’ll look elsewhere (see also: Bored people quit).

Are your employees happy? Do you have any idea? Find out.

The code to our (very simple) app is here on GitHub. The README has all you need to get it running on Heroku and collecting data.

TicketZen is a product we’ve been incubating at Terrible Labs over the last few months. This week we were fortunate to share a sneak peek of the mobile app at WebInno39 and walked away with the Audience Choice Award!

If you missed the presentation, check out the video below (Thanks to Jeff Swank for the Oscar-worthy cinematography).

A big thank you to all that came out and voted for us!

For the last two years we have hosted the Terrible Scramble at Woods Hole Golf Club. This year we couldn’t have been more excited to help raise money for TUGG (Technology Underwriting Greater Good) and more specifically the Science Club for Girls.

We couldn’t have had such a successful event without the help of our sponsors:

We had a beautiful fall day with over 60 folks from the Boston startup community out playing golf for a good cause. You can check out some of the photos from the event below.

A big thank you to all of the companies who participated this year!

That picture is from a little over a year ago. I had just received a new hat and was vaguely buzzed from a job interview at Terrible Labs. Honestly I wasn’t expecting such a warm reception – I only got the interview after attending a meetup hosted in a bar in downtown Boston. I was unaware of the chain of events and truly interesting people that I would meet because of it. It all started with this picture, sitting at State Street Station, head full of Ruby code and a little IPA, unaware that I didn’t get the Job I just interviewed for.

Not yet, at least.

A little context: I moved from Connecticut to Boston in February 2011, just after another record snowstorm. I decided that I wanted to program after attempting to be an ad executive, a Wordpress maintainer, and – lord help me – a ‘social media expert’. I had some history with the CS field, but nothing stuck. I picked up a painfully small amount of Java, some Python, some Javascript. It was on a hot August day that a friend of mine passed me a link and I got my first taste of the Ruby community writ large. I fell in love with the language on August 19th, 2011, otherwise known as _Why Day.

I distinctly recall wanting to be a part of any community that could produce someone like _Why. Ruby was a great programming language, the one that made the most sense to me at the outset – but it was the style of _Why that made me want to join the party. I started attending as many meetups as I could find, trying to absorb as much as I could. My github is littered with a number of aborted projects, sites born to familiarize me with a new concept and then left in the dust. I felt like most intermediate beginners do: like a living god (Note: That goes away, but not as much as you might think.)

I attended meetings and project nights, listened to lightning talks, subscribed to Railscasts. I began getting familiar with the different faces and companies in the area, meeting so many people who were just as eager to learn and teach. I felt very welcomed, and it helped me learn. Still, I was hungry for more, and I felt like I was just about ready to be hired by a company, if only I could find one that would have me.

Though I was nervous about going to the Drinkup, I wasn’t nervous about emailing the man with the beard who was in charge of that interesting company with the T-Rex logo. I forwarded him my Github account, and I was absolutely shocked when I heard back from him. I was on top of the world, well on my way to becoming the newest hotshot developer. I walked into the Terrible Labs office, meeting Jeremy (previously mentioned bearded fella) and the rest of the Terrible team. They offered me a beer, and I began to pair with some Terrible folks on a gem I had made – a dice simulator for RPG tabletop games.

Looking back, the gem was not pretty. So much documentation, so little code. My description was much less of a joke then: my gem really was just a wrapper for the ‘Rand’ function, one that you could call with a series of shake-and-bake constants. Despite all of this, Jeffrey Chupp sat down with me and paired on this silly gem for the better part of two hours. Jeffrey took two hours out of his day to help me roll fake dice.

Most tellingly, he’d continue to do it for the next seven months.

Within a week or so, I heard back that I was too new to get the job. Jeremy sent me an email that didn’t read as stock, describing the various reasons why they couldn’t hire me at present. Admittedly I was too green, way too fresh to be job hunting. But Terrible surprised me again: Jeffrey was interested in working with me further, helping me work through my problems and giving me a desk whenever I needed it. I had a mentor, and – as I would learn – a damn helpful one at that. I learned to appreciate how one-on-one help with code, combined with a helpful community, can really lift a new programmer. For seven months, I came in as often as I could. I’d code like crazy whenever there was downtime from my various jobs, and then come in and present my conundrums to Jeffrey. The entire Terrible Labs team would pitch in and teach me new tools, neat tricks, and things that I would not have learned without such a context.

Jeffrey is a fantastic mentor, more willing to course-correct than simply provide an easy answer. For my learning style, this is paramount – I’d much rather know what to Google than know what to type. As it turns out, knowing the former tends to reinforce knowledge of the latter.

One day I was working on a side project of mine and came to Terrible Labs for some more debugging. I sat at the empty desk, as I always had, when Jeffrey – who is as bad at lying as he is good a mentoring – began to ask me questions about my “current employment situation.” Within a week, I was his co-worker, and I met the rest of the Terrible team who have each taught me loads more than I would have alone. I am deeply grateful for their help, even if I occasionally repay them with mistyped commit messages and awkward Cosby-related humor. Y’see.

Last week, I attended a local project night and went toe-to-toe with local up-and-coming Ruby dev Alex Wheeler on the merits of Bootstrap (formerly of Twitter) and Zurb Foundation. It was a blast. Alex has come into the office sometimes with various programs he is working on, and it’s been a great experience sitting down and dedicating a few hours of time to helping him out.

Developers: you should know how important the donation of time can feel to someone just starting out. Programming is daunting, and it helps to have someone more skilled give you the time of day. Simple answers, nudges in the right direction, an invitation to email – being able to rely on these things can really help unstuck a problem and keep the learning momentum up. If you don’t already, please volunteer yourself, even if only for a few hours a week. That one simple gesture can mean the difference between a hopeful newbie and a salaried employee.

New folks: embrace the community. People can’t wait to help get you here. Take advantage of local meet-ups (I always enjoy the Boston Ruby Project Nights, myself). There are organizations like RailsBridge, BostonRb, and LaunchAcademy that are geared at ramping up new developers. Join mailing lists. Work on projects that teach you something new.

If nothing else, feel free to email me at alxjrvs (at) gmail (dot) com. I’ll do what I can to help. If I can’t offer some advice, I can definitely forward you to a local group or friend that will.

Until then, Keep Building.

On Monday evening we hosted a discussion with Silicon Valley Bank on the always-changing payments space. Dan Allred and Smith Anderson from SVB did an incredible job of pulling together an all-star panel which included:

• BC Krishna, Founder, CEO, Mineral Tree
• Bruce Wallace, COO, Silicon Valley Bank
• Garen Staglin, Investor, Winemaker, NvoicePay(BOD), Silicon Valley Bank(BOD), Staglin Family Vineyards(BOD)
• Jay Singer, Head of US Commerical Products, MasterCard
• Bryan Derman, Partner, Glenbrook Partners

As a development shop that builds payment technologies as well as applications integrating technology produced by the payments industry, we are always looking to learn more about the state of the payments industry.

From Monday’s discussion, it’s clear that the payments space, especially B2B payments, is ripe for disruption but startups face some very big obstacles. The biggest obstacle being the behavioral evolution of the accounts payable and accounts receivable departments at corporations. There has yet to be a technology that’s 10x better than the current billing/invoice and remittance processes. Until a common standard is adopted by all industries (or even within specific verticals) the ability for mass innovation in the B2B payments space will be slow.

If you’re interested in coming out to a future Terrible Labs event, reach out to us at info@terriblelabs.com.