This depends a lot on the domain you're programming in. For example, if you're working on a proprietary application like high frequency trading or code for an embedded device, it's not likely that you'll find an open source library to do whatever you need, or get a lot of help from Google or Stack Overflow.

Also, a lot of open source libraries are not robust enough for commercial applications that have requirements like support of legacy East Asian character encodings (pre-Unicode). Not all programmers work on web apps where you get to control the environment (hardware, operating system, database, languages, etc.) you run on. Lots of software has to be built to run in the customer's existing environment.

I think that's a distinction that the author's language made. Most programming problems have been solved. The head of the Zipf-curve of your work, no matter the domain, will be reusing old-hat knowledge. Every program, even HFT, needs proper data structures, algorithms, task scheduling, etc. Hopefully this stuff is mostly already provided by your platform, but a great majority of every developer's time is basically "bringing the platform up-to-snuff" with everything it really should have had to begin with.

Once that's done, the code that's actually business-domain specific (whether the domain is ERP, trading, games, graphics, AI, simulation, etc.) will likely be novel, because it's a codification/automation of a business process which is itself novel. (And business processes being novel is sort of the Anthropic argument of capitalism: a perfectly non-novel process means there's already a company doing it somewhere with lead-time on you, which means you have no advantages and won't survive in the market. So every new business that survives must have some sort of mutation, for better or worse.)

Did you know, that if you make a control loop running basically newton's method of approximation (more or less), it can be statically stable in continuous analysis but when you run it on real world discrete math with short-ish rounded floating point it can get squirrely and oscillatey (are those even words?) so that's why you ram the output thru a low pass filter to damp out the oscillations. Or at least that's one way to fix it.

Oh another funny one is picking a local maxima / minima that randomly happens to have a near zero derivative. From memory Newton doesn't like that very much. Another funny one is any time you have tiny rounded floats divided by other tiny rounded floats, who knows what you'll get as an answer. You can fix that by fuzzing the input first guess with some random noise. Makes your execution speed non-deterministic, but stuff is fast now a days isn't it, and its faster than doing double/quad floating point anyway, which may or may not help much.

Sure the google found some python or fortran or mathematica which on the surface is useless, but psuedocode is psuedocode and compilable fortran is a tighter syntax than any random human generated psuedocode so in some ways its better.

This is before you hit the "well, that library speaks to 16x2 LCD displays, I guess I'll have to start over from scratch because I'm using a 20x2 LCD..." Well, typically, no.

For HFT I agree, you're stuck behind layers and layers of patents and trade secrets. But embedded is not a problem to get google-type help.

I encourage anyone who wants to get an intuitive grasp of simulations to just write a simple little 2D game engine, and try to work up toward a simple two-player realtime LAN system with predictive physics for expected network input. Seeing sprites shudder and vibrate against their integer pixel positions, jump instead of smoothly curving when a correction is issued, etc., is a visceral learning experience.

Well, "chaotic" is what you'll read in textbooks, but that's just because they couldn't come up with "squirrely and oscillatey", I assume.

The best programmers I have ever worked with sought continual improvement personally. They viewed themselves and their career as a system that they monitored and acted upon.

I focus on this because it is a factor that ignores the variables that often influence or weight the typical measures. Age, Experience, Education - all of these things affect the quality of work and the perception of skill so I have constantly sought that thing I can look to outside of that which is indicative of long term value.

So far, desire to improve, is the best I have found.

It sounds trivial yes, but people who actually embody this are very different than those who give lip service to it. Ask 100 programmers is they wish they were better and 99 will say yes (there is always one dude...). Ask those same 100 what they do each week to make themselves better and you find 10 or less actually doing the work in their spare time that it takes to become a master.

"To put it more simply (and, perhaps, too obviously): if you see someone excitedly grabbing problems and acting on them, chances are you have a good programmer on your hands"("They just do it")

it depends on the type of person someone is, more than the quality of the programmer. I know bad programmers who are excited to jump from problem to problem (never doing much good on any of them). And I know great programmers who think twice about taking a problem - because they are working on something else and wish to finish it properly, because they want to think it through,... there are many reasons.

Also, I wonder how many of us identify ourselves with the good ones? As someone said, it is very interesting to observe that about 80% of programmers are in top 5%. ;)

I'm often surprised at the fact that most professional programmers do almost no programming on their own time. They're no more interested in it than most plumbers are interested in unclogging toilets for fun after work. Most programmers program for a paycheck, because they'd rather do that than clean toilets.

Great programmers ARE often interested in other things, too, but they are interested enough in programming to do it as a hobby outside of work; they're not just doing it for a paycheck. (And, yes, I exclude those who are currently going through day-job death marches at work and need something completely different to recover after work. I've been there, too, but when the tide changes, I'm back to programming my own projects for fun.)

As someone who's just recently started to consider full-time hires beyond our founding team, it's ridiculous how important this is relative to how little it's talked about. The other traits - "avoiding crises", "doing their research" - often boil down to effectively working together with your teammates and finding information / reaching decisions quickly.

And I do think it's got something to do with educating programmers. Working with interns and contractors we've had at Harvard, MIT, etc., the best have been Olin College (http://olin.edu).

I'm not going to gush about it in this comment too much, but suffice it to say the best communicators about technical problems are usually the ones who spend the most time working in teams and presenting their work, and those are Oliners to a tee.

2. Being able to recognize a bad design and improve upon it.

3. Not wanting to re-invent the wheel every time the code base stinks.

4. The understanding that no problems in general might be new, but some specific problems inside a particular situation might be.

5. The importance of listening and taking into account the solutions others provide.

6. Being able to deliver. I have met too many full stack rockstars whose code never works and is as tight-coupled as melted cheese to bread.

That's not a life worth living.

No one sits in front of a computer 24/7 to program. No one. Hell, Linus talks about how he spent so much time programming Linux in the very early days in the book "Just For Fun" and he even has time for socializing.

> That's not a life worth living.

For you, maybe. Don't assume your values apply to others. The other side is that it's not a life worth living if you spend 40 hours a week doing something you avoid the other 128 hours.

You should be networking, talking, going out, learning, traveling and filling your life with a wide variety of things. Yet the start up programmer lifestyle is programming 24/7. It's not healthy. I can guarantee you a lot of start up founders, don't work the hours their programmers do.

I miss the days of childhood though where I could build what I want on a whim, at large companies you don't always get to build what you want to during the times of the day they pay you.

This is not only the essence and truth of this article, but also what I believe is the core of all good people - shaping the world into something beautiful.

Of course there are exceptions to every rule, and I'm probably biased.

I strongly suspect this sort of thing is HR-compliant code for "we'd like someone in their 20s with no family who won't mind doing unpaid overtime".

What strikes me is that this notion seems to have developed in the software industry that people working on code in any significant capacity should be living and breathing code. I've seen it said here that there is no excuse not to have a flourishing github account in this day and age. Well, what if I don't use github for my stuff? What if my work is pretty much all proprietary? Side projects you say? Like my personal algorithmic trading platform, I should put that on github? No thanks. How about the field of math I've been teaching myself over the last three years? That doesn't count because it doesn't go on github?

For me it comes down to the fact that developers seem to be expected to have no life, but simultaneously expected to have a diverse set of skills/interests. I have a ton of side stuff going on, but it's not all public, and it's not all programming!

Although I would agree with you that some would prefer young ones without responsibilities and a lot of spare time over those with more experience but with families. I guess this reflects more of a certain company hiring philosophy more than anything else. Energy to the young, wisdom to the seniors.