Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Choose Boring Technology (2015)

mcfunley.com

Post reply on HN
Print view View original

71–80 of 297 posts

Re: Choose Boring Technology (2015)

#71

Post by at_a_remove »

I am all about the boring technology. I dislike the churn of learning something only to discard that knowledge in favor of something else a few months later. I would rather get better at the things I know how to do rather than learn how to do something new and hope to get proficient at it. It feels like time wasted, learning something that I know is disposable.

I get it, in the end everything is disposable but I like to minimize that churn and polish what I have that works for me. It isn't as fashionable or as cool but I try to avoid those circles if I can.

Re: Choose Boring Technology (2015)

#72

Post by brabel »

Throwaway8588 wrote: post #9

Except the most employable technology keeps changing every few years. TypeScript and Go and Rust are the hot ones now and they were barely on the radar a year ago. Ofc I am inserting them into work projects as I need to learn them.

I definitely wouldn't put Go and Rust on the same basket. Go is definitely boring at this stage (as in, it's proven and widely used - everyone knows its problems etc)... But Rust is still evolving, specially its libraries (if you follow the Rust ecosystem, you'll know what I mean), and I am not aware of it being used for lots of critical projects (though it's popping up everywhere where innovation is not frowned upon).

Re: Choose Boring Technology (2015)

#73

Post by archived22 »

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…

Another drawback of complex stack bites those people who have idea and money, but try to get product done through consultancy because they lack tech skill or does not have enough experience.

They read lot of 'buzzword' on the internet or heard them from their tech friend and ask for everything i.e. Microservice Architecture and cloud and all and etc. since beginning. Resulting in unnecessary huge team and tech complexity. An idea or poc which could had been easily done and tested in market with small techstack/small team. No wonder lot of these products fail.

Re: Choose Boring Technology (2015)

#74

Post by archived22 »

risyachka wrote: post #69
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…

Almost no one. And you don't need an interview for that. As you said, it requires a few years of continuous focus. And most jobs won't give you that. So it's even more time. And if a person with 5 years of experience sais he is an expert in a,b,c,d,e you don't need an interview do understand that this person doesn't even know what it takes to be an expert in one of these, because he obviously can't evaluate his skill…

As lot of businesses do not reach that scale where architectural or design or quality issues may pop up, "full-stack" devs keep moving the wheel. I think that is good enough and good enough is OK.

Re: Choose Boring Technology (2015)

#75

Post by brabel »

dmnd wrote: post #34

I'm constantly invoking this principle, but I have a small tweak: combine it with the (now anachronistically named) Python Paradox to get "use a tool from your toolbox". Restricting the number of different technologies in your toolbox gets you most of the benefits described in TFA. But contrary to "boring", it's actually preferable for some of those tools to be bleeding edge. That way you also get to enjoy the benefi…

> you need to have good enough taste to pick new techs...

So you see tech as you see fashion, i.e it requires good taste?!

When you choose a new tech, perhaps you should consider what problems it solves and whether its costs are worthwhile for you, not whether its a hot new fashionable thing to "wear" in parties (conferences).

Re: Choose Boring Technology (2015)

#76

Post by kitd »

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…

> YouTube was (and still largely is) written in Python, way before it was cool and well-known.

I agree with you on just about everything, but python was well-known well before YT. Django was a staple of the early web.

Re: Choose Boring Technology (2015)

#77

Post by namelosw »

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 was no preemptive scheduling but Erlang has preemptive scheduling so it was okay. Those details reflect they were very confident and they know perfectly what they were doing.

Re: Choose Boring Technology (2015)

#78

Post by beerbajay »

kitd wrote: post #76
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…

> YouTube was (and still largely is) written in Python, way before it was cool and well-known. I agree with you on just about everything, but python was well-known well before YT. Django was a staple of the early web.

The web has been around since the early 90's and Django was first released in 2005...

Re: Choose Boring Technology (2015)

#79

Post by Toine »

aaronbrethorst wrote: post #64
wp381640 wrote: post #24

Welcome to the enterprise tech world - it's funny how hard-learned lessons are re-learned in startups the hard way.

Welcome to being older. It’s funny how hard-learned lessons are relearned by younger people the hard way.

Exception in thread "main" java.lang.StackOverflowError

Re: Choose Boring Technology (2015)

#80

Post by peferron »

gavinray wrote: post #23
l0b0 wrote: post #13

As relevant as ever. It's fascinating how big web stacks are these days, even for small-to-medium sites: various combinations of at least one styling language (SASS/LESS/CSS), frontend framework (Angular/React), frontend language (JavaScript/TypeScript/Node.js), backend framework (Django/Express/Spring/Rails) backend language (Python/Ruby/PHP/Perl/Java), and message bus (ZeroMQ/Redis/RabbitMQ). That's just the fronte…

I don't know that necessarily correct. Previous startup I was at had a stack like this: - Frontend: Vue + Typescript - Android/iOS App: Vue (NativeScript/Capacitor) + Typescript - Backend: Node + Typescript - Database: Postgres - Deployment: Everything in Docker containers I know of a lot of places taking similar stances where the frontend and mobile apps are done in this way (IE React and React Native) and then you…

I just built a frontend and backend with TS following this same logic. I'm super happy with TS for the frontend, but I regret picking it for the backend and am considering rewriting the backend in Clojure while it's still early.

My reasons are:

- I don't need to share type definitions between the frontend and backend; the frontend can generate TS type defs using GraphQL introspection regardless of which language the backend is implemented in.

- The backend is doing a lot of data manipulation, which TS is not very good at. For example, there's no built-in group-by function, and group keys must be primitives since TS doesn't have value equality for objects or arrays.

- Static typing doesn't help much with setting up GraphQL resolvers correctly, and overall feels much less useful than on the frontend where it's absolutely stellar to type check all GraphQL queries, React calls, 3rd party component props, and so on.

- I miss clojure.spec for validating calls to external services.

Plus a few more situational reasons:

- I work in a team that's already familiar with Clojure. I don't think it's a huge barrier to hiring either; I didn't know Clojure before I joined, they just recommended me a book.

- I personally don't find that using the same language everywhere helps much in reducing context switching costs. Using different languages actually feels more engaging, especially when one is as pleasant as Clojure.

Put all these together and I'm seeing real benefits in using different languages.

Post reply on HN