Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Choose Boring Technology

boringtechnology.club

Post reply on HN
Print view View original

211–220 of 356 posts

Re: Choose Boring Technology

#211

Post by cutler »

Bahamut wrote: post #162
lvh wrote: post #92

Earlier quoted context omitted.

I've ran multiple org that are largely or almost exclusively working in Clojure(Script) and trained over a dozen folks to be proficient Clojure programmers, and have not found that any of those to be a problem. For example: you mentioned debugging serious performance problems, but the JVM has some of the most advanced instrumentation on any platform. This is actually a point subtly made in the talk: your real product…

As a counterpoint, I have had a developer who had wrote production ClojureScript tell me it was the worst of all worlds - it doesn't abstract away issues of the DOM and yet you still have to debug what was happening in JS and translate it over to Clojure. Another thing I noticed is that most developers who had to touch Clojure in my org all pretty much didn't like it at all.

Did you use Clojurescript Dev Tools? https://github.com/binaryage/cljs-devtools

Whilst Clojurescript may not solve all of your JS problems re-frame is certaily an advance over React + Redux. In fact David Nolen and Clojurescript have had a big influence on the development of React.js since Peter Hunt first introduced it.

Re: Choose Boring Technology

#212

Post by asdfman123 »

rlonn wrote: post #14
neilwilson wrote: post #5

There's a longer term issue that appears to be missing here. At what point do you change? There must be a point otherwise we'd all be here writing COBOL/CICS with some whizzy Javascript interface library. Over time it becomes harder and harder and more and more expensive to maintain old technology. Because frankly maintaining old technology is pretty boring and career destroying so you need to be paid more and more t…

Recipe for getting things done: 1. Place every new & cool technology into mental quarantine for 3-5 years. 2. If, after that: a) the tech is still widely used, and doesn't seem to be getting overtaken by something else b) you're about to start a NEW project where the tech would help c) you're not in a rush and feel like trying something new ...then go for it. Learning complex tech that just arrived is a waste of your…

> It's only useful if your aim is to appear knowledgeable and "in the loop" to your developer peers.

Which means you get respect and better job offers.

Re: Choose Boring Technology

#213

Post by gfodor »

cutler wrote: post #194
gfodor wrote: post #177

Earlier quoted context omitted.

Surely what you state here can be said of any advice given due to experience. As long as the natural inclinations of younger developers push up against said advice, it's completely sane to give it. Because without it, young developers will have an incomplete mental model, and will lack the intellectual tools to potentially make better choices early in their career. Also it seems to miss the point somewhat: choosing '…

Because my family need feeding and housing.

I gather your response here is meant to be a retort to the idea that you should be working on the most important ideas in your field, or that the question by Hamming implies some sort of judgement if you are not. That's not the point of the question. The point of the question is for you to reflect on the reasons you are not, as a means to helping you guide your future choices insofar as working on things that are important matter to you. (Which for some, may be not important at all.)

Many people do not reflect on the reasons they work on the things they work on, or on the weight they give to the import of the problems they are solving, and so need such a question to be asked to help them to understand their needs, motives, and goals. When I first read the question I was in a situation where yes, I had financial needs that were pre-conditions for a job, but I failed to recognize the degree of choice I had over the problem space or system I was working in with regards to focusing on problems I cared about solving (or, more commonly, avoiding working on problems I considered meaningless or superficial.)

Re: Choose Boring Technology

#214

Post by asdfman123 »

reallydontask wrote: post #20
neilwilson wrote: post #5

There's a longer term issue that appears to be missing here. At what point do you change? There must be a point otherwise we'd all be here writing COBOL/CICS with some whizzy Javascript interface library. Over time it becomes harder and harder and more and more expensive to maintain old technology. Because frankly maintaining old technology is pretty boring and career destroying so you need to be paid more and more t…

I spoke once with a Microsoft consultant, he was advising us on upgrading strategy, as our customer had a mandate to be at least on version N-1, that is the customer must be on the latest major version or the version before, so at the time we were migrating off Windows 2003 as Windows 2012 was going through internal validation. He mentioned that on a bank he'd been advising, the mandate was the opposite, namely at mo…

Counterpoint: I spent my first 3 years at a major programming coding in Java and never actually learned anything there except how to work with people. It was all adding if statements to a gigantic file because no one there knew what they were doing.

I worked in an HR company and didn't learn much.

Then at my last job I worked under a really smart guy who did everything the right way, and I'm way better now. If I had started at a company like that, I would be much farther ahead now.

However, the real think to know is how to architect a project properly with tests/dependency injection/layers, not all the newfangled technologies.

Re: Choose Boring Technology

#215

Post by vidanay »

lowercased wrote: post #198
csours wrote: post #175

Earlier quoted context omitted.

Yesterday reviewed my first script that went global about 8 years ago. I think it had one update from my original deployment. =)

In 2017 I got a call from someone saying "the system's down". It was code I'd deployed for them in 2002. Crazy reviewing some of that code. Some was really good, some was... not so much. :)

My favorite on these old systems...."Your software has a bug"

No, at this point there might be some un-anticipated behavior but most likely there is either a piece of hardware going bad or you have changed your procedures and are no longer using the software the same way.

Re: Choose Boring Technology

#216

Post by jasim »

loulouxiv wrote: post #203
jasim wrote: post #89

Earlier quoted context omitted.

I've found that systems usually get robust over time - most issues in commonly run code paths get ironed out in production, and if we don't keep modifying the code, and the system's relative external world remains stable, things chug along. It is the greatest feeling though! We have a DOS application (inventory, accounts etc.) that has been in operation at a couple of retail stores for about 15 years now. No major ch…

You were still deploying a DOS application in 2004 ? Do you mind telling us more about the reasons why ?

That was the only programming environment (CA-Clipper) I knew at the time. VB6 was a thing, but I had some GUI-antipathy, coming from the older, "purer?" world of DOS. Also POS terminals needed first-class keyboard accessibility. SQL wasn't welcome either - you had to give up the fine grained control of row-level cursors in the flat-file xBase database and use a rather unwieldy looking language.

I would still love to go back to the ergonomics of building user interfaces in DOS. No mouse, no events, no callbacks - just straight imperative programming where everything, including user input, blocks. Nothing async - even network communication was thru Novell Netware file writes, using shared locks. And a single screen to design: 25 rows and 80 columns, and just 16 colors.

After doing GUI work for many years after DOS, thru VB6, jQuery DOM manipulation, Angular etc., ReasonReact and Hooks are the closest I've come to recapturing the ease of building UIs again. I'm also looking forward to trying out concur one of these days (https://github.com/ajnsit/concur-documentation/blob/master/R...) -- it is a Haskell GUI library that lets you do evented handling in an imperative-looking manner.

Re: Choose Boring Technology

#217

Post by dmix »

asdfman123 wrote: post #206
dmix wrote: post #204

Earlier quoted context omitted.

True, this puts the onus on the CTO not the junior developer who will make lots of dumb choices, not just shiny-chasing. But there's no reason you can't work a day-job doing boring technology and do fun stuff on your side projects. Companies should actively support your side-projects, especially if they involve R&D experimentation that could be useful in the long run to the company. Whether that's paying for you to a…

There are too many CTOs and senior developers out there who are too busy working on their pet projects to care. The foremost role of senior devs (at least in a company with juniors and mid-levels) should be technical oversight. Set up the architecture, set standards, and do the code reviews. Not sit in the corner and learn React.js.

Why would anyone pay a senior developer $100-200k+ to sit in a corner and learn React.js?

I was talking about junior devs making (predictable) bad choices not senior devs. Your senior developer should know better than to shiny chase and value delivery over cute technology, otherwise he's not a senior developer.

Some startups can't afford a senior developer or simply don't know any better... but even junior can pump out working apps. Then it's just up to the next evolution round when you build a professional team instead of some cowboys.

Re: Choose Boring Technology

#218

Post by asdfman123 »

dynamite-ready wrote: post #59

This is an excellent article, but it's almost advocating a doctrine, when perhaps the best approach is to have no doctrine at all. I appreciate the idea of mastering a language or technology. It is often much easier than adopting something new. But the main reason for adopting something new, is to make doing something much easier. That 'something' is often a call to solve a new problem. I feel you generally come to u…

> when perhaps the best approach is to have no doctrine at all

A general rule of thumb in life is you should follow rules until you understand when to break them, and despite the ageism in this industry I feel a decade under your belt of high quality experience really helps.

KISS is a great general guideline .

Re: Choose Boring Technology

#219

Post by delusional »

xwdv wrote: post #86

There’s a certain amount of ladder kicking involved in telling people to choose boring and beige technologies after you started up your career chasing after new and exciting shiny things. Every developer should spend some time working at the bleeding edge, so they know how it feels to get cut. The best time is absolutely at the beginning, when you’re a fresh grad and have the energy. You have the rest of your life to…

Isn't it a bit silly to presuppose that what we have now is the best we are ever going to get. I mean, files were state of the art at one point, but i don't think anyone will suggest we go back to punchcards.

"Boring Technology" is the wrong thing to aim for. Aim for simplicity.

Re: Choose Boring Technology

#220

Post by delusional »

asdfman123 wrote: post #208
agumonkey wrote: post #40

Earlier quoted context omitted.

chasing trends is a problem but suffering java You can deliver so much more, so much safer using other techniques...

I think it makes sense to keep up with the latest version of the programming language you use, and keep updating the codebase. The important part is not introducing an entirely new language that no one knows, or changing around the entire architecture without really being able to understand the long term consequences. Also, after moving to C#, I don't know why anyone uses plain old Java anymore. C# runs on Linux now.…

> The important part is not introducing an entirely new language that no one knows

> I don't know why anyone uses plain old Java anymore

You see, if we refuse to change, we can't ever get better.

Post reply on HN