I make a point of not learning the new framework du jour. (Back in The Day it was the next UI frame Microsoft was putting out.) If I keep hearing about it for a few years, I figure it might be worth looking into. I starting writing new sysadmin scripts in Python instead of Perl after I kept hearing about it, for instance. Other than that, I tend to learn on a need-to-know basis. I feel like that has led to little churn in my knowledge. But then, I also try to avoid working in areas that have high churn, which has led to my experience being in areas of low churn.
Reflections of an “Old” Programmer
81–90 of 339 posts
Re: Reflections of an “Old” Programmer
#82Earlier quoted context omitted.
Well, sorry, but... it is. Maybe you find it interesting, that's subjective, but there's no real technical challenge in front end stuff. You're not solving hard engineering problems; you're pasting together libraries other people wrote on top of libraries other people wrote (and on it goes) and searching google to figure out why your opaque stack doesn't seem to be working. Developing a good UI is difficult, no quest…
Honestly when I see what my friends who design airplanes and particle accelerators are doing, I feel like we're all kind of fucking around in software engineering, frontend or not.
Try looking into or messing with actual engineering of software instead. You'll get similarly amazing things. Here's a few:
http://www.anthonyhall.org/c_by_c_secure_system.pdf
http://www.methode-b.com/wp-content/uploads/sites/7/dl/thier...
https://ts.data61.csiro.au/publications/nictaabstracts/7371....
Re: Reflections of an “Old” Programmer
#83Earlier quoted context omitted.
I never said that I was old ... One good sign is that my wife keeps telling me to act my age!
Nobody has any experience of being any older than they currently are, but a lifetime's memory of being younger. Hence most people of all ages feel old. One trick I like to play on myself is to imagine I come back from twenty years in the future. What advice would I give myself? First thing would have to be "shut up about being old! Your life is still ahead of you." I like the other trick too, where I imagine being vi…
I use that timetravel trick as well; I never thought I was old (I like getting older so far; so many doors just open that were closed before), but yeah things to tell your younger self; do not hurry so much. Make 10 year+ plans when doing things. I always hurried thinking something would end; I have been running companies since I was 15 and, for instance, the first company I co-ran with my uncle, made educational software for MS-DOS and later Windows 3.11 and then Win95 etcetc. I was in hurry because I thought first MS-DOS would go away and then that Windows apps would go away because web. The software I made then sells well still; it's now over 25 years old... Why did I hurry/worry?
Things I thought that would end, like the CMS market 16 years ago (a market my company thrived in) didn't end. They became bigger. If I would've not hurried, I would have less stress at the time and probably be running on a larger scale than that company is doing now. You cannot stand still and for some parts there needs to be a sense of urgency but it doesn't change that much in most markets. Currently I use that to tell my colleagues we need a 10-year plan, not just a 3-5 year plan.
Re: Reflections of an “Old” Programmer
#84At 27, I still feel old in the same regard as a lot of the ways the author is talking about. A lot of things I'm seeing reeks of being a fad. I'd rather avoid naming any technology or framework, but my instinct has been to avoid planting my seeds in soil that's churned up every 6 months and keep an eye toward that which has been solid for a decade and is likely to continue. I don't mind learning a new language -- there are a couple I'm hopeful toward and think could be long-term winners. But I'm not about to waste grey matter on things I suspect will be obsolete before I can even reach mastery.
Re: Reflections of an “Old” Programmer
#85I'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…
What's the last truly new thing you can think of? I'm interested because I am young (22) but have studied programming language paradigms and history and I also agree a lot of "new" stuff is old.
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 in schools. Microsoft Flight Simulator released in 1982 is first super-popular 3D simulation software.
Mid-1980s: GUIs- Macintosh 1984 based on ideas from Xerox PARC.
Late 1980s: Graphics had more colors, more resolution, faster processors. So- cooler games. File servers. 1987 GIF format, 1989 GIF format supporting animation, transparency, metadata- not that popularly used though- was a compuserve thing.
Early 1990s: Internet, realistic quality pictures, webpages/browsing, global file servers. Mosaic web browser. Most pages involved horizontal rule dividers that might be rainbow animated GIFs. Bulleted lists. Under construction GIFs were popular. Linux. JPEG format. Netscape. Blink tags.
Mid 1990s: Windows 95 (with Winsock). IE vs Netscape. IE had marquees. VBScript. (Mocha->LiveScript->)JavaScript. Applets. Shockwave. WebCrawler search. Altavista search. OOP pretty solidly how you should program now with C++ having been around for a while and Java slow but write once/run anywhere and OOP. Apache webserver. CGI: can email from webpage.
Late 1990s: ActionScript. Google search. CSS. Extreme programming. Scrum. JSP. Some using ORM via Toplink. Java session vs. entity beans. IIS. Java multithreading. Amazon gets patent for 1-click ordering. AOL instant messenger. PhP.
Early 2000s: ASP. .Net/C#. Hibernate ORM (free). Choosing between different Java container servers.
Mid 2000s: Use CSS not tables. Rails.
Late 2000s: SPA and automatic updating of content in background via Ajax. Mobile apps. Mobile web. Scala. Cloud computing start. VMs. Streaming video mature. Configuration management via Chef/Puppet.
Early 2010s: Cloud computing standard. Container virtualization. Video conferencing is normal- not just big company office thing. Orchestration of VMs more normal.
Mid 2010s: Container Quantum computing starts at a basic level (not important yet).
Note how I can't really thing of anything recently that has to do with new things in webdev.
Re: Reflections of an “Old” Programmer
#86You know, if truth be told, we really haven't come very far. You'd probably be surprised at just how well a modern COBOL system can operate. ( http://blog.hackerrank.com/the-inevitable-return-of-cobol/ ) In fact, in many ways we've made things worse because not only does the sand keep shifting, there is now way too much sand. Young people come into the field and they want to make their mark. So we are constantly goin…
> I can only hope one day some breakthrough in C.S. will get us past this "Cambrian Explosion" period and things will finally start to settle down.
I genuinely do feel like we're in the stone age in this industry right now. I've thought about it a lot, but of course, it's hard to really get to the good ideas when you can't hop on lot of stepping stones that will be found later and taken for granted.
I think a few things will happen. 100 or 200 years from now (if it's even appropriate to think on such a timescale!), we'll have some very large scale, stable data storage systems that people can simply rely on. A few common development paradigms will have thoroughly been cemented in our collective consciousness, and the programmers of the day will be essentially what construction workers are right now, perhaps with a bit more creativity. They'll follow plans and be put into rigid confines when programming with the system, and it'll be scalable from a development perspective.
I haven't got much further than that. It's hard to step more than a few layers deep on stuff like this. A lot of the rest of it depends on how things like AI and VR and a bunch of stuff I can barely imagine will pan out. But from a software point of view, I think we're still waiting on a bunch of 100-monkey-style revelations.
Re: Reflections of an “Old” Programmer
#87I 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…
posts like this are why I love HN. Intercooler looks cool and simple, and simple enough I can just re-write it. Angular is big enough that my eyes glaze over thinking about reading into it.
This is the first time I've heard of it and it's elegant enough that I want to start working with it.
Here's the flipside. This is way easier for me to grok than Angular but which one has way more of a presence at companies and job reqs out there? I'd probably get screened out of a lot of resume filters.
Re: Reflections of an “Old” Programmer
#88I 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…
I can vouch for Intercooler. We're rewriting large parts of our app (used to be a complex flux beast) and it is now way more maintainable and indeed around 1/10th the code. We now keep most of our app state within the server, instead of spread throughout client and server.
Of course, it is not end-all-be-all: it solves simple interface problems, those that should't require 200mb of JS dependencies to solve. Once the interface gets complex enough, you should use JS. We've still got a couple of JS components though.
Re: Reflections of an “Old” Programmer
#89I 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…
Old guy here too. When I was a younger guy and first saw the web, after making a few web pages I naturally wondered "how can I program this?" At the time, the old guy programmers were old mainframe / terminal architecture guys, where a dumb terminal (teletype or monochrome) sent text to and from a smart "central processing unit". It was natural for them to follow server-side patterns, and invent PHP, NetObjects, Cold…
I did a lot of UI client/server back in the day; VB, Powerbuilder, Delphi and I remember being able to bang out an app in days. Then the web came around and turned UI development into a chore. Recently though, I started playing with Elm and it makes UI development fun again.
Re: Reflections of an “Old” Programmer
#90I 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…
I can vouch for Intercooler. We're rewriting large parts of our app (used to be a complex flux beast) and it is now way more maintainable and indeed around 1/10th the code. We now keep most of our app state within the server, instead of spread throughout client and server. Of course, it is not end-all-be-all: it solves simple interface problems, those that should't require 200mb of JS dependencies to solve. Once the…
Holy shit I can't tell you how happy that makes me to hear.