Hacker News Reader

"I don't consider programming to be a much greater skill than the ability to install fixed wiring in a house or balance a budget."

The vision you seem to be espousing is someone tells the programmer exactly what to do, and the programmer does it exactly to that specification. Wiring a house and balancing a budget are solved problems. So you seem to be saying that programming is also a solved problem.

Which is so out of touch with reality I feel that, surely, I must be misunderstanding you. A computer program can do pretty much anything. Depending how you feel about the equivalence of Turing machines and human brains, you can argue that a computer program can potentially do anything a person can do.

With the geometric increase of computing capacity available to us, how is it even conceivable that "programming" is equivalent to balancing a budget or wiring a house? You seem to suffer from an incredible lack of imagination.

"However, I think that is a much better position to aspire to than self-aggrandizement and glorifying a skill that is really no different than any other skill that any suitably motivated 12 year can acquire with a couple library books and an internet connection."

That is the same as saying a 12 year old can write or play a musical instrument. Sure, they can spell words and make sentences, or know the correct fingering for certain notes. But the potential for improvement in those endeavors is also unbounded. The same is true of programming, in my opinion.

An electrician is not given absolute exacting directions on what to do and then follows them by wrote. A master electrician is given guidelines (in the form of regulations) and then a list of what the customer wants. They then consolidate the two into a plan for the building (locations of outlets, fuse boxes, etc.). Once the general plan is done (what power is needed where for what) they have to determine where at what type of wires and junction boxes need to be places, working through the design of the building. Once the electrical diagram is completed, it's handed off to a journeyman, who, with other electricians, run the wires as close to the plan as possible, frequently having to deviate slightly due to the differences in reality.

This is the absolute, most common, frequently found, frequently followed process for developing software. There is more "wiggle room" at each step, but it's the same exact process, whether it's one guy doing it and dreaming up the requirements or a team of thousands of developers.

Exactly. Now the big difference to me is in the kind of programming.

For instance, the people that write papers on new datastructures, computer vision and other state-of-the-art developments. They're not working with 'requirements' other than 'it would be nice if you found a way to solve 'X', come back in three years'. (well, not quite like that, but closely).

That's basic research and a definite amount of artistry is involved at that level.

But after the paper is written up it has solidified and it becomes applicable science, and for the person calling the API that embodies the concept it has become 'mere' bricklaying.

I think we're running around agreeing with each other. I think any scientific research involves a bit of art and intuition in the approach to the discovery. I think the only difference would be that I don't consider the research part as programming. It involves programming, but in itself is really the same as any other scientific discovery process.

"But after the paper is written up it has solidified and it becomes applicable science, and for the person calling the API that embodies the concept it has become 'mere' bricklaying."

I completely disagree.

The art for the person calling the API is often found in "building something people want." Think of the people who frequent this website. Many of them are writing lines of code to make something people want. Surely there is some art to that. There needs to be an idea, building something to show customers, and iteration on that idea taking customer response into account. The customers have input, but the programmer decides what to write.

Just as wealthy people once commissioned portraits and told the artist what to draw, programmers can be employed someplace where the question of what to program is decided by someone else. But there is nothing inherent in art prohibiting painters from deciding what to paint, or in programming prohibiting programmers deciding what to program.

Radically disagree with you there. Wiring is in principle really simple - make sure the right wires are connected, insulated properly with appropriate safeguards; accounting is similar, where there are essentially only four kinds of things.

Putting together a large piece of software, or optimizing a particular path in a large codebase, or putting together a creative solution to a class of problems, requires a much higher level of thinking. You need to bring together far more concepts at different levels of the abstraction stack, and have enough of them in your mind to arrange them without them interacting poorly at one level when you're coordinating them at a different level.

Programming is more like building a whole new kind of house, without a plan, or altering an existing house, without it all falling down around your ears.

As to subjectivity: you're wrong that software quality can be measured objectively, because of two simple facts: software isn't static - it must be modified over time - and humans are limited in their capacity for complexity. The abstraction which yields most readily to the changes that matter, such that those abstractions mesh well with those people doing the modifications, are subjectively good - their worth is dependent on the observer.

Programming is in principle really simple - make sure the right lines of code are used, follow each other and are debugged properly.

Sure, putting together a large piece of software is hard, but then again, putting together the electrical system for a nuclear plant or something on that order of complexity is just as hard, if not harder (no 'undo' switch on that one).

There has to be a way to see that programming is really not that hard 'in principle'. It is hard in practice, and this goes for a large number of other activities as well.

To argue on a programming forum that programming in principle is a simple thing is probably an unpopular point of view, but really, we're not half-gods or somehow special, we're just bricklayers and watchmakers. And if you've never built a brick wall I challenge you to go and do it and afterwards we'll talk about how easy it was 'in principle'.

I saw a few years ago a study which claimed professional programmers had the second or third highest average IQs of any occupation. Probably depends on how you measure, but you get my point. After 10 years of programming, it's only gotten marginally easier. The fundamental stuff of programming, solving highly complex and abstract problems, never seems to go away. Somehow I doubt bricklayers can say the same.

Programming is part craft, part science, and occasionally a very small dash of inspiration or art.

But for the most part I think that a very large amount of it is very comparable to bricklaying. Especially in the part where most people in the IT world make their money, such as software for the financial and the business world.

Rarely does it elevate itself to the level of watchmaking and even rarer do you find art. It does happen though, but not often.

I'm sure that programming is conceptually different from bricklaying in a sense that we are solving puzzles, sometimes. But everybody that got in to it for that reason knows that the only time you really need that skill is when you've messed up and you are facing a very tough bug.

Once you get better at programming it is more like knitting or weaving than puzzling.

Of course there are different styles of programming, and there are only so many kinds of brick. But programming for the most part is hard because we have chosen to make it hard. If bricklayers had to create each and every brick from clay and bits of stone then you'd be much closer to what programmers do for a living than what bricklayers do.

Bricklaying has been 'industrialized', and one day programming will be too. It will probably still be marginally harder than bricklaying, even after that has happened. But if you can explain what you want done and in which order then you are essentially programming.

People often say they would like to learn how to program but they are not smart enough for it. And plenty of programmers just love that because it makes them appear special.

But I think anybody can program, the difference is not some binary switch in your head 'programmer/non-programmer'. The difference is in how complex an arrangement you can create, and that's a continuum.

Some programmers are better at this than others and can solve more complex problems.

Bricklaying is actually a really good comparison to programming. It's stacking bricks with glue. But those bricks eventually end up making an entire building. And with that, you have corners, archways, windows, doorways that you have to determine how to cut or turn the bricks so that it will support the bricks you're going to put above it, or the lack of bricks below it. Bricklaying is a craft and an application of sciences that are well understood. That's the reason why so many comparisons fall flat, why there's discussion about "is it science" and "is it art". The only part of software development (I'd like to use the term engineering and have it mean that one day, it'd be nice) that's art should one day be science.

Let's face it, with programming, we're inventing entirely new domains with their own special rules that we create. It can be an artistic process or a scientific process. As an artistic process, it's very hard to judge the outcome from the start. As a scientific process, the result is much easier to judge prior to completion. Until the processes and methods are understood to a sufficient level, programming will be very much like an art. Once they're understood, it's a science, apply the rules and out pops a software.

I have several relatives that are plumbers, electricians, carpenters and architects. Once there's a common set of tools, language (as in, for communication between people) and understanding, programming is no different than any other craft.

The windows, corners, doorways and arches where exactly what I had in mind, but even a straight wall is already pretty hard. Each building is, when it's done a work of art, and possibly more so than most computer programs, especially your garden variety throw-away web-app.

The 'art' part in programming is exactly that part where it is not yet a science.

"Bricklaying has been 'industrialized', and one day programming will be too."

This prediction has been made for decades now. I suppose if people keep predicting this indefinitely, someday it will become true.

In the meantime, new programming tasks are invented faster than the old tasks are industrialized.

"Once you get better at programming it is more like knitting or weaving than puzzling."

This is up to you. Was building Google, Amazon, Linux, Firefox, iPhone OS, etc. etc. etc. more like knitting or weaving than puzzling? Maybe what you are saying is that most programmers aren't good enough to build those kinds of products, or would just rather stick to their knitting and weaving. That I would agree with.

"Some programmers are better at this than others and can solve more complex problems."

This is trivially true of any cognitive task.

> This prediction has been made for decades now. I suppose if people keep predicting this indefinitely, someday it will become true.

One day is on purpose very vague, I haven't a clue on what timescale we're talking. But I'm fairly sure what will be the sign that we've reached it, it's when we will remove the term programming from language and use 'teaching' instead.

> This is up to you. Was building Google, Amazon, Linux, Firefox, iPhone OS, etc. etc. etc. more like knitting or weaving than puzzling? Maybe what you are saying is that most programmers aren't good enough to build those kinds of products, or would just rather stick to their knitting and weaving. That I would agree with.

Most of those were huge projects, but if you break them up in to little pieces some of them were artwork, most of them were bricks. The architecture of each of those was likely artwork.

> This is trivially true of any cognitive task.

Yes, but many programmers seem to think there is something 'magical' about the ability to program, as if there is some kind of essential element that differentiates those that can program from those that can not.

And I think that is not the case.

"many programmers seem to think there is something 'magical' about the ability to program, as if there is some kind of essential element that differentiates those that can program from those that can not."

You should read this, and maybe the linked academic paper, too: http://www.codinghorror.com/blog/2006/07/separating-programm...

I challenge you to find someone that I can't teach how to program a computer.

Maybe they won't be the next Donald Knuth, but they'll be able to hold down a job and make a living. I guarantee it.

You ship 'm I'll teach 'm, no matter how much time it takes I'll do it. The only pre-requirements are a willingness to learn and a willingness to spend the time, as well as an iq of 80 or more.

Anybody can do it, not equally fast, not equally good, some may hate it and some may love it.

That test is so biased it's not even funny, I've linked the script below, it assumes that people will clue in to the different meaning of the '=' sign in programming (assignment) as opposed to what it means in the rest of math (equality). I note that some programmers that are very well seasoned have been caught to mess up '==' and '='.

I always thought that the '=' sign for assignment was a huge mistake and that '<=' would have been far better.

But it's a little late for that now. What galls me even more about that test is that instead of providing a warm up with a bunch of assignment samples and 'print' statements afterwards would have given the really interested parties a shot at figuring out how it works, to test their assumptions.

The problem with programming is an educational one, not some kind of genetic pre-disposition to being able to program.

Just as there are people that are better and not-so-good at arithmetic there are people that are better and not-so-good at programming.

It's a skill thing, and if you work at it hard enough you can get better. The ten thousand hour rule definitely applies. If that's not the case then how come there are a thousand and one books that will teach you how to become a (better) programmer. It is teachable, it is a skill, there is no magic component, in spite of what this so-called study says.

Here is the test script:

http://www.eis.mdx.ac.uk/research/PhDArea/saeed/test(week-0)...

Have read, and see what you think, try to pretend that you have no programming knowledge and that all you know is arithmetic, it basically tests a single question in different forms over and over again.

In my opinion, a much better way to grade people to find out who will be the 'good' programmers is to find who is good at solving puzzles.

"The only pre-requirements are a willingness to learn and a willingness to spend the time..."

There are many people for who this is not true when it comes to programming, and this is why they will never become a programmer (good or otherwise).

Almost everything is not hard "in principle", though. In quantum physics, you've got 4 fundamental forces, a handful of elementary particles, and together they explain all of the universe. In medicine, you've got a bunch of organs hooked up to the circulatory/lymphatic/nervous systems, and they make the body go 'round. In molecular biology, you've got 4 bases of DNA and they explain basically everything.

The problem comes from the complex interactions between those elements. You can learn how the body works in high school biology, but that doesn't prepare you to operate on it. Similarly, you can learn how software is constructed ("make sure the right lines of code are used, follow each other, and are debugged properly") from Hacker News, but that doesn't prepare you to actually put those lines of code together.

One of the unfortunate effects of Internet forums is that it seems to have shifted attention from the nitty-gritty details of how to do something to the high-level overview of how to do something. So we have a bunch of programming forums where we talk about programming, but never actually program anything. It's not just programming (just look at reddit.com/r/economics), but programming seems to have been one of the most affected disciplines. But I'm afraid that this is giving a skewed perception of the field to newcomers, such that they look at the code they see on blogs or Hacker News and think that's all there is to programming. The #1 reason people fail Google interviews is because they don't have enough depth: they can recite code snippets they found on the web and maybe even put them together, but they can't analyze the performance of their programs or suggest how they might adapt them if requirements change.

Funny, yes, it really is like that, I call them 'cargo cult coders'.

Able to produce by tying together endless snippets of googled code, it is the professional equivalent of the script kiddie.

Without knowing anything about you, on the basis of this comment, I suspect you are a much better programmer than most people who constantly talk about how difficult their programming work is.

I've been trying for several months now to get my head wrapped around the 'functional paradigm' (oh I hate that word), so far with very little progress so I'm not so sure about that ;)

Having tried to wrap your head around function programming puts you leaps and bounds above most programmers.

I don't think the analogy's a very good one. If you want a housing analogy, I'd say it's more like architecture than ceiling-fan installation. And architecture has, hundreds of years later, never totally coalesced into a science. There are scientific and engineering sub-parts, but still significant "art" parts as well, and good architects are at least reasonably knowledgeable about both.

If you have not yet read Stewart Brand's "How Buildings Learn", I highly recommend it. The basic premise is how the building is built determines how adaptable it is to change.

> With a science of programming, we can aspire to a position where programmers can at least claim to be engineers.

This is not a good aspiration I think. Engineers can be replaced with not huge efforts, while you can't easily replace artists.

Also this vision will lead to more bad programmers coming out from universities (if programming is an art), as the process of learning programming is totally different if you think it's a science or art. If it's a science, do CS courses. If it is an art, put them into craftsman shops to learn how to code.

"Accordingly, programming is not _currently_ a science."

Yes it is, it is just that in information processing, the problem domains are often ill-specified and ill-behaved. The system analyst's job is to pull the pin on a wish list grenade, fling it at the engineers, and run away before they realize what has been done to them. The engineers are then forced to pile crap together, reverse-engineer a problem definition, and see if anybody wants to pay for solving it.