Choose Boring Technology (2015) • Hacker News Board

Re: Choose Boring Technology (2015)

#131

Post by ryanbrunner » Sun, Jun 07, 2020, 12:32 PM UTC

onion2k wrote: post #45

archived22 wrote: post #39

Job description these days become reflection of complexity in new age tech stack. Know C++/Java/Scala/Enter_Your_Lang_Here with python and React/Angular/Blah/Blah with Big Data Technologies - Hadoop, spark, etc. with Docker/K8 and with Azure/GCP/AWS. It is time consuming process to become expert of one thing, requires couple of years of continuous focus. I don't know How many people are actually expert of all these a…

I think this is largely representative of the real problem in web dev - the tech has changed, the complexity has grown, and yet the expectation that a web app is still something one person can build on their own using all the modern approaches hasn't changed. You can still make something that works on your own, but not using all the new tech. You have to compromise somewhere. The notion of "full stack" devs is long g…

Sure you can, if you reject libraries and tools that were designed by large companies with a ton of specialization to serve the needs of those companies.

If you want to be effective as a small team, choose tools built for small teams. Rails is a great example.

Re: Choose Boring Technology (2015)

#132

Post by ProZsolt » Sun, Jun 07, 2020, 12:38 PM UTC

robert_g wrote: post #115

nine_k wrote: post #62

I still think that "boring" is a wrong word. Choose the technology you know in and out, and are immediately productive with. Choose the technology which is sure to be around in 5-7 years, preferably 10-15. Choose the technology for which you are comfortable hiring the next 15 engineers. This does not mean that you need to choose something unpleasant, unergonomic, or ancient. Neither does it mean that you need to choo…

There should also be an explicit call out to both tooling and community. Even if a programming language ticks all the other boxes, Without a sizable and stable community to constantly push tooling languages will fade, not necessarily die. In my past job I was ColdFusion programmer for 15 years. ColdFusion ticks all the other boxes. * Created in 1995 and is a very mature platform * Easy to learn and productive * I was…

I currently see it happening with Ruby. I used it as a scripting language for DevOps tooling, CLIs, and for small web apps, but without rails.

What I see is Go pushing it out from the DevOps space and Python is more popular as a general-purpose language. Tools that were written in Ruby(eg.: Puppet) are outdated and new tools are written in Go. I still think Ruby is a superior language compared to Python, but because mathematicians used Python and the recent ML/big data hype it got more popular and got better libraries which caused an upward spiral.

While Ruby is the language I most comfortable whit and I don't see it going away in the next 10 years. I have to accept that first-party integrations will come later and later and there will be less third party libraries. That is why I'm currently learning Go and if anyone asks me what language should they learn first I point them to Python.

Re: Choose Boring Technology (2015)

#133

Post by limomium » Sun, Jun 07, 2020, 12:46 PM UTC

nine_k wrote: post #62

I still think that "boring" is a wrong word. Choose the technology you know in and out, and are immediately productive with. Choose the technology which is sure to be around in 5-7 years, preferably 10-15. Choose the technology for which you are comfortable hiring the next 15 engineers. This does not mean that you need to choose something unpleasant, unergonomic, or ancient. Neither does it mean that you need to choo…

Choose PHP.

Re: Choose Boring Technology (2015)

#134

Post by Aeolun » Sun, Jun 07, 2020, 12:50 PM UTC

JamesBarney wrote: post #87

baron816 wrote: post #38

Earlier quoted context omitted.

React has been around for 7 years. ES2015 has been around for 5 years. React has become the de facto lingua franca for front end development. Could you imagine some CTO or technical lead saying, "We're not going to use React because it's too new and unproven." React has proven itself. Facebooks has 100K+ components. There are no unknowns there. Using jQuery or vanilla JS instead would be way more problematic and have…

Despite React being around for 7 years, it still seems slower to develop, slower in performance, and buggier than an equivalent SSR app. Despite having a couple years more experience in React than SSRs, I can knock out a 10 page web app with an SSR framework from scratch in a day (security, frontend, backend, data schema, deployment) but it takes me a couple more to knock out the same app in React. (Crud/Search/Repor…

I think this is partially because people suddenly ask for a thousand things that are impossible on a server rendered app.

Re: Choose Boring Technology (2015)

#135

Post by pydry » Sun, Jun 07, 2020, 12:52 PM UTC

namelosw wrote: post #77

nine_k wrote: post #62

I still think that "boring" is a wrong word. Choose the technology you know in and out, and are immediately productive with. Choose the technology which is sure to be around in 5-7 years, preferably 10-15. Choose the technology for which you are comfortable hiring the next 15 engineers. This does not mean that you need to choose something unpleasant, unergonomic, or ancient. Neither does it mean that you need to choo…

This is pretty much spot on. People usually missing the point of 'boring' because they would think of unpleasant and ancient stuff. The key value is indeed to avoid surprises. When I read WhatsApp used Erlang back in the day, I was pretty impressed. Not only the obvious things like Erlang was the forgotten secret weapon for massive concurrent apps, but also details like they used FreeBSD back in the day when there wa…

Whenever I hear "exciting tech" I tend to think "hyped to kingdom come". I think of node, docker, mongo, golang, etc. - tech that was pushed with marketing $$$ or big names. I have an inbuilt bias against that stuff - not that it's necessarily worse than alternatives but that the marketing budget or big name backer instantly makes me more suspicious.

For most developers it seems to work the other way around - big names and marketed heavily => it has buzz => it must be good.

Under boring there are two types - PHP and postgres. Boring tedious and annoying and boring reliable workhorse.

The 2nd type is my favorite type of tech.

Re: Choose Boring Technology (2015)

#136

Post by theshrike79 » Sun, Jun 07, 2020, 12:53 PM UTC

semicolonandson wrote: post #106

I've boot-strapped and lived from a web-application for over ten years, some of which have involved less than one day per month's worth of work. I credit this to boring technologies. Looking back, the best technical decisions were: - using an SQL database with lots of constraints and foreign keys and indexes. It's like typing for data. - emphasis on shell scripts and leaning on UNIX features (since these continue wor…

And vendor your dependencies if at all possible, that one library/tool you were using might just disappear of the internet.

It will still work in 10 years if your toolchain hasn't changed much.

Re: Choose Boring Technology (2015)

#137

Post by theshrike79 » Sun, Jun 07, 2020, 1:02 PM UTC

jasonkester wrote: post #29

MattGaiser wrote: post #4

This makes sense until I need to find a new job in 18 months.

The solution to this is to use the New Shiny at your day job, and the good boring stuff for your own projects: https://expatsoftware.com/articles/happiness-is-a-boring-sta... If it’s Somebody Else’s Money paying for the development, go nuts with whatever crazy tech their 19 year old CTO wants to roll with. Hopefully they have a VC holding the bag to subsidise the ride. But when it’s your stuff, and it’s your weekends…

Ahh, good old Resume Driven Development :D

Re: Choose Boring Technology (2015)

#138

Post by tarkin2 » Sun, Jun 07, 2020, 1:04 PM UTC

nine_k wrote: post #62

I still think that "boring" is a wrong word. Choose the technology you know in and out, and are immediately productive with. Choose the technology which is sure to be around in 5-7 years, preferably 10-15. Choose the technology for which you are comfortable hiring the next 15 engineers. This does not mean that you need to choose something unpleasant, unergonomic, or ancient. Neither does it mean that you need to choo…

Yeah. Java is pretty boring but I wouldn’t recommend for the majority of cases.

Re: Choose Boring Technology (2015)

#139

Post by theshrike79 » Sun, Jun 07, 2020, 1:04 PM UTC

ngngngng wrote: post #108

I once overheard a conversation between two colleagues. "I'm not interested in learning Go because it doesn't have many compelling features" "That IS the feature"

Having to build stuff from basic blocks with no hidden magic is the best part in Go.

It's SO boring, but also very efficient. Yes, you type more words, but that's why you got the fancy clicky keyboard.

You get stuff done and other people can actually understand your code, because there are no hidden gotchas, everything is just as you typed it out. Even the boring and repetitive if err != nil stuff just fades away, but you DO notice if it's missing somewhere.

Re: Choose Boring Technology (2015)

#140

Post by ProZsolt » Sun, Jun 07, 2020, 1:15 PM UTC

randombytes6869 wrote: post #117

AmericanChopper wrote: post #68

Earlier quoted context omitted.

Whether you end up with a hellish dependency tree is more up to the developer than the language. I’d say the only reason this is more common in node projects than it is in other languages is because dependency management in other languages is more tedious, so the barrier for introducing new dependencies is higher. All of my node projects have had rather tidy dependency trees. It’s also been quite easy for me to use p…

Trust me, its the lack of standard library. Python and Java are both "batteries included" . You can write apps decently with just 5-10 dependencies if you want. Every JS app I've worked on has like 10-20X the dependencies of projects written in languages with a good standard lib

I'm currently learning Go and it's at the other end of the spectrum. Most of my apps have only one to three dependencies and one is usually a database driver. It's a really good feeling when there is something missing from the standard library and you questioning yourself that you really need that thing.