Programming is a Pop Culture
raganwald.posterous.com
raganwald.posterous.com
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?
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.
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.
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 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.
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?
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.
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).
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.
However, should we stick doggedly to a given tool, especially in the presence of something better?
No.
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.
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. :-)
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.
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.
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.
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.
Sometimes duct tape is the right tool. Sometimes a very well architected program is. It all depends on so many variables.
Its ok to focus on current technology to do something for a time but just never advancing and trying something new is not pointless.
Instead, do it for the fun.
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.
Like musicians, language advocates must dance the dance to have their message accepted by the masses.
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.
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.
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.
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...
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.
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.
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.
Case in point: i don't know any major project that does not follow the style conventions of the framework it's built upon.
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.
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.
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.
"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?
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.
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.
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.
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!
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?).
e.g. Let's throw away these unwieldy relational databases! And then spend years adding the functionality back in, piecemeal and part-complete!
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.
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.
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.
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...
"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."
Well done!
Or: it was used because it was available.
http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=018ea5...
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?
Whether software engineering is on par with its more respectable siblings mechanical and electrical is a different question.
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.
Flawed analogy. Programming is more like being a carpenter or an electrician or a landscaper.
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.
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?
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.
This is why a Computer Science education is not a sufficient condition to a successful career as a software developer.
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?
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.
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.
Jethro Tull has you covered: http://remus.rutgers.edu/JethroTull/Albums/TooOldToRocknRoll...