>> Well, if you enjoy something, it's much easier to put a lot of time in to figure it out.

I started programming as a kid because I wanted to make games. It was fun. The problem was that I didn't get the more formal stuff until college, and it made me a much better programmer. But I could also see how boring the data structures class would be to someone with no experience because they really didn't have insight into how applicable some of the concepts could be.

I have always advocated for creating games (and other useful things) to teach programming. Most if not all the major concepts can be applied to games. Why anyone would use the fibonacci sequence to teach recursion is beyond me - it's a stupid solution to a stupid problem. Let's talk about board games and minimax search. Yeah, you have to build a lot of code before that comes into play but you'll learn a hell of a lot more and have way more fun doing it.

Doing simple games like 2D scorched earth really brings home basic vector math and physics. Any 80's arcade game with a thrust button allows you to apply that stuff.

Any kind of 3d graphics goes right along with linear algebra - a topic that is not required by all CS programs even though matrix operations run 24/7 on supercomputers.

Text processing. chat bots anyone?

I used to have an example that used trees but it escapes me right now. Chess doesn't really count because you don't store the tree. We can go back to 3d graphics of course - photon mapping, kd-trees, various BVH structures.

If you start with data structures and algorithms, peoples eyes will glaze over. If you start with simple things that are somewhat interesting you'll get people interested and then you can progress them slowly to more advanced topics by introducing problems they'll want to solve.

I agree with all that, and in my experience, students really react well to courses and coursework based on doing games.

And yet, I will use Fibonacci as introductory example tomorrow when I teach "Intro to computational complexity" this week. The great advantage of Fibonacci over just about anything else is that it is so short, so simple, that everybody can immediately understand it. There is no preparation needed. Just about anybody who can breath, can understand Fibonacci.

Despite this simplicity, Fibonacci is so rich: You can use it to illustrate: Recursion, exponential complexity, going from exponential to linear complexity by memoisation. Relationship between loops and recursion. Tail calls. Stack space used by compilers, the limitations of compilers that do not do proper tail call optimisation,generating functions, recurrences, solving recurrences.

>> And yet, I will use Fibonacci as introductory example tomorrow when I teach "Intro to computational complexity" this week. The great advantage of Fibonacci over just about anything else is that it is so short, so simple, that everybody can immediately understand it. There is no preparation needed. Just about anybody who can breath, can understand Fibonacci.

Despite this simplicity, Fibonacci is so rich: You can use it to illustrate: Recursion, exponential complexity, going from exponential to linear complexity by memoisation. Relationship between loops and recursion. Tail calls. Stack space used by compilers, the limitations of compilers that do not do proper tail call optimisation,generating functions, recurrences, solving recurrences.

I agree with all you said too ;-)

I would say "Intro to computational complexity" is a more advanced course and the students should already be familiar with recursion from experience prior to learning to analyze time complexity ;-)

IMHO Fibonacci is still a poor example because the most obvious (to me) implementation has always been a loop. Pointing out how a recursive version can be simplified to a loop seems silly, and so does making it more efficient with memoization. But as a first example, sure I suppose. Then you drop the bomb on them and show how it can be done in O(log(n)) by using fast matrix exponentiation.

Thanks for reminding me of the O(log(n)) algorithm. I had forgotten about it. Just added this algorithm to the lecture slides. I <3 the internet.

I start with the recursive algorithm because it follows directly from the definition F(n+2) = F(n) + F(n+1). I also think there's a big schism in programmers: between those that think recursively, and those that are of a more iterative bend. I'm in the former camp, probably owing to the fact that my first programming language was Scheme.

>> and those that are of a more iterative bend

And that would be me ;-)

This is a problem in general in math-based education, and sometimes in science also. The solution is problem-based teaching, where the problem is introduced before the solution. By establishing the need for something first, it makes it much more concrete.

It's not really surprising that good programmers are often also good at legal drafting.

When you're a programmer, you understand that the processor is dumb and has to be guided through absolutely everything. If you don't factor in the corner cases, your program is going to screw up somehow.

Legal drafting is the same thing, just replace the processor with a judge and the programming language with English. If, while writing a contract, you precisely define everything and cover all the ins and outs of what can and cannot happen and what should and should not happen in the event that any or all of the above likely or unlikely events shall happen during the lifetime of the contract. Then if you ever need to get the contract enforced by the judge, you can clearly point out exactly how the opposing party already agreed to resolve the situation in some way.

The real reason why you need to hire lawyers has more to do with making sure that the contract you draft is enforceable (considering current law and legal precedent), or else risk having the entire contract thrown out later by the judge. AKA legal system faulting.

A lot of less technical management doesn't understand how important being able to find corner caeses is. This is what separates a good and solid application from one that is routinely failing.

I think the question of whether anybody can get good at programming is very interesting. I often hear "anybody can do it, but you can only become really good if you enjoy it".

So then the question is: why do you enjoy something? Are we born that way, or is it something we do? (I don't know what the answer is)

Edit: also, it is interesting to replace "programmer" with "math professor". Can anybody become a good math professor if they enjoy doing it? If not, what is the difference (assuming it is true for programmers).

For me I think the determining factor of a good programmer is not enjoyment (although that is necessary), it's curiosity. I work with a guy who I'm pretty sure has a photographic memory and would probably run circles around me in an IQ test and with his GPA, but I'm constantly showing him more efficient ways to write code. The difference is I am forever curious about CS-related stuff. I spend hours a day reading HN and other things like it. I'm orders an of magnitude better prgrammer than he is simply because I'm curious.

I think it's a bit of both nurture/nature. In hindsight it was obvious that I would be a programmer even though I didn't have much access to a computer until college. Growing up I gravitated towards math/science, loved any sort of problem solving, and enjoyed things that many would consider tedious (building model WW2 naval ships with my grandfather for example). I did have a Nintendo that was in a constant state of being taken apart, but it did work most of the time :) When I finally had school computer time starting around middle school, they literally had to drag me off of them. Trying commands, tinkering, etc... was just...fun.

None of my friends (or parents for that matter) understood because they were mostly jocks with a few artists types mixed in. But, my friends never cared as long as they could get me out of the house to play whatever sport was in season.

To circle back around, I had a natural inclination with people like my grandfather encouraging it without really knowing.

I'm not sure but I suspect that viewpoint has a massive effect.

It's similar to the old saw about growth vs fixed mindsets.

I often describe programming as "failing 99 times and succeeding the 100th time, and counting that as success". There are a lot of people who are not wired and acculturated to that sort of "success".

That said, I don't (obviously via the growth mindset) think it's a fixed quality, it's more of a learned and acquired routine.

I think our enjoyment of an activity depends on how we see our progress.

If we keep struggling with it, we will hate it, even if we thought we would like it at first.

We could also begin to enjoy an activity if we see ourselves progressing in it. When you see your improvements, your brain probably releases dopamine (or another one of those addiction chemicals) and that makes us want to do it more (to taste that sweet taste of victory/progress).

Some subjects aren't really fun until your good at it though. I used to hate it until I forced to do it and found it was fun after I got the basics down pat.

When I think of somebody who enjoys programing, they usually have a goal or task to compel them. Just solving random CS questions and math is pretty boring to the majority of folks.