URL Routing in Recess my upcoming PHP Framework - <AUTHOR> http://www.recessframework.com/page/routing-in-recess-screencast <comment><USER2> I'm really looking forward to Recess! I've been in the need of a PHP REST Framework for a small project and Recess seems to be the closest thing to what I need. All the other Frameworks seemed to have REST functionality "hacked" in, instead of being built with REST in mind.

I can't wait! :)

</comment><comment><USER3> Hey, that's pretty clever! It fixes some of the issues with "traditional" mvc style routing (say in CI or K). Very impressed.

Also liking the deployment and dev modes & the tools app (which is a killer feature IMO!).

How far off complete is it?

<comment><AUTHOR> Thanks - I'm really excited about the tools, personally.

Preview bits will go out to folks on the mailing list this week. There's a fun road ahead in bringing the framework to maturity - but there 'core' meat of the framework is solid and a nice departure from the current state of PHP frameworks.

<comment><USER4> I'm looking forward to this. I plan on giving a talk at work about frameworks and would love to know more about Recess. Routing looks good so far.

</comment></comment></comment><comment><USER5> Nice stuff.

Might you consider dropping the bang in "Recess!"? I can't imagine a more annoying naming gimmick. It's not so bad when the name is used alone but it really messes up the reading when it's in a paragraph.

<comment><AUTHOR> Duly noted. I've gone back and forth on the bang, you're right it really screws up paragraph readability.

<comment><USER6> I agree. I think Recess by itself is an awesome, very catchy brand name for a web framework.

</comment></comment></comment><comment><USER7> Looks very much like Sinatra - <http://sinatra.rubyforge.org/> \- PHPized.

In Sinatra you don't even need the methods. For example:

      get '/say/*/to/*' do
        # put code here
      end

      post '/somewhere_else' do
        # put code here
      end

If the original developer hasn't seen Sinatra it'd be worth checking out for some ideas - Sinatra is becoming quite popular in Rubyland lately so the ideas are reasonably sticky and probably worth porting to PHP.

<comment><AUTHOR> Not familiar with Sinatra. Will look into it, thanks!

</comment></comment><comment><USER8> How would this handle backwards engineering?

When debugging an application someone else has written, generally I'll be given a problem - and I want to find out all the code behind whatever is broken or needs looked into. So you start from a URL, go to your centralised dispatcher router whether that be your Zend bootstrapper, a mod_rewrite rule in a .htaccess file, your django URLs file or.. whatever. From there you'll be able to work out which controller and action you need to look at. In this case I'm looking through a whole bunch of controllers and then their doccomments to see which route matches. Not pleasant.

As someone said, this is pretty clever, but I'm not convinced it leads to maintainable code. Which is the entire point of frameworks and the MVC pattern. There are other ways to implement DRY in a dispatcher without resorting to inlining a pattern into a comment. For example, you could delegate a base pattern to another URLs conf like you do in django.. or use nested routes like the Perl Mojolicious framework:

[http://search.cpan.org/~sri/Mojo-0.9/lib/Mojo/Manual/Mojolic...](http://search.cpan.org/~sri/Mojo-0.9/lib/Mojo/Manual/Mojolicious.pod)

<comment><USER3> He seems to have built a set of tools to handle this problem.

From the very brief sneak peek we got at that it looks like a killer toolset for something lie what you describe. Knowing where to head to BEFORE even opening a controller file is a big bonus :)

</comment></comment><comment><USER9> wow, this looks impressive. how long did it take you to get this far?

Me and a friend are looking for a good php framework to build an application on. Any idea on when this will be out?

The support for methods and paths is very cool. Is there any support for media types/content negotiation?

<comment><AUTHOR> Recess has been in development, full-time, for about 3 months now. It all began after returning from the Web 2.0 Expo in New York - reinvigorated about the pragmatic utility of PHP by Cal Henderson (I now refer to his talk as my PHP Tent Revival) and inspired by DHH and others about the beauty of RESTful interfaces and the HTTP spec.

Content negotiation is on the radar. Currently the negotiation is one-sided and depends on the request having a .json extension for example. This will be beefed up after the preview release.

</comment></comment><comment><USER10> You've reinvented Lisp macros in PHP. I did the same thing Rails for caching; this is a classic example of something macros make easy and natural.

<comment><USER11> "Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp." -- Philip Greenspun

</comment></comment><comment><USER12> I really dig the simplicity of this approach, yet I think it's disaster waiting to happen.

Essentially, you're moving a part of your functionality (the part that determines which URLs exist, and which parameters are defined in those URLs) from a programming language environment to a common language environment (the comments). That common language environment is not as capable when it comes to defining, specifying or altering functionality - but it's what a programming language excels in.

So what do you do if you want to _generate_ URLs? Or if you want to define URLs based on some content in the database? Those are hard things to accomplish with your current approach. I assume that there's a proper API that might address such issues, but the article doesn't mention such a thing. Good luck though.

</comment><comment><USER13> This is actually pretty cool, but I'm genuinely curious why it's advantageous to write the routes in the controller files instead of one central place that's easily maintained?

CakePHP, (<http://book.cakephp.org/view/46/Routes-Configuration>) for example, can do all of what this does out of the box without the need for an application to monitor your routes.

REST also seems very well implemented : <http://book.cakephp.org/view/476/REST>

Am I missing something? Can someone explain the benefits?

</comment><comment><USER14> Hmm, so your routes are "structural comments." Isn't this what XML is for?

Am I the only one here who finds this ugly?

</comment><comment><USER15> What happens when you accidentally duplicate one and have to go through every controller looking for the culprit?

<comment><USER16> This is covered in the screencast. One of the smart error messages that the framework gives is the location of any duplicate routes.

<comment><USER15> Guess I should have watched the whole thing :) Thanks.

</comment></comment></comment><comment><USER17> Hmmm nice work (around) don't you wish php had attributes support...

Have you thought about using "named" variables for this sort of functionality without interfering with the commenting system.

<comment><USER18> That was my first thought too, since the Reflection API lets you get to the actual parameter names... However, I'm not sure off the top of my head how pretty URL's would be implemented(probably would have to use mod_rewrite). There's also the URL prefixes he's implementing. I think he's giving up the efficiency of mapping _REQUEST params straight to arguments in favor of more features/flexibility. My takes on frameworks went the former route (straight mapping + mod_rewrite), but I've since become less hardcore about being minimalistic with URL's.

<comment><AUTHOR> There is some additional overhead in mapping the the $_REQUEST params but it's not actually so bad.

Design decisions have been made to err in the favor of making user code simple and more expressive. Having some routing logic contained in the code and 'pretty urls' in mod_rewrite is much more difficult to approach.

<comment><USER18> I'm not sure what you mean by additional overhead... You're already using the Reflection API to to get to the names of the method arguments so that your /hello/$first/$last works, no? Or are you just relying on the order and assuming the developer puts things in teh right order, ie /hello/$foo/$bar works just as well?

If the former is true (you're already getting the param names), then there's no further overhead to map directly to $_REQUEST. I forget the exact Reflection syntax, but wouldn't it just be something like

$argsToPass = array(); $args = ReflectionMethod->getParams(); //you got an array of param names in the order they appear in the function foreach ($args as $arg) { if (!isset($_REQUEST[$arg])) { //check if the arg is optional and fail if not } $argsToPass[] = $_REQUEST[$arg]; } $ReflectionMethod->invoke($argsToPass);

I haven't touched this stuff in a while, so I might be completely off, but I'm not sure what overhead you're referring to...

Once again, I'm not defending this approach, as the extra logic you've put in to interpret the path probably makes things a lot more flexible and easier to debug.

<comment><AUTHOR> Thanks for clarifying and the code bit. This is very close to what's actually going on. The 'overhead' I mentioned is minimal, and exactly what you described.

The names are important in mapping so... / __!Route GET, $last/$first */ function foo($first, $last) {...} Maps $first to $first properly, etc.

Indeed the hope is that this will be easier to understand and use.

</comment></comment></comment></comment></comment><comment><USER19> Doc Comments, that's a new one.

<http://www.php.net/manual/en/language.oop5.reflection.php>

</comment><comment><USER20> This looks like it's going to be great. When can we get a hold of the code to play with it?

</comment><comment><USER21> Great! But "Smarty templating pover views"? Please don't!

<comment><USER18> Why does everybody hate Smarty? Explain please.

<comment><USER22> The trade off between wasted processing and elegance is not high enough for most people. I could see it being nice if you are giving access to "non- developers" to modify the views/templates of your system and want to make sure they only have access to a given subset of functionality.

<comment><USER18> Smarty compiles its templates, so only the first execution takes the processing hit. If you have APC, the hit is also very small.</comment></comment></comment></comment>


Do call yourself a programmer, and other career advice - <AUTHOR> http://www.yosefk.com/blog/do-call-yourself-a-programmer-and-other-career-advice.html <comment><USER4> You should call yourself whatever based on the situation.

If you are hanging out with a group of consultants, you call yourself consultant; if you are a special effects programmer, and talking to a model, you say you're in the movie business; if you are interviewing with the author, you call yourself programmer.

The best way to connect with others is to understand how they perceive things and find ways to relate to them, not enforcing your own world view onto them.

<comment><USER5> This so obvious I'm amazed that it isn't discussed every time this topic comes up. Programmers seem to think that there is something "dirty" about adjusting your language according to audience.

<comment><USER6> > Programmers seem to think that there is something "dirty" about adjusting > your language according to audience.

Yes. I am struggling with this right now, myself. I mean, not specifically that, but this general idea that putting effort into social bullshit that has little to do with my actual competence is dirty. It really /does/ feel dirty, and I have a difficult time articulating why.

The problem is that I have moved myself more towards management, and so getting people to do what I want really is part of 'competence' now.

A big part of this is that humility (false or not) is so absolutely core to getting along with other engineers, and so absolutely terrible when dealing with business types; behavior I have put a lot of effort into training out of myself now needs to come to the fore.

I don't know. One track is to view social nonverbal communication as ethically neutral, but eh, that... might have other problems, too. As this is an active problem for me, I clearly don't have the correct solution.

<comment><USER7> I've recently found myself in a leadership role as well, and I don't think it has to do with whether people are business types or not. Humility is necessary to fit in with peers and to get along with superiors. Confidence is necessary to influence people (be they peers, superiors, or subordinates), and you can't manage without influence.

A piece of advice I've seen in a couple places is to focus on service, whether that's service to your organization or to the team you manage, or the customer. The idea is that it takes your focus off you and your communication skills, and lets you argue from what the company or team needs.

<comment><USER6> Edit: Yes, I know this sounds kind of... angry and juvenile. Bitter. That is what I meant when I said that I clearly don't have the correct solution.

a big part of the problem is that I don't even know what most of these words I'm using _mean_ \- And honestly? I think it's "confidence[1]" that other people say they do. Of course, I know I'm not competent enough in that area to know that for sure.

>I've recently found myself in a leadership role as well, and I don't think it has to do with whether people are business types or not. Humility is necessary to fit in with peers and to get along with superiors. Confidence is necessary to influence people (be they peers, superiors, or subordinates), and you can't manage without influence.

But when you are dealing with less-experienced Engineers, your accomplishments are that influence. And when you are dealing with more-experienced Engineers, well, you should be giving them requirements, and listening to them tell you what should be done. I mean, yeah, sometimes emotional bullshit intervenes, but it's bullshit I can mostly deal with.

As an example, I came in conflict with my apprentice a while back... I am fairly certain the conflict was caused by the fact that he had learned enough that he was, well, better than me for some of the parts of his job, and that wasn't the deal when he hired on. (I mean, it also wasn't true when he hired on; he worked here for a while, and he learned a lot.) I don't know how much of it was him not adjusting to our new roles and how much of it was me not adjusting to our new roles (and how much of it was me just not being able to pay him what he was worth; he ended up getting a much better job elsewhere.)

I mean, I didn't understand how to /fix/ the emotional bullshit, but I had a pretty good idea of what it was about. that's the thing about dealing with people who are primarily engineers; I'm not saying that I am good at managing Engineers? but when I screw it up, I usually have a pretty good idea of how or why I did so.

The problem is that when you deal with normal folks, they are influenced by what looks to me like empty arrogance. It's like they have no way of judging actual skill, so they say "Why don't we do what the tall guy says?" you know, they focus on things like posture and voice and how you dress... which really have nothing to do with anything that matters.

My other problem is that I've always been way better at managing down than managing /up/ \- that's the primary reason I started my own company. If you always focus on what _you_ think is best for the company and/or the customer? you are going to come into serious conflict with the management above you. [2]

>A piece of advice I've seen in a couple places is to focus on service, whether that's service to your organization or to the team you manage, or the customer. The idea is that it takes your focus off you and your communication skills, and lets you argue from what the company or team needs.

Yeah, well, it's my company, so I think I do keep my 'eyes on the prize' as it were. But that doesn't really help when it comes time to negotiate that big new bandwidth contract (or get them to interpret that contract in my favor, after it's signed.)

I mean, that's the thing. when you are negotiating with professionals, it's their job to take as much of the surplus value out of a deal as possible. It is, by definition, 'surplus value' \- the difference between the highest price I'm willing to pay and the lowest price they are willing to give me.

(the other thing about negotiating with professionals that is not fun is that they usually don't have the attention span or the knowledge of their product offerings to negotiate other than in the emotional manipulation way. I'm very flexible, and very willing to line up what I buy to what they have surplus. I'm also very willing to share what I would like, and what I can be flexible on. A professional? generally speaking, wants to collapse that down to a linear type deal, where we pick a product and hammer eachother on price until someone is exhausted. Their secrecy destroys any possible gain in value from negotiation.)

Of course, now I'm conflating negotiation with influence in general, while I probably ought to think of those things separately.

[1]Confidence as in "a confidence game" \- I don't think anyone understands human interaction the way you can understand, say, how a program works. The meaning of a word someone used early in a conversation changes towards the end of that conversation. This is where I'm lost with verbal communication. The line between "saying nice things to give someone a good feeling" and "outright lying" is... I don't even see it. I have no idea where that line is or if it even exists. Does a professional think it's even possible to lie in a medium that isn't recorded?

[2]some of the things my apprentice and I disagreed about would have fallen under this. The really funny thing, for me? was that I remember having nearly exactly the same fight with my boss when I was his age, and was working in a similar role. Things... look different when you have to balance the business end. But, fundamentally, I think I _can_ learn to deal with those conflicts, because I understood where the guy was coming from.

<comment><USER7> It's like entropy: the emotional bullshit in a closed system only increases. Until one person leaves, or you bleed off the pressure outside it.

With negotiation, my understanding is that the real negotiation starts weeks beforehand, because the game is about getting an information advantage, enough to make the other side's shady tactics irrelevant. All the nonverbal skills are just used to hide the math layer of the exchange. Assuming you can't dump the shady opponent for one who thinks win-win, but even then having more information can't hurt.

<comment><USER6> >With negotiation, my understanding is that the real negotiation starts weeks beforehand, because the game is about getting an information advantage, enough to make the other side's shady tactics irrelevant.

You say 'shady' \- I say 'professional' because this is what the big guys do. the bullshit isn't nearly as thick when you are dealing with a smaller company, generally speaking. They are less interested in wasting time.

Even when dealing with professionals, information is essential, but it doesn't make the emotional bullshit irrelevant. It's irritating, as first? I don't know if I want to do something unless I know what it costs. The negotiated price is generally 30% to 50% of the list price (but that varies a /lot/ both by vendor and by industry.) And the only real way to get prices is to negotiate with a vendor. So, yeah, I'm looking at a /lot/ of work to just find out if a business that, say, requires more bandwidth makes any sense at all.

<comment><USER7> So the business wouldn't make sense (but just be less profitable) if you had to pay the list price?

<comment><USER6> some businesses, it makes the difference, like re-selling bandwidth or co-lo; the margin I get on that sort of thing is usually between 10-50% so if I negotiate badly from my supplier, yeah, I'm losing money on the deal (or charging above-market rates, which considering that I'm bad at negotiation, means I'm losing even more money because the space sits empty.) - usually you have to get commercial style leases on those resources, too... and so you have all the problems of commercial leases 'Oh,' the landlord says 'you are doing well... now that your lease is up, of course, the market rates have gone up!' even if there are empty units on either side of you.

So yeah, for co-lo? it makes all the difference in the world.

Other things, like VPSs? it's just a matter of profitability... the margins on VPSs are pretty good if you don't count labor, so it'd be a matter of just not raising my bandwidth quotas like I ought and maybe spending more money on hardware.

Sometimes, there are two substitute products, one where it's traditional to negotiate, and one where it isn't... for instance, if you buy pre-assembled servers? if you aren't getting 50% off list price, you are getting it in the shorts. But, if you are buying the parts used to build said servers? generally speaking, the lowest price on the internet is pretty close to the real lowest price.

This is the primary reason why I do my own assembly; assembling computers is way easier than negotiating Dell down to a reasonable price.

So yeah; this is starting to shape what businesses I want to get into. I mean, co-location only has margin if you own the building. (I'm working on that part, but I don't have an ETA.) - so yeah, if the 'owning the building' deal doesn't work out... well, I'm not going to dump existing customers, but I am not taking more at the moment.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> I was having a beer in this small Brazilian town, mid-afternoon. Two girls come to my table. We try to chat ; they can't speak any foreign language and my Portuguese is awful.

\- Me: What is your job ?

\- The girls: Programma

\- Me (for the next 30 minutes): Oh great, me too ! Which languages ? <here comes the enumeration of the 100 programming languages I know, each one pronounced in 10 different ways, Brazilian accent, etc.>

Even "Java" didn't seem to mean anything to them. Strange. I assumed they had special programming languages in Brazil.

10 years later, in Palo Alto. I read some article about Brazil society. One word catches my attention.

Programma = Prostitute. Oh.

So yes, don't call yourself a programmer. Especially in Brazil when you don't know the language.

<comment><USER9> That's pretty funny. In case anyone's wondering, the full term is "garota de programa", literally "girl of program" or "program girl". Obviously, the English is "call girl".

Normally, "programa" just means events, like "what's the program for the evening?". Here, of course, you can figure it out yourself.

<comment><USER10> Now I'm wondering if there is a difference between call-by-value girls and call-by-reference girls.

<comment><USER8> If only my wife's body was immutable.

<comment><USER11> I'd love to continue this but I have garbage collection to attend to.

<comment><USER12> And they say nobody around here has a sense of humor! Happy to see it was just a matter of injecting the proper dependencies!

<comment><USER13> Whoops, came to reddit by accident.

</comment></comment></comment></comment></comment></comment></comment><comment><USER14> A few comments:

1\. _To me, however, a programmer is who I 'm looking for, while a resume full of revenue increases and cost reductions sounds like an "anomalously high-cost parasite who types some mumbo-jumbo into Excel and PowerPoint, claiming credit for others' work"._ This is in no small part because you are a programmer. The vast majority of people who pay other people for work that involves programming are _not_ programmers (and that does not make them any less smart, or any less lucrative.)

2\. Abstracting a greater point from Ron Garret's career history is tricky, if only because the vast majority (by which I mean myself) of programmers will never reach his level of competence.

3\. There is absolutely a chance that the value of the company which employs you will increase by ten times over the course of your employment. This chance is vastly overestimated by workers, especially in startups.

Overall, I think Yosef is misconstruing a lot of patio11's original points (though the points Yosef makes, especially about forming relationships with coworkers, are still quite true.) Perhaps the biggest takeaway: the path to success in a chip architecture career is entirely different than the path to success in a SaaS/freelancing career.

<comment><USER15> My replies to your points:

1\. Do you have stats? In absolute terms, a whole lot of people hiring programmers have programmed themselves. How do you know the other people hiring programmers are "the vast majority"? (I sincerely wonder about it. I cited two numbers by two bloggers, one says it's 80% of the cases, the other says 90%. I have no idea, but I intuitively feel it's less than 50%. Are there real stats?)

2\. I mentioned Ron Garret because I replied to an article mentioning him and Google as a proof of something that this example actually disproves, not because I thought it's a good example to generalize from.

3\. I agree, which is why I said that people overvalue _early_ option grants (hoping for the value to rise tenfold which it probably won't); I added to that an explanation why _late_ option grants past the point where value can possibly rise tenfold are undervalued (because the money you make is the difference in prices, which rises with the absolute value of the stock price even if the growth rate goes down.)

I said near the end that I'm not sure I'm reading the original article as intended so you could say I misrepresent it; what I am pretty sure of is that a whole lot of people read it very closely to the way I'm reading it in my reply, and I'm writing for those people.

Your "biggest takeaway" is exactly what I'd like the takeaway to be; all I'm saying is that SaaS/freelancing career is not the only path to succeed in "programming", and that there are other paths you might want to take and you'd behave differently if you took them.

<comment><USER16> 1\. There are far more non-programmers than programmers. Even with a correlation between being a programmer and hiring programmers, it is plausible that the vast majority of hiring managers are non-programmers. This becomes more plausible if you step back a layer to the budget allocation for headcount rather than specific hiring decision.

<comment><USER17> Isn't it also plausible that after the first programmer hire (by non- programmer), any subsequent hiring will at least involve this first programmer?

I would even go as far as saying that an 'expert opinion' from a programmer would typically be involved in the hiring decision (be it from an external consultant, a friend or what not). Given that the non-programmer would typically realise they don't have themselves the skills to evaluate programming abilities or CVs.

<comment><USER7> _> Isn't it also plausible that after the first programmer hire (by non- programmer), any subsequent hiring will at least involve this first programmer?_

Definitely. You'll generally have to convince a programmer of your competence. Once you've passed that test, you may also have to negotiate with a non- programmer for your salary. At that second stage is when you want to be able to convince someone of your ability to multiply dollars.

</comment></comment></comment></comment></comment><comment><USER18> I think Patrick's article is one of the best-written I've seen about the realities of the intersection of programming and business for people who have come from a strict tech background with zero business exposure. In my experience what he says is spot-on in almost every way.

Businesses exist to make money. Yes, very often making stuff is an integral part of the business model, but its still a business. To excel in a business you need to be responsible for growing its bottom line. This can only happen through increasing revenue or decreasing costs.

This probably applies more to consulting than any other field. If you go to a potential client and try to sell them on the fact that you are the best Java developer in 5 states, they are going to look at you with glazed eyes and stop listening. Tell them you think you can bring them a 10% increase in revenue with a simple piece of software, and you will get much further. This is in fact how large consulting firms make sales every day. I assure you they don't send in their developers to sell clients, they send in people who are flashy and know how to appeal to a decision-maker's interests.

I think more than anything his article explains things that are necessary to successfully convey value to purse holders who don't speak techie. If you restrict yourself to describing yourself in purely technical terms, you will sound great to other people who understand you but will never resonate with those who don't.

</comment><comment><USER19> The business terms are "cost center" and "profit center". If you do IT for a financial firm, you are a cost to be controlled. If you do product development at a software company, your work contributes directly to profits and the more of you there are, the more profit they make. I can add that aside from software, consulting also treats programmers as profit makers although clients will see you as a huge cost. Good companies know that IT facilitates their work and should be treated with respect, but that mindset is still the exception rather than the rule. The one an interviewer told me I had asked an excellent question, was to ask how IT is viewed within this (financial) organization

<comment><USER11> In a former life, projects were paid for either from 'expense' or 'capital expenditure' buckets. Investors like expenses to be low as possible, but capital expenditure is investment in the future. Managers were always trying to creatively finagle projects in whichever bucket had some available money.

</comment></comment><comment><USER20> There's a major point in this article that not many commenters seem to be picking up on: there's a fork in the road of careers. To one side is a multilane highway over fairly level ground leading straigh to predictable suburbia. To the other side is an uneven dirt path leading through mountains and countryside to parts unknown and has many forks of its own. Neither path is right for everyone. And hardly anyone needs to be talked into the highway, as it's the default choice and the common wisdom.

The sad part comes when some bright, young up-and-comer leaves off their interesting personal projects in less used languages in order to focus on only mainstream stuff.

<comment> UK-AL Its also sad when some bright up and comer ends working for lots of little small companies, on a tiny wage when they could be earning a seriously better life working for a large company.

<comment><USER21> "earning a seriously better life" is one of the saddest phrases I've heard. You don't earn a good life, you make it.

<comment> UK-AL Of course you can. For a lot people the good life is a nice family, nice holidays, not being stressed. For that you require money. Otherwise you might end up in a tiny apartment, eating cheap food, feeling quite stressed.

<comment><USER21> No. Having a nice family, nice holidays, and not being stressed _do not_ require money. Furthermore, your counterexample of a tiny apartment and cheap food don't actually contrast your definition of the good life. You can have a nice family, nice holidays, and not be stressed while living in a tiny apartment and eating cheap food. A lot of people do so every day, all around the world.

</comment></comment></comment></comment></comment><comment><USER22> Having just hired two senior programmers (admittedly for a small "software company"), I couldn't possibly agree more with this: "To me, however, a programmer is who I'm looking for, while a resume full of revenue increases and cost reductions sounds like an 'anomalously high-cost parasite who types some mumbo-jumbo into Excel and PowerPoint'."

Resumes full of marketing-speak go onto the discard pile very quickly. I want to hear about your skills, and I want to see that you can present them effectively (which is your first opportunity to demonstrate your intelligence and aesthetics). People who claim to be programmers but talk about revenue growth and such _in their resumes_ are always the types who want to talk to you about how they "have tons of great ideas, [they] just need a team to implement them!" Well great, then start your own company. I'm certainly looking for smart people with ideas, but we already have a product and work that needs to be done. We're not here to provide a team to implement our new hire's hand-wavey built-for-adsense get rich quick site or whatever.

Whew. OK, veered a bit into hyperbole there, but it demonstrates the visceral sort of mental response that kind of resume can provoke...

Edit: Given other comments that agree with focusing on costs and revenues, maybe the take-away is that you should really have two separate copies of your resume, and do your best to find out whether a programmer or non-programmer will be reading it before choosing which one to send. Because it seems like the reactions are essentially polar opposites. Which honestly I find surprising. I would expect that what sounds like mumbo-jumbo to one intelligent person would largely sound like mumbo-jumbo to another intelligent person, regardless of specific discipline - even if those disciplines are as different as marketing and programming. Perhaps I just haven't ever received a _good_ resume that focused on financials.

<comment><USER23> something to consider, though: your job may not be the best opportunity for this hypothetical candidate we're musing about. for pure programming skill, there is no well-defined "value" for the business, which means you simply want to hire the best programmer for the least cost. in many markets today this is about $200k for an entry level programmer (employer costs). why pay more than that?

the point of marketing mumbo-jumbo is that it frames the value of the individual. if a candidate is capable of making you $10 million extra dollars, why not pay them $1m? you'd be a fool not to!

<comment><USER15> Erm... because that $10M is a conjecture, while the $1M is a cost paid upfront with complete certainty? Or do you want to pay in equity? Also - <USER2> someone else is willing to do the same job for less? I'm not sure that "framing my value" will help me when someone is willing to do the same for less money.

</comment></comment></comment><comment><USER24> In the huge mega conglomerate where I work, I was told by my old boss to not call myself a 'programmer', as those with that title they can outsource to India, I had to have something with Architect in it to hopefully keep me employed continuing the daily grind.

Of course in all reality I am more of an architect, but when people ask what I do, do I say architect of this or that, and have to explain that, or simply computer programmer and that they get right away.

<comment><USER25> Yeah, I usually say programmer/software engineer rather than architect. Makes explaining it a lot easier

</comment></comment><comment><USER26> I don't agree with the point about later stage options:

 _But what this misses is that you don 't get paid in percentage points - <USER3> get dollars. A $100 share going up 20% to $120 means you make $20 per share. A $5 share going up 100% to $15 means you only make $10 per share._

If you join a larger company, the shares will be more expensive but you will own less of them. Percentage growth is definitely the way to measure opportunity when it comes to options. In other words: (how much I might earn) / (how much I have to pay).

<comment><USER15> If you _join_ a larger company, yes you'll get less. If you _stay_ in a company while it grows larger and you _then_ negotiate for more options, maybe you'll get relatively many, as you're now rather uniquely valuable to that company. What people do instead is decide that options aren't worth it any more because how much the price will rise at this point, and ask for relatively small salary increases instead of relatively large option grants. This is doubly wrong since their salary is already pretty high at that point and there's a ceiling on salaries for various reasons that I don't fully understand but which certainly exist, while there's much less of a ceiling on option grants.

</comment></comment><comment><USER27> I have been a professional programmer for 32 years. When I stop calling myself a programmer I will call myself dead (if I could).

<comment><USER28> My "career" aspiration in school was to be a bearded, suspenders wearing unix admin/hacker.

I don't ever want to get non-technical. I've been a project manager, and found the work excruciatingly boring.

I've been a freelancer, and found the work mind numbingly boring.

I much prefer working for a company where I can be neck deep in designing and building challenging products.

</comment></comment><comment><USER29> Funny thing. It took me _ages_ before I actually had the balls to call myself a programmer.

</comment><comment><USER30> I don't call myself a programmer because software development is not programming, probably not even mainly. Moreover, programmer gives other people a false impression of your work. Outsiders consider a 'programmer' to be a 'trained monkey that does the typesetting'. Software developer, in an all- encompassing sense, is the best description I have found for my work.

<comment><USER31> I promise you, outsiders have no concept of what a programmer does beyond, "Works magic with a computer." "Software developer" and "programmer" are equivalent to the layman.

The negative association with the word "programmer" is an industry-specific thing.

<comment><USER30> Zed Shaw on corporate programmers (not mainly on titled ACLs): [http://vimeo.com/2723800](http://vimeo.com/2723800)

</comment></comment></comment><comment><USER32> In Georgia, it is the mostly used title - "Programisti".

Because, we don't have one single word, the synonym of "Software". So word by word translation of "Software Engineer" in Georgian would be:

Computer Program Provisioning Engineer.

Nobody uses this title.

<comment><USER33> Your Georgian language looks exactly like Russian J

<comment><USER32> Actually no. There can be some particular similarities, as with any other language, but overall, they are quite different.

</comment></comment></comment><comment><USER34> When I was first started out in programming, someone gave me the advice "never work at a company where you're a cost, always work at a company where your output is [directly tied to] the profit."

It seemed like a truism, and was somewhat memorable. To date, the only really bad jobs I've had in programming/engineering/what have you were ones where my work output was seen as a cost and not as a product or service, so anecdotally it's worked out.

</comment><comment><USER35> No, the person he's responding to is right. In general, hiring managers don't care about bits, they care about dollars. They're going to be looking for dollars you made for other companies because that translates into dollars you can make for them.

Money. It's the universal language.

<comment><USER36> That is not true across the board. Many companies are looking for specific technical talent. When nVidia is looking for someone to fill a specific niche on the CUDA team, they don't care about how much money you made for company A or B; they care whether you have the technical ability to fill the niche as they conceive of it. The hiring manager isn't naive, and already has an idea of why this position was created and what they're looking for in a hire. The interviewer is quite likely to be an engineer already on the team.

What they want you to convince them of is that you have the technical skills to fill the role. If you start talking about ROI and business value, it can be seen as a red flag that you're from a more "soft" background like business informatics, and not a good fit for the position.

Of course, if you're getting hired by someone who _doesn 't_ have a specific technical role they're trying to fill, or doesn't know what exactly they're looking for, the situation will be different. But that is not usually the case at chip-design firms.

</comment></comment><comment><USER37> I thought the general advice is to call yourself a software engineer.

<comment><USER38> I hate the trend of calling people who code 'engineers.' It's just not a good title for anything to do with software. And invariably people who embrace its usage seem to be trying to compensate or ignorant of what a real engineer actually does or is.

<comment><USER39> The trend extends to other words. Sometimes I hear Programmers calling themselves Computer Scientists or Computer Engineers [1] [2] [3] when in different cases they are a Developers or a Hacker. Which they get wrong too. You are what you are. of you're acting another role you should state that you're playing that role not that you are.

Ex. Computer Scientist, who can fill the role of a Programmer.

This discussion keeps popping up [4] [5] , but the definitions are clear. I believe there's a Wikipedia article somewhere that explains all the differences.

[1] In Puerto Rico [2] [http://www.eng.buffalo.edu/undergrad/academics/degrees/cs- vs...](http://www.eng.buffalo.edu/undergrad/academics/degrees/cs-vs-cen) [3] [http://en.m.wikipedia.org/wiki/Engineer](http://en.m.wikipedia.org/wiki/Engineer) [4] [https://news.ycombinator.com/item?id=5936652](https://news.ycombinator.com/item?id=5936652) [5] [http://blog.hartleybrody.com/hacker-developer- engineer/](http://blog.hartleybrody.com/hacker-developer-engineer/)

<comment><USER40> What's the difference between a computer scientist filling the role of programmer and somebody who is both a computer scientist and a programmer? If you can fill the role of X competently, why can you not rightly be said to be an X?

<comment><USER39> You're X AND Y. Not just Y. Just like someone here on HN who worked on their double bachelors of Math AND Physics while there was a minor called Math- Physics. S(he) worked hard for that and.

</comment></comment></comment></comment></comment><comment><USER41> I am suprised the author does not mention growing a beard and wearing sandals among his career advice. That sure has kept me from having to interact with the likes of Patrick McKenzie.

</comment><comment><USER42> First of all, taking patio11 too seriously is a sing of having inadequate mental representation of so-called reality.

Ironically, there is some unintentional truth is his blogpost - one really shouldn't call oneself programmer, because what he described is a dumb coder. Programmer could realize what is blogging, not vise versa.)

A programmer (one who understands how things works and why) will easily avoid such scenarios like ending up in a coding sweatshop or toxic things like PHP, Java or JavaScript. It is obvious that one should avoid certain things, like one avoids scams, frauds or just wrong things.

Real programmers, such as rtm, pg (god forbid!) sysoev would always find a niche for oneself and a project to do. The difference is that _they themselves_ would choose what to program and why, not someone else.

Another point is about whose opinion one should value and why. Programmers usually does not care what "talking-heads" are broadcasting, intuitively and correctly anticipate that there would be zero useful or even interesting information for them. It is like to read, say, Oracle's press-releases and PR pamphlets about mysql instead of actual Changelog files.

So, right, do not call yourself programmer if you're mere a coder or blogger. There is some truth in it.)

<comment><USER15> You know, somehow your comment conveys a uniquely Russian atmosphere, making me feel slightly nostalgic.</comment></comment>


The Anatomy Of Search Technology: Blekko's NoSQL Database - <AUTHOR> http://highscalability.com/blog/2012/4/25/the-anatomy-of-search-technology-blekkos-nosql-database.html

<comment><USER2> This is the same technology that is used by the webgrepper tool [<http://blekko.com/webgrep>] (a grep for the web pages' sources).

Disclaimer: I work at blekko and I developed the webgrepper.

As a side note, we have used this for various other purposes - some fun ones being, store a big music collection (to extract meta data via mapjob), citizenship test q&a (to pick random questions), the 'joke of the day' (of course, this is our "hello world" example internally to new employees) ..etc.

<comment><USER3> It looks like it'd be useful for a lot of stuff besides search engines. Is there any place to get more details?

<comment><USER4> Greg has planned a whole series about the combinator architecture behind blekko's datastore. Greg and I have both presented aspects of the system at various conferences, but we're happy to chat about it with you directly too. I think this might be the first time it's been published on the web though.

<comment><USER5> There's a video of one of Greg's talks (from Surge 2011) here: <http://lanyrd.com/2011/surge/shzth/>

</comment></comment></comment></comment><comment><USER6> Hey, great stuff! How do you implement high availability?

<comment><USER7> There are 2 parts to our high availability.

First is on our frontend side. We have 2 nginx servers (using linux HA and vips) which send traffic out to the nodes of the cluster which are up, retrying to a different node in the case of failure or a slow reply.

Deeper in the system, there are 3 copies of every piece of data.

Both of these are fairly normal mechanisms; the 3-copy thing is used at Google and by Hadoop and friends.

</comment></comment><comment><USER8> Isn't DynamoDB on SSDs? AWS alone might not be cost effective but, how does it look with the other services also offered?

<comment><USER9> Since our SSDs hold a cache of what's on disk, it's most effective to have the SSDs and the disks are in the same server. It's hard to assemble separate pieces into a tightly-coupled system.

</comment></comment><comment><USER10> Very good article in deed. I have always been amazed of how the search engines can query so huge data sets so quickly. This brings some light to it.

It would had been nice to see some examples of the query language they use, it if is comparable to other NoSql databases.

<comment><USER9> Like many NoSQL databases, we don't really have a query language. Mostly you read a few columns from a particular row. That could contain a combinator, such as at TopN containing 1,000 inlinks to a webpage... something that you would ordinarily fetch using a range query that returned 1,000 rows from a table.

</comment></comment><comment><USER11> Can you say more about the choice of swarm algorithms instead of Paxos?

<comment><USER4> Paxos would be good for electing a master, but we wanted to avoid having any masters in the architecture. There are also scenarios where paxos can be slow or fail to reach a consensus. We wanted high availability from each node in the cluster regardless of whether 2/3 of the rest of the cluster were down or unreachable; both parts of a partioned cluster should also be able to continue to function as best they could.

Individual nodes can often make "personal" decisions about what to do in subobtimal situations. If you can answer an incoming request, even with partial or out-of-date data, do so; it's better than not replying. For the repair agent, each node can see its own view of "holes" in the 3-level replication, and offer to make copies of <3 buckets to bring back up to three copies.

<comment><USER11> This article and you guys' comments in this thread are really interesting and suggestive. I hope you continue writing and talking about it. It's great marketing for blekko too :)

</comment></comment></comment><comment><USER12> Awesome insights into what goes into building a search engine. Very impressive indeed.

</comment><comment><USER13> does blekko DB partition data base on primary key or it just query all nodes everytime like elasticsearch?

<comment><USER4> Partitions are based on a hash of the primary key. The number of buckets in the system has to be a power of 2. But we can split buckets to increase the number, or even have some buckets that have split and some that haven't yet. Each bucket is stored on 3 separate servers (and the assignment makes sure the three servers are on separate racks).</comment></comment>


Ask HN: Advice on picking up the phone and selling my product. - <AUTHOR>

I work in a small three person startup as the CTO/sole developer. We recently hired someone to take care of the marketing and sadly I have absolutely zero faith in their abilities or approach. It's come to the point where they've just out right said that me having a say in the marketing is making us lose focus. I'd let them go if I could, but the long story is they are a friend of the CEO who doesn't have the heart to just tell them what to do.
The CEO is away for two weeks during which time the marketing manager had a telesales person come in for two days last week. They prepared nothing for them, in terms of core message, goals etc. I had to actually cue this person and tell them what their message should be and how they should try presenting it. I can't describe how frustrated I've felt since then. Every moment they are working on the marketing feels like another moment the business feels like it's slipping away into nothingness.
So, I'm going to pick up the phone myself with the sole aim of getting meetings in-front of potential customers. We sent out a letting introducing ourselves to a list of potential clients and I'm going to follows those up myself. Problem is I've only done calling like this once and it felt like the most stressful thing I've ever done. The anxiousness and the fear of rejection.
My current thinking is I'll just be honest and say "We're trying to get the thoughts and opinions of people like yourself. Would you be open to meeting with us for only 5 minutes?".
But what can I do to make the process easier/better? Are they any simple approaches that I can use to secure meetings? How do I get over this anxiousness and stress that I feel, even when I just start to dial a number? <comment><USER2> Its sounds like you already have a list of prospects, which is great. I'd take a day or two to determine if you can secure warm introductions from friends, acquaintances, advisors, etc into any of these target companies (LinkedIn is a stelar resource for finding these types of intros). If you can, then you should have a more receptive target which should help you gain some confidence in your own abilities prior to jumping right into the "cold calls".

Another technique that I've used with some success is to determine the target individual is within a company and try to find their preferred communication channel. For example, I've gotten some really great contacts by connecting with people first through Twitter or their blogs. I think this can sometimes cut through the noise of the 100 unsolicited calls they get in a day.

You may also want to try sorting your target list by those you think have the most strategic importance. Then, start calling from the bottom of that list (i.e. the folks who you believe have the least strategic importance) and work your way up. This will give you the opportunity to work out your pitch/confidence with some lower priority targets. I've seen some startups try to pitch their most important potential partners right out of the gate and have a bad experience because they haven't had a chance to refine their pitch yet.

As far as the message, being straight forward about what you want out of a meeting is definitely the way to go. Make sure that you also figure out what the benefit is for the potential target. For example, can you offer them some discount or free trial of your product in exchange for some feedback at this early stage. The actual benefit you can provide to them will obviously vary greatly depending on the type of product you are selling and the type of company you are selling to.

Hope this is helpful- good luck!

<comment><USER3> This advice is good. Definitely listen to the part about reverse ordering the calls you make based on the value you place in the target accounts. Also expect to not get a sale or meeting most of the time on these types of things as people have a different agenda than you and are overly busy.

Don't sell features, sell solutions to problems. They will only buy something if they have a problem that your solution fills.

Good luck!

As an aside, how did the marketing guy get hired? Was it a consensus or a unilateral decision? Either way if the guy is not bringing enough to the table you need to measure the persons performance and hold them accountable. This is not being a bad guy, it is simply holding them to the same standards that you are held to. If you shipped out a product full of bugs or were late on every milestone your partner would hold you accountable so you should not feel bad about doing the reciprocal.

</comment></comment><comment><USER4> I found that by telling people outright that your the CTO and sole developer let's you off the hook from having to actually try to sell them anything. Often they will relax and actually have a real discussion with you about your product.

Only salespeople should do a 'sales' pitch. Technical people are best off with an 'innocent' reach out to talk about the product to see if they might be interested in it (or just have constructive feedback). Tell them about your product, what you find most applicable to their business, then do what sales people don't often do.

Listen.

Then, at the very end, if they are interested, close with a prepared line about a demo or ask if you could go over pricing or something. A good line is "are you interested in being a customer of ours?". If they are interested figure out ahead of time a commitment they can make that proves it. Perhaps it's an opening order. Maybe it's a followup phone call to review a price sheet you're about to email them. Define what a successful call is before you make it as you don't want to be caught off guard and you want to have the appropriate commitment for your industry and product.

Some people just get so excited about an honest conversation with someone knowledgeable about their business concerns they'll be your customer because they believe in you first and your product second. But make sure they know there is a price to this insider information in the form of a commitment or a purchase order!

Another 'get out of jail card' is if they ask for something you aren't aware of, like can they have longer terms or pay in a lump sum always say 'I'd have to talk to a sales guy (or CEO) about that one'. Even if it's your final decision, it gives you time to figure out if it's a good deal for you despite our innate desire to say 'yes' to anything to close the sale.

</comment><comment><USER5> Easier? Well, just do it and get over the first few rejections. Things I kept in mind to make me feel better when I started in sales engineering are:- a) every "no" gets you closer to your next "yes" b) some customers are out there waiting for someone to come along and solve the problem you application solves c) Expect low conversion rates, e.g. of 100 calls you make less than 10 may accept a short meeting.

To make it better, a) prepare an elevator pitch to get you started b) make sure you have quality leads - e.g. if your customer is the marketing manager, don't pitch to HR or the secretary - make sure you have the right telephone numbers c) be relevant. d) You are less likely to get an audience when you get introduced through a "friend" so use social networking sites. LinkedIn was particularly useful

Good luck

</comment><comment><USER6> If possible, meet your prospects in person. Go to industry events, shows, etc. Have a 20 sec pitch NAILED. Practice it incessantly on friends and family-- anyone should be able to "get it" no matter how technical the product. Tailor it to their needs, not features. Make your goal to get an actual meeting with someone. Prepare a very short written "pitch" presentation. Make it look good.

Rinse and repeat. As others said, let rejection fuel--not discourage--you.

</comment><comment><USER7> I agree with most of the things that have been said on the thread so far. Especially listening. Here's a little more of classic salesman strategy and something to practice. Give them two choices that work for you.

Example: When they say now is not a good time. Instead of asking, "Would next week be a good time to discuss how we can help?" Ask, "What would be a better time to discuss how we can help? Wednesday or Friday?" This way, instead of a response of "No, I can't." You'll get an appointment.

I hated being a salesman but that was probably the one rule I learned and actually kept. Always be closing. (someone had to say it)

Another thing I think you should try is up-selling your current customers. Contact some customers that you've had interaction with (maybe exceptional customer service) and see if you can get them to sell one of their peers on your service and provide both of them a discount.

</comment><comment><USER8> > The CEO is away for two weeks during which time the marketing manager had a > telesales person come in for two days last week.

If they're not taking care of this sort of thing, what are they doing?

> I'd let them go if I could, but the long story is they are a friend of the > CEO who doesn't have the heart to just tell them what to do.

The CEO's job is to make sure that the company succeeds.

Perhaps you should fire both of them.</comment>


Making a Googol:1 Reduction with Lego Gears - <AUTHOR> https://www.youtube.com/watch?v=QwXK4e4uqXY <comment><AUTHOR> Sorry, I know this is very off topic but I found the video fascinating and thought other people would enjoy it too. Feel free to remove if this is too far from the point of HN.</comment>


Police arrest guy with headache because he said "exploding" over the phone - <AUTHOR> http://translate.google.com/translate?sl=sv&tl=en&js=n&prev=_t&hl=sv&ie=UTF-8&u=http%3A%2F%2Fwww.expressen.se%2Fgt%2Fsprangande-huvudvark-utloste-terroristlarmet%2F&act=url

<comment><AUTHOR> A poor guy with an "exploding headache" talked over the phone and the police thought he was a terrorist</comment>


5 Months After Switching to Colemak - <AUTHOR> https://nicolasgoles.com/blog/2013/09/5-months-in-colemak/ <comment><USER2> I've tried switching to Colemak three times, and I just can't do it. Here's why:

I can currently type 110-125 WPM on QWERTY, which I've projected would take upwards of a year to re-achieve on Colemak, which is a total no-brainer if I could reasonably expect positive long-term gains.

However, from what I've read (and heard from friends on Colemak), switching _back_ to QWERTY is painful, so my typing speed on anyone else's computer (which I realized, after trying to switch, I do fairly frequently) would go down to 30 at best.

The primary argument for Colemak is that it reduces finger travel distance from the home row. But my fingers don't naturally fall precisely in a line: my left middle finger naturally drifts between the space of E and D, my middle and ring finger on my right hand drift up closer to I and O.

Culturally, being on Colemak means the world is suddenly against you. It's like choosing to be a left-handed person in a right-handed world: vim keybindings don't make sense, applications and flash pages ignore your custom keyboard layout and switch you back to QWERTY, and every single keyboard|laptop|smartphone you buy for the rest of your life will require a certain amount of tweaking before it's maximally usable (think iPhone autocorrect).

Keyboard layout hacking in general, however, is fantastic. Here's a few tweaks I've accumulated that have immediate benefits for little of the above downsides:

1\. remap `caps lock` to `ESC`: goes without saying for vim, but extremely useful in other situations too (like playing starcraft and de-selecting units)

2\. remap 1234567890 to !@#$%^&*(): as a programmer, I use these symbols far more often than I use the numbers. Switching to shift to numbers with symbols as default makes all the sense in the world. It no longer takes finger gymnastics to surround something in () or negate a term with !.

3\. (optional) shift doubletap for caps lock: I missed caps lock after a while, so I brought it back with a double-tap of shift.

<comment><USER3> Anecdotally, Android 4.2 and up comes with a Colemak layout that works with all of the bells & whistles, including swiping and autocorrect.

<comment><USER4> Wow, so it does! (Along with the other more common keyboard layouts.) You have to dig under the "advanced" settings but it's there. Neat!

</comment></comment></comment><comment><USER5> I've been typing exclusively on Dvorak for 12 years, since I was about 16.

Does colemak offer any significant advantages over dvorak that would make it worthwhile attempting to switch?

<comment><USER6> It does, to a Qwerty typist, or to one who switches between for whatever reason. Quite a few keys in Colemak are preserved between it and Qwerty (like zxcv), making it both easier to learn and easier to jump back and forth.

Personally, when I play the occasional video game, I'll do so in Qwerty instead of redefining every key. For typing and programming (aka daily life), I use Colemak.

</comment></comment><comment><USER7> Switching does have its benefits but I'm afraid it'll be a pain to deal with it switching the vim keys around.

<comment><USER6> I never felt pained on switching layouts. If this makes any sense: learning the muscle memory for Colemak almost seems to be on a lower "level" than vim (to me), so I kept hitting 'i' and 'a' and so on without even noticing.

<comment><AUTHOR> Makes sense to me, I felt the exact same way.

I think that it's better to let the muscle memory of Colemak to develop and you will eventually get used to vim.

When I use vim I'm constantly thinking about words, like 'ci' (change in) 'ya' (yank around) etc.

So when you get your Colemak right vim is not a big hassle.

<comment><USER8> I do the same thing with Vim short cuts, think about their "meanings". I found it helped a lot!

I'm curious about h, j, k, and l. Same story?

<comment><USER9> When I switched to Dvorak, I adapted pretty quickly to vim. hjkl are effectively exploded across the keyboard, and I had to adjust to that, but adapting to the new locations for other commands was easier if I thought about the semantic meaning of the commands, and the keys themselves as abbreviations.

</comment></comment></comment></comment></comment><comment><USER10> Is there any quantified, credible (semi)scientific evidence that colemak or dvorak is actually faster/easier/better? I've seen lots of theoretical stuff, but mostly anecdote and/or poorly designed tests.

Thanks.

<comment><USER11> I'm interested in what you consider "theoretical stuff" or "poorly designed tests." If metrics like number of words possible from the home row alone or total finger travel given some body of text do not satisfy you, then I doubt anything will.

I will say one of the biggest misconceptions is that the Dvorak layout is for speed. I've known people who type 80+ WPM with _two fingers_ on QWERTY. You can be fast on _any_ layout, but Dvorak is way more comfortable. Once you can type faster than you can think of _what_ to type, it doesn't really matter.

<comment><USER10> Metrics like: % of users getting RSI per year adjusted for age and number of characters typed in a year on controlled hardware. Characters per minute of typists who've used both layouts for a year plus.

Words typeable from the home row is what I'd consider a theoretical metric. It should help with efficiency and health, but it is a leap of logic to say that it definitely will.

"It's more comfortable" is what I'd consider to be a valid anecdotal data point, but one that I fear has response bias as people who try dvorak and find it less comfortable silently switch back to qwerty.

Absent well designed tests, qwerty/dvorak/coleman is a religious argument.

</comment></comment></comment><comment> V-2 Most of the keyboard layouts - alternative to QWERTY - are optimized for English. (QWERTY itself is not optimized for any human language in existence). It would be very interesting to see how well they work for other languages. Or to try developing a "compromise" layout, optimized for two (or more) different langauges at once and see whether it is at all possible to gain a significant advantage over QWERTY in those several languages at once...

<comment><USER12> It's likely that Colemak would be at least somewhat better for any European language if only because all of the vowels are under the home row (except U, which is under QWERTY's "I").

</comment></comment><comment> V-2 I didn't find Colemak all that comfortable, but I experimented with carpalX and I found it very pleasant. Even if you are not curious about trying new keyboard layouts, the website is packed with very interesting theory and research: [http://mkweb.bcgsc.ca/carpalx/](http://mkweb.bcgsc.ca/carpalx/)

<comment> V-2 I see now that MrGando posted that link already, I hadn't read all the comments before making mine. I second that recommendation anyhow

</comment></comment><comment><USER13> I've been using Colemak cold turkey for 6 months now and I still can't type properly to save my life. I barely make a proper sentence these days. I never had this problem when I was trying to learn Dvorak. It seem the hand alteration makes it easier and you more accurate.

</comment><comment> V-2 Another interesting link: [http://www.andong.co.uk/dvorak/](http://www.andong.co.uk/dvorak/) (an online analysis tool you can use to compare the efficiency of different layouts - including Colemak)

</comment><comment><USER14> No mention of Carpalx?

[http://mkweb.bcgsc.ca/carpalx/?full_optimization](http://mkweb.bcgsc.ca/carpalx/?full_optimization)

If you're going to learn a new keyboard layout, why not make it the best?

<comment><USER15> I'm in the process of learning Colemak now. I'd love to use QGMLWB, but I liked that I was able to use Colemak on my Macbook, Windows box and Android devices without having to install anything extra. I figured that the few extra efficiency points I lost by sticking with Colemak would be offset by its comparatively broad availability.

</comment></comment><comment> V-2 One great feature of Colemak is the idea of mapping capslock (useless as it is) to backspace. Eg. it allows for quickly deleting last word with ctrl + capslock combo - one hand instead of both.

</comment><comment><USER16> Very well written article; can you gauge the convenience on switching to colemak instead of dvorak?

<comment><AUTHOR> Great question,

Dvorak is awesome, but the 'great' thing about Colemak is that the symbols and numbers are unchanged (in contrast of Dvorak). So basically the learning curve from QWERTY, should be shorter, and simpler.

Another personal thought, is that at least most of programming languages where made with QWERTY in mind, so the symbol usage ([], {}, ; etc) in programming languages is influenced by that too. A symptom of that is many foreign guys using the American QWERTY layout to code.

Cheers :D

</comment></comment><comment><USER17> Great article, ¿What are you using to measure your WPM in colemak?

<comment><AUTHOR> Hey there!

I'm basically using Amphetype... it's OSS written in Python.

You can feed it with text (like your favorite public domain novels in .txt, Sherlock Holmes is one of my favorites) and then it extracts lessons based on difficulty level.

Cheers & glad you liked it!

</comment></comment><comment><USER18> How long does it take to reach around 40 – 50 words per minute ?

<comment><USER6> In my experience it took around 1-2 months to become fully "fluent" in Colemak.

<comment><USER9> It took me about 3 weeks to acclimate to Dvorak, but I actually used a copy of Mavis Beacon to help with the transition (no joke.) I mean 80wpm. It felt both faster and more comfortable after that.</comment></comment></comment>


A Tour of a Whole Country That Has 'Transformed Itself for Cycling' - <AUTHOR> http://www.theatlanticcities.com/commute/2013/10/tour-whole-country-has-transformed-itself-cycling/7333/ <comment><USER2> I spent three weeks in the Netherlands with my family this summer. The cycling experience is truly magical. To add to some other comments made in this thread:

\-- Roel appears to have knowledge in this area, so I don't want to contradict him, but it does seem that the Dutch went at least part-way down the path towards a car-focused society and successfully pulled back. Read [http://www.roadswerenotbuiltforcars.com/netherlands/](http://www.roadswerenotbuiltforcars.com/netherlands/) for more history.

\-- The "bike path" in my town that we celebrate as amazing would be derided as complete crap in Holland. It's too narrow, not well paved, not lit at night, and it's mixed-use, which means you have to dodge pedestrians, roller bladers, dog walkers, etc. Bike paths in the Netherlands are BIKE ONLY. Not only are you separated from cars, but also from pedestrians. One of the worst crimes as a pedestrian (and a sure sign of a tourist) is to _stand in the bike lane_.

\-- Cycling is not just a fair weather activity. Nearly all bikes are equipped with dynamos to power lights, which are legally mandated for riding at night and are useful in the fall/winter fog and gloom. Yes, people ride in the rain, and even in the snow. For most people, biking is the one and only way to get around, so it's not an option, it's a requirement.

\-- It's hard to comprehend how thoroughly bikes are integrated into society. Every office has a bike parking shed with racks and locks. Apartment buildings have storage rooms in the basement, with special ramps built into the stairways so you can roll bikes down the hill. Train stations have _massive_ bike storage areas, and most stations have both bike rentals and also repair stations. For an extra 6 Euros, you can take your bike on the train with you to go anywhere in the country, and if you have a folding bike (very common), you can take it on the train for free.

\-- Cycling is integrated into daily life. No Lycra and clipless pedals -- you cycle in street clothes. Bikes are upright and comfortable. Nobody wears helmets, even kids (our kids went nuts because we made them wear them ...) People ride at a good clip, 10-12 mph, fast enough to get there, but not so fast that they get sweaty or out of breath. When you run across a friend or co-worker on the bike path, you'll typically pull up next to them and ride two-abreast (the paths are wide enough) so that you can talk and ride.

My favorite thing: you'll often see older couples riding side by side holding hands.

Man, I would love to see this take hold in the US, but it will take a major change not just in public opinion, but also in city planning and infrastructure investment.

<comment><USER3> The lycra thing is important. When you've only got keep fitters in lycra riding bikes, it seems to de-normalise it for everyone else.

</comment></comment><comment><USER4> Actually we haven't transformed, we've never accomodated cars much at all. A big difference.

<comment><USER5> That is not quite true. In some cases, the idea of building for cars was abandoned before it got fully executed, but that didn't always happen.

Examples:

In Amsterdam, the Vijzelgracht was turned into a highway into the centre of town (it's hard to imagine, but about half of Amsterdam's waterways have been filled in to make room for traffic (much of this predates car traffic). Even as late as the '50s, there was a plan to fill many canals to make room for parking garages).

Utrecht had plans to fill its outer moat to make room for a ring road. Part of the Catharijnesingel was filled in 1970 or thereabouts to build 'the shortest highway in the Netherlands', but afterwards, the plan was luckily abandoned (the Catharijnesingel will be dug again in a few years)

Residential neighborhoods built in the '60s were designed first for cars ([http://bicycledutch.wordpress.com/2013/08/08/making-a-1960s-...](http://bicycledutch.wordpress.com/2013/08/08/making-a-1960s-street- grid-fit-for-the-21st-century/))

Rotterdam, after the bombing in 1940, rebuilt its city plan to accommodate for cars.

<comment><USER4> Yes I know, of course, and obviously there are ways for cars to get to places, but the mere fact that you can name specific counterexamples confirms my point that in general most places were not designed around wide spread car ownership and -use, and car use was retrofitted where needed.

Not to be an asshole about it but I'm a Dutch planning professional, I've lectured and published about the effects of transport infrastructure on urban planning.

<comment><USER2> Roel, since you're an expert -- can you help shed light on the history? From what I've read, other demographically and geographically similar countries in Europe have much lower rates of cycling. These other countries were undoubtably also not designed for cars, they were designed for horses and pedestrians (as I can attest from having driven in Europe). The source materials that I've read suggest that there was a major inflection point in the 1970's where bike transport share stopped declining and started increasing, and also that the linear miles of bike path have increased dramatically (3x?) in the past 20 years.

<comment><USER5> That's from [http://bicycledutch.wordpress.com](http://bicycledutch.wordpress.com) ([http://bicycledutch.wordpress.com/index-by- theme](http://bicycledutch.wordpress.com/index-by-theme) is an excellent entry point, too)

My layman's view is that both sides are right. Most city centers date from before 1900, so they weren't designed for cars (Amsterdam wasn't even designed for carriages). Up to ~end of World War two~, cars weren't common enough to build 'cars first; all others enter at your own risk' neighborhoods (for example, the first river car tunnel, the Maastunnel in Rotterdam ([http://en.wikipedia.org/wiki/Maastunnel](http://en.wikipedia.org/wiki/Maastunnel)), built in 1937-1942 has separate tubes for cyclists and pedestrians. Traffic jams formed at its escalators in the fifties)

After World War Two, there was a period when the USA seemed to show the future. That led to ideas that cities such as LA were the future of city building. Some ideas/attempts to reshape cities were formed/made, but those were abandoned or at least seriously adjusted really soon. For example, the Bijlmer (1968; [http://en.wikipedia.org/wiki/Bijlmer](http://en.wikipedia.org/wiki/Bijlmer)) was designed as a paradise for cars, but also as one for pedestrians. In the same period, Ommoord also is very car friendly. Yet, its neighborhoods also have the typical dead end streets that make streets safer for kids to play in, and it has a metro connection to the center of Rotterdam.

Almere (1978; [http://en.wikipedia.org/wiki/Almere](http://en.wikipedia.org/wiki/Almere)) already shows a trend away from 'cars first'. Later, we got Houten ([http://en.wikipedia.org/wiki/Houten](http://en.wikipedia.org/wiki/Houten))

So, yes, there was a trend towards 'cars first', and there was a turn, but that turn was made very early. That made the turn relatively easy. Changing LA into a 'cars are guests' city would be a challenge on a different scale.

</comment></comment></comment></comment></comment><comment><USER6> The Netherlands are at the forefront of thinking for a lot of different social/environmental issues and everybody recognizes that in Europe, but the funny thing is that the Dutch I've talked to have a hard time recognizing that themselves.

<comment><USER7> The Dutch are relaxed about sex and drugs, but they are actually a very conservative people with deep and cherished traditions. It's only in America that "conservative" implies prudish, everywhere else it just means that people want to go on living the way they always have.

</comment></comment><comment><USER8> Dallas, where I live now, is about as far away from this as one can imagine.

For that matter, so is the European country I'm originally from (Malta). My brother is an avid cyclist there and gets sneered at by local-redneck- equivalent motorists pretty much everywhere he goes.

<comment><USER9> I used to do the wind/rain/snow type commuting, and I probably should again, but your brother's experience in Malta is similar to mine in the US. You're definitely doing something that most people regard as a nuisance. I've heard of other cities where it's not like that, but I've just never ridden in them. I live in Atlanta now, and it's almost suicidal riding a bike. Obs my sample size of cities is small, but hey, there it is for what it's worth.

The video also made me think, "Man, I'd love to cycle in the places, but I'd have to seriously rearrange my US cycling survival skills and attitude toward a less hostile environment."

</comment></comment><comment><USER10> I was there in June, and I have to say that riding around on a bike there really changed my perspective. Riding there was a joy. The "Share the Road" programs here in Utah are a joke.

The bike lanes there were amazing. Most roads I saw there were dark brick, the "lines" were usually white bricks, and the bike lanes were red brick and were wide where they weren't actually separate altogether.

The other best part? There were no angry SUV drivers swerving around you at 60 MPH. People were courteous.

</comment><comment><USER11> What do people do when it rains or snows? Do people walk instead, take mass transit, or drive?

I think the reality of what people are arguing for is for people to live more closely together. That makes biking, mass transit, and even walking more viable.

Some people like it, some don't. Part is what you are used to. People coming from rural areas think that the Bay Area is crowded but the East Coast is more crowded, parts of Europe are more crowded still, and then parts of Asia are more crowded still.

<comment><USER12> Put on some fenders, rain pants, a rain coat, and ride! Or take transit.

Living closer together is great, but cycling infrastructure matters too to get people onto bikes.

<comment><USER13> That's a new difference between US and UK English for me - "fenders" here are things that are used to stop boats/ships bumping into things, across here we call them "mudguards".

Having said that, I know some people who could benefit from fenders (UK) on their bikes...

</comment></comment></comment><comment><USER3> It is ace, but I wonder if you'd get cycling as mainstream anywhere else. That country is almost uniquely and famously flat.

<comment><USER14> _sigh_

Every time people post about great cycling cities, the immediate reaction is a pile of reasons why it would _never_ work here because I live in a place that's completely different and special.

There are challenges in every task. Either you overcome them or you wimp out. These are not unsolved problems. Montreal literally means Mount Royal - it's a city built around a mountain. They manage to have great cycling infrastructure.

Even worse is the moaning about winter cyclists - almost every one of the great cycling cities have bitter winters.

You're always going to have an excuse _not_ to do something.

<comment><USER3> I'm not looking for an excuse not to cycle, I'm a pretty fit cyclist and spend at least 10 hours a week on a bike. I'm saying that holding this up as an example that others can follow isn't ideal as they have a big natural advantage over practically anywhere else. Unless you can overcome the issues of terrain and climate, it's just not going to become mainstream like it has there. Look at the bikes they're riding, big heavy comfortable clunkers. Most people simply couldn't get those up the hills surrounding my town, they'd have to push.

<comment><USER15> I think the ultimate solution long-term are assisted electric bicycles. They aren't fully electric, you always have to pedal, but when you're going up hill you can enable the assistance to help you go up the hill faster.

Think of it like gym bands to aid you doing pull ups.

If the bike could charge itself through pedaling that would be a double plus.

A lot of people don't cycle because it's slow, and they may not care about the exercise benefits. If commuting they don't want to wear special attire or be sweaty when they show up to work. However, they would probably be cool with an assisted electric bicycle if they could get up hills faster without breaking a sweat.

<comment><USER3> Perhaps, but it's a tough sell to get someone to ride a £2k electric bike instead of buying a car.

</comment></comment></comment></comment></comment><comment><USER16> Almost seems utopic. Rather than look for excuses as to why it won't work in the U.S., what would it take (years, dollars, planning, infrastructure) to convert a reasonably sized (large, but not top 10) American city built for cars (say Austin, Indianapolis, Columbus, Denver), into a cycling focused city?

</comment><comment><USER17> Is there car access to the houses? for emergency services for example?

<comment><USER18> Yes. In the Netherlands for example, bi-directional bike paths have to be 4 meters wide, which is sufficient for emergency vehicles.

</comment></comment><comment><USER19> This is pretty, pretty awesome!

</comment><comment><USER20> That would work really well here in Texas. My job takes me nearly an hour to reach by car. You can basically fit all of Europe in Texas with a little rearrangement. Scale matters.

<comment><USER21> Even places of similar scale and population density in the U.S. fare poorly. New Jersey is half the size of The Netherlands, with a similar population density, but is very car-oriented anyway.

<comment><USER14> Shh, you're interfering with their wimpy excuses that they use to conceal the fact that they just really don't like cycling.</comment></comment></comment>