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

321–330 of 356 posts

Re: Choose Boring Technology

#321

Post by closeparen »

kabes wrote: post #150

Somewhat playing devil's advocate, but if everyone joins that club, we keep the status quo and there's no more progress. If everyone joined this club in the 50's/60's we'd still be writing assembly. It's the guys pushing new shiny things that allows our domain to go forward, we just need to accept that 90% of the shiny new things eventually turn out to be crap. It's about the other 10%.

We are all writing assembly. There are just increasingly powerful levers between us and the assembly. That's why sticking with a technology for so long is powerful - the advances in tooling keep compounding. Imagine if we switched to a completely different paradigm every few years and had to start compiler research over from scratch.

Re: Choose Boring Technology

#322

Post by KaiserPro »

yellowapple wrote: post #305
KaiserPro wrote: post #139

Earlier quoted context omitted.

It fits in the ruby part here: http://boringtechnology.club/#33 It would be something that you are adding to the stack. Yes, you are intending to replace something, but in practice there will still be legacy nodejs hanging around. But crucially this one: http://boringtechnology.club/#43 If you are spending time (and therefore money) changing from one language to another, you are not making features for the business.…

It ain't just about speed, though. If TypeScript is able to prevent entire classes of bugs, then that lowers the ongoing maintenance costs relative to the costs of maintaining the non-TypeScript version. It'll also make implementing new features easier and faster (and therefore cheaper) in the long run specifically because of that avoidance of bugs interfering with delivery of those features. Both of those factors ca…

I see those arguments but:

o the new feature speed is only gained after a complete re-write

o in 80% of businesses people cost >> than hosting

o re-writing always introduces more bugs

The only time that I would agree to something like this, is to get all my teams onto the same platform. Again, thats not a technical decision though.

Re: Choose Boring Technology

#324

Post by tamrix »

KaiserPro wrote: post #268
parasubvert wrote: post #98

A huge part of our VC bubble in OSS infrastructure (NoSQL, clouds, middleware, automation) is fueled by a generation of technologists not choosing boring technology. This is a great presentation, and great advice. What this piece misses are the marketing, hiring practices and incentives in that capital pool that is fueling FOMO (fear of missing out) as the main driver of our technology trends. Most people orbiting IT…

The thing that is missed with this argument is that tech just enables the business. If a company is boasting constantly about how it moved from X to Y, they either have too much money, or none at all. If they have the luxury of re-writing a core business system every 6 months, we can glean two things: 1) they have terrible leadership 2) their teams can't agree to support each other. One thing that is really dangerous…

In my resume I used to list a bunch of technologies. These days I write the outcome of my projects. Eg 'My team increased customer retention by 3%'.

Technology is a tool to solve a problem and all problems are people problems.

Ultimately, you need to have a balance between tech and talk as that's the job to translate the two.

Lean too far on the talk and you end up in management, to far on the tech and you're writing software no one wants.

Re: Choose Boring Technology

#326

Post by undreren »

c0vfefe wrote: post #176
undreren wrote: post #61

Earlier quoted context omitted.

Code absolutely is a liability. It is not a tool, it's a means to an end. A simple tool, like a hammer, is not volatile over time. The house that you build with your tools is. It will weaken and rot, and given enough time it will crumble. It takes care and maintenance to keep it safe to live in. It is the same with code in production; at some point in time in the future, through no fault of your own, the code can bec…

> It is not a tool, it's a means to an end. You could almost call it "something (such as an instrument or apparatus) used in performing an operation."[0] [0] https://www.merriam-webster.com/dictionary/tool

If you are going to use my own trick and use the same dictionary against me, at least have the common decency to also use my own words against me!

Definition 1C in the link you provided lists "a means to an end" as a definition of a tool, which I explicitly mentioned code was.

So I must concur, code is a tool. But I'm adamant that it is also a liability.

Re: Choose Boring Technology

#327

Post by pjmlp »

jasim wrote: post #315
pjmlp wrote: post #271

Earlier quoted context omitted.

Well, if you would be using Turbo Vision, then there was mouse, callbacks, events, the whole stuff. And async would just be a couple of chained interrupts. I also used CA-Clipper, Summer '87 and the OOP variants 5.x. Most of the stuff did use a mouse and some TUI navigation, with menus and stuff, we had a couple of libraries for it. Now doing those forms it was pretty neat.

Yeah I used to look longingly at Turbo Vision GUIs, but C++ was scary at the time. Do you think building TUIs with TV was qualitatively better than approaches popular today? Any insights why?

I used Turbo Pascal's variant of Turbo Vision.

As for building TUIs not really, other than the usual Clipper entry forms.

For example, when I moved from Turbo Vision (MS-DOS) into Object Windows Library (Turbo Pascal for Windows 1.5) I did not regret it.

One thing I do conceed, a full keyboard experience is much better for data entry forms and on GUIs the mouse is given too much focus, although the same approach could be easily implemented as on TUIs.

Re: Choose Boring Technology

#328

Post by HNLurker2 »

grumdan wrote: post #301
rexpop wrote: post #245

Earlier quoted context omitted.

Does he?

I know the comment you replied to was in jest, but he did actually say quite the contrary (at least according to Theravada, one major Buddhist tradition): He in several places said the point of all his teachings was to help people put an end to suffering; he only taught the particular things he taught because according to him, they were the best/only way of reaching that goal. Some schools even go so far as to say th…

>Some schools even go so far as to say that the Buddhist path is something to let go of as well at the very end of the process in order to truly reach enlightenment. It's only a tool to get there.

Interesting view (we share the same). To understand it more simply think as a big ocean. Enlightenment being an island. This is where the 4 stages are named after (stream entrer, non returner etc). Once you reached the island the boat is no longer useful (and the boat being 2500 years old as a tradition is a pretty quality one)

Re: Choose Boring Technology

#329

Post by a_imho »

ghaff wrote: post #229
rb808 wrote: post #183

Earlier quoted context omitted.

> but after 10+ years they still just work I think this is also a mindset of devs who are committed to a job long term. Many places seem to churn through people every few years. If I had to look for a job every year or two I'd be doing resume-trendy "best tool for the job" stuff too. If I knew I'd be on the same system in 2029, I'd be keeping things easy to maintain.

And in all fairness, many people seem to churn through places every year or two because (among other reasons) they value newness over longer term projects.

Do not agree, changing places has a very high cost. People change places because that's seems to be the only way to get a meaningful raise.

Re: Choose Boring Technology

#330

Post by ptx »

runarberg wrote: post #292
mcguire wrote: post #260

Earlier quoted context omitted.

Which JavaScript framework is the simple one?

VanillaJS! But seriously while Svelte is the new kid on the block, they do claim to have minimal API design and no virtual DOM. So I guess the real answer is Svelte.

It does have a compiler, though. So compared to the old-fashioned JavaScript workflow it adds a mandatory build step. And I don't think it would work with languages that compile to JS – or does it?
Post reply on HN