bballant's comments

I can only speak from my American experience, working as a software engineer for ~12 years in NYC. I am 33 years old--I never feel too old for this. My non-tech co-workers and engineering peers respect me very much. I love them back. We do awesome shit together. I solve hard problems and make beautiful software. I work hella hard but get paid well and I love every second of it. I am so glad I do what I do and when I read about people not being respected and not loving their work, I can only suggest that you do something else or do it somewhere else. The world is your oyster. Life is short. Carpe diem!!

My main point is that the JVM manages memory better than ruby. Its dead easy to benchmark it yourself by writing a pair of tiny programs. As I said, the JVM will use up all the memory it can. You can probably tweak davmail's runtime flags to use less. There is typically a CPU tradeoff if you cut back on the memory a program can use, and usually a happy middle-ground.

In my personal experience, I've re-written a few ruby utils in Java for an order of magnitude speed improvement. I've seen a ruby site crater under load because of memory issues that its java replacement easily manages (which is sorta what the OP is about). The JVM is especially well suited for handling "stateless" http requests because it's ability to quickly create and destroy small objects.

I've heard good things about Play, but we've chosen to go with Spring MVC because we didn't need the full stack -- we have a lot of existing Java ORM-ish code and a bunch of existing JSP functionality which we wanted to re-use. JSP is actually our biggest pain point at the moment (aside from generally suckiness, it doesn't work with scala collections), so we're looking into using SSP via Scalate, but we've yet to make that move.

Aside from JSP, we're really happy w/ Spring MVC. We've managed to avoid the crazy amounts of XML that Spring is known for in favor of its more modern annotation-based way of doing things.

On my team such remarks cost a dollar. The JVM generally does very well in terms of memory use compared to many languages. It's easy to test: write an a small program in both languages that creates boatloads of objects and then watch the memory.

The JVM will use up all the memory it can (the amt is configurable with some runtime flags) before the GC kicks in and frees up space. It uses a couple of buckets for different types of objects, and can easily clean small short-lived objects with a bit of a CPU hit, but without affecting the performance of the application. The upshot is you'll see Java's mem use slowly creep up, you'll see a small spike in CPU, then the mem use will drop. If you don't see this, it means the code is poorly written and its keeping around object references.

Ruby's GC is much less efficient. It has no concept of memory buckets like the JVM and will effectively stop execution and traverse every object in the heap twice, marking and then freeing up space.

Early versions of Java (pre 5) had some substantial problems with memory management, but it's been very performant for quite some time and easily out-paces ruby.

I've worked in ruby, python, java, and most recently, scala -- on both small and large projects. Tangled hairballs and hidden runtime exceptions can happen anywhere. I've just seen less of it with Java. I think this is partly because the compiler catches things that one would need to write tests to catch in ruby. For me the compiler is another layer of defense keeping bad code out of production.

Another advantage of statically typed OOP code for big teams is it allows a verbose yet formal way to define interfaces as a team, and then break up the work into smaller chunks. The formality can certainly slow an individual programmer down, but in a big team I've found it makes breaking up the work easier.

I wouldn't argue against the notion that ruby's expressiveness and use of functional paradigms might make up for it's lack of static typing, and ruby in the hands of a great programmer is pure pleasure, but most teams don't have just great programmers.

Finally, I absolutely love Scala and I think it's worth mentioning in any discussion of ruby and java. It, sorta, bridges the gap between the two languages and I'd recommend it as a good choice for a team of any size.

I also thought that was a weird comment. But In my experience a big team benefits from a compiled, statically typed language like Java (better yet, Scala). Perhaps that's what the author meant.

To use your analogy, I don't think Brad is saying to wear shorts outside during a blizzard. He's saying that if it's a sunny day, you shouldn't wear earmuffs just cause it's unseasonably warm and may or may not snow tomorrow ;-).

edit: Perplexed at the down-votes. Is it the smiley face?

Well maybe it was my mistake to generalize (and say "much"). And by develop, I meant develop, test, support, and maintain over a wide range of phones and capabilities. These issues may be more or less pronounced based on what the app does and the size of the user base.

Mr. Wilson's numbers leave out some key realities about Android as it stands as a smartphone platform.

First of all, Android is much harder to develop for than the iPhone. This is because the Android ecosystem is so dispersed. There are many more phones, many more os versions, and many more carriers to support. For a resource-strapped application team, iOS is a simpler choice and a quicker win.

Also, there is, what I would say, less of an app culture amongst Android users than iPhone users. I think this because I develop and work on a team that develops native apps for both platforms as well as a cross platform mobile web app. Our iPhone app does about 50 times better (in each category -- downloads, usage, and revenue) than our Android app without exaggeration. Part of this, to be honest, is our iPhone app is better, and that is partly because of my first point. Even in our mobile web app, though, we see about twice as many iPhone users.

Now, I'm glossing over a whole slew of details here, but the net takeaway for me is, if I were a start-up looking to make a dent in the smartphone market, I'd start with iPhone.

I agree. Cable news is horrendous. On the other hand, the photos of the tsunami devestation published by the Boston Globe alone tell a story that is deeper and richer than anything else I've seen or read on the matter.

It makes sense that the post on women founders wouldn't be similarly flagged if the difference is related to comfort level.

Comfort comes from trust and exposure, among other things, and I'd say that most white men have more relationships with women than with people of color.

The legacy and history of the feminist struggle and the civil rights struggle, although related, are vastly different. I would be careful equating the two under any circumstances.

You're right, a lot of things take years of experience to learn, which is why solving a difficult problem is not the only way I evaluate a candidate. I definitely look at their previous experiences.

But someone who is so specialized that they can't solve problems outside their area of expertise would worry me. I don't expect a programmer to learn heart surgery, but if you've been doing C++ for years, I'd expect you to pick up Javascript in a month or two.

Now, in terms of "knowing who we actually need to be hiring for," I know exactly. I want someone who can do their thing well but shift and learn as technologies change and as the business grows, and potentially do things they've never done before well. It's integral to have people like this in any start-up (any of USV's portfolio companies) or a fast-growing company like FB.

The trick for me is, how do I evaluate this?

Lastly, here's a real-life example that hope illustrates what I'm looking for. At an old job we had built a web app that monitored an embedded device via ajax polling. The client liked the solution, but found it impractical to always have a browser window open. None of the engineering team had any experience w/ XMPP, but our research and discussions with the client led to an XMPP-based solution. We didn't have time or money to hire an XMPP specialist and we didn't want to lose the client. We had to learn and adjust.

I've already brought my partner on that project aboard my new company. But every time I step into an interview, I am wondering how I can find someone like her.

I've recently been on the other side, trying to interview and hire people. It's difficult.

My primary concerns are: Is the candidate going to be competent and capable of solving difficult problems and contributing to the team? Are they going to work efficiently and be productive? And perhaps most importantly, are they going to be enjoyable to work with?

It is less important to me that a candidate has a particular skill with a particular technology because those things can be learned easily by good programmers. I'm looking for more of an intuition, problem solving ability, and the ability to cleanly translate the solution into code.

To that end, I try to get candidates to code with me, usually by asking a challenging problem and then sitting down next to him or her to work it out. The whole process has been more difficult than I anticipated though. I find many candidates unwilling or unable to write code in an interview.

I'd love to hear some suggestions on hiring tactics and questions to help me better find my next co-worker.

It depends on what you do, but if you're a freelancer, finding your own clients, managing your own projects, and paying for your own social security and benefits, then 100/hr is fair for a good programmer in NYC. It is comparable to 100K full-time, full-benefit work, which is at around what one of USV's NYC portfolio companies will offer you if you're a good programmer w/ 6 years experience.

If you feel you are underpaid, then apply for one of those positions on USV's portfolio jobs page. All of their NYC companies are awesome.

i would prefer to always use Linux, but my company gives all the engineers Macs, so that's what I now use. I miss Linux deeply, but maintaining two dev environments, not to mention context switching wrt key commands, drove me to the brink.

On the positive side, OSX is still unix. MacVim rules. OSX fixes some of the Linux issues that drove me mad (like power mgmt & plugging in an external monitor). And I've gotten around the screen resize issue mentioned here w/ a little 3rd party app called sizeup... Not ideal, but a workable solution that keeps me productive on the platform.

Re: good vs. bad clients -- I commented on part 1, basically saying that being friendly helps me find work, but it also means my clients are friendly/casual which can lead to time wastage. It's like the opposite of the super-type-a micromanager client.

When I feel a client is wasting my time, I try to gently remind them that, for a freelancer, time is money. Also, as Ryan suggested, having two clients/projects going on at once is the best scenario.

Thanks for the tips. Perhaps I could raise my rates, but I think I lose money more by a) not properly estimating timelines and b) becoming idle while waiting for client feedback/help/etc. As I said, I'm only 6 mo. into it, so I'm still learning how to better handle these things. I'm finding that when I go into a client's office to code, they are more inclined to provide me the resources they need and I feel ok billing them for the hours, even if they've left me idly waiting for their input.

I've only been freelancing for 6 mo. but I have about 10 years of experience as a software developer in the same market. Right now I'm totally saturated with work and it's come entirely through contacts -- I haven't talked to one recruiter or answered a single ad. So far it's been a blast, but not quite as lucrative (yet) as working full-time for a salary.

In my opinion, the two major reasons I've had success finding good work are:

1. I'm specializing in a popular niche and, backed by my experience, I can claim I'm an expert. This also means I can charge high rates.

2. I've always been a nice person to the people I've worked with and have remained friendly with previous bosses and co-workers. I've developed a reputation as a capable programmer who's easy to get along/work with. (Conan O'Brien, last spring, attributed his success to being passionate about what he does and being a nice guy. I think this is really true.)

I'm still struggling with a couple of things. I basically always get my time estimates way wrong. I have trouble focusing and switching contexts from wheeler-dealer (finding jobs and managing contacts) to h-core coder to my personal life. To that end, I tend to work from my clients' offices quite a bit and I'm considering renting a cube somewhere. Finally, being a nice guy has it's downsides--I almost never get paid promptly and clients often times don't provide as much support as quickly as I need (like when I need to work w/ a client API and I need documentation/time with their engineers to move my work forward).

Another quick comment about doctors and pay (because I had this conversation the other day w/ a young doctor). Doctors are incentivized to prescribe costly tests. They get paid more w/ every test/procedure, and tests also serve to cover their asses. Patients also, often, demand the testing.

Those who are against tort reform often use some statistics showing that tort fees only account for a tiny percentage of health costs, but they miss a deeper relationship between the fear of being sued (most doctors get sued at some point in their career) and the defensive, expensive, care doctors give.

For point # 3, it's actually even worse than that. These days, the best doctors also do a fellowship after residency. It's slightly less ridiculous than a residency, but it's another 2-4 years of being underpaid tacked on to the previous 10.

My buddy, who is nearly finished with his cardiology fellowship, is nearly 300k in debt at this point. On the other hand, that dude has already saved some lives and I'd trust him w/ mine in a <dorky pun>heartbeat</dorky pun>.