To illuminate the rationale a bit more ... A lot of folks have asked for quick "gut checks", "sanity checks", and similar overviews of their codebases in the past, and this seems like a way to:
1) Help folks out in a way that doesn't entail a massive commitment or expense. Much of the time, when people are struggling with a thorny technical problem, an outside perspective and a bit of friendly advice is invaluable in getting it solved.
2) Get a lot of valuable exposure to different approaches in production apps, to learn as much as I teach.
3) A style of work that I can be productive with, even without a reliable internet connection, or offline entirely (a large problem these days).
So, it seemed like a fine idea to try. I'll keep y'all posted on how it goes. And although Code Reads will be entirely confidential, if any of the companies are interested in sharing theirs (perhaps to attract recruits) -- maybe I'll be able to post one or two up publicly.
Can you take a high-profile public project (like coffeescript or underscore/lodash or angularjs) and do a code read? (yes I'm aware that you are the man behind coffeescript and underscorejs but I'm sure you can find something in a code read)
I'll admit, it would amuse me.
It would, I think, be instructive to see rough pricing guidelines. I am assuming that whilst you get a feel for the market these things are in a state of flux, but nice to see ballpark figures when thinking about whether your service could be relevant.
Think of it as a StackOverflow for code review. Reviewing someone's code gives you karma/points/kudos/<whatever>, and dupes are OK because we're trying to encourage everyone to help (score points). Note: I haven't really given this a lot of thought, just an idea.
That said, if anyone is really excited about this sort of thing, and think they'd be good at it -- do drop me a line. I imagine there might be ways to team up.
Still open to explanations of why ninjas have an enhanced coding ability though.
<button ...
onclick="location.href='mailto:jashkenas@gmail.com?Subject=Code%20Read%20%5BSmall%5D'">
Small
</button>
Not a huge deal but I think it's good to show where a link goes on mouseover, especially a mailto: link (some mail clients take a while to start) ... it'd seem you want <a> here.The idea is to perhaps eventually sell these directly on the page, via Stripe, in a more explicit fashion. But for starters at least, I think we'll work together on setting the scope of the "read", and keep things bespoke.
In any case I'd think a small contact form a worthy investment, as I doubt he's charging pennies.
I'd get a lot out of it as I'm building a Javascript static analysis tool - exposure to lots of production code would identify how useful its features would be.
I'm no Jeremy Ashkenas, but:
- I've been writing JS apps since 2009, after I stopped doing AS3 apps with Flex
- Teach Backbone.js, JS and d3 at General Assembly, have given various talks/workshops
- Lead dev on two 10k+ LOC JS apps (for Picklive and Skimlinks) using Backbone.js
- Built 3 game clients for Picklive with JS, on mobile and web
- Built a visual scraper recorder/runner plugin for Chrome for Arachnys
- Contribute to JS open source - shims, Sinon.js, lots of little pull requests
https://github.com/timruffles @timruffles
Looks like a great idea. Maybe you could require projects first convert to Literate CoffeeScript to make your job easier. ;-)
... now you see the hidden motivation for the recent flurry of Docco releases. I want to make these sort of working code/prose documents easier to produce ;)
Keep updating it!
If an Architect came with great refactoring suggestions that would take minutes or even seconds to implement, what's the value in dumping me with a document?
The best Architects would just do it if it was straightforward, review it with me (so I'd see why/if it was better and teach me) then commit.
I'd like to see a similar thing here. Hands-on code reviews with commits. There's little I hate more than documents that never get actioned.
I love the spirit of this service but add in commits to make it dynamite.
That said, we do live in a Git world these days. Maybe a fancier package could include the creation of a branch that implements some of the tweaks/changes/ideas.
You're right on the code bomb problem, but I think a good review involves making a judgement on the entire codebase. Something may be the 'right' thing to do but completely uneconomical due to dependencies.
Understanding the impact of a recommendation leads to a valuable refactor or rewrite call that developers often have to make on a mature ecosystem.
Judging by a post on his blog* I doubt that his was very lucrative for him.
I could see this being a inflection point for him (or someone who runs with this idea) in a few years. Good luck!
* I've worked on JS for x years.
* I've written client-side JS for x companies.
Anyway, you get the idea.
The HN effect only lasts for so long. Once the flash crowd evaporates, prospects need more than such an unvarnished offer before they can act.
Cozy up to your prospects. Release some educational content. Give some examples of how you deliver value with your code reviews.
Going forward, a testimonial strategy definitely wouldn't hurt.
Like very well documented and widely used compiler of some language to JavaScript, perhaps?
He's talking about very general "code reading" on the whole article and then, at the bottom, he lines out which languages he knows - and it suddenly gets disappointing for anyone outside the Ruby/JS world.
He has to be more clear about that in the headline.
Also, would anyone be interested in dramatic reading of potentially horrible/hilariously bad code?
I think either could be fun, but maybe that's just me.