Live data from Hacker News

Reflections of an “Old” Programmer

bennorthrop.com

191–200 of 339 posts

Re: Reflections of an “Old” Programmer

#191
post #97

Earlier quoted context omitted.

> You're not solving hard engineering problems What, in your mind, makes an engineering problem hard? I've certainly had to dig out CS algorithms and 'clever' applications thereof to reach desirable performance out of some custom widgets in front end projects. I don't know if that can considered hard – hindsight tends to make everything seem easy – but it is certainly beyond pasting in a library like you describe. I…

>What, in your mind, makes an engineering problem hard? A problem which requires a high degree of creativity, intelligence, and technical ability, likely one which hasn't been solved before. You're right; it's a bit difficult (at least for me) to define, but we know it when we see it. Sending men to the moon was a hard engineering problem; implementing the UI for gmail was not. You speak of using 'CS algorithms' in y…

> You didn't solve these problems, other people did

that's a high bar for engineering. Integrating known solutions into a situation is engineers. Mechanical engineers don't discover the laws of motion themselves.

Re: Reflections of an “Old” Programmer

#192
post #13

I'm a bit older than the author. Every time I feel like I'm "out of touch" with the hip new thing, I take a weekend to look into it. I tend to discover that the core principles are the same, this time someone has added another C to MVC; or the put their spin on an API for doing X; or you can tell they didn't learn from the previous solution and this new one misses the mark, but it'll be three years before anyone noti…

The more I learn about fundamentals (recently non determinism + predicate logic) the more I realize the trends are shallow (or not so shallow) obfusction of the same basic blocks. And pardon the following hint, I found FP a pretty good vehicle to express these blocks in an abstract manner. Binary operations, composition, accumulation, iteration, induction, state transitions.

Re: Reflections of an “Old” Programmer

#193
post #95

Earlier quoted context omitted.

You're describing a task which is more frustrating than technically challenging. Nothing you described requires a high degree of intelligence or training, only time. Of course some are better than others at it, but that's true of anything. Think; designing the CV systems for self driving cars (since that's a hot topic at the moment) vs designing a UI which works seamlessly across browsers. One is a real, honest to Go…

by UI design I do not mean cross browser compatibility, but rather an understanding of the underlying data and operations on it, which involves familiarity with the business domain. this is hard. putting stuff on the screen is not hard. I am OK with tables and gifs. with all due respect your contempt for people who build UI (and clean the toilets) and misunderstanding or general principles of engineering are sad (par…

> putting stuff on the screen is not hard

> your contempt for people who build UI

You've carved out your own definition of Frontend dev, it doesn't always require business/domain knowledge, many just put stuff on the screen.

Incidentally, I found this hard - not in a math problem way, but in a costing a lot of time and patience way. I distinctly recall spending a couple of hours trying to align some div after being requested to do so. I strongly dislike CSS.

Re: Reflections of an “Old” Programmer

#194
post #94

Earlier quoted context omitted.

So, another non-response response. I don't think you have a leg to stand on and you just enjoy feeling superior (for no good reason as far as I can tell.)

So far everything I've seen you post has been either a humblebrag or a serious need to feel superior to those of us that do the "easy" work. How much are the big 4 paying those of us that don't have hard jobs?

> How much are the big 4 paying those of us that don't have hard jobs?

Expect the gravy train to end eventually. I feel the web-dev scene is already too competitive.

Re: Reflections of an “Old” Programmer

#195
post #10

Earlier quoted context omitted.

Twentysomething year old here, so you know, not like you don't have a point but: >the other reason is because it's easy/boring as hell I legitimately think front end development is not only very fun, it can have some really challenging aspects. I wouldn't think there's any programming challenge that is inherently easier because it's on web as opposed to something else. Of course I bet there are domain-specific tasks…

35 here. I completely understand why you are on defensive about something you are passionate about. Try to see our perspective though; web dev, we've been there. In my case, you name it, I've done it, nobody gave me a T-shirt thought they all asked for unpaid overtime. At some point you realize that it's a race to write more lines of code with every iteration, and that employers will gladly abuse your passion in many…

> go for the lower level/more specialized stuff

This is my own strategy, though domain specialised rather than low-level.

I don't want to do "business" or project manage.

Re: Reflections of an “Old” Programmer

#196
post #173
post #10

Earlier quoted context omitted.

Twentysomething year old here, so you know, not like you don't have a point but: >the other reason is because it's easy/boring as hell I legitimately think front end development is not only very fun, it can have some really challenging aspects. I wouldn't think there's any programming challenge that is inherently easier because it's on web as opposed to something else. Of course I bet there are domain-specific tasks…

I can't get over the endless yak-shaving in front-end dev. Fighting with browsers that all do things slightly differently, a terrible programming language, an abused, crufty markup language and a baroque styling language on top of that is not my kind of idea of a good time. Not to even get into the node/bower/grunt/gulp/webpack/babel shitshow compile and build process that it seems to be trending towards. Working on…

> endless yak-shaving

I think this is the issue, it's not that the problems aren't hard, rather you aren't solving new problems, but trying to figure out how the existing tangle of software can be made to do what you want...

Re: Reflections of an “Old” Programmer

#197
post #93

Earlier quoted context omitted.

A history of new things geared toward web app developers, starting with relevant popular technologies: Late 1970s: microcomputers, explosion of BASIC and ASM development Early 1980s: proliferation of modems, BBS's become big, Compuserve becomes big- people able to read news online and chat in real-time (but not popular like much later). software stores, software pirating, computer clubs, widespread use of Apple II's…

Trends: Ajax, Long polling, WebSockets jQuery/MooTools/Prototype, Bootstrap/CanMVC, Angular/React Javascript debugging tools, profiling, 60fps, responsive pages, AMP RSS, Web Push, WebRTC HTTP Auth, Cookies, oAuth, new social protocols Perl, Java, PHP, Node.js, Go

Thanks! You caught some ones I missed, so here are some edits and responses to your list:

1. I didn't mean to put "container" in front of quantum computing.

2. I didn't mention history of certs or encryption, as I think that security is often a feeling rather than a reality. I'm not sure that "HTTPS everywhere" plugin and then movement in early 2000s was innovation more than it was tightening up security after Firesheep.

3. Yes, I should've included WebSockets over long polling in Early 2010s.

4. Yes, RSS mattered- 1999/Early 2000s.

5. I probably shouldn't have mentioned OOP, etc. as I didn't mean for methodology to matter, since it doesn't matter to users. Similarly debugging tools don't matter for innovations that users see.

6. Yes, fluid layout, grid layout, and responsive design in Late 2000s (though Audi had responsive in 2001).

7. jQuery/MooTools/Prototype, Bootstrap/CanMVC, Angular/React - none of the implementation details of these things matter. The only things that matter are how things appear to the user- like whether a page has a clunky refresh or smooth transition and whether things update automatically when they are changed elsewhere. Also, Applets, Flash, frames, and the move to JS all screwed the visually impaired.

8. Cookies mattered because they were used to track users in ways they didn't want to be tracked. People disabling JS for a while mattered. US announcing Java was insecure mattered. Flash and Flash being abandoned mattered.

9. Forgot to mention frames in Mid/Late 1990s.

10. As you mentioned oAuth, SSO becoming a big deal in the Late 2000s with Facebook, Google.

And I should have mentioned blogging, microblogging, move of much of the web to Facebook, Tor/private web, peer sharing and impact on music industry as well as impact on the value of well-created data and applications vs. the value of constantly creating data and making data available and clear.

Despite all of the things I missed, the point is that the things that really matter aren't new libraries and frameworks- they are technology and how the world uses it. If a user can't tell a positive difference between something you were doing 5 years ago and today, then you didn't really innovate.

Re: Reflections of an “Old” Programmer

#198

I get where the guy is coming from, I'm right there as an old guy. On the other hand, I think there is a bit too much fatalism in the article. Sometimes the kids are being stupid, and they need to be told so. The vast majority of web apps could be built in 1/10th the code with server-side rendering and intercooler.js. All this client-side crap is wasted when you are trying to get text from computer A into data-store…

Thank you for mentioning intercooler.js. After skimming through the docs for five minutes I am sure I will use this regularly from now on.

After skimming through the docs, my mind went all the way back to ASP.NET Web Forms days :) This model, unsurprisingly, brings it's own problems when things get complex.

Re: Reflections of an “Old” Programmer

#199
post #13

I'm a bit older than the author. Every time I feel like I'm "out of touch" with the hip new thing, I take a weekend to look into it. I tend to discover that the core principles are the same, this time someone has added another C to MVC; or the put their spin on an API for doing X; or you can tell they didn't learn from the previous solution and this new one misses the mark, but it'll be three years before anyone noti…

> Every time I feel like I'm "out of touch" with the hip new thing, I take a weekend to look into it. I tend to discover that the core principles are the same, this time someone has added another C to MVC; or the put their spin on an API for doing X; But that is only for the 'abstractions' they implement; the details are another thing. I feel the only thing that really changed is that now big companies with PR / mark…

React is a lot more than it seems. The essential problem it tries to solve is componentization: how can you have a large team of varying skill work on separate parts of a page in a web application without one part breaking the others in hard to detect ways?

Many people focus on JSX or virtual DOM and muse about how that just duplicates the browser-- what's the point? But that isn't the point. It's componentization and encapsulation for large teams at scale, and for Facebook it works, it makes them more successful at pulling together disparate modules on a single page than their competitors, so there is some meat to this $NEWSHINY.

Now, if the browser itself had been properly designed years ago to be componentized and encapsulated, we'd have those features without inventing a new DOM or creating a new tagging language or isolating CSS. There is a web components standard that offers much of the same thing... It came out around the same time as React, but still isn't widely used outside of Google Polymer. Truth is these were developed in parallel before they knew of each other.

Anyway, React makes a lot more sense if you think of it as rewritting the browser from outside the browser. In the old days the stack that would have been hard to impossible-- you would have simply started your own browser. And people would have shamed you for not following existing standards, so you would have petitioned the W3C or served on committees to bring your real-world cases for years, being mostly ignored.

Now, devs have the ability to change the browser quickly and find things that work (and also create chaos and suffering).

Meh. Kids. ;)

Re: Reflections of an “Old” Programmer

#200
Mid 50's here. I've been coding professionally for about 30 years. All of this is pretty much spot on.

More so, the ability (and desire) to learn the latest/greatest has waned. I fear that we only have the ability to jam so much new knowledge into our heads. At some point, we must discard the old to make room for the new.

I'm just afraid I'm gonna delete the ability to control my bowels.

Post reply on HN