Qualities of my dream job

• Freedom to choose what I work on. I want to be able to work on anything at any time.
• Ownership proportial to my contribution (literally, I want shares).
• No managers. I don't want to manage anyone, nor do I want a manager.
• Consistent paycheck, like a normal job.

Even at the best tech companies, there are no positions that have those qualities. Oh and I forgot one other thing: I want everyone I work with to have a job with the same qualities.

So, is this dream job even possible?

That's what my team is working on building. We're creating the platform to support the first three bullet points above. As for the last one: My dream is that the company we build together can provide that, too.

Want to help? Send me a message on Twitter.

Wait, why Node.js?

Good question! There are a lot of ways to write a web-based software platform. Ruby on Rails seems like the most popular solution for most sites, and I think it is good for most things. It probably would've been a good choice for us, too.

So here are the biggest reason's why I chose Node.js:

• It's just Javascript. I know it well, and chances are you do, too.
• There's no magic. Rails has too much magic (in my opinion).
• It's asynchronous by default, which encourages scalable design.

If you're looking for a more thorough explanation of what's so cool about Node.js in general, see: Why The Hell Would I Use Node.js? A Case-by-Case Introduction

And then there's the fact that I just wanted to learn it for my own reasons, and no one could tell me not to. Freedom of choice is one of the best things about working on your own projects.

Swagger

Node.js has no shortage of frameworks, and I spent weeks evaluating the options, some by reading docs, some by testing. I picked the API framework, Swagger, first. It was almost a no-brainer, as I haven't ever seen a RESTful API framework that is built in a cross-platform, declarative manner. Since a huge part of DevShare is the API itself, I wanted to make it as solid and easy to use as possible, which I've done thanks to swagger-node-express and swagger-ui.

Knex and Bookshelf

Choosing the ORM and database framework was a lot harder. There are a few that I really want to like, but ran into various gotchas with. I wound up choosing Bookshelf (which utilizes Knex) because:

• It's a lot like Backbone.js, which I know and love.
• It supports Sqlite and Postgres.
• Migrations are simple and easy, thanks to Knex.
• Ghost uses it, so it is getting a lot of development right now.

Postgres

This is probably the part that I'm least excited about. Not that there's anything wrong with PG, but I just don't know enough about it yet. Part of me was hoping I could use some NoSQL solution, but I don't yet trust any of them for data integrity as much as an RDBMS. Since Bookshelf supports either MySQL or Postgres for production, that made the DB decision a lot easier. After some research, PG just made sense. Plus, I <3 Heroku and they <3 Postgres, so by the transitive rule, I <3 Postgres.

Heroku

I just feel like time spent administering a web-server is time poorly spent, so I make Heroku do it for me. Other good things about using Heroku:

• Prevents environmental cruft from forming, since the whole project is redeployed from scratch each time, leaving only a few specific environment vars hanging around.
• The server can "scale-up" it's hardware quickly and easily.
• Anyone familiar with Heroku can understand how to deploy the project.

The "front end"

When I'm building a tool for developers, I like to imagine: "What if this hits the front page of HN?" If the tool is web-based, it better damn-well be able to handle that level of traffic. Since DevShare falls into the "web-based" category and I don't want to pay for a bunch of servers, the solution is to go static and cache as much data as possible on the client-side.

Seeing as how most of DevShare's services are going to require some use of GitHub's API anyway, what makes more sense than hosting the front-end for free on GitHub Pages?

The front-end framework itself is still being worked out, but it will likely be built on Backbone.js.

I'm hoping that there will eventually be other "front ends" for the project, but this will likely remain the primary one.

Dev-ops

We're using Flowdock and a Hubot instance (named Ideabot) to automate tasks common to our organization in a visible and fun way. For example, this is how we do on-boarding: ideabot onboard <github_user> <email>

For continuous deployment, we have a Strider instance that re-deploys DevShare whenever there's a push to master that passes all of the Mocha unit tests.

That's all?

Well, that's not everything, but that's all the big stuff. It's been a fun few months designing the infrastructure of Devshare, and I'm proud of what we've accomplished so far.

There's still a lot left to do, though. If you're interested in the things I described in this post, we are looking for more developers-- just send me a message on Twitter.

For some groups, disagreement on equity can even stop work or kill the project entirely-- which is insane given that the intent of start-up equity is to enable contributions, not prevent them.

Trusting people is hard

We've all been burnt in one way or another by trusting the wrong person at the wrong time, so it's understandable that we have a difficult time trusting eachother when working together to build something new that is potentially very valuable.

It's interesting how different this atmosphere of subtle mistrust is from the atmosphere of the open source world, which on the whole manages to crowd-source a vast amount of work for literally nothing.

In the open-source world, trust is essentially quantifiable. It's easy to review anyone's GitHub profile and see what they do well and pull-requests provide a publicly available code review. In the start-up world, the intentions of participants are not peer-reviewed prior to enacting them, and their complete history is not publicly available.

This lack of transparency is holding us back.

So how do we fix it?

I think we need a system that tracks and rewards start-up contributions in a similar way that GitHub tracks and rewards open-source contributions. Going one step further, I think there needs to be a system that enables anyone to contribute to a start-up, in the same way that anyone can contribute to an open-source project. Can you imagine the amount of work that could get done if only we could all just trust eachother?

This is what my team is working on

And we could use some help. If you want to get involved, send me a message on Twitter.

This blog is simply a static site hosted on GitHub pages and powered by Ghost to make administration easy. To make it look good, I skinned it with a theme from ThemeForest.

However, Ghost doesn't generate static content out-of-the-box. So how did I do that? Buster, a static site generator for Ghost. The README isn't too great for Buster, so luckily I found this great tutorial (see the last step below).

How to imitate (and flatter) me

If you're a developer, then you can get started by following these steps:

1. Download the latest Ghost release and extract it.
2. (Optional) Place your Ghost theme in a new folder in content/themes/.
3. Run npm install to install Ghost's dependencies.
4. Edit the url in the production section of /config.js.
5. Start Ghost: npm start --production.
6. Admin your blog at: http://localhost:2368/ghost/ (that's the default url).
7. When your blog is ready, follow this guide to get Buster set up and deploy to GitHub pages: Ghost static site generation with Buster.

If you're not a developer, don't bother with following the above steps. I recommend going with a hosted solution of Ghost.

Keep in mind that although your static site will be versioned on GitHub, you should probably set up version control for your source, too. However, since the source may contain a database with your password in it (Ghost uses sqlite by default), you may wish to keep your source private (tip: gitlab offers free private git repos). I also recommend placing static in .gitignore, since the contents of that folder are what is versioned on GitHub pages.

Alright, that was fun! Let me know if I missed anything.

I've been working with a small team on some new ideas. Although it's still in the early stages, I think we're going to be building something that is really quite great.

In order to build this thing (and hopefully other things, too), we're going to be growing our small team into a not-so-small team.

This blog is an attempt to document the decisions that I make and explain the things I've created so that my team understands them well enough to make them better.