Ask HN: What kind of information do you look for before learning/using new tech?

[wrestlerman]

Hey. I am currently writing a blog post about my experience with Elixir. I aim to write about things I liked, but also I want to describe stuff that I just hated or disliked. Because I've noticed that people always try to praise the new tech they are using, but rarely point out bad things. And the truth is that learning a new technology is many times very time/money consuming process.

[outsidetheparty]

* Is there a clear reason the new tech exists? What differentiates it from its competitors? This alone rules out like 90% of new front-end web frameworks / widgets / plugins.

* Bonus points for tools whose authors have made the effort to explicitly compare it with competitor tools, particularly ones that acknowledge points where the competitor might have the advantage. ("Our new tech is better than existing old tech in every possible way" gets the side-eye from me; "Our new tech is better than existing old tech for these particular purposes, but old tech may still be more appropriate for these other purposes" goes a tremendous way towards confirming that the new tech has a real reason to exist.

* Is there documentation? Is it any good? This is a really low bar, but far too many new tools have no documentation at all ("just check out the source code") or have minimal, incomplete, or tautological docs ("bar.foo(): executes the foo method of bar"). A message board or IRC channel is nice, but not a substitute.

* How big is the API surface? Does it need to be that big? I tend to avoid tools where there are six different ways to do the same thing -- looking at you, Angular -- it suggests the developers are unfocused or in disagreement, and makes it harder to find support or documentation on any particular issue. Same thing if the API has undergone major breaking changes or paradigm shifts between versions (looking at you, Angular...)

* What does the tag look like on stackoverflow? This serves as a good indicator of whether the tech is too new or obscure to bother with, what the common pain points are, the average skill/knowledge level of its users, and whether help will be available if I get stuck when using it.

* Is there a relatively simple way to try it out? I'm much more likely to experiment with something where I can clone a repo and get going with simple but nontrivial example code; if I have to reconfigure half the settings on my machine just to get a hello world, I'm not going to bother.

[chiefalchemist]

Ya know...this - along with other answers - is a product waiting to happen. Kinda like Product Hunt (I suppose) but with particular Q&A crowdsourced so everyone can get a clear non-marketing spun picture of a given product.

Maybe?

[jasode]

>Is there documentation? Is it any good? This is a really low bar,

I definitely understand your reason for prioritizing documentation but I wanted to point out that "documentation" actually accomplishes the opposite of the OP's concerns about warts/disadvantages/gotchas/etc:

>, but also I want to describe stuff that I just hated or disliked. Because I've noticed that people always try to praise the new tech they are using, but rarely point out bad things.

As we know, documentation is typically written by people who are generally positive about the programming language or technology. Hoping for documentation authors to point out the flaws is like asking a mother to list the reasons her son is defective and girls shouldn't marry her.

To echo the specific issue the OP mentioned, my [totally unrealistic] dream documentation would be written by a crusty skeptical person that was an expert in the technology but became disillusioned by it. They'd point out all the flaws and pathological (but realistic) use cases where the technology fails or is inappropriate.

Since official documentation doesn't include the contrarian viewpoint, the newbies trying to evaluate new technology have to synthesize the "negatives" from other sources. E.g. I've typed the following phrases into google search:

  "golang sucks"
  "disadvantages of golang"
  "rust sucks"
  "disadvantages of rust"
  "disadvantages of python"
  "disadvantages of functional programming"
  "disadvantages of Linux"
  "disadvantages of <anything>"

It's the contrarian writing that helps us learn the limitations and tradeoffs of the technology. Do I search on "rust sucks" because I think Rust is bad?!? No. I search on that because that's the negative phrase that others might have used -- and I want to read their criticisms of Rust.

By all means, read the official and blessed documentation of the technology but be aware that it's a very biased viewpoint.

EDIT: added "[totally unrealistic]" to prevent misunderstanding of my point

[itwy]

So you have this list written, and whenever you encounter a new technology you run it by it?

Or you just imagined your ideal choosing process?

Or perhaps you use what you employer's previous employee chose to use.

[nikanj]

What I want to see is at least a few really gnarly bugs that were eventually solved. I want to make sure the tech is backed by people who are 1) highly skilled 2) actually motivated to solve the issues. In short, the kind of people Mickens refers to in his infamous essay ( https://www.usenix.org/system/files/1311_05-08_mickens.pdf ).

I have built this standard up after a few mistakes, where we chose a tool just to realize pretty much everyone working on it was a extremo ultimate rockstar ninja, better known as first-year CS dropout with a god complex.

NB: I'm not saying all first-year dropouts are bad, or that having a degree is in any way mandatory in this field. All I'm saying, is that when our site is down, I'd like to have a few people with 1980s MIT Electrical Engineering degrees on my team. The kind of people who know what a process is, how TCP passes packets, et cetera.

[iiv]

In which way is his essay infamous?

[ukutaht]

Almost all tech decisions come with a set of tradeoffs. I wouldn't trust articles praising certain technology because they are probably ignoring the tradeoffs that come with it.

Elixir is great for a chat application. At the same time it's probably not the right choice for a Machine Learning project.

Of course there are a number of absolutes that I look for regardless of the context:

* How good is the documentation?

* Is it actively maintained?

* Is it mature?

* etc.

[lostcolony]

Interesting example you chose there. While Elixir doesn't have a "when to use/not to use", it mentions its ties to Erlang quite clearly, and Erlang has this http://erlang.org/faq/introduction.html, specifically section 1.4, "What sort of problems is Erlang not particularly suitable for?"

Relatedly, while I wouldn't use either for many types of ML...I wouldn't use Python either. The only benefit to using Python in this space is it has libraries bound atop C/C++ implementations. Erlang/Elixir doesn't, that I know of, but that doesn't prevent it from being done if someone wanted to. In terms of actually building something from the ground up...well, it depends. It isn't fast...but it does make the concurrency part easy to model ( https://www.amazon.com/Handbook-Neuroevolution-Through-Erlan... for instance), and for learning/prototyping that might be what you're prioritizing for. Certainly, Erlang/Elixir have seen use in high speed trading and ad bidding platforms, things known for needing low latency.

[analog31]

The first new "tech" I learned was in the early 1980s, so I benefit from the perspective of seeing how my choices have panned out over the short to long term.

And now this might seem weird, but I have had good results following tech trends that attracted the widespread interest of hobbyists. These tend to be things that are easier to obtain, install, and use, and that have communities built up around them. The hobbyists will tend to weed out the things that are just too painful to use.

Examples over the years include Turbo Pascal, Visual Basic, PIC microcontrollers, Arduino, and Python.

Some of these are proprietary technologies, of course, but their vendors didn't abuse us too much (until Visual Basic went overboard with dot-net, whereupon I switched to Python). I got a good solid decade or more out of each of these things.

Of equal or greater importance to the use of these tools is what I can learn. I don't mind throwing a vendor a few bucks if I will use their tool to expand my knowledge, and if that knowledge is applicable to a broader range of things. For instance through Python and the community of developers, I've learned new disciplines that have made me a better programmer in any language.

[kenha]

What’s the goal of learning/using a new tech? Is it for a task? Or is it for your own learning?

If it’s for a task, I’d say:

1. Really spend some time to understand what you’re trying to solve 2. (If applicable) What pain point are you experiencing with existing solution? 3. Find tech (old or new) that might be a good solution, and understand their limitations/trade offs that you'll be making by choosing this tool.

Then, make a decision.

If it’s for learning, it ultimately is what are you trying to get out of the learning experience, and see if it fits your goal. (It is totally OK to learn a new tech just because it sounds cool - Learning more about something cool is a type of goals as well.)

[scarface74]

The job boards.

My time is limited for learning any new to me technology. If it doesn’t either lead to me making more money in the future or remaining competitive, I don’t learn it.

[wrestlerman]

Makes a lot of sense. Thanks, I didn't think that way, although I do check out job lists quite a lot.

[spreiti]

I apply the same strategy and focus on job listings from government related jobs/projects.

[Bahamut]

But wouldn't that mean you're lagging trends?

[jwr]

1. Is there something interesting/novel/intriguing? Something has to capture my interest and show significant value. I mostly write in Clojure, so the bar is set pretty high for this one. New syntax doesn't impress me, building large reliable systems does.

2. Is it elegant? In the general sense: things that are elegant are often also good designs.

3. Do people use it? This is a hard one, and stems from 25+ years of experience. No matter how beautiful or impressive the new technology is, there will be problems, and I am too old to iron them out myself. I've got things to do. So, tough as it may sound, these days I will not start using things that have not seen reasonable adoption. This does not mean I won't read about them, just not use them. And my criteria for "reasonable adoption" are not "everybody and their dog uses it", I just need to see a user base. Also, the threshold is higher for databases. Practical examples: Clojure and ClojureScript are fine, Datomic is not. RethinkDB just fell below the threshold and I have to migrate; FoundationDB is barely getting to the threshold.

Taking Elixir as an example, it fulfills all three criteria. I know what it is, I've seen it in action, I read about it and I keep in the back of my mind as a tool I might want to use when needed.

[royalghost]

I decided to learn Elixir not just to learn the language but to understand how functional programming works. On my day to day job I use Java/Kotlin but in the past I have used Ruby. So, for me it makes sense to learn Elixir and apply it's good practices of functional programming to my day to day job.

[moonlet]

Maybe I’m strange by HM standards, but unless it’s sometjing I’m just learning for fun, it must be used by 2-3 major companies or projects before I’ll consider it worth seriously picking up. It must solve a problem I have that I can’t solve with technology I already know. It must be relatively approachable and have at least minimal documentation.

[lm28469]

It highly depends and what you're doing, most people don't face the same issues as "major companies" like Netflix, Google, Uber etc ... Yet a lot of people chose their stack based on these companies and you end up with over engineered solutions which are slower / harder to maintain than smaller / less hyped technologies.

[yaseer]

Interestingly, those blog posts that are of the form "I/We started using X. It's so much better than Y, we used before!" tend to attract more attention than a nuanced analysis. Probably because a positive blog post is inherently more exciting than one that goes over the subtle but important details.

The most important is an analysis of what use-cases is Technology X good for, and why? Every technical decision is a list of pros and cons. If it fits the use-case perfectly, that is the most important factor.

After that the most important factor I consider is community and momentum.

It's possible a technology is immature and lacks good documentation. BUT - if it has a rapidly growing community and momentum, these 'cons' will disappear rapidly.

[tabtab]

Here's my check-list based on personal experience:

1. Is it road-tested for a few years at least? Unless you are in R&D or a high-risk start-up, don't volunteer to be a guinea pig. 5 years is my rule of thumb.

2. Are there successes in similar organizations? One size does NOT fit all. Make sure it's useful in your particular organization in terms of domain (subject matter), culture, and company size.

3. Do the benefits over-emphasize a few narrow factors while ignoring others? There's rarely a free lunch; most decisions are balancing various trade-offs. There are probably down-sides that vendors or fans don't want you to know about or failed to notice due to enthusiasm bias.

4. Does it over-extrapolate current trends? For example, just because more UI's are going mobile does not mean every business is throwing out their mouse and big monitors. You may be limiting yourself by trying to make your UI's both mouse-friendly and finger-friendly even though most actual business users will be on a desktop. It's not always good to keep up with the Tech Kardashians; they are not always rational or timely.

5. Does it require a big learning curve or lots of prerequisites? If the new technology turns out to be mostly a fad instead of a real improvement, a long learning curve or expensive investments will drain your time and budget. Look for incremental improvements first.

6. Vague buzzwords or promises: Lack of specifics and realistic examples is a sign you are being had.

7. Experimenting is fine & recommended, but don't do it on production projects. If possible, introduce it to production gradually.

[harel]

This might sound a bit esoteric, but it works for me every time: First of all, it's a feeling. Tech A feels more 'right', or resonates better, than tech B (where both are in the same category). Of course this is not the only metric. I'll look at longevity prospects of the tech, how much it breaks with 'tradition' and I'll try to focus on the negatives people have about the tech. But if more than one solution presents itself and I'm at an impasse - feeling wins.

I also acknowledge that one day, I might wake up to a stinking pile of tech-crap, but even then at least I know that at the time it felt right.

For example, many years ago, in a decade far far away (The 90s), I went with ColdFusion as a tech stack. Back then it was that, Perl or maybe TCL. ColdFusion felt right because it allowed very rapid prototyping with a clear syntax and batteries included. There was nothing like it. Fast forward a few years later and that tech was so smelly it made everyone nauseous but I knew at the time it made perfect sense, and by then other options presented themselves.

[outsidetheparty]

I had the same experience with XLST back in the day. At the time it was the perfect tool for my needs -- I no longer had to wheedle the back-end guys into giving me the specific data I needed, they could just dump it all on me in a big wad of XML and I could do anything I needed to it.

I mean, the whole time I knew it was a doomed language, far too philosophically pure to be practical, and the signs that XML was a mass hysteria were there from the beginning -- but it was exactly the tool I needed at the time I needed it.

[tonyarkles]

I call it “does it speak to me?”, which I realize is a totally non-scientific approach. That captures things like philosophy (is it a shit ton of tiny objects you glue together? Or more of a functional/immutable kind of approach? Etc), ergonomics (does this feel right in my hands after using it for a few hours?), documentation, etc.

[geoka9]

Another similar and esoteric one: I also look at the pedigree (the people behind the project). For example, Golang caught my interest because of Pike, Thompson and Kernighan and I'm a big fan of their prior work. Adopting a new language for non-toy projects is always a bit of a gamble, and in this case it paid off in spades.

[bulletsvshumans]

Does this tech bring me joy?

[stared]

Basically these key factors:

* are there any tutorials / code examples? (to see if I like its API/philosophy AND there is a way to pick it up)

* are there any practical, working projects out there (used by companies, etc)? (otherwise it may be not useful for bigger projects)

* is it in active development? (otherwise there is a risk that it will cease to be useful)

* how does it match against other tools (e.g. maybe it is easy to pick, but so are all other frameworks).

Also, I did write some comparisons. Vide: https://deepsense.ai/keras-or-pytorch/ (got popular here).

[jshowa3]

What kind of information do you look for before learning/using new tech?

I look for a book. Books in general are usually miles better than technical blogs and you can find a ton of information addressed about a subject in one place, so there's the convenience factor (not that you couldn't create some program that indexes your bookmarks, but still have the problem of providing meaningful titles and organization for your bookmarks).

I also find that books are generally peer reviewed, especially textbooks, so the BS is kept to a minimum. Makes for a more boring read, but its more accurate.

That being said, I like language analysis posts. People tend to bring up a lot of things I haven't thought of, and there was one done on C a while back on HN that looked very good: https://eev.ee/blog/2016/12/01/lets-stop-copying-c/ (tbh, I skimmed the article because I didn't have a lot of time to read it at the moment).

[ibash]

I’m surprised this hasn’t been mentioned: Can I read the code?

This applies to everything open source, including languages. If you open up the codebase and go “wtf” that’s a problem. If you open up the codebase and go “I don’t understand this, but it looks clean and with some effort I could understand this” that’s gold.

This is especially true for libraries, you get a sense for the right size and right amount of complexity in dependencies.

[thisisit]

Two things really.

One, usability over existing systems. It is a difficult one to actually answer but I find people talking about new technologies all the time and when you ask them - Okay, what can we do with it which older technology couldn't? Mostly I hear murmurs or barely justifiable answers. But, if the explanation is sound, I go for number 2.

Does the person talking about it has significant exposure into the problem space? Mostly you will see people talking about how X is great but never having to work with the nuances of an older tech Y.

Now this process has some bias built-in. As a supporter of older tech Y it is entirely possible to never find a reasonable explanation. The only way around it is to talk to as many people as you can.

[mschaef]

This is an excellent question. I think this maybe a fault of mine, but I tend to let myself be dragged into new technologies rather than actively pursue them. (What I'll offer in my defense is that I also tend to pursue roles where I'll be pushed to use new things.)

Rationale is that in a world with limited time, I'd rather focus on solving problems external to the technology itself. If I have something in my toolbox that will work, then it's generally the easiest thing to use, rather than learning something new. There's less of an immediate learning curve and fewer of the issues associated with being an early adopter.

Where this changes are in situations where either the investment to learn a new technology is low enough or the potential for return high enough that the learning might be expected to produce a high ROI.

So what that means practically is that I'm looking for things where I either have an immediate commercial need to know it or a strong feeling it's likely to be useful in a way that none of my existing toolset will fulfill.

From the perspective of something like a programming language, this is part of the reason I've tended to like Lisp-family languages as an adjunct to C-family languages. They're different enough that they're more likely to be complementary to each other and it's likely to be easier to make choices about what code goes in which language.

[kodablah]

I think your post would be valuable. I specifically look for (and sometimes make) lists of annoyances w/ any language I work with. A lot of times at a glance you can't tell if a compiler is buggy, some parts don't feel ergonomic, there is limited support/ecosystem, etc. I don't use the info to make my decision, I use it to temper my expectations.

[teunispeters]

Same questions for learning old technology (eg : lisp) - why is it used, what is it good for, how can it change how a problem is approached, what domain is it intended?

and of course compare with existing and known. Very rarely does an old or new tech measure up against comparison... unless it offers something not present elsewhere.

And of course, bug reports (). If there's a long queue of bug reports I won't touch it until a significant number are addressed. (when I worked in commercial drupal dev, this is how we picked modules to use). If there are no bug reports or any kind of online reputation of ignoring or denying bug reports, it gets avoided. This is not unusual in project with particularly fragile egos in charge and therefore unreliable. () bug reports include feature requests, documentation requests and similar as well.

[yamalight]

I always look for articles that talk about issues that arised with that specific tech during / after development. Edge cases and workarounds, things you cannot do at all, maintenance, etc - this is IMO the most interesting bits when you are evaluating a new technology.

[Maultasche]

I look for what a technology is good at and what it isn't so suited for. All technology has its advantages and disadvantages, and I want to find out what those are. What sort of applications is it suitable for? What operating systems does it run under? What does it not do well?

I'm also learning Elixir and writing about it at https://inquisitivedeveloper.com/. In the first couple of posts, I talk about what Elixir is really good at and what it isn't good at. I'm generally positive about it but I do grumble when I encounter something I feel could use improvement or doesn't make sense to me.

For example, Elixir is great for concurrent and scalable software. I'd use it to build a web service or game server, but it is unsuitable for a game client, physics simulations, or OS development. It's just not low-level enough for those purposes.

To sugar coat it is to just set up your reader for disappointment further down the line when they hit the limitations and realize that it's not suitable for their needs.

I also keep a general awareness of what technologies are out there and what they're good for. I've never used Redis, for example, but I know what it's good for. The same applied to RabbitMQ. I knew what it was good at even though I didn't use it. That lasted until I encountered a situation where it would be useful and I ended up introducing it into my organization.