Hacker News Reader

Comment by increment_i | Hacker News Reader

As a 'hobbyist' programmer who makes his money outside of the software game, this is something I've really taken note of. And I have to say the programming tech treadmill is one of the most cringe inducing phenomena I've ever witnessed - particularly in scripting languages. Software folks tend to see themselves as futurists in the fast lane, and as a Hacker News-er I tend to carry myself this way as well. But I kid you not, I can't count the amount of articles I've come across where the title is 'X tech is the new ish! - so rockstar lol' and the article is a simple example of http routing or process spawning. It is SO easy to get caught up in this drivel when you're starting out as a programmer.

I've since learned to use programming languages to solve problems I care about. If that makes me the forever-novice then I'm cool with that.

View on HN

I think this phenomenon is an artifact of the media that we as programmers consume. The easiest way to become an programmer celebrity is to build tools (languages/frameworks/etc.) for other programmers. Many programmers of equal skill are out there programming to solve actual problems, but the HN sphere and like are awash with people programming on programming itself. Which, while is surely intellectually stimulating, does seem a bit 'meta' and removed from why we're all doing this in the first place. But people who work on programming tools get the most press because those topics appeal most broadly to the audience of their peers. Then people in that audience see those topics as 'hot' and focus their energy on them. It's a reinforcing cycle. It reminds me of the ideas in this article: http://slatestarcodex.com/2014/12/17/the-toxoplasma-of-rage/

  > programming on programming itself ... does seem a bit
  > 'meta' and removed from why we're all doing this in the
  > first place.

I heartily disagree, and think that tools vs. "actual problems" is a false dichotomy. Software design/engineering is very much its own discipline. A good API/framework/whatever can lower defect rates and generally make your software more coherent and maintainable. That saves time, money, and headaches. We should absolutely care about the tools we use, because nobody else is going to, hence "programming on programming." Attributing that to a quest for "celebrity" is cynical, and I don't see how you can blame programmers for seeking a good professional reputation by creating tools for their peers.

I teach my kids that the systems they are programming should be considered onions of abstraction layers. They need to understand how to choose from among the options available at each level and to realize that those options are constantly changing.

This onion is the only way we can deal with the ever-widening diversification and combinatorial explosion of hardware platforms, communications channels, types of users, geographic dispersion, data sources, problems to solve, etc.

Improvements at one layer demand adaptations at another; accumulate enough options at one layer and you need to encapsulate them in another. And the bigger these onions get, the more leverage they provide to anyone who uses them, meaning any improvement you make to some part of the onion is contributing to solving a thousand, or a million "actual problems" simultaneously.

If solving end-user problems is "why we're all doing this in the first place," a toolmaker who can solve 50% of each of a million different problems simultaneously is contributing more than those of us who solve the remaining 50% of just one.

So much of the treadmill seems to be about reinventing existing computer science concepts. People learn about a particular concept and become enamoured with a particular pure implementation of that concept.

Just because you need asynchronous I/O doesn't mean that you should exclusively use node.js. And a lot of the hype tends to ignore the underlying CS concept that makes the software worth using. You don't need ElasticSearch because of "search and analytics" but because you have queries that benefit from an inverted index.

But you can find yourself spending too much time coercing technology to do things that it was never designed to do. If you have huge SQL queries to implement basic faceting you should probably just learn ElasticSearch. If you need to completely retrofit a language to do async networking maybe just learn Go.

amen brother (or sister) its the problem that is the cool and interesting part of the job - the tech used to solve the problem is a tool not the end in its self

Software isn't a game, it's an industry. People use particular languages, frameworks, etc. because it makes them more productive. As a professional, I also can't follow every single trend (e.g. I've got no idea what Chef and Puppet are) but I keep an eye on things that are close to my own area, because I don't believe that fads come out of nowhere, or that you can ignore what other people are doing. Most of the major trends I've seen are justified on technological grounds:

Node.js - lets you share code between client and server

Docker - a more reproducible environment than a VM

Python - the most user friendly syntax of any language

You have a fake humility in your post, but I would ask you what particular things (e.g. what scripting languages) you think are "cringe inducing".

Trust me, it's not a fake humility. I really have nothing to do with the development of software in my day to day life. And I wish I could agree with you on the "it's not a game" thing, but having used enterprise Windows software for most of my working life I really can't come to any other conclusion than a lot of the software out there running our day to day lives must be produced in settings not unlike your local McDonald's. Having said that, I've yet to come across a situation where I've shared code between a Node server and client code. Don't get me wrong, I LOVE writing processes in javascript but when I was starting out, the language wars really confused me.

If you work with a lot of bad software, a better conclusion might be that producing good software is hard for multiple reasons than it being a "game".

I agree, but I did not make that conclusion nor did I assert that making good software wasn't "hard", and certainly not because it's a "game".

It's false humility in the sense that you emphasize that you are not a professional, and then go on to precisely attack professionals for their judgement in what languages and frameworks to use and comment on.

I can't comment on enterprise Windows software in itself, since I'm not a big user and have never written it, but the Windows itself could never be compared to McDonalds. Incredible skill and expertise was needed to write Windows. As to the software written on Windows, are you qualified to judge it? Have you written something similar by yourself?

I've never used Node myself, I was just assuming that people really did share some code across server and client in practice (otherwise why not just use Python for the server).

1) I didn't compare the technological achievement of Windows to McDonald's. It was a personal anecdote about enterprise Windows software being so terrible that I'd imagine it wasn't written in an environment where user experience was a major concern. I never compared the OS itself to anything. Do I think I could write something better? As a matter of fact, yes, I think I could. Should I put my money where my mouth is? I suppose I should, but even if I don't certainly I should be allowed to criticize software that I use on a daily basis. After all, I'm the user, no? These are my own observations, surely I don't need to claim they're gospel or apologize for them?

2) Maybe I offended some people when I used the term "software game". Rest assured I was making a slangy generalized reference to the software industry itself, and in no way did I mean to trivialize those who do dev for a living. In fact, I applaud you.

as a profession programmer, i think there are loads of reinvented wheels, churn, bullshit, etc. i think your initial comment that spawned this back and forth is spot on. its an argument about the degree i guess.

Regarding enterprise software, as a user you can say what you thin about the software, but how can you make claims about how things might be better? You could only make that sort of claim if you understood something about what it was like to write that software. As an amateur you know more than the average user, but I would ask you consider that you don't know all the constraints faced by the person writing the actual software

>Maybe I offended some people when I used the term "software game"

Yes, you did offend me. And I appreciate your clarification. My main point was that it's easy to criticize, but until you get your hands dirty, you won't really know what it's like to write software for a large user base. And it doesn't have to be commercial. If you're working of open source software with 100,000 users, your experience is as real as with commercial software.

> Regarding enterprise software, as a user you can say what you thin about the software, but how can you make claims about how things might be better?

Because I'm the USER! If we're hitting a language barrier I apologize but enterprise software is for the user. Surely this cannot be disputed.

> You could only make that sort of claim if you understood something about what it was like to write that software.

NO! IMO, this is an insane way to think about client software! The user doesn't care about the technology nor the hardships involved in shipping said software! This is why software sucks! I can sympathize if you work at a shitty company with a shitty boss, believe me I can. But no, I feel your software should die if this is your ethos. Let a company who cares about its users take those reins!

EDIT: grammar

> I apologize but enterprise software is for the user. Surely this cannot be disputed.

Nope. The reason enterprise software sucks is because it isn't worth making it not suck. And the reason for that is there is a huge disconnect (many layers of management) between the person who buys the software and those that use it. Thus the sucktitude of the software is largely irrelevant for purchasing decisions because the buyer never experiences the pain of using it. This is starting to change as people get more experience with quality consumer software, and such software (e.g. Dropbox) begins to invade the enterprise.

I'm not arguing against your right to complain that software is bad from the user's perspective. But that wasn't your point. You claimed there was something wrong with the software industry, that their failure to produce better software was in some way related to your original post regarding faddishness in the software industry.

That's what I'm arguing against. I'm saying that you can't know the reasons why software sucks unless you've worked as a programmer (or have some other equivalent way of knowing, e.g. being a product manager).

I don't really have a problem with anything he's saying. It's not even a secret that we culturally care only dimly, if at all, about the people who are receiving the photons we spew out of their screens, and we are the worse for it (look at how often people kvetch about PMs who want things that are hard but obviously better for the user). We're too busy looking inward and bragging about our build systems to muster any empathy for people outside our clique.

Your attempts to shut him down with "well you're not there, man" are offensive to me, and I do have the resume to hurdle your arbitrary no-complaints bar. I don't have to be the employee of an oil company to know that regulatory capture's a thing, he doesn't need to be writing a bunch of leet node.js to know that few people working on anything in tech gives a single solitary crap about him or anybody else using their stuff past the buying point.

He's right to be mad about what we, as a culture, foist on our users. It reflects poorly on us that we are not likewise angry. We should be angry about many things and we are not.

I wasn't initially attempting to shut the poster down because they weren't a professional. In later posts I did devolve into saying "well you're not there, man". What I was initially criticizing was the false humility that somehow made not being a professional into a kind of virtue, affording the poster a greater insight than actual professionals:

As a 'hobbyist' programmer who makes his money outside of the software game, ... the programming tech treadmill is one of the most cringe inducing phenomena I've ever witnessed - particularly in scripting languages...

I've since learned to use programming languages to solve problems I care about. If that makes me the forever-novice then I'm cool with that.

I am a professional and I totally second his position. It makes perfect sense to me and illustrates a large chunk of the frustration I feel every time I see the same old stuff in a new package trotted out like it is the greatest thing since sliced bread (only usually a lot less efficient).

Yup. I'll put my thumb on the scale, too. The amount of aggressive reimplementation of the entire universe is something that makes me pretty sad. I think it's most acutely visible in certain parts of the JavaScript ecosystem--Grunt? Gulp? RequireJS? Browserify? Webpack?--where the incremental improvements of a given tool are seen as license to rewrite the universe. Which isn't to say it doesn't exist elsewhere, that's just top-of-mind. And don't think that I'm not aware that there are benefits to those incremental improvements--but we spend so much time on them, on how so much better this is because teensy-change now everybody switch over...I don't think we do much caring about our users. That upsets me.

Saurik had a great post not too long ago[1] that made me think about how Github and the public nature of open source feels almost competitive now. I'm not at all immune to it; when I started running into teeth-pullingly irritating problems with Terraform (written in Go, which I, uh, "don't like" at a minimum), my first thought was "well screw it, I'll go rewrite it in $X and show them!". Fortunately, my good sense prevailed and I wrote a hat on top of Terraform to add some of what I would editorially consider "sanity"[2] on top, but a lot of what I see out there seems to be people succumbing to the siren song of "well, I'll do it myself and it'll be awesome and I'll get all the credit."

[1] - https://news.ycombinator.com/item?id=8854587

[2] - https://github.com/eropple/terraframe

Reducing context switching when working on both, easier to hire people that are fluent in a particular language than people who are fluent in 2, performance, in that order.

I think software as a whole is a lot more subject to fads and personal preference than you're leading on here. Which is okay because picking the exact best technical fit (if it's even possible to figure this out ahead of time) for any given problem will give you tech ADD.

E.g. lots of people use node.js because its in a language they're familiar with and it fills a niche (lightweight process that can accept and process many incoming requests). I use Erlang for those needs, which actually existed before node.js. But it's a "weird" language so most people don't use it.

I like Python more than Ruby. I've learned both but never use Ruby anymore. Other than preference or mandate I'm not sure why I would use one over the other.

Lots of people used to writing in scripting languages seem to be discovering the wonders of a speedy language like Go. You could obviously use speedy languages before Go but their preferences made them not want to use them. For whatever reason Go is attractive to them.

>E.g. lots of people use node.js because its in a language they're familiar with and it fills a niche (lightweight process that can accept and process many incoming requests). I use Erlang for those needs, which actually existed before node.js. But it's a "weird" language so most people don't use it.

If languages are close enough, then yes, familiarity or popularity will influence usage.

>I like Python more than Ruby. I've learned both but never use Ruby anymore. Other than preference or mandate I'm not sure why I would use one over the other.

Never used Ruby, but my impression is that like Python, Ruby is a slow interpreted language with a good set of libraries and user friendly syntax. So you're probably right that there's not much between them.

>Lots of people used to writing in scripting languages seem to be discovering the wonders of a speedy language like Go. You could obviously use speedy languages before Go but their preferences made them not want to use them. For whatever reason Go is attractive to them.

I think that attraction of Go is that there is one build system, one debugger, one linter, etc. Having all these things be take responsibility by the language developers is a big plus as it avoids buck-passing and inconsistencies. While Go doesn't excite me at an emotional level, there are some things that it seems really good at.

How about if a person who develops software for a loving agrees that it seems more and more like a game. Words and phrases like "our stack", "you need X years of Y language," or "we need a Z language dev" and so on all read like rules in a role playing game to me. Sometimes after I read certain posts--and particularly posts gushing over some language's features--I feel a bit surprised the commenters don't mention hearing a "ding" after "leveling up".

Our industry is filled with tens of thousands of professionals carrying on quietly developing software boring and exciting, and inundated with loud mouths acting and speaking in ways strongly suggestive of a certain " gaminess."

Awesome. I can almost visualize playing "Dragon Age" with my daughter while reading your comment.

Considers +2 "XML Mace", but requires level 15 Java Brute Force skills to wield. Reconsidering player "cast", selects +3 "RegEx Dagger", which better matches level 18 Perl Dexterity. Upon leveling up, considers how many XP to spend on "management persuasion" craft skills. :<>

Reply on news.ycombinator.com