Hacker News Reader

Comment by auggierose | Hacker News Reader

I think you don't get the point. Learning a new language after you programmed for 5 years in a variety of paradigms like assembler, object-oriented, purely functional, will take you between a couple of hours and a week. But if you have NOT had those 5 years of varied programming experience, then the new language is not your problem. Learning the concepts is, and that will take time.

View on HN

I think you don't get my point: I expect a domain expert to be a domain expert, but I don't expect a trainee to know anything and I'll structure my interview accordingly. I'll ask the domain expert questions about his domain. But I don't expect a domain expert to know the programming language that we work with just because he's a domain expert. And seriously, I'll prefer the eager-to-learn math graduate with little coding experience over the bored cs graduate that knows the java reference doc by heart and now thinks he knows how to build stuff. In any case coding examples in your interview will show you little beyond the fact that somebody memorized the docs.

The actual pain point I read from the article is a different one: There's a mismatch between hiring process and expectations. If I need a lead programmer for the iOS project that I'm about to start next week then I can't hire anyone that doesn't know Objective C and then I absolutely need to structure my interview accordingly. But if I have a couple of weeks more I'll happily teach him. And if I'm hiring somewhat smart I try to avoid those "we need someone urgently" situations.

I also think that there might be a mismatch between hiring process and expectations. When you say "But if I have a couple of weeks more" then you obviously underestimate the time it takes to learn if we are actually talking about somebody without much programming experience. Try "if I have a couple of years more".

See, there's so much more that you need to learn when you start on a project in a company. There's the framework they use, their libraries, the requirements for the project, the problem domain, the people you work with, the process they use, ... just to list the few that come to the top my head. Especially learning the problem domain can be very hard and challenging to programmers with little or no knowledge of the field. It can easily take a couple of month, if not years to become reasonably proficient.

So yes, "a couple of weeks" is certainly not enough to transform a graduate into a project lead for bespoke iOS project, but it could easily be enough to transform a decent java programmer with solid project lead experience. Transforming a crack Objective C Programmer with no lead experience can take easily as much time, if not more.

My gist is that programming knowledge will only get you so far and depending on what position you're hiring for other experience combined with the ability and willingness to learn may be much more interesting. And whatever I do, I tend to hire for that trait since that allows people to pick up other abilities when required.

I think you vastly underestimate the time it takes to learn these sorts of things. Sure, you can teach someone to write a simple, passable iOS app that does a few basic things in a couple weeks. But they're still going to be a raw-novice iOS developer. Maybe the app you need them to build is super simple, but if not, you're doing yourself and your company a disservice by not hiring someone who's done iOS before.

I'm speaking from experience here: I learned iOS (even after having previous MacOS X desktop devel experience) on the job, when a friend asked me to write an iOS app for her startup. I learned quickly, but made a lot of mistakes in how I structured the app that came back to bite me months later. If I'd had the time to start over from scratch, I would have done things quite differently and the whole thing would have been a lot easier.

And I was slow. Every new framework I had to learn slowed me down and added days to implementing the part of the app that needed it. A seasoned iOS developer wouldn't have run into problems like that.

I think you vastly underestimate the value of "other knowledge" for any kind of complex undertaking. Unless you get a domain expert who happens to be a rock star programmer and a ninja architect and top-notch devops, you'll have to compromise somewhere. Take an iOS game: Depending on the game it can be vastly more value to have knowledge of game programming and game AI than having knowledge about iOS frameworks. If there's a team on the project I'd even go as far and say that I would pick the domain expert over the framework expert as team lead, given that all other capabilities were on par.

Sure, there are always compromises. I wasn't claiming otherwise. I was merely pointing out that ramping up on a particular platform is nowhere near as easy as the parent suggests.

Games are a bit of a special breed, though, and there are several game engines out there that hide the platform pretty well. I draw a bit of a distinction between "building and iOS app" and "building an OpenGL app that runs on iOS". The latter is much easier if you lack iOS experience but have the required OpenGL skills.

Learning a new language is fairly easy. Learning the language's standard library to the point that you don't have to look at the reference docs every 30 seconds takes a bit more time.

The author clearly showcases how this is not true in his (and probably others') case. Anonymous functions, function pointers, etc. are not language-specific features, but rather something you learn when learning to program.

I think the point of the article is that being smart at puzzles is not enough. It may not matter whether you have 3 or 10 years of programming experience, but if you have 20 years of puzzle solving experience with only 6 months of (real-life) programmering experience you have a lot of non-trivial learning left to do.

Being in a startup setting where everyone (usually) is expected to be a bit of jack-of-all-trades, I would argue that having programming experience trumphs being smart, at least for the first period. You may be the master of finding smart algorithms to design your application, but if you can't build the first CRUD website it does you little good.

So true. I've been a professional developer for 15 years and I've worked with several languages (C++/Java/PHP/Python/Perl/C#/Ruby/JS/Groovy), but man, does this whole "functional" stuff is being hard to get a hold of. Specially Scala, for me, is very hard to understand the syntax, even after a year of working with Play. The most frustrating part is understanding the flow of the data in chained calls like in map-reduce.

Reply on news.ycombinator.com