sfamiliar

think about a cocktail party. the host comes in, introduces everybody around. you meet new people, talk about stuff. generally a good host will tell you a little about the other people you haven't met, and say something like 'they'd be a good person to talk to about X', where x is some topic you know you have in common. most dating sites don't do this -- there are no introductions, no incentive to converse. you get to know/be comfortable/uncomfortable with people through interaction. a guided interaction is exactly what most online dating applications are missing.

no, we absolutely should not hold the developer responsible for the higher up questions -- the responsibility should fall on the shoulders of the person who made the decision. did the developer implement what he was asked? did he render solid feedback which was promptly ignored? if so, he bears no responsibility for the quality of the decision, only the quality of the implementation. if he made the decision, of course, that's a different matter. and in any case, the measurement of his 'productivity' is meaningless as a part of this metric.

comparing two programmers is possible. comparing a single programmer against a theoretical ideal is improbable. finding a remotely accurate formula for measuring developer productivity and yielding data that's actionable in the business space is really, really unlikely.

when we're measuring productivity, what are we trying to measure? i mean, really? ultimately its how much value is created, in what span of time. relevant to this example, the questions to be asked are:

1) how much does joe's paintjob increase the value of the home for the HGTV-obsessed house-flipper?

2) how much will the value of jim's watercolor appreciate after he kills himself following a week-long binge of heroin?

put another way: how efficiently is value being created? the important answers lie more often in the decision process, and less often in the implementation schedule.

for example, a web developer working on a brochureware site: the right question may be along the lines of 'how will the work you're doing affect the conversion rate?'. in reality, those decisions aren't up to him -- the might lie in the internet strategy department or some such. they push the order, the developer implements. a real measure of results is closer to 'did the designer make the right decisions to yield results?' rather than 'did the developer get the code done more or less quickly than last time?' in my experience, when someone who is a non-developer is trying to quantify developer 'productivity', what they're really doing is dodging the question of whether or not their decision-making was good or bad, usually when they know it's bad and are looking for something to roll downhill.

more interesting to me, as a developer and sometimes manager, is whether or not a developer can deliver when they say they can? if clay says it'll be done in a week, and then it is, he's been sufficiently productive. 'sufficiently productive' is maybe the best thing we can do. the race analogy is an apt one -- if developer 1 can produce a set of functionality with the same defect level faster than developer 2, we can say that d1 is 'more productive', but it's a difficult thing to quantify absolutely. take the number of hours a developer spends working on a given project point, multiply it by their hourly rate, and you get a development cost for that project point. then consider the value that project will add to the product, over time. if you have 30,000 customers who haven't bought the product yet because it doesn't have Feature X, and adding feature X costs dollars Y, then your value-add is something line Z= customers * product price. your efficiency is something like Z/Y.

clearly you want to minimize cost, and therefore keep your efficiency as high as possible, but the ways to manipulate that, and a lot of points to consider:

a simple example -- if you can hire a developer that will take twice as long, but work at 1/3 of the rate, would the revenue lost during the extended development period negatively affect the profit efficiency?

the important questions are somewhat higher up.

ruby 1.9.1 is mainly stability fixes to ruby 1.9, which had a few .. quirks.

for a less-than-complete guide to ruby 1.9 features, consider reading eigenclass's summary from way back: http://eigenclass.org/hiki.rb?Changes+in+Ruby+1.9

jim cramer has said before that one shouldn't have a position you can't afford to spend an hour/week investigating. however you may feel about his financial wisdom otherwise, this point seems sound. in this case, that'd mean an hour/week for each currency, reading up on that country's economics. you might have that kind of time, i don't know. first world western countries' currencies are very stable, and change slowly over time, their values increasing and decreasing by slow degrees. if the dollar, euro, or pound suddenly went horribly south, the rest of the world would definitely feel it, and their currencies would also likely plummet. so there's no safe harbor abroad for currency.

consider instead gold, silver, platinum, and jewelry. since we're talking about an 'escape scenario', they might be your best option. mr. wemmick in 'great expectations' had a not-terrible plan in terms of an unstable economy: he had gems and jewelry pinned under his lapel, and frequently touted the value of 'portable property'. this might be a better route to take than currency since it doesn't fix a destination, it's easily liquifiable, and very portable.

someone alert Stan Rogers!

couldn't have been more aptly named. this is pretty funny, in a sad kinda way. we've all been there, kiddo. thanks for giving us a reason not to go back.

sounds like you want a mini-dvi adapter, a big standalone screen, a usb keyboard and mouse, and a steelcase chair, not a desktop computer.

if you want processing power for web servers and databases, get a slice somewhere -- they're pretty affordable. don't buy an entirely new machine when you can get everything you asked for in the first paragraph for the macbook (and the sync hassles that come with two machines). you'd have to buy that stuff anyhow if you got a desktop, why not get it without the desktop?

my setup: three slices, a macbook, 25" 16:9 flatscreen LG in portrait mode. i use the mac keyboard, but have a really comfy chair. there's a file server in the kitchen, but it's left over from an old desktop and is not a speed demon -- it doesn't have any inputs or outputs connected save for ethernet.

nice article, though i'm not sure that's the One Thing. my one thing would be 'know your audience'. that's part message and part usability. if you're designing an app for engineers you design the ui very different than if you're designing it to allow residents of the local retirement community to self-schedule dinner deliveries.

that said:

if you're a resident in a company with a separate marketing team, it's key to speak their language -- after all, the people you're going to be marketing -to- is the marketing team. it's their job to get the message out, it's your job to be sure they know what the message is, and what it isn't. make sure you don't oversell, and let them know what would be overselling, and promote key features internally; they'll get external through the firm's marketing wing.

if you're a startup, marketing is doubly important. if you can't sell a friend on the idea of a product, you won't be able to sell the public. if your startup idea is complex, you're going to have to find a way to make it intelligible in ten seconds by picking the key features you want understood. and everyone in a startup is on the marketing team, whether they like it or not.

it's really worth it to read a book or two on marketing, if for no other reason than to get the lingo down. i've found my suggestions much better received when i could speak market-speak to the marketing team and sales team, and promote effectively to civilians. i recommend 'the culting of brands' by doug atkin as a good start.

they're buying up hosting to compete with amazon, likely.

we use slicehost and really dig it. will this adversely affect our service and pricing? time will tell.

to include in a website, jsjac is pretty nice. (http://blog.jwchat.org/jsjac/) it can be used to replace nearly all of your messaging functionality -- short messages, group messages, and live chat. it's reasonably easy to configure and install, and requires a jabber server running somewhere.

walk through your next week and carry a notebook, making a note of all the things you think of that you wish existed, but don't. when i do this, it's generally through little irritations, conveniences that save me 3-4 minutes, realizations about people's work process -- that kind of thing. go fishing in the real world. do this until an idea for a product hits you. it will, and likely soon: something you want or need that no one provides.

in the meantime, get into a startup, on an equity basis. look for contribution to the work, not a paycheck. learn the atmosphere, see what works and what doesn't. get involved with your local user groups and search for a partner, someone like-minded.

put down the tech for a bit and read. spin down the head for a bit. my best ideas happen when i'm not thinking about them.

it's really a question of the want-to. if you have that, you'll be okay.

lisp was introduced to me as follows: Lots of Irritating Superfluous Paraentheses

also: most game boy games were written in lisp. true story.

this is excellent. 'curse you under my breath' will henceforth be in every contract i write. they're pretty simple to begin with, but that's choice.

i'd correct the first paragraph (emphasis for clarity):

'... entered into _today_ and between _you_ (hereinafter "The Advisor") and _I_ (hereinafter "The Keeper of the Idea" ...'

then keep it around, laminated, to show folks.

seems like git isn't designed to handle long-running branches, or branches with more than one committer. i'm still pretty novice at git, and was hoping this article could clear that up, but mailing patches around seems .. inefficient.

anyone want to correct me? i like git in most respects, and am now using it on a few projects.

If you're working with other people: Pair Programming. Fastest way to learn anything.

On your own? I'd look for a reasonably simple project on github, or somewhere the source is available. Before you start trying to understand everything, prime your brain with a little previous exposure. Look through the directory structure, look through the source code. See if anything makes sense. Build it, to understand the build process. Run it. Now change something. Could be a title bar, a background image, a validation. Just something. Build it. Check your work.

Now your head is in the right space to learn. Find a cheat sheet, and go through that. Go back to the app you're fiddling with and walk through it again with the cheat sheet handy. Change something more fundamental. Build. Check.

After you've gotten the cheat sheet (primer) understood, build something from scratch. As run4yourlives mentioned, the blog is the new hello world. Build that, build a file uploader, and build something event-driven and flashy. At this point, you'll want to go through a book -- but skim the whole book first to get a sense of where things are.

Now dive deep. As you are learning, write stuff down -- build a tutorial. Try to explain it to someone else (that always helps me, anyhow). By the time you finish writing your tutorial, you'll be ready to contribute, and you'll learn more on the job.

Good luck!

the win on this article is the comments: he posted the article, someone cracked the license generator, posted the source. there was a brief, friendly discussion about this.

if it were one of my previous employers, they would've immediately sic'd lawyers, the fbi, homeland security, and anyone within shouting distance on the commenter. (the head of the legal department once got up at a quarterly meeting and ecstatically announced how many people had been prosecuted that quarter. there was an uncomfortable silence that followed, as everyone began expecting security cameras installed in every room. they started appearing shortly thereafter.)

the authors sense of humor about this and pragmatic outlook is appreciated, and in my mind, correct. do what you can, make it easy to buy, make it uninteresting to break, have free versions available for people who need them.

nice, solid review.

if only there were some sort of wiki where all these ad-hoc Rails security guides could be coalesced. hmm, what to do.

most textmate dev nowadays is being done in bundles. while the elastic tabs thing doesn't work quite right in textmate, textmate's tabbing (soft-tabs to convert tabs to spaces, backspace to go back a 'tab', autoindent based on syntax conventions) is pretty satisfactory.

one thing it doesn't do that looks REALLY appealing with elastic tabs is multi-tabbing, especially to appropriate spacing on multiline parameter lists. i'll add 'write a bundle to do this stuff' to the long list of projects that fall behind the startup.

also midwestern, and have also historically had problems finding edgish work there. they like their .NET and their java. also, work rates are terrible. i can generally expect to take a $30K pay cut working locally in central ky/southern ohio/northern tn as opposed to working remotely.

even if there were some random startup, you still wouldn't be able to participate in the startup community you would in the bay, or boston, or chicago, or ny. there'd be no networking, no idea sharing across company lines, no post-work barcamps. part of the fun of a startup is the culture.

good luck. as for me, i'm hoping YC comes through for us so i can move to the bay.

want.

You have to also love making money. I love making money. By definition, it is impossible for me to become unhappy if I have to make money doing what I love. /obvious.

I had a girlfriend like this: she was an excellent photographer, had a degree in fine arts with a photography specialty, but didn't want to make money doing it -- she didn't want it to become her job. This discrepancy made her miserable, not only because she generally didn't get to take pictures, and didn't get to make the money she could be making, but also because she wasn't using her degree.

I went to school for CS, not because I love it (though I do at times) but because the market forecast was good, and I wanted to retire early. What I like about programming is the freedom to innovate, to solve problems. I get to solve problems, solve puzzles with my job. That's great. When I get done working, I'll write a book -- that'll be even better.

I think it's enough to work doing something you like, to support what you love.

it's also possible to use twitter to cross-promote a product to a wide userbase. pushing ads for their other products through twitter would be simple. letting other people do it would also be simple.

even failing that, the success of twitter gives the people who are currently working on it a lot of credit for future products. it's not a revenue-generator immediately, but it builds faith. i think the author's focus is a little too short-term.

title should be: Rails Conferences that Matter

in general, the conferences that matter most for a given company are those that address the tech on which the company is based and those specific to their market sector (social networking companies should hit social networking conferences).

an overlay would've been nice, scaled.

making online dating reasonable @ flowmingle.com. the balance of structure and expression is a challenge, but a fun one.

generalization is not always correct, and isn't intended to be. that i have to explain this makes me sad.

i have worked with 120 or more indian programmers over the course of many jobs and several years, in bangalore, kochi, and chennai. i have met a few that were technically solid, self-directed, and would give me hell for my code, or the code of another american on my team. i'd have been happy to hire these folks if they'd walked off the street into my office at the market rates. i've invited a few to come visit when they get to the states. some i'd even call friends. by and large, it was through these individuals explaining the mindset of their coworkers that i came to understand it. i didn't drop in, make a bunch of judgements and bail. i asked the people who were driven why the other people on their team weren't. they made the generalizations, i just observed their correctness.

in observation, those driven and enterprising developers are the exception, and the exception by a wide margin. i can't speak to Absolute Truth here, and maybe there's a secret society of programming ninjas in india that few people have ever heard of or interacted with, but i have to lean on my own observations, my conversations with indian developers over half a decade, and the observations of a wide swath of software development community.

as a math nerd: i approve.

as a pragmatist?

i actually attribute that to the overall culture of india. i was in south india; chennai. the folks that live there have been in a caste system for a long time -- it's integral to their culture. when the caste system was abolished it didn't go away, it just manifested differently. russians can't exist without dictators, indians can't get by without brahmins.

at its core, it is a fundamental need for permission. it's not that indian software developers can't make decisions, and can't make good decisions -- they can. they're sharp folks. rather, there's an inherent prohibition within the culture not to jump without being told to. not to strike out on their own and forge new code. it's the injunction to wait for orders from a superior, or else face the consequences. it's a very subtle thing, a cultural trend that's hard to identify the origin of in an individual, just like it's hard to figure out why all americans need to have credit cards. credit cards are just what we do. they wait for someone to tell them to do something.

it's even more insidious than that, especially if you're closely partnered: if you tell them to do something, and it's a bad idea, 9 times out of 10 they won't correct you. i, as a fallible human, depend on other people to correct my dumbass mistakes, especially in matters of software development. no one gets everything right. that's what's so fantastic about pair programming -- both people get the best judgment of their partner. if you're paired with an indian, and they perceive that you are in a higher position than they (even if it's on a subconscious level), they'll follow you right into hell, or at least an ill-advised has_many :through relationship, even if they know better. it's the way they're raised, the way they live.

i'm not passing judgments on the culture, it just makes for bad programming partners and strange traffic patterns.

you should license this to Rosetta Stone immediately. not kidding.