Choose Boring Technology • Hacker News Board

Re: Choose Boring Technology

#271

Post by pjmlp » Tue, Jul 02, 2019, 7:01 PM UTC

jasim wrote: post #216

loulouxiv wrote: post #203

Earlier quoted context omitted.

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…

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.

Re: Choose Boring Technology

#272

Post by sgift » Tue, Jul 02, 2019, 7:05 PM UTC

c0vfefe wrote: post #172

regularfry wrote: post #163

Earlier quoted context omitted.

"The way to ship good stuff is to ship lots of stuff and keep the good bits" - apologies to Linus Pauling

Or perhaps to build lots of stuff, and only ship the good bits.

If you don't ship it you don't know if it is good or bad.

Re: Choose Boring Technology

#273

Post by pjmlp » Tue, Jul 02, 2019, 7:06 PM UTC

TulliusCicero wrote: post #227

asdfman123 wrote: post #205

Earlier quoted context omitted.

Yes, this. At my last job, I was a mid-level developer. I set up a dev ops pipeline. I moved a bunch of stuff to microservices. I did a whole bunch of other shiny things. It looks great on my resume. Microservices were a mistake. I should have fixed the underlying problem with the DB (we were misusing the ORM) first. It's fixed now, but we still have to deal with debugging microservices which sometimes mysteriously f…

I wished Google followed the Google model, because I work there. 20% projects are still technically a thing, but not many engineers actually have one.

For NDK users that is what it feels like, a 20% project from Android team, given how slow it progresses.

It only took them 10 years to fix the header file mess.

Re: Choose Boring Technology

#274

Post by potta_coffee » Tue, Jul 02, 2019, 7:06 PM UTC

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.

I value stability, but the companies I've worked for haven't provided any. There's definitely two sides to the coin. Would love to find a job that deserves long term commitment.

Re: Choose Boring Technology

#275

Post by nafey » Tue, Jul 02, 2019, 7:06 PM UTC

Balgair wrote: post #259

mcguire wrote: post #246

I am in complete agreement with this. (Sing it, brother!) But, " My friend Andrew wears the same brand of black shirt every day. He thinks that if he conserves the brainpower it would take to pick something to wear, he’ll bank it and be able to use it later for something else. [...] I like to think about it like this. Let’s say that we all get a limited number of innovation tokens to spend. [...] These represent our…

The meme that you can 'save up' or 'train' your mental reserves has seen a bit of a come-back lately. However, the scientific evidence of such a thing is scant to none. In general, people that claim you can train your focus and eureka-moments are not looking at the evidence. Brett at AoM has a good intro article on it here: https://www.artofmanliness.com/articles/motivation-over-disc... Tl;DR: Be disciplined, not mot…

It is not just about saving "brain power". It is also about saving time.

Re: Choose Boring Technology

#276

Post by mastratton3 » Tue, Jul 02, 2019, 7:08 PM UTC

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…

The interesting thing here is that I find many young engineers want to work on the newest tech, however, they also want the 10-5 schedule.

If you want to work on new and exciting, you have to be willing to own the consequences and stay up late digging into the bugs, learning the ins and outs, and committing to delivering what you said would be delivered.

TLDR: If you want to work on interesting, it'll take more commitment.

Re: Choose Boring Technology

#277

Post by pjmlp » Tue, Jul 02, 2019, 7:18 PM UTC

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

Because there are plenty of platforms where Java runs and C# does not, the world is not constrained to Linux and Windows.

Copiers, phone switches, IoT gateways, SIM cards, military control units, drones, Intel ME and a couple of phones.

And all of them have libraries that work across all JVM implementations, regardless of the OS, not the hit-and-miss that still happens between Framework and Core, without a good story how to go cross platform [1].

As for Oracle, they rescued Java while no one else cared [0], kept Maxime alive transforming it into Graal, made several improvements to the language, while allowing jars from 20 years ago to still run unmodified in modern generations of the runtime.

I use both platforms since their initial releases. Each of them has plus and minus.

[0] - Only IBM did an initial offer, that they withdrew afterwards.

[1] - Naturally there is Xamarin, but it isn't without its issues and doesn't run everywhere where Swing, SWT or OpenFX run.

Re: Choose Boring Technology

#278

Post by ptx » Tue, Jul 02, 2019, 7:19 PM UTC

mcguire wrote: post #260

delusional wrote: post #219

Earlier quoted context omitted.

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.

Which JavaScript framework is the simple one?

Mithril? https://mithril.js.org/

The downsides might be (I'm guessing) performance for very complex apps and lack of pre-built third-party components.

There is definitely a spectrum of simplicity among the frameworks. Angular seems to sit on the opposite side of the spectrum. It has many benefits, I'm sure, but in every aspect they've chosen the more complicated solution.

Re: Choose Boring Technology

#279

Post by pjmlp » Tue, Jul 02, 2019, 7:20 PM UTC

guitarbill wrote: post #224

asdfman123 wrote: post #208

Earlier quoted context omitted.

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

As a previous fan of C# and a long time Java sufferer, I'm pretty sure it's too little, too late for C#. Sadly, years of being locked to Windows has stunted the C# ecosystem and given Java enough time to get less horrible. Java 8+ is okay. Lombok helps. There's other great, mature libraries around. There's a choice of IDEs. There's JREs to choose from - there's even JVMs to choose from. Gradle makes build files not s…

Many consulting shops actually use both, they see it as an asset instead of doing platform wars.

Not only Java vs C#, rather JVM and CLR languages.

Re: Choose Boring Technology

#280

Post by mrfredward » Tue, Jul 02, 2019, 7:25 PM UTC

mcguire wrote: post #254

hadsed wrote: post #153

Earlier quoted context omitted.

Not sure I agree with this perspective. Many of these companies are started by engineers or product managers who have seen the boring solutions not work for them. In some cases they either see it not work many times or see a future where other organizations get to that point and need a better solution. In digging into what these companies do it becomes clear that they aren't doing it just to push new tech, but maybe…

" 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 shortcomings of current solutions, and to wonder if there is a better way. It's not healthy to chase shiny objects simply because they are shiny, or to massively complicate your tech stack because it helps marginally with a short-term problem.