Live data from Hacker News

Choose Boring Technology

boringtechnology.club

311–320 of 356 posts

Re: Choose Boring Technology

#311
post #229

Earlier quoted context omitted.

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.

" If you’re giving individual teams (or gods help you, individuals) free reign to make local decisions about infrastructure, you’re hurting yourself globally. It’s freedom, sure. You’re handing developers a ball of chain and padlocks and telling them to feel free to bind themselves to the operational toil that will be with them until the sweet release of grim death. " That last sentence really should be, "You’re hand…

Exactly. And then the poor sods who have to come to pick up their (frequently undocumented or poorly documented) train wreck have to try to and keep it running, or rewrite it.

Re: Choose Boring Technology

#312

Earlier quoted context omitted.

" Many of these companies are started by engineers or product managers who have seen the boring solutions not work for them. " Most of the time (not all, but almost all of the time), if a "boring solution" doesn't work for you, the problem is you , not the solution. There's a reason it is boring.

>if a "boring solution" doesn't work for you, the problem is you, not the solution Were the people who hated their pagers and wanted cell phones idiots? All the people who were writing GUIs in C and debugging memory leaks...was the problem that they were shitty programmers, or is there something to be gained by spending more time on the business logic and less time on memory management? It's healthy to see the shortc…

> Were the people who hated their pagers and wanted cell phones idiots?

Tangential comment here. No they are not idiots, but I can tell you from experience (my team and I build and manage a wide area paging network supporting over 40000+ emergency services first responders over an area of 230,000 km²+) that there are still advantages to paging protocols over 3G/4G in certain circumstances.

Coverage is one of them. Sometimes the best tool for a particular job is the older one.

Re: Choose Boring Technology

#313
This is one of my favourite tech talks ever. So very, very true. I agree with everything he says. On the other hand, writing software the same way without changing is hard to do and there is the temptation to try something new for the sake of trying something new. It's very strong with me and I've learned to indulge my urge to play with shiny new toys in a way that doesn't blow the main project to kingdom come. I need to write something that will go nowhere just to get it out of my system.

Re: Choose Boring Technology

#314
post #84

Earlier quoted context omitted.

But: - good luck finding a Clojure programmer if your current one quits. - good luck finding answers for your exotic bug/performance issue etc. Code is a liability, it's much more than language/VM/compiler features

> good luck finding a Clojure programmer Why nobody ever says: "good luck finding good Javascript developers"? Or good Java programmers. Why it became a default norm: every programmer is a Javascript expert now? In my experience: hiring Javascript developers is hard - most applicants don't even know the difference between null and undefined or can't explain how prototype chain works. And even when you find someone wi…

Haha, spot on! The emphasis on learning frameworks instead of learning the ins-and-outs and quirks of Javascript can't have been good either. It's interesting being an interviewing candidate when that emphasis shines through. Knowing Javascript, getting up to speed on whatever framework is used on the job is trivial in comparison.

Re: Choose Boring Technology

#315
post #271
post #216

Earlier quoted context omitted.

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…

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?

Re: Choose Boring Technology

#316
post #54

Earlier quoted context omitted.

Go is a compiled language and Ruby/Python are interpreted scripting languages. There are domains where it's a much more appropriate choice (distributing binaries, performance sensitive code). The type system is also quite nice vs. dynamic typing (in most situations). It's weird to see people comparing Go and Python in this thread as they solve entirely different problems and shouldn't be interchangeable, not due to d…

> It's weird to see people comparing Go and Python in this thread as they solve entirely different problems and shouldn't be interchangeable, not due to developer preference but due to fundamental features of the language. Yes but when Go first came out, a lot of people jumped on the bandwagon and started proposing they would use Go for web applications too. There's definitely some overlap in building web services wi…

I don't know about that. I do a lot of web development and Go is really very nice as a web server.

It's extremely simple and pleasant to use. All it needs is generics and it would be my go to for most web services.

Re: Choose Boring Technology

#317
post #237

Like many developers I have a strong desire to work with more exciting technology, even when there's no business case for it. Strangely enough, I've found the best outlet for that energy (other than personal projects when I get free time) is configuring Emacs. It's less disruptive than putting a new language or database into production, and makes me significantly more content to work with a boring stack. Plus I get a…

I am the same way. I can tell when my main job gets boring because I start to tinker with emacs more and it provides that intellectual stimulus I need. Not to mention helping optimize away some of the more rote parts of my job.

Re: Choose Boring Technology

#318
post #28
post #14

Earlier quoted context omitted.

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…

This works, but it does force you to ignore new enabling technologies that make new use cases economical, where most innovation and value creation is. You'll be very efficient at accomplishing old use cases, which is just as well, because you'll need it - the market for them is most probably commodified, very competitive, and with low margins. Dominated by big actors with economies of scale. Not a comfortable place t…

[deleted]

Re: Choose Boring Technology

#320
I think it's much more important to choose a minimal set of technologies, than to choose ones that are boring. If one 'shiny new' tech can replace two boring ones, I am first aboard that hype train.
Post reply on HN