Live data from Hacker News

Reflections of an “Old” Programmer

bennorthrop.com

281–290 of 339 posts

Re: Reflections of an “Old” Programmer

#281
post #97

Earlier quoted context omitted.

>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…

Lol, you think you are spending 40 hours a week at the forefront of problem solving new challenges? Let's be real, for a moment. By your definition of a hard engineering problem, very few people are spending their time doing it. Virtually no one is doing it every day. Why pick on front end dev specifically? You think the average backend dev building installing flask is facing a lot of unsolved problems? You think the…

So, I didn't want to say what I do because I didn't want to make it personal, but yes, I do. I work in biotech and desogn control systems for an immunofluorescent imaging device and associated computer vision algorithms used to identify circulating tumor cells in the blood stream.

We just released a prognostic test for colon cancer which is actually relatively groundbreaking as it provides a new treatment path for people who previously had no options.

So yes, I feel that I am. I have been a part of small engineering teams delivering brand new technologies to the market my entire career.

And you're right, very few people, especially in software, are solving hard problems. I wasn't picking on anyone, I was responding to a comment.

Re: Reflections of an “Old” Programmer

#282
A bit older than the author here and I don't know why he thinks he is "old". I use all kinds of bleeding edge tech and I leverage my experience to make choices about which to use and then make it happen. I am more and more concerned with hiring younger programmers who are eager to use unproved technologies (just because it is fun or looks good on a resume).

I'm currently hiring and the big issue is finding someone who can think algorithmically and do work without a lot of oversight.

Re: Reflections of an “Old” Programmer

#283

Earlier quoted context omitted.

Browsers have improved greatly and new web development frameworks are necessary to make use of those improvements but the actual process of building usable web application doesn't seem that improved. It's certainly not any easier to achieve pretty much the same results. > The idea o a web-based office suite on the web would have been laughable 20 years ago. What's laughable is how much effort has gone into rebuilding…

What kills me about a lot of the technology we use today is that few people, at least in positions of power are brave enough to pause every now and then and say, "WTF are we doing?" So many technologies live on because of so-called "critical mass," big investments, marketplace skills, and other things that are about anything other than the technology itself. These of course are mostly practical reasons and important…

I find it super disappointing that Android, from an operating systems perspective, is so terrible. It's the newest popular operating system but it's no better than Windows, iOS, or Linux. It's a mess of passable API's, average security, etc. Rushed to market for, of course, practical reasons.

I don't see any opportunity in the future for any person or company to take all the lessons learned in the last 50 years and build something new that takes it into account.

Same with browsers; It's only now that we kinda know what a browser really needs to be but there's no way to start from scratch with all those lessons and build a new kind of web browser. There is always going to need to be what they currently are and build on what was already done.

I understand why, but it's still kind of sad.

Re: Reflections of an “Old” Programmer

#284
post #97

Earlier quoted context omitted.

>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.

So you're right about that, and I thought the same right after I posted. There is of course a scale here. Taking academic scientific research and turning it into something real is a far cry for changing e.g. an array to a hash table to improve lookup speed.

Re: Reflections of an “Old” Programmer

#285
post #70

Earlier quoted context omitted.

That's nice. Not here though. Equating the technical complexity of learning a UI framework and designing back end systems is just silly and you know it. This is also not a form of reductio ad absurdum which fits the definition; it's just a silly linguistic reduction which excludes many important details.

You're like a living version of this comic but for IT nerds... https://xkcd.com/435/ (Just to be clear, in the IT version, you're not standing where the mathematician is.)

You have no idea what you're talking about. So much of the HN crowd wants so desperately to believe that what they do is meaningful and difficult, but in reality 90% of it is just trivial web dev BS that will be irrelevant in a few years. There is real engineering happening out there, but believe what you like.

Re: Reflections of an “Old” Programmer

#286

Hm. The author works for a web/mobile development agency and uses React Native and GWT as examples of the new and the old, respectively. I hope it isn't news to anybody here that this sort of work is a race to the bottom and has such turnover precisely because it's mostly being done by junior developers. Linux systems programming arcana, for instance, doesn't disintegrate so quickly as the ten years the author cites.…

Yes. I'd love to hear some people's journeys to advance their career and move from web development into more specialization. Off the top of my head, there are three types of specialization, for money, for domain knowledge and for technical skills. For Money: Not necessarily any more satisfying or churn-proof than web development; But definitely more lucrative. Salesforce/SAP/Oracle consultant, mobile app developer, S…

Well, I learned to code in order to do bioinformatics. I didn't start out as a programmer looking to specialize.

I agree that it seems that programming + X is often a much more powerful combination than programming or X alone. But I would say to anyone starting out that it is better to head towards, and get the formal qualifications for X, and learn programming on the side (or if in college, get the major in X and a minor in CS).

The reasons are that programming is relatively easy to learn outside of classes, and programming itself really doesn't require formal qualifications.

For me, biology has been orders of magnitude harder to learn than coding. With coding, you can learn by doing, and you get immediate feedback from the compiler/interpreter. Not so with biology. You can be mistaken for weeks/months/years and never realize it until you read just the right article. And often, domain-specific knowledge like biology seems to be composed of thousands of tiny details without too many general principles, whereas if you learn a few basic principles for programming, you can learn pretty much any new language or framework easily.

I don't know if this is generally true of all specializations, but if so, it would behoove someone to get started on learning the specialization-related information ASAP, because that will take much longer to reach proficiency than for programming.

Re: Reflections of an “Old” Programmer

#287
post #46

Please. Reduction to absurdity isn't a valid argument. Are those folks working at large scales? Are they tuning DB's for applications which have to handle hundreds of thousands or millions of transactions per second? I don't imagine you actually know what you're talking about here.

Backend dev here. I think what JSDave says is not absurd and is actually spot on. The goal of an engineer is to make something that works reliably. Most of the time using old time-proven boring already-done-before stuff is the way to go.

Sorry, gluing together JavaScript is not remotely engineering.

Re: Reflections of an “Old” Programmer

#288

It is plain and simple, Kids. I'm 52 - been programming professionally since the 70's when I started writing C code and getting paid for it in 5th grade. Our "professional" is writing glue code, and how it is done and what hoops are jumped through simply do not matter: all that matters is the final shipping product, widget, or logical dodad works for the immediate marketing moment. I speak from enviable experience: g…

You're totally right but then people are faced with the possibility of an increasing number of code monkeys graduating from college every year.

Then the question becomes, how do you keep your job year after year when the number of code monkeys just keep on increasing. Some of them are shitty but a lot aren't.

Re: Reflections of an “Old” Programmer

#289
A good article that makes valid points about the difficulties of keeping up in rapidly-changing fields. Since I'm "old", and have a foot in the worlds of medicine and programming, it's apparent to me there's not that much difference in the "aging curve" in these occupations.

The parallels include the explosion of new knowledge, or at least variations on the old knowledge, that a practitioner needs to keep up with. In programming it's languages and frameworks, in medicine it's discoveries (basic science), new drugs and techniques, and aspects of the regulatory environment. In either case a few years out of school/training it becomes daunting to keep up.

I should add here a particular peeve, the proliferation of abbreviations and acronyms is way out of control. It's nearly impossible to read an article without encountering an avalanche of incomprehensible ABBRs. What's worse, the same ABBR is often used to mean entirely different things one article to the next. Cross-field usage is a naturally incongruous extension of the confusion, though at times it's humorous.

What the article doesn't emphasize is the blizzard of details to keep up with is just one part of the experience. As years in the trenches becomes decades the value of "time in grade" becomes evident. The ability to size up the demands of a complex problem, to have a clear idea of where to enter the path of its management, and calm assurance growing out of having been down the road before are all won only by virtue of real experience.

Having done what I have for 40 years, it took me only 33 years to realize I didn't know what I was doing, and that's when I got really good at it. Therein is an essential wisdom that time and effort alone confer, and can't be gained in any other way.

Re: Reflections of an “Old” Programmer

#290

Earlier quoted context omitted.

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.

New stuff: Machine learning that works. Rust's borrow checker. 3D SLAM that works. Voice input that works. Lots of image processing stuff. Machines with large numbers of non-shared-memory CPUs that are actually useful. Doing non-graphics things in GPUs. The webcrap world is mostly churn, not improvement. Each "framework" puts developers on a treadmill keeping up with the changes. This provides steady employment for m…

I think the fact that we'really starting to make native apps using Web technologies speaks to the progressadele for webapps.

The whole HTML rendering pipeline with advanced scripting support is really an innovation in itself. The downside is speed, but that's where we innovated the most, VMs for JavaScript.

Hopefully Web Assembly will really show the improvement we've made.

Post reply on HN