Comment by djtriptych | Hacker News Reader

Comment by djtriptych | Hacker News Reader

tl;dr - Ship something, THEN look for a job.

In the real world, your age is a handicap, no matter what people say. Look for differentiators. A great one is the ability to point to something reasonably complicated that you built from scratch and shipped. Very few programmers can do that, and the ones that can are a class above in the eyes of many employers.

One thing you have going for you is actual life experience that a fresh college grad can't possibly have. I'd try to figure out a way to emphasize that in the interview process. Certainly it's a better strategy than trying to hide your age.

I earnestly recommend going WAY, WAY past whatever you're learning in class, and becoming a subject matter expert in whatever you like working on most. If it's Java, read the entire JVM spec, for instance. Many employers will test primarily for raw problem-solving ability and general CS knowledge in interviews, but I find that intimate, detailed knowledge of one or two areas can also be a powerful differentiator.

Of course, make sure you can actually code. The only way to do that is to code a lot. Remember it's possible to know a lot, and even be able to explain a lot of technological concepts, and still not be able to code worth a damn. Don't be that guy. If you ship something substantial, you're going to have no choice but to do a good deal of coding, and enough server admin / networking / etc work to get an idea of how everything fits together, and a taste of the sorts of compromises one makes in actually getting something out the door.

I suffer from a different, though similar, disadvantage in the interview process: being black (and dressing, acting, talking like it unabashedly). I've learned to live with reduced initial expectations over the course of my educational and professional career (not interested in a debate on this; I have dozens of unambiguous life experiences to confirm). The upside is that people are primed to be surprised by what you can do. Try to view that as an advantage.

Knowing the entire JVM spec is frequently less useful than being able to code a for loop whose contents do some domain specific thing that a 22 year old ninjedi will, with diligent study, understand in ten more years.

You mean, be able to come up with in ten years, or understand in ten years?

The former is good. But in case of the latter, I wouldn't want to touch your code with a ten foot pole. (Even complicated Haskell type trickery, or, say, mathematical optimization algorithms shouldn't take longer than a few weeks to explain.)

"domain specific" means something like, your code implements the thing you spent the last 10 years becoming an expert on, which you hopefully understand to such a degree that expert coding will be no help in trying to replicate it.

Yes. That's why I mentioned not only type trickery but the one domain specific example where I can claim to be an expert in (mathematical optimization).

I guess, the original ten years was hyperbole?

I think you're missing the point completely. Patrick's comment wasn't about a specific for loop and how hard it is to understand. Knowing what types of problems people have and how to write code to solve them is much harder than learning the JVM spec and much more valuable.

How long did it take you to become an expert in mathematical optimization, for example? I doubt very much that that's something you picked up in a few weeks.

I know that solving problems people have is hard, and worthwhile. It takes a long time of concentrated effort to get good at it for specific domains. That includes picking the right problems, and then either picking the right solutions or coming up with them in the first place.

But here's where my contention lies: Making those choices is hard. But you should be able to explain the logic behind them (or how you came up with a solution) in a few weeks.

To give an analogy: The first task is like acquiring a map of a territory. That needs painstaking surveying of the whole area. The second is describing a path you took through that territory. You needed the whole map to choose the right path, but describing the path should be faster than acquiring (or describing) the whole map.

Don't read the entire VM spec. This thinking of knowing something inside out helps you how to use it is bunk. You don't have to know the how the rules of chess came into being to play chess.

Or you could go that way, and do it as the parent says, and end up like me, somewhat dazed and confused a decade later.

Just because you invented radio does not mean the programming you put on it is the best. Realize that programming(computer) is a skill that most can achieve only through rigorous grind.

There, I saved a few years of frustration to you. Knowledge is power. Amen.

I have to disagree strongly here. I do believe understanding something inside and out help you use it, and more importantly helps you invent new solutions, but I realize mine may be a minority opinion.

Then again, this is HACKER news and what I've described is pretty damn close to the core hacker ethic.

The two languages I call myself an expert at are Python and Javascript, I can say confidently that I wouldn't call myself an expert at the former without a damn good understanding of the entire language, data model, standard lib, and standard CPython implemention, nor the other without at least a decent grasp of the ECMA-262 spec, the knowledge of which comes into play more often than one who hasn't read it might guess.

Your chess analogy doesn't really make any sense, sorry. A better one is to understand how a car is built before you drive it. I think that might just make for better drivers.

Hopefully, the OP and those reading the discussion take away that you shouldn't stop at proficiency. Strive to know your stuff down to the bits. Don't become complacent; as I've read elsewhere here, Feel the incline, and walk uphill.

> A better one is to understand how a car is built before you drive it.

Yep, I agree. That is a better analogy. If you know how to build a car, you will be an expert at building cars, not driving them. I mean, how many of the better racing drivers are builders themselves?

If you always have to think about the how, the expression and the art suffers. Always. Human brain does not think in abstract logic, no matter how much you convince yourselves otherwise(may be except for some). It is always better at thinking intuitively.

Now, if you disagree, I would encourage you to keep posting. I like to discuss this. Not just to challenge you, but would like to know about the mistakes in my thinking.

>Knowledge is power.

I do not think that phrase means what you think it means, given the rest of your post.

:) Good catch. Meta-knowledge is power.

Great points! It comes down to how deep you want to go, too. Programmers are still finding jobs, and it seems like our market is better than most hiring markets, at least in the United States. So if you just want a job programming: they're out there.

If you want to be a real hacker, though, (Why else would you be here?) you need to be a little crazy, and obsess over the deep details of your specialty.

Reply on news.ycombinator.com