Live data from Hacker News

The Programming Steamroller Waits For No One (2013)

thecodist.com

11–20 of 48 posts

Re: The Programming Steamroller Waits For No One (2013)

#13

There is no steamroller. I know many programmers feel this way, but in my humble opinion it is a fallacy, and not a very healthy one. No-one can deny that our industry is evolving at breakneck speed, and it is an exhilarating place to be. But just because there's a new technology every week on HN doesn't mean that we are losing old ones at a similar rate. It is perfectly possible to have done nothing but C or Java fo…

This is actually a very good response. There are new technologies sprouting up continuously but only a few survive. However, the older ones have already shown resilience and will likely survive a long time (C/C++ and Java were mentioned).

Re: The Programming Steamroller Waits For No One (2013)

#14

There is no steamroller. I know many programmers feel this way, but in my humble opinion it is a fallacy, and not a very healthy one. No-one can deny that our industry is evolving at breakneck speed, and it is an exhilarating place to be. But just because there's a new technology every week on HN doesn't mean that we are losing old ones at a similar rate. It is perfectly possible to have done nothing but C or Java fo…

I'm in agreement here. The engineers that will lose out are the ones that think that by learning the latest and greatest frameworks and libraries, they are somehow improving in their mastery.

This is, in fact, stamp collecting. Fewer and fewer engineers feel comfortable doing the basics. Implementing a raw custom data structure, writing a new parser, twiddling bits on a wire, debugging segmentation faults. The new-age programmer is in reality, a scripter who learns hundreds of different ways to do more or less the same thing.

There is no steamroller, but there is stagnation.

Re: The Programming Steamroller Waits For No One (2013)

#15

There is no steamroller. I know many programmers feel this way, but in my humble opinion it is a fallacy, and not a very healthy one. No-one can deny that our industry is evolving at breakneck speed, and it is an exhilarating place to be. But just because there's a new technology every week on HN doesn't mean that we are losing old ones at a similar rate. It is perfectly possible to have done nothing but C or Java fo…

> - and if you love it then you will pick up new technologies out of sheer intellectual curiosity.

I like learning new concepts. I don't like learning things that are kind of the same as the what I'm already used to, lacks 5% of what I had in the 'previous' technology, adds 5% of what that other 20 year old technology did (and did better) that I already know, and "learning it" is more about rote learning and getting used to corner cases than it is about gaining a new perspective.

I don't know the ratio of this type of learning to the more perspective-shifting type of learning.

Re: The Programming Steamroller Waits For No One (2013)

#16

There is no steamroller. I know many programmers feel this way, but in my humble opinion it is a fallacy, and not a very healthy one. No-one can deny that our industry is evolving at breakneck speed, and it is an exhilarating place to be. But just because there's a new technology every week on HN doesn't mean that we are losing old ones at a similar rate. It is perfectly possible to have done nothing but C or Java fo…

"It is perfectly possible to have done nothing but C or Java for your entire career and yet remain extremely employable."

I am Java programmer and the above seems to be true. However, it does not mean that Java programmers can stop learning and code as if it would be 1995. Even if you confine yourself into Java world only, there is enough to be learned in five lifetimes.

Many people here equate "learning something new" with "learning new cool programming language". It is sort of fallacy. New or improved frameworks are coming out every day. You can lean new design patterns, whole domains or simply dedicate few years to security, algorithms, graphics, gui design, sound manipulation, internals of common data formats etc.

That being said, it is ok to skip a technology or two. Most of them will disappear in few years anyway.

Re: The Programming Steamroller Waits For No One (2013)

#17

I think it is funny how he sees managers - the ranks of managers include those who could not stay ahead and were flattened by the steamroller. Do managers see themselves that way or in the cab driving the thing?

As an engineer that has been a 90% manager for the past five years, I just got utterly bored with the "steamroller".

This so called steamroller is IMHO just mostly riding around in circles, and when you've been in the business long enough you start recognizing the repetitive scenery.

Staying in front of the steamroller is neither a goal nor a means to an end. It's a distraction. You're better off getting out of its path and observing, and pick up only the stuff you really need. Be it for the job your doing or to keep up your market value.

But for either of those you only need one out of a dozen new shiny toys every once in a while, not all of them.

Re: The Programming Steamroller Waits For No One (2013)

#18
In my opinion, this is less of a problem for a programmer than for a product-company.

Depending on the size of the change, a reasonably competent programmer can pick up enough of a new programming language or framework in something between a weekend and a month of playing around with it.

However, if a company has invested years of work into a product, they can't simply switch the programming language or framework. Worst case is that they have to rewrite everything.

I'm in a position where pretty much exactly 5 years ago, at the company I worked at we evaluated which web-framework and programming language we should switch to and rewrite the product in (that was previously written in Perl).

We decided to go with Java, as it seemed a safe bet. That was before Sun was bought and, while Java wasn't an innovation leader, the language was being properly maintained. E.g. Lambdas didn't seem to far away, there was talk about replacing get/set methods with properties etc. Then Oracle came along and drove the whole process straight off a cliff. Meanwhile, even Objective C has both properties and blocks!

We chose the Seam Framework: Open Source, innovative, trying to get their stuff into the standards. The last part actually worked somewhat, however stateful web framework have proven to be a looser: Especially in enterprise, back in 08/09 browser performance was terrible and you'd try to do as much as possible on the server. Today, it's the other way around.

Plus, the stateful Seam Framework works really bad in the cloud. Each server needs memory to store session state. Want to load balance requests between servers? Want to be able to kill a server? Synchronize the state between servers and loose as much performance as you gain by adding a new server. Plus, you'll always have to buy beefy instances to have enough memory at hand. 5 years ago, cloud was much more about IaaS than PaaS and during the hype anything was ready-for-cloud and every solution had lots of initial quirks.

We tried to make a couple of safer bets 5 years ago. We lost. As a programmer, I easily moved on to greener pastures. But migrating that product off to something like Angular in the frontend or to a stateless architecture in the backend? Even if the new technology doubles the development speed, halfs the maintenance effort and hosting costs, it'll take a massive investment... by the time it pays off, half of the technology is probably hopelessly outdated again.

Re: The Programming Steamroller Waits For No One (2013)

#19

There is no steamroller. I know many programmers feel this way, but in my humble opinion it is a fallacy, and not a very healthy one. No-one can deny that our industry is evolving at breakneck speed, and it is an exhilarating place to be. But just because there's a new technology every week on HN doesn't mean that we are losing old ones at a similar rate. It is perfectly possible to have done nothing but C or Java fo…

> Really, the only way an experienced developer is going to end up flipping burgers or flying a manager's desk is because they have lost the desire to learn - ie fallen out of love with programming in general. I believe few people work in this industry for money alone - you either love programming or you don't do it - and if you love it then you will pick up new technologies out of sheer intellectual curiosity.

I think this is spot-on!

Mere inflexibility or old-fashionedness is often not enough to make one unemployable. I have colleagues who insist on various odd-and-nearly-dying technologies without that having a negative impact on their work. I have my own perks, like instantly turning off syntax highlighting whenever I have to use a new editor (sadly, the state of most embedded development ecosystems usually means new MCU = new fucking everything, oh, and on Windows!).

What I do find troubling and hope I never get is something akin to calcification, only intellectual rather than physical. I currently work for a company that has developed, among others, various computer security tools. Consequently, I have a lot of colleagues who have spent their entire careers writing software for nothing other than Windows. Some of them get very excited when they talk to me about other operating systems (I haven't used Windows, except when occasionally forced to, like a few years ago because well fuck you too Microchip!); I get to find out interesting stuff about various pieces in Windows, they find out about interesting stuff that hasn't made it to Windows (like ZFS) and we get to compare programming approaches.

Then there's the other group. The people who are absolutely 100% convinced that the only way to do something is the one they know. Unix? Phbt. Broken because the applications keep their settings all over the fucking place in whatever format they want. Windows does it neatly and keeps them in the Registry, in a singular format. You mean you read a file to find out if an Ethernet device has a link? That's really clumsy, what does a file have to do with anything? Why don't they give you a neat API? What do you mean "What happens if you want to use it from a language that doesn't have bindings for that API"? You got C# and C++ for complicated apps, VBScript for moderate ones, PowerShell for scripting and a bunch of hipster stuff like F#. Python? There's no support for that in Visual Studio, I'm not sure it even exists.

Sadly, the latter camp vastly outnumbers the former. It's not a case of I'll-just-use-the-tool-I-know-best. I see programmers I honestly respect doing that for the sake of safety: X is probably a better fit than Y for this, but I know Y inside-out and I only know the name of X. Deadline fast approaching + Y can do it as well without being bastardized = we're using Y.

No, these guys are at the other end of the spectrum: it's the "Y is a programming tool, I need to program something ergo I use Y". Technical merit is secondary as long as we can do it, and human effort is not only expendable, it's being paid for. The fact that this misled can-do attitude is indistinguishable from the one backed by technical prowess to most people in HR and management certainly doesn't help.

Re: The Programming Steamroller Waits For No One (2013)

#20
> People could even get a programming job with no experience or education, as I did.

...well, they still can you know, and this is part of the beauty of the field, you get to work with people with all sorts of backgrounds. Now, yes, you need a github with some cool projects, some contributions to interesting projects and/or a mini-portfolio of projects that you did for free for schools/charities (and yeah, "cool" and "interesting" are in the eyes of the employer), but compared to most other technical field, it's much easier to make it without a degree or ample experience!

Post reply on HN