Programmerless programming is just a mirage | Hacker News Reader

Programmerless programming is just a mirage

crazymcphee.net

29 pointsedw51928 comments

Programming isn't about knowing syntax, it's about understanding abstraction. Some people can solve FizzBuzz, some people can't. If you can't abstract then you can't program, regardless of the tools. That's the problem we need to solve, not simplifying the interface.

I've seen secretaries build beautifully elegant systems with Excel Macros and I've seen CS graduates from good schools fail to build even the simplest of programs. I expect most people here have seen similar extremes. A large proportion of CS majors never learn to program. Until we figure out why, and how to change that, 'programmerless programming' is doomed.

The place I work recently encountered someone who couldn't solve FizzBuzz, for the first time. I think a little bit of them died that day - they were looking around with a shocked expression for quite a while.

I hadn't heard of FizzBuzz, but tried it out a moment ago.

How is possible for someone with a rudimentary understanding of programming to be unable to solve this in a couple of minutes?

It's not.

The problem with the world of professional programming is that there are a lot of people claiming to be programmers that aren't.

The reason why people can code-monkey their PHP scripts but not solve FizzBuzz is because of an iterative process. When you are hacking some web page, you just change stuff until it works. You try again and again and again and eventually you're right.

With FizzBuzz, you have to think about a couple things before you answer. It's so simple that you have to get it right the first time; you're supposed to think, then program. But most people are not in the habit of thinking, and just skip right to the press buttons while staring at the blinky cursor stage. Then they fail the FizzBuzz interview.

Thank you, this is very insightful, this idea that some problems are amenable to just trying things and some problems require thought before starting.

The one I was referring to (and apparently others, though they 'solved' it) didn't know about modulo. Which would certainly make it harder, though it's ridiculously fundamental. They worked for about 20 minutes writing out something to do with a 101-element array and decimal arithmetic to initialize it (without using ceil / floor to compare, thus mimicking a mod function) before they admitted they were stuck.

This applicant was a graduate of some fairly high ranked university, though I don't know which one. They can come from anywhere.

Wow. Well, thanks for the FizzBuzz discussion. This self-taught programmer feels just a little less like a bozo. There's hope for me yet!

That's even worse than the CS student (she had a bachelor's degree in CS, and was in the final year of her master's degree program in CS)... she actually attempted to delete an object in C++ by calling its destructor directly.

Needless to say, my company didn't try to keep her when Booz Allen Hamilton recruited her away from us.

To be fair, for some people solving cognitive tasks under pressure is absolutely impossible.

I just wrote a FizzBuzz solving script in python in about two minutes sitting on the couch drinking wine, while the tv is running in the background. But I guarantee you that I would mess it up in an interview situation. Under extreme stress, I do not have the ability to think straight. It's almost as if my mind goes into survival mode, allowing only basic operations in order to ensure a fast reaction time.

Ha you're right about that.

I heard that our brain can only hold a certain amount of blood, and that blood carries the sugar that fuels it. So when you're scared, and blood is pumping to your amygdala, your frontal lobes have less fuel to make decisions.

Do you program for your day job? I do and I've found I'm under that sort of stress consistently, and with harder problems to solve. I guess it does affect me but I've been working on my 'not caring' skills to compensate.

"A large proportion of CS majors never learn to program."

My first reaction was deep scepticism, but in college I did some tutoring of English and CS (no, not together).

I had one CS student who just could not grasp arrays. I tried as many different ways to convey the essential concepts as I could, but I never got through to her.

Maybe I was a bad tutor, but I'm usually pretty good at explaining things, and did well with my other students. (Note to current students: If you can, try to do some tutoring. It helps you develop communication skills, and the feeling you get when you see another student's eyes light up with understanding after you've explained something they were stumbling over is priceless.)

In this case I really felt this poor woman had just picked the wrong major. I finally asked to have someone else take over as her tutor because I clearly wasn't helping her, but maybe she should have been changing majors instead.

I agree with the analysis and have come to the same conclusions over the years. Still, there's one huge exception: the spreadsheet. That's the one UI that has been massively successful at letting non-programmers program without knowing they're doing it.

I think one of the big mistakes is the assumption that one can get away from symbols and language by using gadgets, windows, or flowcharts. Even if you succeed at some level, you end up with a different language, which still requires programming and abstraction skills, but the language usually ends up being inefficient.

I find that written symbols are very efficient. At least, as long as I have this keyboard in front of me.

It's very, very tempting to believe that this is true. However, the example picked - business process management - is such a spectacularly badly tooled, over-promising and under-delivering area that I don't think it's possible to draw conclusions that wide from it.

BPM has the potential to support some really agile business styles, but I just don't see (or hear - maybe I just haven't got my ear close enough to the ground) that it's being applied to the right businesses at the right time. The best time is right at the start, which means that the tools need to be small, simple and agile, not bloated and overweight.

Everyone deals in abstraction to some degree; business owners and managers are no different. We just need to find a way to map their abstractions to ours in a way that's easier for them to understand. I don't know what that would look like, but I also don't expect it to be a dumbing-down. I do know that BPEL and BPMN aren't it.

The thing that I find really strange is that development is becoming more about putting the pieces together and writing code to make small changes than it is about really writing much code. Between the many available jars, gems, plugins, etc. out there, many things we need have been written. While I know some semblance of a programmer will be needed to get things done for some years to come. But at some point, instead of craftsmen, we're going to have more "McDonald's" programmers that are following the book, throwing the code into a microwave, and bagging it.

This is certainly a trend. But it will never take over the entire programming world, and there will always be a supply of more challenging and interesting work for those of us who crave it. In my optimistic moments, I think maybe this trend is a solution for the fundamental problem of the software industry, that the demand for programmers has always by an order of magnitude exceeded the demographic supply of people who can really do it.

It's not a trend. It's the very nature of computer science. COBOL was a way to program computers directly in something like English, without the need for a programmer to write all that machine code and manage the registers. SQL was a way to program computers directly by describing the data you wanted to retrieve, without the need for a programmer to write the COBOL to hit your VSAM tables.

There will always be programming work, because there will always be a need to formalize knowledge and processes - I believe it will eventually be automated, but that is an NLP-equivalent problem. It's not going to be solved with today's technology.

Perhaps a better take-away would be that such "non-programming programming" platforms should still be written by people who understand the processes we've developed to ensure more workable software, things like version control and unit testing. It's not like these couldn't be integrated with this sort of easy-to-access domain-specific tool that permits technically less savvy people to codify some of their own knowledge.

COBOL is the nature of computer science? Couldn't disagree more. It is certainly the nature of the enterprise computing market, though.

easy-to-access domain-specific tool that permits technically less savvy people to codify some of their own knowledge

But this is the pipe dream that the OP argues against, that perennially comes up and inevitably fails. Well, to be more precise, it inevitably fails technically. It often succeeds, in the short term, at convincing people who want to be convinced, and those people are sometimes executives who write checks, so there's usually a buck to be made at it if you want to sell vaporware.

(With, of course, the enormous exception of spreadsheets.)

In 1955, COBOL was the cat's pajamas. The fact that you're unimpressed fifty years later - when COBOL is still the most widespread single programming language on the planet - is precisely because it established the very foundations of your world.

The "pipe dream" fails because it is implemented by people who honestly believe programmers are superfluous if you just automate them away - people who don't actually know how programming works. Excel being a case in point. Have you ever tried to shoehorn an Excel spreadsheet into an enterprise software maintenance program? It's really hard.

I wonder if there's a version of Muphry's Law for condescension. I've been impressed with aspects of COBOL. I even wrote Robert Glass to buy hard copies of his detailed defense of it 5 years ago so I could learn more about what made it great. In certain ways COBOL was better than what came later. Nevertheless what you're saying is historically inaccurate: COBOL was never the cat's pajamas of computer science. It was the original success story of manager-driven development, and that is a very different matter.

Hm. I suppose my use of "computer science" as the study and use of computers was sloppy; blame it on my having studied my computer science at an engineering school. Perhaps you'd be happier had I used the phrase "computing technology"?

Sounds about right.

I remember people saying that, too.

In 1980.

It really isn't true, and the reasons why it isn't true have been known for a long time, and it will never be true, and it is this: A (good) programmer is always prototyping. Virtually by definition, you are doing something that hasn't been done before. If it had been done before, you would buy it or download it, it would be a component, and then you would move on to the part of the problem that hasn't been done before.

It is not true that programming is moving towards a model where you just grab components off the shelf and wire them together. Or if it was true, it has happened, it is in the past, it isn't "becoming" true. All the components mean is that you no longer have to research the best way to handle images, and you get a lot farther before hitting the unsolved part of your problem... but it's only the unsolved part of the problem that is interesting. There's no money in solving solved problems. (Well, that's not entirely true, but this is a comment reply, not an exhaustive description of all programming niches.) The unsolved problem is always the focus and pretty much by definition there will always be more unsolved problems.

If you aren't writing much code and you really, truly are just wiring bits together, it is time to either learn how to write metacode that wires the bits together for you and start wiring much, much faster, or to desperately cast about for a new skillset because you are easily replaceable (or possibly just discardable) and you really need to change that as quickly as you can!

Developers are using more and more code that has already been written. Sure we still code, but if you were coding in 1980 (like I was), then you know what I mean.

I'm with you and the author that the non-technical customer is not going to be able to move the legos around on the screen until they have their working webapp. I've been a part of projects that promised those types of things, and they were failures for the most part.

But, the trend is to have more and more complicated pieces that the developer puts together. The developer feels as if he/she has really done something significant, but what they did technically was more brainless than what a game programmer wrote in assembly in the early eighties, for sure.

If developers need to know less and less about what is really going on, sure maybe they will still be called developers, but they'll be closer in function to the guy making your big mac. It won't happen overnight, but just because it hasn't happened yet and may not happen during our lifetimes doesn't mean it won't.

I expect that in future there will be more automated programming, based upon a vague description of the problem. However, I've seen very little progress made in this domain other than a few applications of genetic programming and the use of Wizards or UML templates.

In the early days of my software career I encountered plenty of situations which had resulted from the use of Wizards to generate database applications by non programmers. The results were always quite disastrous.

In my experience(YMMV) with trying to use BPMN to make inroads into automating workflows at a small financial authority, I had to reduce it to an extremely small subset even just to get business stakeholders to look at the models. The only ones who were assigned to actually help me create the models were the most-spareable, least-knowledgeable people in the organization who pretty much only used a subset reduced to ANDs, ORs, and XORs, and after months, still didn't consistently understand the difference between ORs and XORs. The ability (or even the earnest attempt) to use the symbols correctly had absolutely no relation to the enthusiasm any individual showed towards using heavily marketed tools promising automated execution.

So basically, I was assigned the least knowledgeable people to work on models, and I had to spend an order of magnitude more time redoing their work than they spent doing it. In the end we had a big beautiful graph that no one could verify was accurate in any way except me by describing sections in plain English during the 20 minute meetings I could sometimes wrangle out of the people who knew the business side well enough to give me a plain English answer that was interpreted by me and added to the giant unverifiable graph.

Really a horrible experience all around. And at the beginning of the project, I really thought BPMN looked nice. Of course, I looked at it like a programmer:)

How did they express their models before the BPMN tools?

No matter how easy you make programming there will always be an irreducible complexity in creating a tool for a task. What form that task takes and the difficulty involved may change but ultimately there is a kernel of "programmingness" that you won't be able to get rid of. More so, making easy projects trivial and making hard tasks easy merely makes previously impossible tasks possible, so there will always be developers pushing the envelope programming at the maximum level of difficulty that humans are capable of. No different than any other skill in history.

Reply on news.ycombinator.com