Who Is ShakaCode?

Blog
1

Shaka Sign

This gesture is more than just a mere wave or thumbs up. The shaka is a symbol of the “Aloha spirit,” which is the coordination of the mind and spirit to think and exude good feelings to others. (by Megan Denny, www.padi.com)

by Justin Gordon with help from the ShakaCode Team, September, 2015

Who is ShakaCode?

It’s the global web development software consultancy and product company started by Justin Gordon, AKA “railsonmaui” in the Ruby on Rails world. We’re focused on what we believe to be the best technologies for web development. Today, those are Ruby on Rails and React. But it’s not just us, we like to think that it’s the larger WE in the open source community that loves collaborating on beautiful code.

Why Change the Name from “Rails on Maui?”

We’re polyglots and we’re not just based in Maui. When Justin Gordon started out, he was focused on just Ruby on Rails, and “Rails On Maui” was the name he used for his Twitter handle and blog.

Why “ShakaCode”?

The “shaka” is really the embodiment of the philosophy, culture, and team behind ShakaCode as well as our community of open source collaborators. In order to fully explain this, we’ll need to tell you a bit about the meaning of the “shaka symbol” as well as a lot more about us. Let’s first summarize the key points:

We love open source collaboration (the friendliness of the Shaka meaning) and we love to code. These go hand in hand. We love code so much that we want to share it! And we only want team members that love it as much as us. With a team that loves to code, we don’t need to be handcuffed to an office. We need a good computer and a decent Internet connection anywhere in the world. The company was born in Hawaii, and all early company employees love surfing and tropical beach culture. Sunshine and surf perfectly balances intensely passionate coding!

Read more if you’d like the details. Or go surfing! Or skiing, mountain biking, etc.

The ShakaCode Philosophy

Here’s a bit more about us:

  1. We’re passionate about what we do and we all love to write and read code. Because we’re 100% remote, we can only hire team members that love code. Jeff Atwood put this well in his article On Working Remotely. “But the minimum bar to work remotely is “to find someone who loves code as much as you do”. It’s … enough.”

  2. We love open source and helping others. There’s probably no movement that’s changed software in the past 10 years like open source. Open source is not just about creating some well known project, like Linux or Ruby on Rails. It’s about doing what you can in a system of freely sharing ideas and helping others. This might be writing blog articles, participating on Stack Overflow,or working on open source projects. We believe this open source philosophy complements the definition from Wikipedia of the shaka symbol: “Aloha Spirit”, a concept of friendship, understanding, compassion”

  3. We almost all surf, and we all love to get outdoors and do fun, athletic things. In fact, Dylan met Justin from surfing in Maui, and Justin contacted Alex when he saw that his Facebook profile page featured a picture of him in Bali. Samnang does huge mountain bike rides around Cambodia. We want to structure our lives to pursue our passions, which is coding and doing fun sports like surfing. This is akin to how 37signals Works Remotely.

  4. Part of loving code is viewing it as an art. It’s like creative writing. When you first see really beautiful code, what is it that you see that is special? It’s a bit like looking at a random page of an Ernest Hemingway novel and seeing clear, short sentences. Great software is written such that it’s simple and clear. It’s easy to read.

“Beautiful code is similar to beautiful prose: Succinct, it has flow and rhythm, and it’s an expression of clear thinking that doesn’t jump around different layers of abstraction all the time.” from the article David Heinemeier Hansson: Geek of the Week.

DHH’s RailsConf 2014 keynote on “Writing Software” nicely summarizes this philosophy.

Thus, Shaka + Code embodies who we are!

Is ShakaCode a Service or Product Company?

We’re both, and we’re open source contributors! Our company role model is 37Signals. They started off as a web development shop. Out of their work, they developed the program “Base Camp” to address their own needs for more organized and effective client interaction. From that work, they extracted Ruby on Rails, undoubtedly one of the most successful application frameworks ever created.

Why is it important for us to have an internal project?

Our ultimate mission is to maximize our creative contributions. This includes:

  1. Helping our clients achieve their goals through well-written software.
  2. Building a useful product.
  3. Contributing to open source, including source code and articles.

Goal #2, building a product, is a critical component for several reasons:

  1. We can experiment with the latest technologies, such as React, projects of rackt, including redux and react-router. Our clients often don’t want experimentation with the latest technologies. An internal project allows us to gain the expertise needed in order to conservatively apply such new technologies for our clients.

  2. We can work on the latest, often beta version of software. It’s almost impossible to contribute meaningfully to open source when you’re working on ancient versions of open source. Almost all the action and collaboration is happening on the leading edge, as it should be.

  3. We have a training ground for introducing team members into the ShakaCode style of development. We can interview prospective team members by pairing with them on open source. We can hire junior level engineers who are not ready to be placed in front of clients, and groom them into senior engineers.

  4. Our internal project epitomizes how want our client code to look. It’s sparkly, shiny, and fresh. It’s how we believe code should be written and how projects should be organized. It’s a living example of what we intend to do for our clients. There’s no better “training” or “documentation” than a living example of a real software project.

  5. It’s fun to have our own project! Coding is our passion!

  6. We intend to give back TONS to the open source community. And that requires “Extraction” rather than “Design” by itself. Ruby on Rails was an extraction of the 37Signals App, Basecamp, and Twitter Bootstrap was an extract of the UI framework used by Twitter. This article Extraction vs. Design nicely sums this up:

David Heinemeier Hansson (the driving force behind Ruby on Rails) is a huge believer in using extractions as a method to add functionality to your projects, typically in the context of a framework. You need some particular functionality, you write it, and if it’s good enough you extract it from it’s original context and make it generic enough that it can be used by other people. You could also call this “building stuff you need” instead of “building stuff you think you might need”. It’s part of the whole YAGNI philosophy of programming, I guess.

Our Internal Project: Friends and Guests

This application solves the problem of “I’ve got a vacation home that I want to share with my friends, but not with the general public. What’s the best way to do that?” It’s based on our experiences sharing Sugar Ranch Maui with our friends and with long-term tenants. One such long-term tenant was Beau Hartshorne, a YC and Facebook alum, who also expressed a need to share his places with his friends, and not the general public. It turns out that many of our friends on Maui have a similar need, as Hawaiians typically have space for family and friends to visit. Thus, “Friends and Guests” is designed to scratch the itch of our friends. It’s not about “what we can build to make the most money”. It’s about, “what we can build to enrich the lives of our friends”.

We believe that the part of the enjoyment of a vacation home is to share it with your friends. To that ends, we’ll be part of the means with the “Friends and Guests” application.

Anti Discrimination Policy

Part of ShakaCode is that we don’t discriminate on:

  1. Geography and Time Zone
  2. All the normal stuff, like gender, race, age, tattoos, piercings, sexual preference, etc.
  3. Degrees and credentials. Justin has degrees from Harvard, UC Berkeley, as well as a CFA credential. However, based on his experience working with great software engineers, education is only one of many signals. In fact, education is less important than passion and great taste.
  4. Working remotely (that’s what we do!).

We do discriminate against:

  1. People that discriminate on the above.
  2. People that view writing software as a job, and not as an enjoyable creative endeavor. Passion is critical.

Influences

Here’s some of our favorite influences:

37 Signals

Definitely listen to this interview of David Heinemeier Hanson on The Changelog for some great thoughts on the influence of David and Ruby on Rails on the ShakaCode philosophy. Plus, see this article: David Heinemeier Hansson: Geek of the Week

Coding Horror

Justin still remembers reading Jeff Atwood’s book where he describe how creating a programming blog was the best thing he ever did, and how it led to Stack Overflow and now discourse.org.

Aloha

As Jeff Atwood said on “On The Meaning of “Coding Horror” (why he blogs):

But that’s not the complete story. I’d be lying if I didn’t admit that there’s an element of selfishness at work here. I love computers and programming. I love it so much it borders on obsession. When I saw the movie Into The Wild, I was transfixed by the final note written into the margins of Dr. Zhivago by a doomed Christopher McCandless: “Happiness only real when shared.”

Justin Surfing

This is a companion discussion topic for the original entry at http://www.shakacode.com/2015/09/17/who-is-shaka-code.html
2 Likes
2

Remote-First vs. Remote-Friendly

Zach Holman definitely understands “Remote-First vs. Remote-Friendly”. I bet he’d relate to the "ShakaCode philosophy!

He starts the article:

Yeah! We’re remote friendly! We got Bob who lives in San Diego, we’re based in San Francisco, and we have a Slack room, and people usually can come in to work at ANY time (between 8am and 9am), but really fuck Bob he’s kind of a loner and we’re going to probably let him go soon anyway, but yeah you can totes work remote!

I’ve been there! The one remote person, or even the “one of a few remote people”. It’s not good. It never lasts. It’s probably a good thing for companies to decide if they are or are not “Remote-First”. Certainly companies like FaceBook, Google, and LinkedIn are non-remote. Other companies like Basecamp.com (formerly 37 Signals) and Automattic are “remote-first”.

And this hits the nail on the head, when Zach writes:

##Geographical makeup of teams

The number one indicator of well-functioning remote teams inside of a company is a reinforcement of remote employees in the structure of the team itself.

In simpler words:

Teams with one or two remote employees on them are fucked, and teams with a larger proportion tend to do better.

I’ve seen this play out again and again across many different spectrums of companies. It seems to be such a clear indicator that if you’re the only remote employee on a team, I’d recommend you might be proactive and try moving to a different team entirely (unless the team itself is particularly adept at working in a remote-first environment).

I think the rationale behind this perspective makes sense, and I don’t think it’s inherently mean-spirited, either: if seven people are in the same room in San Francisco and someone else is in Singapore, the seven locals are naturally going to have more informal and formal conversations about the product, unless they go out of their way to move their conversation online. It’s doable, but it takes a dedicated team to do that.

If you’re going to have a go at fostering a strong remote culture in your company, try structuring a diverse representation of geographies on a team. If you don’t have enough of one or the other, aim for either all-remote or all-local teams… it’s better than having the odd person stuck as the de facto outcast.

3

Wow, here’s another article from Zach Holman “How GitHub Works: Hours are Bullshit” that perfectly fits the ShakaCode philosophy!

Many years ago, I worked at a large company and we had standard hours, but we also were supposed to be available to a remote team in India at odd hours. We’re a global team at ShakaCode, so the best time to work is any time the creativity is flowing!

Hours are bullshit

Hours are great ways to determine productivity in many industries, but not ours. Working in a startup is a much different experience than working in a factory. You can’t throw more time at a problem and expect it to get solved. Code is a creative endeavor. You need to be in the right mindset to create high-quality code.

Think back to the last time you were depressed or angry. How productive were you? Now think back to the last time you were truly productive. Code flying from your fingertips. Not just the sheer quantity- the sheer quality of that code. When you’re in the right mindset, your best day of coding can trump weeks of frustrated keyboard-tapping.

We want employees to be in the zone as often as possible. Mandating specific times they need to be in the office hurts the chances of that. Forcing me in the office at 9am will never, ever get me in the zone, but half of GitHub may very well work best in the morning.

By allowing for a more flexible work schedule, you create an atmosphere where employees can be excited about their work. Ultimately it should lead to more hours of work, with those hours being even more productive. Working weekends blur into working nights into working weekdays, since none of the work feels like work.

4

This new article from DHH really nails it. ShakaCode is 100% aligned with this philosophy.

https://medium.com/@dhh/reconsider-41adf356857f

RECONSIDER

Some of my favorite quotes:

I’m going to pull out another trite saying here: It feels like honest work. Simple, honest work. I make a good product, you pay me good money for it. We don’t even need big words like monetization strategy to describe that transaction because it is so plain and simple even my three year-old son can understand it.

another

These motives, for me, meant rejecting the definition of success proposed by the San Franciscan economic model of Get Big or GTFO. For us, at Basecamp, it meant starting up Basecamp as a side business. Patiently waiting over a year until it could pay our modest salaries before going full time on the venture. It meant slowing growing an audience, rather than attempting to buy it, in order to have someone to sell to.

1 Like
5

Wow! Another great article that ties into the ShakaCode philosophy:

I don’t want to be a winner by DHH

Is there anything our society exalts more than The Winner? That fiery someone who crushes all competition to stand alone and victorious at the end. A genetic predisposition, I’m sure.

The paradigm of competition is so ingrained as the basic business narrative that we usually don’t even recognize it, much less question it. Well, of course there are winners and losers! What are you, a fucking communist?!

David, this starts off in grade school where teachers grade on a bell curve. You have to “win” on your college entrance exams to get into the right university. Then you have to compete against your classmates for grades and jobs. I was even told that if besides excelling in academics, I had to be a pro level tennis player, “in order to get into the right college”.

Then the college grad goes into corporate America and learn the meaning of Stack Ranking. I’ve been there when the manager of can only give out a single “1” performance ranking, and has to give out a few “3’s”, where “1” means amazing, and “3” means you’re given a “performance plan”, which means “we’re firing you and we don’t want you to sue us.”

Actually, no. I’m a capitalist who doesn’t like direct competition. Is that an oxymoron? It shouldn’t be. In fact, it’s the profitable, justified motivation I smiled to see affirmed by Blue Ocean Strategy, the business book that explains this non-combative style with case studies like Cirque du Soleil.

I think that’s why I never really liked individual sports or games either. I remember how hard my heart would race playing 1-1 Quake, and how infinitely more shitty it felt losing than winning, and that even the latter wasn’t all that interesting!

Competition is the direct cultivation of stress and paranoia. Tapping fight-or-flight for game and gold. No thank you. Not for me, no siree!

I cannot think of any better example of such a “grow the pie” rather than “slice the pie” philosophy than the collaborative nature of open source, as epitomized by the Ruby and Rails communities. It’s probably not surprising that a former employer of mine that “stack-ranked” would also require multiple levels of management approval to commit any open source project.

The only competition I’ve come to love is the one against myself, and that’s not really a competition, now is it? The progress of betterment. Playing your part to the best of your abilities in a beautiful whole.

That’s the joy I take away from racing cars for endurance. It’s not so much being faster than the other cars, but striving to perfect your own contribution as part of a team. Pushing against the limits of perfect execution over the long term. 24 hours of testing your capability to avoid mistake and fatigue. Winning is almost incidental to that.

The joy of surfing is akin to car racing this respect. Every day one goes surfing, the primary battle is to become connected to the energy of the ocean. It challenges you both at the physical level, as you need strength and agility to ride waves. It also challenges your judgement. Can you predict where the next wave will break? Are you the surfer best positioned for the next wave? What I love the most about surfing is the feeling that the learning process never ends. I also feel this way about writing code, especially open source where I’m getting my code reviewed by the best in the world.

The same goes for making Basecamp the best software and the best company it can be. It’s not about taking out or choking existing or upcoming competition. It’s not about dominating a space to the exclusion of all others. I’m not sipping sour grapes or feeling bad when a competitor hits its stride. In fact, it’s so much more interesting when Basecamp is just one of many, different choices for people to make progress together.

The world is better off when its not being held in the palm of a few dominating winners.

David, we couldn’t agree with you more!

We, at ShakaCode strive to make this philosophy of non-competition reflected in the our open source, client projects, and eventual software products!

6

Another great article that resonates with ShakaCode:

How to Build a High VelocityDevelopment Team, by Eric Elliott, medium.com

I think the team at ShakaCode could agree with me when this article is basically preaching to the choir for our organization!

The most relevant topics for ShakaCode are:

  • Open sourcing what we can
  • Valuing people first
  • Remote work

Thanks, Eric, for the great article!

7

Great article, thanks, and thanks for your Open Source contributions.

I hope to transition to this sort of a more international work/travel lifestyle in a few years when my son leaves for college. It’s good to know that this is increasingly possible in the tech world :smile:

– Chad