How many times have we been passed over, the quality of our work ignored, and our passion and our creativity stifled?

Nothing in our lives is perfect, but on Project Hierarchy, we will always try to create an environment that rewards truly good work, creativity, and taking well, thought-out risks. The size of our team is small right now, but we want to lay the foundations of how we will work now and in the future.

Here are our guidelines for working on the project

Meritocracy - Our goal is to judge you based on how good your work is, and how good a team member you are. Seniority is not based on years of service, but on your abilities as a developer and qualities as a person.

The No A**hole Rule - This is one of our favorite workplace principles. Basically, the idea is that at work, don't be a bully, don't abuse your power, don't be a jerk:

Non-Political Environment - Every work environment has some type of politics with groups of people forming factions and tribes. We will try our best never to allow our personal allegiances to determine what decisions we make, and even more than this, we will try not to let them influence what ideas we support or don't support. Everyone gets a chance to speak, and no one will shut somebody down just because they aren't in your own personal circle.

Competition is Good / Competition is Bad - Having ambitious goals and a risk taking spirit is good, and a little competition between team members is always healthy. But... if competitive drive is causing you to break rules 2 and 3, then we have a problem. Many of you might agree, but over-competitiveness is often the root of many problems on a team. Let's keep it under control.

"Not My idea" - Going along with the competition theme, smart people have lots of good ideas and often we have a perfectly naturally tendency to favor our own ("Not My Idea"). Hey, we're smart people, it comes with the territory. But, almost all ideas have some merit. So no trying to block other people's ideas just because they weren't your own. Be open to everyone's input and once an decision has been made, we all need to be 100% on board.

And, to put this another way: Let the best ideas win.

Question Everything - We want to create an open environment, but we don't want people to shut their brains off. All ideas and decisions should be examined back and forth, from many different angles. If no one is questioning a decision, then something is very wrong.

Explore All Options - This is how Hierarchy was actually created. For any feature, design, or business decision, we will always explore several different possible options, as many we can think of.

Take Well, Thought-Out Risks - Doing something truly useful or interesting is very tough. Let's push things as far as we can - take risks - but at the same time, think them out. There are bad risks and good risks, and we'll always take a good risk.

You're Allowed to Make Mistakes - We know that when we shoot high, we have to expect mistakes to be made. In a sense, mistakes are good, it often means we're being ambitious.

Plan for Mistakes - The bigger risk we take, the more we should plan for a lot more things to go wrong.

Learn from your Mistakes - Making mistakes is fine, but making the same mistake over and over again is not. Learn from your mistakes.

Good Software is Not Just Good Code - Creating a good product is not just about developing good applications, but it's also the dozen other things around the code: good, easy-to-read documentation, helpful support-people, a useful web-site, great support-tools ... Plan for making these as well.

Let's Try to Push Programming Forward - As a project, this is our real goal. We know it is not easy to do on many levels, but life is short, let's aim high.

... And, one last note to us, let's all try to stay humble. Programming is tough and so very empowering. In our experience, big egos often lead to bad products. A good amount of fear of whether what you've created is good enough is healthy.

Our Design Philosophy

Design is Important! - Agile development was a very useful advancement in software engineering, and we use many of its principles on Project Hierarchy, but too often these days, Agile development becomes an excuse not to do well thought-out design. I don't know if you've ever had to work on a system where it's "design as you go along," but they often yield systems that are patched together like the Frankenstein monster. Here on Hierarchy, consult with the the leads to come up with a design that fits the current architecture. The main idea here is think before you do!

Requirements is extremely important - Let's not create ad-hoc components that do very specific things and thus are very inflexible: think the plug-ins to CMS's like Drupal and Joomla, and (with no disrepect to RoR in general) the Rails framework. Think through the problem to find simpler, well thought-out tools and features that balance ease-of-use with flexibility and scalability.

Always balance ease-of-use with flexibility and scalability - We know we just mentioned this, but it bares repeating as this is our major design-philosophy on Hierarchy.