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

221–230 of 356 posts

Re: Choose Boring Technology

#221

Post by Quarrelsome »

macspoofing wrote: post #32
ovi256 wrote: post #28

Earlier quoted context omitted.

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…

You're talking about a tech stack, which is not the same as, for example, a modern web application. You can build a perfectly modern web app with 'old' Java/JEE stack, backed by an unsexy SQL-based database. You don't need Node.js with MongoDB. Techstacks very very very rarely enable new use-cases. They are the equivalent of fashion statements by young developers who haven't learned what it means to support software…

I'll raise you a windows service that communicates with Singleton .NET Remoting hosted with a WebForms 2.0 app or a WCF delivering SOAP service. Both talk via remoting to the windows service which talks an SQL Server choked with materialized views.

Is that boring? It certainly has some issues.

Re: Choose Boring Technology

#222

Post by cutler »

malvosenior wrote: post #78
nickjj wrote: post #54

Earlier quoted context omitted.

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

> Go and Python are also pretty related for command line apps too. You could totally use either one to build a CLI tool. Distribution of Go CLI apps is much easier as you don't need to have your end users install the 3rd party libraries themselves.

As far as I'm aware Go doesn't return the exit status of a process the way Ruby and Python do. Surely this is a big disadvantage for CLI scripts?

Re: Choose Boring Technology

#223

Post by asdfman123 »

delusional wrote: post #220
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.…

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

Sorry, I meant on new projects. I'm not talking about using the latest and shiniest thing, I mean using C# or Python or some other language.

However if youre strongest in Java then you should probably do Java.

Re: Choose Boring Technology

#224

Post by guitarbill »

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

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 suck and makes it easy to add static checking and linting to the build process. AFAIK, C# doesn't have auto-formatting options outside the IDE.

As much as I used to have your view, Java is alive, works fine, and makes money. Or Minecraft mods.

Re: Choose Boring Technology

#226

Post by malvosenior »

cutler wrote: post #222
malvosenior wrote: post #78

Earlier quoted context omitted.

> Go and Python are also pretty related for command line apps too. You could totally use either one to build a CLI tool. Distribution of Go CLI apps is much easier as you don't need to have your end users install the 3rd party libraries themselves.

As far as I'm aware Go doesn't return the exit status of a process the way Ruby and Python do. Surely this is a big disadvantage for CLI scripts?

Sure it does: https://gobyexample.com/exit

If you mean Go can't read the exit status of a command it runs, that's incorrect as well: https://golang.org/pkg/os/exec/#pkg-overview

Re: Choose Boring Technology

#227

Post by TulliusCicero »

asdfman123 wrote: post #205
fogetti wrote: post #161

Earlier quoted context omitted.

The problem is that those people who chose shiny new technology only see the benefit, while all the others in the company will rot in hell because of the stupid choice of a junior engineer (who jumped ships 3 times meanwhile). I don't see how does that benefit the company? The whole point of the article is that you should make wise technology decisions which benefits the whole organization.

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.

Re: Choose Boring Technology

#228

Post by godshatter »

oftenwrong wrote: post #58

Always glad to see this making the rounds, as it has been influential for me, especially the perspective of "Happiness comes from shipping stuff". I often think about this part, in particular: >Then we walked away. We didn’t do anything related to activity feeds for years after that. We barely even thought about it. >Then one day I said, “hey, I wonder how activity feeds is doing.” And I looked at it and was surprise…

I'm always amazed at the lifespan of some of the code I've written over the years. I wrote an api that we use internally in 1996 that is still being used in all of our new production code in that language in our organization. I've learned a lot in the intervening 23 years so looking at some of that code can be a bit jarring. We've had to adapt it a bit when our environment changed a few times, and we've certainly added to it, but I don't think the core code has had any problems that I know of this century. Millennium, I guess, technically.

Part of me really wants to rewrite it, but it doesn't make sense from a developer-time perspective (and I don't want to spend the time tracking down the inevitable bugs again).

Re: Choose Boring Technology

#229

Post by ghaff »

rb808 wrote: post #183
stinos wrote: post #67

Earlier quoted context omitted.

For me, implementing something that provides value with near-zero maintenance for years is the ultimate sign that I've done well. Such a good point it's worth repeating. We have a bunch of small tools of which the code might not exactly be brilliant or adhering all possible good practices, but after 10+ years they still just work without any unsurprising behavior nor bugs and still also just build/deploy with a click…

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

Re: Choose Boring Technology

#230

Post by Scarbutt »

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.

Clojurescript on its own doesn't give you much for web programming and, not worth it over Javascript. It shines when combined with a react wrapper.
Post reply on HN