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!!
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.
There are no benchmarks showing JVM-based programs using less memory than most any other roughly equivalent programs on different runtimes. The JVM's reputation as a pig also comes from people's personal experiences -- even a simple email proxy (davmail) is easily at 100mb resident, over 1gb virtual.
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 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.
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.
Sounds like someone isn't testing their code. "one would need to write tests to catch in ruby". You're damn right you need to write tests to catch problems in Ruby, as you should probably be doing anyways - in any language - in which case confidence gained from your test suite is almost entirely redundant to the confidence gained from successful compilation in a static language.
But if you're not testing your code, then the compiler is indeed a great dose of confidence.
I do, though, firmly agree with this:
"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."
Ultimately things do depend quite a bit on the developer resources you have.
I also love Scala, but how do you do your web frontend? Using Lift? Play Framework? I'm currently developing a side project with Lift and lets say I like the Scala-part of Lift.... The web part doesn't feel nice (also I don't like the last decisions made by the Lift Team). Currently I'm looking into RoR and I like what I see.
So, what I would love to see is a Web Framework similar to RoR written in Scala ...
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.
Because you don't end up breaking code in trivial ways, eg if you have a method that takes a string and change it to take an int it's fairly easy in a statically typed language to figure out all the places you broke the code.
Large teams should be hunted down and broken into smaller teams, it's a stupid idea to have such a large team anyway.
The biggest problems in Java are not static typing (although inferred typing is much better). They are the lack of first class constructors, functions, unsigned types, operator definition and overloading and closures. The one actual feature Java has that no one else has is ironically one that is also one of the worst things about Java: checked exceptions.
When java lets me write something like:
let (|>) x y = y x
is the day I'll consider using it again, btw the above code is the pipe operator which lets you do things like this.
Ruby has a little different mentality (duck typing), for example both of the following work:
"10".to_i #=> 10
10.to_i #=> 10
I can see how dynamic typing, lack of interfaces, etc. can seem to cause a bunch of confusing to someone who's used to static typing, but in my experience lack of code readability is far more troublesome.
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?
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.
First of all, Android is much harder to develop for than the iPhone.
As someone who's published apps on both platforms, I'll disagree with that. For me the occasional extra effort it takes to support multiple resolutions and OS versions is more than made up for by being able to use a semi-modern language. (Preemptive response: Yes, I know Objective-C well, and non-enterprisey Java beats it hands down).
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.
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.
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.
This is the principle problem: "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."
No, they can't be easily learned by people fresh out of college. I'm 31 and have been doing this stuff since I was a teenager. It takes years of hard won experience to really know the ins and outs all the various facets of frontend engineering. This particular sub-field isn't one programming language. It's knowing what html, css, and javascript do across at least 11 different browser platforms. It's knowing what kinds of interfaces work for different devices. It's knowing javascript as a true language and not a copy/paste thing. It's being able to know know to translate a 2 dimensional design into the correct underlying structure, in real-time.
So that's just my answer to your "any good programmer" statement. That just means you don't really know what you actually need to be hiring for.
I agree 100% about being about to get along with people. But problem solving is directly related to the field you're in. Ask a programmer to be a heart surgeon, I'm sure any smart programmer can easily learn those skills. The intuition will be there if the interview is about what the person should know.
Suppose your database queries are running extremely long and slow because you're a startup and you and your cofounder are generalists. Your company starts getting traction and now that database is becoming a problem. You're a frontend dev that knows python, and your partner is more of a biz guy that does some coding. Now you both identify that you need someone who really knows how to scale databases. Do you ask candidates random CS questions to see if they have some ill-defined "intuition", or do you find out if they know how to scale databases?
It's no different for frontend engineers.
I also agree about the coding part. But you have to do it in the context of the requirements. For a frontend, look at their previous work. Identify some area of your own product that you think can be improved, or was improved. Have the frontend candidate work through how they would improve the js/HTML/CSS etc. This should involve coding, and the person interviewing should have at least enough base knowledge themselves to know if the candidate is worth their salt or not.
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.
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.
w/ a little 3rd party app called sizeup... Not ideal, but a workable solution that keeps me productive on the platform.
One of the nice things about OS X for sure is that many of the major pain points in the raw OS can be resolved with 3rd party applications. The community, tired of dealing with these minor unaddressed annoyances, has usually resolved most of these issues on their own -- there are 2 or 3 apps of some kind for most of the major OS rough spots.
One of the bad things about OS X for sure is that many of the major pain points in the raw OS have to be resolved with 3rd party applications. The community, tired of dealing with these minor unaddressed annoyances, usually has to resolve most of these issues on their own -- there are 2 or 3 apps of some kind for most of the major OS rough spots.
