Hacker News new | ask | show | jobs
by weland 3895 days ago
Here's a little story that I tell to anyone who asks me this question. It's how I got it answered for me a long time ago.

> How can I tell if I have programming aptitude?

I have a friend who's a painter. She's a visual artist with a fair deal of success; she can actually live out of her art (and by that I mean she actually sells her paintings for a living, she doesn't just design logos to buy her a little time for her real occupation on Friday evenings).

We were gathered at her house for a gig and waiting for the guitarist to show up (as usual), and while we were each rehearsing various bits and pieces, she sat on an armchair across from me and casually picked up a piece she had almost finished, and began applying some finishing touches. I'd never seen her painting before, so after I picked up my jaw from the floor, I passingly remarked that I'm a little envious on anyone who has a talent for drawing.

(Background: my depth perception is basically shit because of a limp eye. The only reasonable drawings I ever made where in Geometry classes).

Her reply was along the lines of dude, look, the ones who have a talent for this are the likes of Picasso and el Greco. Everyone else, even those of us who paint a lot better than anyone else you can find on the street, just practiced a lot.

She then proceeded to show me a couple of things she had drawn when she was a kid, long before she decided she wanted to do that for a living. Surely enough, they looked much like any other kid's drawings. They were a little less "hurried", as she obviously loved doing it and spent more time on a drawing, but were otherwise indistinguishable from other childrens' drawings. Even later ones, from around the time when she had decided she really liked this, weren't exactly breathtaking.

tl;dr: You have the "programmer aptitude" if:

a) You're a frickin' genius who can talk to computers as if they were kindred spirits, but then I guess you wouldn't be asking this if you were, or b) You like programming enough that you can do a lot of it, and can tolerate spending that time looking at your programs with a critical eye and seeing where you failed and what you can improve.

The pitfall in b) is that it will consistently make you feel like a failure, but hey, that's life man.

3 comments

> ...I'm a little envious on anyone who has a talent for drawing.

Among the artists I know, some have taught drawing at art schools. They've all said drawing and art talent are altogether separate matters. Drawing is about reproducing measurements, a skill anyone able to hold a pencil can learn. Geometry class might be a good start.

> ... the ones whojust practiced a lot. have a talent for this are the likes of Picasso ... Everyone else ... just practiced a lot.

Actually even the geniuses had to practice. For example, Van Gogh started painting when he was ~23, and the first couple of years he was quite bad at drawing. With practice he improved, and went on to produce 900 paintings in his short lifetime. Manet, the first French impressionist, was so bad starting off he had to cut out the good portions of paintings and sell those separately.

Your a. and b. programmers aren't really distinct, many of the geniuses of the field speak about dismal "failures" from which they learned. It probably requires genius to see the truly important mistakes and how to do things better.

The point I was trying to make is that there is no widespread innate aptitude that makes you magically produce amazing programs when you touch a keyboard for the first time, and anyone who does not have that innate aptitude is bound to write shitty web apps for the rest of his life. You look at people doing something that they're very good at and it seems easy, it looks almost like they have an instinct for it. It seems like they're born with it, but most of them aren't.
It seems that a lot of "talent" can be attributed to somewhat random preferences, especially in childhood.

You described your friend's childhood drawings as "a little less "hurried", as she obviously loved doing it and spent more time on a drawing", and I think this is the key. She liked drawing as a kid, which made her draw more than her peers, she got better at it and because people generally like doing things the more the better they're at them, a positive feedback loop started.

It also suggests a practical approach to get good at something: sit down, practice, and ignore the discomfort you'll be feeling at the beginning. Many people considered talented simply didn't have that initial discomfort, so they drifted into a skill early, whereas for non-talented it is a barrier to entry.

I've seen the opposite end of the spectrum, too, though, which is why I don't think talent is only a lot of practice, I just think that you can be very good at something without being one of those "really talented" people.

I have another acquaintance who's a musician (an actual musician, unlike me -- I'm just a programmer who likes playing the drums). The guy obviously had a lot of practice, especially as he graduated a famous music academy so he had to play the violin a lot.

That being said, he started taking violin lessons when he was 6, but by that time he could play it pretty well. Having realized that he can't remember the songs he was inventing, he even developed his own rudimentary notation system (when he was about four), with horizontal lines whose length indicated direction and a combination of dots and relative heights to indicate pitch relative to the first note of the song, so that he only had to remember where to start from. His violin technique was also remarkably good. When he started giving violin lessons himself, he struggled with understanding the first gripes of beginners a lot more than he'd expected. For instance, he never realized it takes so long to learn how to properly angle the bow when playing the second and third string of the violin (they're at almost equal height with respect to the base of the resonance box, so most beginners will unintentionally stroke both at the same time). Not only did he not remember having that problem, he literally never really imagined that someone could have that problem.

He's one of those people who does have an innate talent; there are a lot of techniques that he never learned, nor really "discovered" through an iterative process, he just figured out it would sound good if he did <something>, and it did. His brain was wired in a manner that's favourable to playing the violin and to music in general.

Needless to say, he still had to practice a lot -- he had to learn "proper" notation, he's constantly refining his rhythm and coordination, he had to learn how to play in an orchestra, and it's not like he could play any piece, no matter how difficult, from the very beginning. But there were things which his mind and his body could do without being taught, or which, at least, they discovered a lot more quickly than others did. They weren't enough to make him an orchestra-level musician from the moment he set his tiny three year-old hand on a violin, but they are certainly enough to set him apart from a lot of musicians of his age and experience.

People that excel in something are far less than the ones we perceive as such. Most of these 'talented' people have only above average skills, a big dosis of charisma, ability of selling and a bit of luck.
That is definitely it. I've been playing guitar for years and when some friends tell me how I was born to play because I'm talented, I tell them it's not like this. It actually makes me feel bad. It diminishes all the time that I spent practicing to get better, trying to learn new things, listening and improving my playing.

It's the same thing for almost everything you decide to do, if you take the needed amount of time to practice something every single day, eventually you will get really good at it.

I see a lot of people that can do things much better, and faster than me. It's intimidating. There are also some problems that I can't even solve in pseudo code. I literally just can't come up with an algorithm that would work. I get a few ideas, and then quickly realize that they're all terrible. Yet I'm sure that there are people that can look at the same problem and come up with 5 different solutions in 30 seconds. I can do a lot of problems, but I think it's just because they're easy. Every time I stumble upon one I can't do without looking stuff up, it ruins my whole day. I begin to get really frustrated and wonder if I just don't have the right type of mind to be a programmer.

That's why I was asking for a problem. I need one that will tell me if I have the right brain wiring/mind. "If you can't do this without outside help in X minutes, you should quit learning to program." Not incredibly easy like FizzBuzz, but not incredibly difficult. Somewhere in the middle.

> I see a lot of people that can do things much better, and faster than me. It's intimidating.

I think there is a mindset issue at play here. Instead of thinking "Wow, that person is such an elite hacker, I wish I had been born with that talent." think of it as "Wow, it was amazing how they came up with that solution. I want to learn how they did it so I can do the same.".

Stated different, ask people their process. If they came up with a solution that was much better than yours, ask them how they came about it. It may look like they've magically came up with a solution, but they do have a mental process that brought them to it. Find out what it is, internalize it and make it your own.

It feels like cheating though. Once you ask someone for help, the problem is dead. You haven't solved it yourself, and now even if you do solve it, it won't count. Someone told you how to do it. Your interviewer isn't going to help you with technical questions.
You're looking at this the wrong way. It doesn't work this way for any profession. Do you think that doctors are created by taking a sick person, sticking them in front of an untrained 'doctor-want-to-be', and seeing if they somehow miraculously manage to correctly diagnose and treat an ailment they've never heard of?

No. They train. They study symptoms, and causes, and treatments. They learn about how symptom X is caused by disease Y, and is usually treated by medicine Z.

But medicine Z doesn't work in all cases, it's only 75% effective. So you might need to try medicine Z2 instead. etc.

And they they do this, over and over and over, adding in new knowledge of symptoms, treatments, effectiveness, etc. They do this on paper, and they do this in a controlled, supervised environments until they can demonstrate enough mastery to be able to demonstrate that they know enough of this body of knowledge of problems and solutions to be trusted to apply it on their own.

Programming is no different. Answers don't magically spring, unbidden, from some secret programming organ in your brain - you need to learn the established patterns for solving different types of problems. Then, you need to apply them to different situations.

Right now, you're frustrated because you don't have a very big 'bag of tricks' yet. You've only learned a couple of 'solution patterns'. You said that some problems are easy - right? Well, they're easy because you've already added those to your 'bag of tricks'. You've learned the patterns that solve those particular problems.

The ones that are hard? That's because you haven't learned those patterns yet. Once you do, they'll be easy too.

So, looking up solutions for how to solve these 'hard' problems isn't cheating - it's learning. You're learning new solutions.

As time goes by, your library of problem->solutions will get bigger and bigger, allowing you to solve more types of problems.

So, don't think of it 'ZOMG - I'm so dumb! I can't magically come up with the solution to this type of problem that I haven't encountered before!'

Instead, think of it as 'Hmm. That's interesting. Here's a new category of problem that I haven't solved before. The existing solutions that I have in my toolkit aren't solving it, so let's go learn a new solution pattern. Then I can add it to my toolkit for future problems.'

That makes sense. I do want to make sure I'm not just memorizing strategies though. I want to be able to figure things out independently, with my own logical thought.

I'll continue learning. Getting problems right and watching those tests light up green on Codingbat is a very nice feeling. I do get genuinely upset and frustrated when I can't figure out a problem, though. I'm not sure whether that means I hate coding or like it deep down.

Memorizing can take you pretty far. Mastering and extending a body of knowledge doesn't have to come from independently postulating a few principles and working things out from there (though that can be very fun and satisfying). Focus first on imitation, memorization, then figure out how to apply it. After you can apply it, figure out how to adapt it in certain circumstances. You might even evolve and extend the knowledge, especially as you integrate other things.

One hack I'd suggest for fulfilling the craving of doing things "from scratch" when you're frustrated at a particular problem is to go back to one you already solved, but pick some class or method or set of methods of Java's library you used and make your own version. New problem! Data structures can be the most common. Used a java.util.Stack object? Write your own Stack class. Instead of `int Integer.parseInt(String);`, write your own. Try a hash map when you're a little more experienced. Pretty much everyone with the hunger writes their own string class eventually (usually in C++). Or try to solve the whole problem again in a language that gives you less, like C. It's good practice for college and tech interviews too. Too boring? Waste of time? Good, you'll appreciate it's there next time so that you don't have to keep reinventing the wheel and can just use it as you go about inventing some new thing made of wheels. The only danger is if your appetite is totally consumed, you'll swing the other way always searching and waiting for the right set of already-built dependencies you just have to glue together, and even then you could just hope for a framework that does that, your tolerance for exerting any programming effort for 'boring' stuff will go away, and everything will be 'boring'. That's not a great state to be in if you have aspirations of building rather than simply using.

Codingbat looks cool, hadn't heard of it before. You might also try Project Euler, another programming/math-problem solving site where "the problems range in difficulty and for many the experience is inductive chain learning. That is, by solving one problem it will expose you to a new concept that allows you to undertake a previously inaccessible problem. So the determined participant will slowly but surely work his/her way through every problem."

https://projecteuler.net/

I don't think that's related to liking or hating coding.

I get the same feeling, but I get it about plenty of other things.

I love coding, but I don't love it on a daily basis while I'm working, and I certainly don't love getting stuck on a problem I can't solve. I do love the moment I get it working, though.

Asking for the solution, and asking about the process they've used to solve a problem is not the same. Learn the process so you can solve similar problems in the future. I wouldn't consider it cheating or "not counting", they've had to learn how to solve those types of problems somewhere.
the problem isnt' dead because the solution and what you do with it in the future. Teaching a (wo/man) to fish. There's always going to be future problems and ways that synthesizing what you know from others IS the way we get better. Also you're being selfish. Not asking means you're not able to give another an opportunity to enjoy helping you and taking that with them as an accomplishment for the day. Get out of your head on this one. You're able to help people who can't do something right? Why deny the joy or accomplishment to somebody else?
There's no shame in reaching out to others when problem solving, that's part of (and should be part of!) the problem solving process. In my experience, Interviewers love when you ask intelligent questions.
This response basically proves (to me) that you have an aptitude for coding.

As your knowledge increases, you'll gradually run into fewer problems that you can't solve in pseudo-code, but you're not SUPPOSED to be able to solve any problem in code when you start.

The mere fact that you even have a few ideas to try is testament to your aptitude.

Keep on trucking, you'll get there.