Hacker News new | past | comments | ask | show | jobs | submit login
Programming is a Pop Culture (raganwald.posterous.com)
220 points by raganwald on Nov 1, 2012 | hide | past | favorite | 115 comments



This is who we are and what we do.

Not me.

I'm one of those programmers who's been doing this for a million years and would much rather talk about my customers' issues than my own.

To me, programming is just a means to an end. The real issue has always been solving the customer's problem, whether I had to dig deeply into the architecture, use fashionable high level tools, or just resort to pencil, paper, and duct tape. Some of my most rewarding accomplishments have been decidedly "low tech".

I usually find programming meet-ups boring and language centric threads here on Hacker News pointless.

I realize that most programmers don't feel the way I do...so, if programmers are outliers among normals and I'm an outlier among programmers, does that make me an outlier squared or an inlier?


You're a businessman.

To simplify this even more, you believe more in talking about the beautiful houses you've built and how happy the families are in that house. Whereas there is a full sub-culture of those who want to talk about how they found the newest type of wood for making 4x4's or how fast their new hammer swings.

As if my analog can get even more carpenter like...I wrote about this topic more generally recently: http://www.techdisruptive.com/2012/06/29/the-cyclical-nature... I think often we find ourselves obsessing over the importance of the hammer and believe discussions around the hammer are important and therefore warrant endless discussions, meetups, etc.


A hammer is a skill modifier. Don't believe me? Try hammering a nail with the palm of your hand. As a programmer I deal in thoughtstuff, so things like languages and IDEs are decidedly important. We absolutely must obsess over these things else we'll wind up hammering in nails with the palm of our hands (so to speak) forever.

However, should we stick doggedly to a given tool, especially in the presence of something better?

No.


Your point is definitely true. The challenge is that we don't seem to be skilled in distinguish a hammer that is better from one that is simply newer and different. Programming technology seems to be about 20% utility and 80% fashion.

Sure, wearing pants is good and having pockets lets you carry more stuff. But beyond that, changing your wardrobe because cuffs are out or pleats are coming back is just changing just for fashion's sake.

That isn't to say it isn't important: social signaling is a huge part of what human animals do and we can and should never disregard that part of our simian nature. But we also should try to understand when we're picking things for pragmatic versus social reasons.


Cynical people will see a new fashionable language and dismiss it as a pointless new thing to learn. Eager early adopters will jump right in and swear it's the best thing ever. Look, it even makes program X a one-liner!

Both strategies will make suboptimal decisions, but both have their benefits. Sometimes the reason a new language or framework or abstraction or whatever is a bad idea isn't immediately obvious. It takes real experience with something, including the process of learning how to use that thing effectively, to work out when and where it's useful and where it falls down. Cynics are late to see the good. Early adopters are late to see the bad. Hipsters never get around to seeing the bad, or they decide it's irrelevant… until the fashion shifts, anyway.

Whether you pick up every new technology that comes out or whether you wait until they've matured and proven themselves, you'll spend some time using less than optimal tools for whatever you're doing. But I don't think that's avoidable.

Incidentally, I'm not convinced I truly understand a new tool until I can rant about its shortcomings at length and I've spent enough time with it to be reasonably sure it's not just that my brain hasn't yet warped in the right way for it to make sense. And even then I risk being wrong about it.


> The challenge is that we...

I think that this sentence echoes with the OP's last statement. That is, many people absolutely cannot distinguish, but the "we" you mention doesn't describe accurately, well, we. Otherwise, why are we wasting our time with Dart and ClojureScript?

> understand when we're picking things for pragmatic

I don't know you personally (to my great sadness), but I'm willing to bet that we do. :-)


Everyone thinks they are able to distinguish it, clearly not everyone can. Therefore we might be wasting our time with Dart and ClojureScript (they may be shiny and new, but not much better, or we might be right that they truely are better hammers).


That's narrow. He may be a businessman, but that doesn't mean he's not a programmer.


It wasn't a criticism on edw519 but rather on programmers as a group.

As tptacek once said: "Try to get it through your head: people who can simultaneously (a) crank out code (or arrange to have code cranked out) and (b) take responsibility for the business outcome of the problems that code is supposed to solve --- people who can speak both tech and biz --- are exceptionally rare."[1]

I would put Ed in the exceptionally rare category.

[1]- http://news.ycombinator.com/item?id=4247615


There is definitely a pop-culture around programming - but specifically around web application programming; the culture of "web developers" often reminds me a lot of high school social dynamics.

What I've found is that the older and more experienced programmers, such as yourself, have graduated out of that social vMeme and embraced their craft as a "problem solving" one - not one specific to web development, or mobile apps.

I identify more with incisive problem solving than I do with a specific area of problems - while I professionally make my money in the realm of distributed systems and web applications; I also enjoy (and apply) quite a bit of my own learning in the subjects of:

* Psychology

* Maths

* Carpentry

* Mechanics (I use much of what I know about fixing/building cars in the building of my software!)

* Writing

* Many others &c...

So, yes, while I agree there is a pop-culture I wouldn't necessarily say that it is defining of the individual. I built my own business specifically because it was so difficult for me to find a job writing software in Python and Erlang - the status quo was (and other than Ruby On Rails) and still is PHP in my industry. I define my move from running a consulting business building "web apps" to building a high-tech startup, where the "web app" is just 10% of solution to the problem we are solving, as my graduation from pop-culture programming to the more general "problem solving" culture.


This is a relatively new attitude, mostly due to web startups, which are more similar to rock bands than to "real" companies. Since web startups are successful due to the number of followers, not the amount of money they make, they had to develop cult-like techniques to attract workers and early adopters. As a result new culture of hipster programmers appeared, which thinks that their way is the only true way.


I'm not sure I agree. I feel the roots herald from the great education push of the 90s, where we saw a new found hyper-focus on training to specialize to almost the micro level before being worthy of doing any job. In software, that meant being a developer wasn't good enough, you had to be an expert in, say, Perl to be even considered for the job that used that technology.

I feel we have more recently started to back away from that mindset as we have realized that general software developers are more valuable than <insert specific technology> specialists, but you still see job postings boasting about the software stack being used as a throwback to the way it was once done. Possibly because the people involved are still largely stuck in the old mindset. The mid-twenties to early-thirties group of developers grew up during that time period, so they see it as just the way it is.


> the great education push of the 90s, where we saw a new found hyper-focus on training to specialize to almost the micro level before being worthy of doing any job

This is off-topic, but I'd like to know more about this. Could you give me some keywords to search off, or some links to read, to see what you're talking about?


Agree so hard. Start a band(startup) in your garage(garage) with four of your talented musician(programmer) buddies, work long hard hours eating ramen for the love of rock music(hipster programming), get a facebook following(twitter/blog following), get an indie record deal(angel funding) then sign a major label deal (VC funding) and then have the record company(VC firm) dictate your musical direction(business decisions) and take most of your royalties(equity) away in exchange for risking the initial advance, which was only a leveraged loan against future earnings anyway.

The VC and record label model are similar too. Invest in 100 promising bands(startups) and hopefully 5 of them are successes and 2 hit it out of the park(IPO).


that is unnecessarily dismissive of an entire class of programmers (who were, let me add, around long before the web startup explosion). focusing on solving the user's problem is a valuable mindset, and is after all what keeps the industry alive, but focusing on solving the programmer's problem is equally valuable, and helps keep the industry productive.

at the end of the day, yes, you can take a deep breath or several and crank out tens of thousands of lines of java which do the job perfectly well. but you can also notice that bits of it are far more easily done in jruby or clojure, and publish an article outlining your observations that lets the next person who has the same problem get it done with a lot less work and a lower error-rate, and surely that is worth something too.


Very good point. I would say that younger developers are taught to behave in hipster way as a means to get a good standing with their peers.


I guess this will get rapidly downvoted, but let me say it anyways, because I've always felt there's more than a grain of truth to it - If you want to obtain $$, and you feel the way to obtain $$ is to find this mythical customer, and then solve that customer's problem, and then get that customer to part with his $$, so his $$ becomes your $$....its extremely longwinded and convoluted and most importantly, unnecessary. I had this professor at UChicago who used to say people who did not have a ballmark estimate of M1 & M2 should not even talk about money, let alone suggest how to make it ( http://upload.wikimedia.org/wikipedia/en/5/58/MB%2C_M1_and_M... ) Now its one thing if you are working at a high beta startup...going from 0 to 100MM in a few short years is definitely commendable. But otherwise, this whole idea of squirreling away money little bit by little bit as you find customers and solve their mundane IT problems, whilst not taking an interest in the "pointless meetups & language-centric threads"...is like, I dunno, computing the Riemann integral of some exponential function by taking tiny narrow slices and systematically adding them up one by one. While the procedure is very sound & society will commend you for being this patient, upright, model citizen, you are never going to ever compute that integral this way...life is just too short & there will always be 20 year old Zucks around who will plug the upper & lower bounds into a closed form formula & spit out the answer you were chasing for your entire life. Its just not worth it.

Instead, do it for the fun.


I realize that most programmers don't feel the way I do...

That could be selection bias: how many programmers like you are posting in HN threads, blogging, etc.? I'd venture to guess most are, um, programming instead. The best programmers I know certainly are.


Actually I have 25+ years of programming under the belt and I agree with the observation, so I do feel the same way.

And it is not about being a business men as opposed to a programmer. To me is also a means to an end. OF course is nice to develop for the sake of, but is not reality when it becomes the source of your livelihood.

Having say that, I have observed a pop-culture attitude, but I have not found that attitude in programmers with more than 10 years of experience, so I have always attributed it to youthfulness as opposed to be a characteristic of the profession.


I started off that way. I only reluctantly agreed to start programming to "get things done" for clients. I decided I'd be a solid "business programmer", only interested in coding to solve problems.

Unfortunately, discovering technical things proved to be too delightful. Nowadays, I'd much rather spend time figuring out something, playing with algorithms or doing something technical like reverse engineering, rather than actually trying to delivered a production system.

There's joy in solving problems. A 15-minute script saving an employee _hours_ of work a day - that's awesome. But production, finished, systems usually seem to end up with all sorts of boring "cruft" to deal with the imperfections and craziness of the real world.


When the hackers at MIT in the 60s mostly build tools for programming. Lots of people made fun of them, silly people tring to implement fast lisps, debuggers and simular things. Everybody know that one should fucus on developing useful things with the tools that are allready there.

Its ok to focus on current technology to do something for a time but just never advancing and trying something new is not pointless.


No, I'm the same way. Or at least I've started to become that way.

Conversations about all the cool technologies someone has used in their stack bore me. Or hearing about the wonders of automated testing. Etc, etc.

I find it quite useful, though, to be able to understand tech and also know how it sounds to the muggles. I'm a "business guy" with a CS degree. It's pretty valuable these days to be a translator between the two worlds. In fact, that's precisely what the startup I run helps people with (or aims to).

A lesser benefit is perspective. Guys like us are naturally "duct-tape programmers" - we don't enjoy coding for it's own sake, so we prefer quick 'n' dirty solutions. To be fair, most of the time things should be built properly, but sometimes the duct-tape approach is better.


Have you ever thought of being a project manager or biz dev person? That role usually requires (or benefits from) having past programming experience and the ability to have the skill set to translate and have good communication between tech people and non-tech. I'm a front-end dev/designer but I like communicating with non-tech people and being able to relay that back to a developer in a format that makes him more productive.


Not meaning to nitpick but already doing it... I think you're talking about product managers, as opposed to project managers? Most project managers I know are only spreadsheet pushers while the product managers know a lot about the tech and biz aspects of the project.


For me its all about the right tool for the right job. I'm not talking about languages here.

Sometimes duct tape is the right tool. Sometimes a very well architected program is. It all depends on so many variables.


I don't understand the distinction made here between a craft and a pop culture. Popularity of a technique or tool can definitely matter to a craftsperson, as they directly impact the availability and cost, as well as the marketability of that craftsperson's skills. Crafts are social; craftspeople definitely pay attention to what their colleagues and competitors are thinking and doing, and trends come and go as opinion leaders and trendsetters rise and fall.

The biggest distinction I can think of between a craft and a popular culture is that pop culture is most commonly experienced passively, via consumption, while being a craftsperson by definition involves active creation. So in this sense music is really two cultures: the culture of music creation, which is a craft, and the culture of music appreciation, which is a pop culture.


I think your passive vs active distinction is a good one but I don't think that was the direction taken in the post, the distinction drawn here is how solutions to problems are chosen. Roughly: pop culture will chose a solution based on fashion while a craft will chose a solution based on the perceived quality of both the solution itself and the result. Obviously these two aspects are mixed in reality but the point that it's more fashion than craft is one I find convincing.

What I don't find convincing is the defence of fashion driven programming techniques. Too much of an ode to mediocrity for my taste. Pop culture will be mediocre and fashion driven on it's own, the only thing pushing it to be better is the craftspeople complaining about it.

As more and more of our infrastructure runs on software we need people pushing for more engineering discipline, not less.


> pop culture is most commonly experienced passively, via consumption, while being a craftsperson by definition involves active creation

I don't agree with that distinction. Every pop culture has two sides, the consumer and the creator. What makes it pop is the immediacy and the need to affirm itself by popularity only. In other words, if something is not popular, it can't be pop.


Novelty for its own sake aka fashion.


I agree with that. This article seems to focus on the craft of language creation and specification versus the pop culture of consuming languages and creating with them.

Like musicians, language advocates must dance the dance to have their message accepted by the masses.


The author seems to think the programming community is limited to web development, or cool new techniques and languages. There is a vast amount of slowly or non-evolving programming, from maintaining legacy COBOL banking systems, to writing groundbreaking technology with mature languages like C.

People who write code for SpaceX or use Fortran at CERN to solve the mysteries of the universe probably don't see this "pop culture" and the constant pressure of using the latest idiom. All you can say is that some aspects of the industry act like this, in which case you're not really saying a lot.


The author recalls writing banking code that talked to a "legacy" application written in MUMPS :-)


So? I've got semi-recent code that sucks data out of InterSystems Caché with yet another obselete programming language. The ability to access legacy systems to assist clients is a sign of craft, not necessary pop-culture programming.


It could also be a sign of engineering. All metaphors are leaky, some more so than others, especially mine.


I think that programming is a microcosm of culture as a whole, not just pop culture. On one end you have the pop aspects of it (Node, Ruby, <insert trendy language/framework>, and at the other end you have COBOL and Fortran and other 'un-hip' languages. In-between is everything that makes up the programming culture.


Many things in programming are like that. Why do you use CamelCase in JavaScript but underscores_in_ruby? Because everyone else does, and that’s the language’s "style."

By that logic, driving on the right side of the road in the US vs driving on the left in the UK is "pop culture".

The reasoning in the article didn't improve as I read on...


>>>By that logic, driving on the right side of the road in the US vs driving on the left in the UK is "pop culture"

Well, if using the definition of pop culture described in this article, pop culture evolves. Where countries drive on the road can be related more to how programming languages define blocks of code. C-like languages use curly braces to define blocks. This can be related to how since medieval times, horses rode on the left side of the road. More modern languages use different ways to define blocks of code. For example, Python uses tabbing and whitespace, Ruby uses the `end` keyword.

Continuing to use the traffic analogy, you don't have to use cruise control while driving on a long stretch of highway, but it's a lot easier to, and everyone else does. In the article, raganwald is talking about how coding conventions and techniques evolve over time. The analogy about driving in the UK vs the US is more equivalent to the syntactic rules of the specific language you are working with; it's the law which side of the road to drive on. You'll get penalized if you do otherwise. Using or not using cruise control is your choice, and so are naming conventions in different languages. Conventions evolve, even when the specific "laws" of the languages don't change as quickly, or at all.


CamelCasing is not enforced, while driving on the right side is.


I've driven in countries where no traffic laws are enforced. People still pick a side of the road to drive on.

And it isn't because it's superficial and fashionable. It's because there are underlying logical reasons for doing what the rest of the herd is doing.

Likewise with sticking to coding conventions for a language.


Laws in any given system are a process of Spontaneous order (http://en.wikipedia.org/wiki/Spontaneous_order).

The performance of every given actor in the system is inhanced by everybody else adopting the system. Its absolutly normual and good. Thats how our social liver works in general, the state mostly only comes in later and writes stuff down.


The article makes some good points, but I think they apply almost equality to both science and engineering, and frankly everything else.


>By that logic, driving on the right side of the road in the US vs driving on the left in the UK is "pop culture".

Not at all. I don't drive on the right side because "everyone else does" and "that's the style". I do it because its the law, and because I would be risking my life and the lives of others to do otherwise. Having a function with an underscore in its name isn't breaking any laws, and isn't risking any lives or anything even remotely analogous. It is entirely based on subjective whims.


You risk confusing and annoying other people who read your code. It's a non-lethal risk, to be sure, but still a reason to follow the local naming customs.


You risk confusing and annoying other people who read your code if you do follow convention also. I hate camelCase just as much in languages where it is customary as I do any other time. It is just a question of how many people you expect to annoy, which is precisely choosing it by popularity.


With Python at least, it's effectively the law, or at least is defined in PEP8.

PEP8 is tricky because it's technically a "style guide", but heaven help you if you're trying to get your code into somebody else's repository and aren't abiding its tenets.

http://www.python.org/dev/peps/pep-0008/


There are 2 factors that would keep you from switching styles: inertia, and symmetry. The benefit from keeping the code looking good usually outweighs the gratification of "going on your own". And frankly if you 're changing coding style in your contribution you look like a prick. The OP's point is valid: it's not popularity that leads to standardization it's because of the initial standardization that it is later adopted.

Case in point: i don't know any major project that does not follow the style conventions of the framework it's built upon.


OP has misunderstood Dr. Kay's comment. He specifically made the comment -- at least in one occasion -- in context of music and noted the fact that "pop music" uses a tiny tiny subset of the available body of musical thought and precedent.

As regarding our field being an arts and crafts field, again, imo, OP misses the mark. It is an arts and craft field because of a lack of an underlying science of creating software.

The issue of scaling to meet the industrial demand on our output, of course, has been clear and evident since 70s, if not 60s, and clearly contributes to unique nature of our 'technological' field, but that inability to scale by adopting an industrial methodology is, again, due to a lack of a sufficient intellectual base to support an industrial process.


This is just link bait for raganwald to sell his new coffeescript book. Why do his blog posts always make it to the top of HN?


In 1977, the movie "Saturday Night Fever" was link bait for Robert Stigwood to sell the sound track album. That same year, George Lucas released "Star Wars," and one of his business goals from the start was to "Build a Real Company," which he did by exploiting merchandising tie-ins.

"Link baiting" to sell a book is a kind of tie-in, just like sound track albums and toys. If what you say is true, then this post is an example of the pop culture it depicts. That would be pleasingly self-referential.

Alas, it isn't true. I wrote a different post yesterday, one about the I Combinator in CoffeeScript. That one was a deliberate tie-in to my book. Some of the feedback I got from /r/javascript was that the idioms were unfamiliar to the JavaScript culture, which provoked this post.

So yes, I do write posts with the thought of promoting my book, but no, this wasn't one of them. But yes, as long as I'm writing a post I include a link to my book. Why not? I read a lot of posts with advertisements on them. Why advertise someone else's dream?


I guess I didn't have much of a problem with you linking to your book, as much as the disconnect between what I read and how quickly it shot up the front page. You are apparently a rock star. It fits right in with your pop culture theme. I apologize for the comment. I will prepare to see your blog on top of HN for the foreseeable future.


I am somewhat loathe to break out the slashdot cliché "you must be new here", but it's apropos here. Reg is popular on this particular internet.

What I'm more puzzled by is why he seems to have written a Rorschach test instead of a post with a point. An awareness of the sociology of your chosen profession or discipline i think is a laudable goal and topic worth considering, but this post doesn't actually do anything to illuminate the subject or equip others with the tools necessary to consider the subject further.

Unsurprisingly, the comments resulting from the post are similarly lacking illumination.


I try to write a lot and experiment with different styles. This one was dashed off almost stream-of-consciousness. I'm not offended by the suggestion that it isn't my best work, and I'm grateful for the candid feedback.


Sure, also, don't take my criticism as an admonishment or lack of respect. From your posts that I've read, you and I agree on a great deal, and I aspire to write as prolifically and competently as you do.


Just as an FYI, although this post did do well here on HN and get quite a few tweets, it had a negligible effect on my daily book sales. It's dangerous to generalize from n=1, but my conjecture (that needs some validation) is that posts need to be strongly related to the subject of the book to pull sales.


Rock Stars come and Rock Stars go. I'm not counting on people liking my posts tomorrow, much less for the foreseeable future, especially if I can't do better than this one.


Why do his blog posts always make it to the top of HN

He writes well.

He often makes interesting points or expresses a provocative (in a good way) POV.

He has been a notable contributor to HN, trying to keep the discourse here civil and high-signal.

Good for him if he has a Coffescript book for sale. I'm not a Coffeescrpt fan, but I'd bet this book is good.

"Link bait" is perhaps the last thing that comes to mind when I see a post from Reg.


> Why do his blog posts always make it to the top of HN?

Because I like them. They are usually interesting and I even learned to recognize his nickname on HN because of quality of his writing. So I upvote.

Repeat that times 100 other HNers who think the same.


I think a lot of people upvote articles without reading them, but just because they like the title or the author. That, or more popular HNers get all their friends to upvote their blog posts.


I think a lot of people upvote articles without reading them, just because they like the title or the author. That, or more popular HNers get all their friends to upvote their blog posts.


I see you've watched the same Alan Kay talk as I have. It certainly changed my opinions about plenty of things.

Many of my colleagues leer at me when I suggest that Computer Science is not so much a field today as it is a pop-culture. We continue to experience novel technology not because it is new but because we continue to forget our past achievements. Innovation has been slow in this culture (I would go so far as to say painfully slow). Worse, it dates me when I gather amongst my younger colleagues and I cannot stand it any longer! I'm not a dinosaur. Not even close!

And still it moves at a lightning pace!


I love this idea - I think it helps to explain the existence of rockstar developers who then become arbiters of what is valuable - a bit like musicians who become critics after they've made their name!

Also, new(er) developers seem to like to set themselves against the mainstream as if to say, 'this isn't your parents' language', until they eventually end up liking jazz (lisp?).


I'm not sure about lisp.... but that's a definite pattern.

e.g. Let's throw away these unwieldy relational databases! And then spend years adding the functionality back in, piecemeal and part-complete!


Who are these famous former-musicians who have become music critics?


Former musicians who become cultural arbiters are the ones that start their own labels (critics who put their money where their mouth is). Examples are everywhere. Mo Wax, Twisted Nerve, Chemikal Underground, Third Man, etc


The author makes the case that programming is a trend-ridden profession, that is false. Some programming styles and languages get widespread not because of herd-like memetism, but because they're actually better than alternatives, or some cases because of a corporate choice (such as objC, win32's CamelCase, javascript's java like syntax(Sun) ). In fact most of the evolution of programming ended in the 80s. The frontpages of reddit and HN are full of people who are overly enthusiastic about things like functional languages, 16 bit CPUs, CSS programming and rounded rectangles, but those are rarely more than the fad of the day. For most people who want to solve problems with computers, programming is a tool. You don't see plumbers and electricians choose their tools based on how cool and fashionable they look.


The interesting thing here is people equate pop culture with being trendy. I think it's entirely possible for a pop culture of programming to exist, but I think in general what this discussion on this thread proves is that there are multiple cultures existing within developer communities, and a lot of devs exist within many of these circles. What's more, the "pop culture" element of programming does not necessarily contribute to the rate of change! The communication mechanisms within programming (Hacker News, Twitter, Reditt, mailing lists, forums etc, that is what accelerates the rate of change within the developer community. Pop culture is actually NOT that fast. People need to spend time performing it before something becomes pop (i.e. the idea that Hipsters start all fads, because they find them first and that is how they spread)

I would say The Active Contributors--The people contribute to open source projects mailing lists etc. These people help promote certain "styles" of programming over others. They contribute to make the things that work even better. These things they create are then consumed by other members of the community.


Pop culture is by nature trendy, you can only listen so many times to the same song before it gets boring. Popular art aims to please, pleasure has certain characteristics, it gets old, it gets kitsch and is driven by novelty. There's no such comparison for programming, you can use the same old language millions of times without any diminishing returns. It's really not even a valid comparison, it's apples to oranges. The one relevant analogy i can think of is between programming languages and musical instruments.

Also, IMHO there are no superstar programmers who can influence developers. All the good devs i know are too arrogant to take any suggestion based only on who suggested it.


> You don't see plumbers and electricians choose their tools based on how cool and fashionable they look.

I'm not sure that's a useful comparison. I would argue that plumbers and electricians have a more clearly defined problem space with a large body of existing solutions and conventions. Programming as a trade, or craft however is considerably less mature and what may look to you like developers choosing tools based on fashion is probably more a reflection of how far we are from settling on a the _right_ way to build software.


Does anyone else think that this article is a Satire? I think it's actually an appeal to common sense. What I read is the author is sad that programming is not moving in the direction of an emergent engineering discipline, sad that popularity, not reason, drives the acceptance of languages.


Engineering disciplines are characterized by extensive standardized formal study, conformance to best practices, and regulation.

Actually, this is only true in programming pop culture. In reality, different engineering disciplines vary widely in the degree to which these features are present.

In my opinion, none of those listed are even especially central or important. (And as a result, I'd argue[1] that software development, as currently practiced, fits quite comfortably in the broader stable of engineering disciplines.)

[1] http://www.zerobanana.com/essays/reclaiming-software-enginee...


Programming is an engineering discipline. Engineering has some things of crafts and is influenced by a culture. It is the same in any kind of engineering, there are fashions in bio-chemisty as there are fashions in how you build a bridge or how you design an electronical circuit. In the 70s, it was in fashion to make buildings with a lot of asbestos in it, just like in the late 90s everybody used to build systems around SQL databases. But now people don't do it so much, not because the culture has changed, but because it was not such a great idea in the first place, and as we progress in our field, we know how to make things better.


"Ruby Archeologists can accurately date a business application by examining its gemspec file" - seems like a fun/small project to do programmatically. How fresh is your spec?


Python's style guidelines are laid out in pep 8[1] and are not likely to change with the times. Things like indentation, using underscores in variable names, and even spacing between classes and method declarations are specified in there.

[1] http://www.python.org/dev/peps/pep-0008/


If programming is a Pop Culture, Python is a Cult of Personality:

https://www.youtube.com/watch?v=7xxgRUyzgs0


Amazing quote from the XML rant linked in the article:

"If GML was an infant, SGML is the bright youngster far exceeds expectations and made its parents too proud, but XML is the drug-addicted gang member who had committed his first murder before he had sex, which was rape."


For more Naggum diatribes, visit http://www.xach.com/naggum/articles/.


Really interesting article and unique way to look at programming - never really considered it to be part of pop culture, but it is a subset of it's own and becoming more "mainstream" as more and more technology becomes engrained in our everyday life.

Well done!


'The programming language BASIC became popular because Dartmouth had it on a computer system, and General Electric franchised that system. Once it spread “in the wild,” it became popular because it was popular.'

Or: it was used because it was available.


Unless you're willing to concede that programming is something that takes zero skill, art, or craft, the argument is idiotic. A pop culture is something anyone can be part of. There is no barrier to entry like there is with programming. No loss, no reward. Why not just concede that programming is something that's never existed before, which can have it's own idiums and rules? Trying to shoe horn it into the pop-culture mold is as bad as calling it a trade.


On second thought, that's wrong. I have one that fits. Programming is a knighthood. Think about it.


Possibly related (from 2005): "SOA, AJAX and REST: The Software Industry Devolves into the Fashion Industry"

http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=018ea5...


raganwald, your blog post titles are getting more linkbaity by the week.


It's a down economy after all, and Christmas is coming up.


"Why do you use CamelCase in JavaScript but underscores_in_ruby?"

Uhh, because the languages' runtime libraries use that convention? For the same reason that Windows C/C++ coders typically use a different style than Unix C/C++ coders? The platform runtime libraries set it forth?


Yeah, that was in fact the gist of the next sentence in the essay.


Actually he makes the opposite (wrong) causal argument that because of popularity these styles caught on and became the "language's style". Nothing to do with popularity, it was all predetermined in the vendor's libraries.


Programming is both a craft and a pop culture but when you use programming as part of an engineering discipline that's called software engineering.

Whether software engineering is on par with its more respectable siblings mechanical and electrical is a different question.


Starts off by appearing to agree with an insightful remark by Alan Kay, proceeds to reverse course and sympathise with the status quo, ends with a sentimental appeal to the 'humanity' of popular culture. Sadly proves the very point Alan Kay was making.


More blogger polemics. The word is "has," not "is."


...but that model gave us Bowerbirds, birds that build elaborate structures that don’t do anything except demonstrate its fitness to spend large amounts of time building elaborate structures. The first thing I thought when I read this was Dribbble. I'm also a designer and have definitely gawked at the immense amount of time some members of that site have spent on entirely useless pixel perfection. I don't really feel the same way about programming, though. I'd much rather dash through a project and get it functional than craft it such that the code is beautiful.


A pop song (even a teriffic one) has a shelf life of a few months, whereas code running in production, either foundational or in larger systems may be there for years. That's where developers need to build things that last, and things turn to more technically complex musical genres like Jazz or Classical where the music may not be catchy - but will last a long time. The lasting pop songs are the ones hardest to compose, but maybe the most beutiful - http://www.youtube.com/watch?v=jBDF04fQKtQ


Programming is like building a house - except that no one talks about themselves as being a "house builder".

There are carpenters, electricians, HVAC contractors, general contractors, landscape architects, plumbers, cabinet fitters, tiling contractors, painters, carpet installers, roofers, architects, etc.

Each one takes a pride in their own craft and together they build house with (hopefully) the minimum of squabbling and turf wars.

One day the process of solving problems using computers will be like that, right now we are in the dark ages.


Errr... not really a valid analogy surely?

I've done varied load of stuff from kernel hacking to Javascript widgets. Now most of my professional work leans more towards low-level and backend stuff in C, but that doesn't mean I can't turn my hand to other things and understand them quickly. The principles are the same in most cases.

Carpentry and electrical work are separate disciplines. Systems programming in C and web-frontend hacking in CSS/whatever are would be just like using different types of wood and knowing which joins and what adhesives go well with them.

There's no need to limit yourself to one tool is there?


I agree with you, though carpentry and cabinet making are generally considered different disciplines despite using many of the same tools and materials. That might be a little closer analogy with respect to kernel hackers and web hackers.

Me? I just like to solve problems. If the problem requires hacking a kernel, I'll do that. If it requires baking a cake, I'll do that. If I need to print a circuit board, I'll do that. I don't see any reason to get too caught up in tools, personally.


And we have systems programmers - including kernel developers, compiler writers, etc -, web developers (often divided into backend and frontend), security experts.

And we do "build houses" with a minimum of squabbling; when was the last time you heard of a web startup hacking on the Ruby core or the Linux kernel? And the compiler vendor deciding what kinds of programs should be done with it?

On the contrary; our work is very specialized. It's just that when we build some house foundations, we can just then ship'em out to others to use, as prefabricated components.


Programming is like building a house - except that no one talks about themselves as being a "house builder".

Flawed analogy. Programming is more like being a carpenter or an electrician or a landscaper.


That was my point - an individual practitioner is like any one of those roles I mentioned. The problem is that we are all lumped together under the nebulous term "programmer" - and that leads to unnecessary antagonism.


"[Programming] spreads much, much faster than education and formal study spreads."

This is why a Computer Science education is not a sufficient condition to a successful career as a software developer.


Programming isn't all there is to software development though.

Be honest now, in how many of all the colossal fuck ups in development there have been, do you think the CODING was the problem?


Good point. Estimation and planning has seem to be two huge factors in failing (missing the deadline) in my experience. But software projects fail for many other reasons as well.

I have read Agile Estimation and planning http://www.amazon.com/Agile-Estimating-Planning-Mike-Cohn/dp... but I'm not at a high enough level in my career for software planning.

Little tangent.


What I find most interesting about this post is that the comments section is replaced with links to Reddit and Hacker News. Not a bad way to stir up attention to a post.


Putting a 'Discuss on Hacker News' link instead of comments section is a common practice as of late. It's not just this particular author.


Imagine we had never heard of this "comments" idea. How would we design such a feature? For starters, we'd need moderation. Some automated spam blocking. Voting might be a nice feature to draw attention to good comments. Reputation for the participants might help.

We'd end up reinventing HN, Reddit, Digg, &c. One of the reasons I prefer to link to HN is that there is a community with a well-understood standard for behaviour. If I had my own comments, I'd have to ask people to live up to some set of arbitrary standards, and that's a lot to ask when someone might only read one thing from me every month or so.


You have a good point. It really depends on how well of a fit the audience in question is to your content. If you're trying to build your own community then it makes sense to maintain your own comments and moderate them yourself.


That strategy works very well for Jeff Atwood, so I'd say you have something there.


This is just the first time I've seen it. I wonder what the policy is on creating an off-site mechanism to post to Hacker News. I looked over the various APIs and none seem to offer a method to post a link. They're mainly read-only.


The article starts by presenting the false dichotomy that programming is either an engineering discipline or a "craft" which the author defines as something learned informally through self-guided study. (Can't engineering disciplines be learned through self-guided study?) Then the author makes some comment about how BASIC "became popular because it was popular", and then I realized I was reading the ramblings of an idiot and I stopped reading.


Programming is pop culture - but it is not about rejecting science it is because the science is mostly irrelevant for the day to day programming. Parser combinators might be cute - but you don't need to write parsers in your day to day job - you just use a library that does the parsing. In a way you do use the science in fact it is just so isolated that it is not really your job.


I didn't understand the photo in the article.


It's the bower of a bowerbird. Note the small nuggets of brown feces on the left: These represent blog posts ;-)


That clears it up :)


Not the way I do it. Hey! Does that make me an aging rock star? Or just a has-been. Hm.


> Does that make me an aging rock star? Or just a has-been.

Jethro Tull has you covered: http://remus.rutgers.edu/JethroTull/Albums/TooOldToRocknRoll...


I think it is more that programming has a pop culture, not that it is a pop culture. Parser combinator avoidance is a good example. The pop culture does avoid it, but not everyone is part of that. Parsec and attoparsec are very heavily used in haskell land. Just as there's people who reject or ignore pop culture in society. Society isn't pop culture, it just has a pop culture (or several pop cultures).


I must say that i always love programming.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: