jejacks0n

I'm a developer at Modeset, we have some open source, and try to contribute back whenever possible and time permits. If you specifically mean code for the ello.co product, there will likely be things that come out of it over time -- it's a pretty hard business model to open source stuff that you haven't completed yet.

https://github.com/modeset/teaspoon for instance.

As a programmer and perfectionist with Impostor Syndrome (http://en.wikipedia.org/wiki/Impostor_syndrome), I've learned some ways to mitigate these frustrations and stress causing issues, and figured they might be worth sharing.

I think many of us know your pain, and as a consultant I'm exposed to it on a pretty regular basis. It takes some of the fun out of my job for sure, but I don't let it stress me out. First, we should always want to be passionate about the projects we work on, and I think this is a result of being passionate in general. Being passionate makes it enjoyable, and it allows you to bring your best work forward (which is rewarding), but in our industry we must always create a balance of cost and quality in the midst of a very complex process. To me, this all boils down to priorities and expectations.

When you take your own priorities and combine them with those of someone else, you will never be able to get them to mesh completely. Your priorities may be to make quality code, or to make it elegant or smart -- easily maintainable, extensible, etc. etc. These are things that make it fun, and programmers all know the benefits of these things. Clients, or your bosses, may not understand the importance of these things, or they may, and they may be willing to pay it down later, whatever the case may be, there are conflicting priorities at play and this is the thing you must mitigate to avoid stress.

For me, I must either disregard the external priorities entirely and do it the way I believe it "should be done", or I must disregard my priorities entirely and adopt the external priorities as my own. This may result in technical debt, or a slow progression in the future, or can raise the potential of bugs to be introduced, but these are not my concerns if they are not part of the external priorities.

It's important that you communicate all of my concerns up front, and if it doesn't impact the priorities that are communicated, you must trust that it's ok. If you don't trust that it will be ok, or think you will be negatively impacted by doing it the way you're being asked to do it, you should leave. A management(or client)/ employee relationship is built on trust, and if you don't have that trust you will be less happy than you could be.

I work on Teaspoon (a javascript test runner for rails) that has support for Jasmine and Mocha -- I don't use it every day, but the team does use it on a daily basis. The thing is that people have submitted a bunch of pull requests for features that I don't personally use (QUnit, Angular, etc.) and that has made it harder to maintain those features.

I struggle with saying no, because I want the library to be useful, but I also don't want to have to maintain and potentially break features that I don't personally use.

I don't like the model of paying for a digital object that doesn't do anything besides bypass a bit of code that makes the experience more laborious or time delayed.

I personally download these games and play the shit out of them, but never ever give them money. It becomes a different aspect of the game -- sure, I have plenty of money to give you, but I don't think I should give it for something to speed up the experience -- I mean, you designed the experience, so it becomes a personal challenge until the game becomes boring -- oh, and I never mention it to anyone else, as to remove the word of mouth part.

I happily pay for good games that don't use this mechanic and tell my friends about how rad they are. It's how I speak with my wallet.

Why not build this as a middleware layer? You can mount a sinatra app within Rails (/services for instance), and then write your API in a predefined path structure that the gem will look into (within the rails app path maybe?)

You can pretty easily share models and whatnot -- and then you have a nice clean place to define/override your DSL. I would have to do some playing to make sure this is valid, but that might be an approach to think about.

I'd suggest https://github.com/jejacks0n/mercury if you're using Rails.

Full disclosure, I'm the primary author.