I can get by some of this article's sentiment, but I can't help but feel that it somewhat devalues programming into this dumb task of copying and pasting. In fact, I've been seeing this meme propagate quite a lot, as of recent. "Programming isn't hard. It's just being able to copy and paste the right answers from Stack Overflow."

This is a horrible idea to instill, particularly onto beginners. That and I can't help but feel that all these sort of articles and thoughts come from people with web developer background. The "hipster" motif being used kind of implies it. My personal background is more in system programming, so I'm not a hipster, but a greybeard, dammit.

In the end, I can't relate to this as much. In fact, I'd say copying and pasting is more harmful today than it ever has been before, due to how complex and multifaceted computing in general is. There's too many things to know.

I'm definitely not trying to suggest that programming is easy. I've seen a lot of code ruined by cut/paste, but it's also true that beginners have to start somewhere!

My main point is that having a better way to look up programming information is something that can benefit everyone.

The first thing that came to mind when I read "Wouldn’t it be convenient if the documentation... already had an answer for someone with the same problem?" was "Oh, like the comments on the PHP docs?"

It's a clunky mechanism and there's years' worth of cruft in there, but interspersed with years' worth of knowledge, and I've often wished other languages had a similar canonical repository of user-contributed information. I seldom touch PHP at the moment, but reflecting on how many times I found a quick solution to something simply by perusing the comments on a function's page makes me think this approach could have huge potential if implemented in a more elegant way.

PHP is the only documentation that feels complete to me, other languages you have to look elsewhere if something is addressed directly. With PHP, 8 / 10 times the answer is in the comments.

I looked at the PHP documentation and realized that it was basically just a forum with a stickied thread per API. And honestly, that seems to work.

Stack Overflow?

The guy in the picture using a typewriter is not a hipster btw (well, maybe but not because of that), he was selling short stories written on the spot in a park.

Indeed. Here's his story:

http://www.theawl.com/2013/09/i-was-a-hated-hipster-meme-and...

On top of which, that doesn't look like a card catalog. Rather, if it is then why are there three different card sizes when there are only two major types of card catalog sizes? See http://collections.infocollections.org/ukedu/en/d/Jg28doe/13... .

(Only one of those boxes looks like it might be the right size.)

Plus, the card catalogs I've used have a rod that goes through a hole in the bottom of the card. This helps keeps the cards from falling down, or falling out should someone drop the drawer. The rod is usually visible on the front of the drawer.

My first job was in a library. The way that you really use the card catalog is that you don't unless you are looking for a specific title. Otherwise the numbering scheme is structured enough that you should have a pretty good idea where books on any particular topic will be located if they are in the collection.

The loop of programming "skill" is the path a craft takes as it moves to mass production. To me, much of programming is building custom automobiles by hand. Eventually, tools and processes will become standardized to the point that true mass production is possible. Notably, powerful frameworks and changing technology stacks continue make problem solving skills and learning ability valuable. But what happens when our frameworks are so powerful, so stable, and so well tested, that we simple do not need craftsmen? The industry will move to low-skill "coders" (assembly line workers), line code supervisors (assembly line supervisors), framework engineers (factory engineers), framework component engineers (machine/robotics engineers), and programming process managers (operations managers).

Thats a terrifying future for a person like me who has just started programming.

But get this , programming can never be fully automated. There will always be one guy who has to sit down, understand the requirements, convert into a logical structure/business rules and then design a proper solution.

Maybe a powerful framework will then allow this one person to realize what he could have otherwise done only with the help of 3 - 4 other junior developers but until we develop true AI programming won't be automated.

Well, the boring programming jobs will be automated, but for them you didn't need a CS in the first place.

I'm a coder at an outsourcing firm in India .. So gulp , I am a bit scared :P

Maybe you should be :D

Joke aside, I thought India was getting more high-tech lately. My impression was that this outsourcing would stop soon anyway because the wages getting higher and India needs their coders for themself.

Wages are actually lower when adjusted for inflation when compared to what IT workers used to make in the early 2000s. Also theres increased competition from Ukraine / China. But its hard to find better work in other sectors and the less said about the standard of education here the better.

I really enjoy coding and I'd say that I'm better than 75 % of the coders here. But thats hardly enough to get into a place where they do the real nice work.

We even have to sign an agreement whereby we're forced to work for a particular company for years and can't leave without paying a hefty fine. Atleast that never happens in North America.

Good jobs are hard to come by and I'm thankful for this job.

> Eventually, tools and processes will become standardized to the point that true mass production is possible.

I like to think that. However, to strain the programming-as-craft analogy (which I think is a good one), I don't think we're yet at the point where we even have a good selection of well-made hand-crafting tools yet.

We've probably got the equivalent of a reasonable axe, hammer, and nails by now (matching these to current day compilers/linkers, interpreters/vms, and editors/IDEs is left as a futile exercise for the reader) and we might have the vital core of some other tools, but I don't think we have well made selection of saws, planes, drills/bits, squares, clamps, levels, etc... yet. We're getting there, fast, but considering the craft is only about 170 years old[0] we just haven't been at it that long.

[0] Starting in 1843 with Ada Lovelace's method of computing Bernoulli numbers on Babbage's Analytical Engine.

That sounds like a very distant possibility to me, bordering on a pipe dream. We're at a far cry from having the tools that enable us to do this equilibrium of power/stability/testing.

The likeliest scenario is that we will keep iterating over the same flat tire that sort of looks like it reaches equilibrium, before it inevitably collapses under its own weight and has to be restarted, again and again. I do not see this pattern going away.

... and the occasional guy/gal who still welds together scrap and builds kit-cars at home.

If this product was highly adopted on the frameworks and languages I use, I would truly love it. I would pay for a subscription if the value was proven and reasonably priced. It could combine a lot of the best features of Q&A (Stack Overflow), documentation, FAQs, and mailing lists.

Omniref seems cool but is unfortunately tied to Ruby only, if it was usable with more languages it'd be a lot better.

Duly noted. ;-)

This is a very interesting project that I will be following; but I can't agree with this sentiment. Experience is a foundation of any skill and programming is no different. This argument could be applied to essentially any profession that requires experience to be competent in.

I think that it's better to look at the issue from another angle; the speed at which programming is evolving. If omniref were to pose themselves as a venue to simplify the act of learning new concepts and tools, that I can get behind.

As you point out, the speed at which programming is evolving makes maintaining relevant experience difficult for a human, which makes programming at least different in degree from other professions. The ultimate goal is to build a hive mind able to effectively share the current relevant experience to address both problems, getting up to speed, keeping pace and ultimately being productive easier.

2025 : StackOverflow becomes self aware.

The US Government is closed as being Not Constructive.

How about creating a universal notation which can then be parsed into the code needed in a particular platform or language.

Suppose we need to get a JPEG from a particular URL.

So the corresponding universal notation would be :

Image -> Representation : Image::JPEG Image -> LocationType : Network URL Image -> NetworkPath : http://xyz.com/a.jpg

Then suppose we want the contents of the image in Base64

We need to query for a function or chain of functions which leads from semantic representation Image::JPEG -> String:Base64.

Kind of like a cross-language Hoogle. We could then have a community effort to annotate all APIs this way.

Another thing we need is an encyclopedia of things that can go wrong. For instance what are the things to watch out for when copying one file to another ?

Permissions ? Lack of disk space ? Power goes out?

There are many things we might miss. So a repository of corner cases would be useful.

Though I don't have enough skills I'm thinking of making something along these lines. Does anyone here think that this is worth doing ?

People have tried to make these many times. In targeted domains (e.g. health decision support software) they're actually quite popular. Look up the OWL project on W3C for instance.

I think makes sense, that programmers are looking on the internet to solve problems. But I think in this informational age that sentiment applies to basically everyone.

Everyone has a certain knowledge base about problems. If they experience a problem they have never seen before they have two options to innovate and create a new way to solve the problem or to do research and see if that problem has been solved before.

I think software development is an obvious example of information searching and usage but I'm sure this the word "programmer" could be swapped out for thousands of other vocations.

Furthermore, there is a lot more to software development than just finding the right answers to problems. Developers need to be able to architect solutions, solve novel problems that are domain specific, and have good understanding of many tools to effectively create and deliver software, plus a lot more stuff.

> Say that you’re new at Ruby, and you want to know how to delete elements that match a certain condition. Wouldn’t it be convenient if the documentation for Hash#delete, already had an answer for someone with the same problem?

Interestingly PHP docs had exactly this since forever. I believe it contributed greatly to success of PHP.

The part the author is missing completely is where, as a programmer, you find the problems you need to solve, and you analyze how your answers/solutions interact. A program is an interwoven web of answers, often reformulated, not a list of verbatim answers.

What you do is not the dozens of quick things you can look up on the 'net. What you do is assembling a larger thing, and that is where your skill comes in.

To go back to the librarian analogy: You're not looking up a bunch of answers, you write a book (or at least the outline of one) for a new topic. Part of that, unless you can afford a research staff, is looking up a bunch of answers, yes. But it's not what you do for a living by a long shot.

If software can execute a million times faster to test a solution, couldn't you theoretically write code to copy error messages or run through a list of questions, search and paste solution and test? If the test passes move on, if it doesn't pass just reformulate question and test the next google search result?

And couldn't this lead to jr. programmers jobs being automated?

Is software going to eat your job if you are a jr. developer?

> Is software going to eat your job if you are a jr. developer?

I hope so. There are bigger and more interesting problems to move on to.

I'm sure the capacity for more complex and more capable software systems is limitless.

This is incredibly stupid just for using the term "hipster"

--interest

Not in ruby, which is the language he's writing the pseudocode in.

Correcting the syntax of pseudocode, you must be fun at parties.

No, for being a pedant. An incorrect one, at that.

In the C family, it should be ++frustration, for speed :p

For an integer, if the pre-increment value isn't used, GCC at least will generate the same code, even with optimization turned off:

    int pre(int a) {                    int post(int a) {
      ++a;                                  a++;
      return a;                             return a;
    }                                   }

    pre:                                post:
    .LFB0:                              .LFB1:
        .cfi_startproc                      .cfi_startproc
        pushq   %rbp                        pushq   %rbp
        .cfi_def_cfa_offset 16              .cfi_def_cfa_offset 16
        .cfi_offset 6, -16                  .cfi_offset 6, -16
        movq    %rsp, %rbp                  movq    %rsp, %rbp
        .cfi_def_cfa_register 6             .cfi_def_cfa_register 6
        movl    %edi, -4(%rbp)              movl    %edi, -4(%rbp)
        addl    $1, -4(%rbp)                addl    $1, -4(%rbp)
        movl    -4(%rbp), %eax              movl    -4(%rbp), %eax
        popq    %rbp                        popq    %rbp
        .cfi_def_cfa 7, 8                   .cfi_def_cfa 7, 8
        ret                                 ret