Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: What kind of information do you look for before learning/using new tech?
171 points by wrestlerman 56 days ago | hide | past | web | favorite | 110 comments
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.



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


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?


Maaaaaaybe. It's really hard to get objective information about this stuff -- people naturally tend to evangelize the tools they already understand, and discredit the ones they don't -- which would make crowdsourcing this kind of info a real challenge. The inventor of tool Foo saying "Foo is good for this but not good for that" signifies much more to me than Random User of tool Foo saying the same thing.

Oddly enough, as I'm rereading through my own list I'm just now noticing how many of them really boil down to assessing the quality of the tech based on the humility of the tech's inventors: if they understand that their code isn't self-explanatory, and that good documentation is important, and that it isn't necessarily perfect for everything just because they invented it, then that implies a lot more care and deliberation in the code itself.


Oh yeah. There's some friction that needs to be addressed. No kidding :) However, we ALL suffer (more) from the pain(s) of not having good information, to say nothing of all the aggregate time wasted testing products because we have no other choice.

I think if there was (kinda sorta) a crowdsourced FAQ that might work. Kinda like you see on e-comm sites in that someone asks a question - aside from some boilerplate questions (e.g., your list) and others can answer. Spammy questions (and answers) can be down voted (a la HN).

Again...Maybe? :)


>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


Proper documentation, no matter who writes it, should cover how something works and what it does. Pros, cons, benefits and drawbacks are irrelevant here.

I want to know when method X of interface Y is called by the framework, with what parameters, and what it’s expected to return. This is a low bar that shockingly few software projects meet.


I don’t think I share your definition of “documentation”. I’m just talking about the “what does it do and how, what are the api calls and how do I call them” stuff. There’s no evangelism or bias there — or if there is, that’s certainly a hard strike against my perception of the product’s quality!


>I don’t think I share your definition of “documentation”.

Sorry for not being clear. I'm not attempting to redefine "documentation".

I was answering the OP's main question: "What kind of _information_ do you look for before learning/using new tech?"

You had answered "documentation" as one of the pieces of information. I was replying that "contrarian and negative" type of information is an important supplement to "documentation" or even a higher priority than official documentation. (E.g. The contrarian perspective may highlight a showstopping issue which could override any need to even look at the official documentation.)

My hypothetical of "dream documentation" including negative info was a utopian fantasy for rhetorical entertainment. It was not a realistic prescription for authors of real documentation.


OK, thanks for clarifying.

I don't tend to agree that contrarian / negative information is typically very useful as an indicator of the quality of a given piece of tech. There's no shortage of "Foo sucks" or "disadvantages of Foo" available for literally any value of Foo, and I rarely find them to be very useful; they generally feel like they're either written by someone who doesn't understand Foo very well, or who is evangelizing in favor of competitor product Bar. (Or, typically, both at once.)

I do of course agree that any product's inventors can be expected to be biased in favor of that product, and that pro-Foo material in itself is not a suitable sole source of information about Foo... which is why I said I weight so heavily in favor of products where the developers "acknowledge points where the competitor might have the advantage," and (in a different subthread) that I'm "assessing the quality of the tech based on the humility of the tech's inventors". It's also why I spend time looking at stackoverflow Q&A (watching people wrestle with their actual problems with a framework is much more illuminating than reading their rants about it afterwards.)


I was replying that "contrarian and negative" type of information is an important supplement to "documentation" or even a higher priority than official documentation.

But outsidetheparty already mentioned honest comparison with other work too, before bringing up documentation.


I think OP thinks about documentation of framework/language like an explanation of why/how/what for and not exactly API references. I agree with both of you, good API docs is mandatory, but also reading about advantages/disadvantages on the official website of given technology should be very easy to do.


>, but also reading about advantages/disadvantages on the official website of given technology should be very easy to do.

Yes, it's technically easy but not socially easy. If I go to the Elixir landing page at "elixir-lang.org", it doesn't list the disadvantages and warts.

Obviously to us, they didn't avoid writing negative things because they ran out of disk space to store the text or didn't have the network bandwidth. The reason is that it's human nature not to do that. We have to find that alternative viewpoint from people like you (since you're interested in explicitly writing about some of Elixir's issues).


Agree with you!


It's the contrarian writing that helps us learn the limitations and tradeoffs of the technology.

I agree that evaluating the contrarian side is quite valuable, however both sides need to be taken with a grain of salt. I think that sometimes reading the negatives is more helpful, because people tend to be a little less careful in exposing their prejudices, or tend to be drawn to the more clickbait-y side. This makes the shallow criticisms more obvious, except for the cases where it manages to exploit your own prejudices.


Yes! And I’d like to add that a lack of such criticism just feels wrong. Like I’m researching into a cult instead of a tool.


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.


These are the sort of thing I tend to ask myself when considering whether to use a new piece of tech, yes. Obviously when I'm working with a company that's already made a technology decision, I'm going to follow that decision unless there's a really compelling reason to start over with something new.


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.


In which way is his essay infamous?


I imagine there are people that get offended by it.

Me? I'll keep doing distributed and low level programming in Haskell.


It usually pops up at least once per week, often when people are complaining about bugs in NPM packages.


Infamous means famous, but for a bad reason. Villains are infamous.


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.


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.


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.


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


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.


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


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


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


Things really don’t move in the market as fast as people on HN think - especially on the backend.

Java and C# have been the go to enterprise languages for at least 15+ years. Sql Server/Oracle/MySQL have been three of the most popular database for more than 15 years. JavaScript has been in demand forever.

AWS adds stuff all of the time, but the basics still work like they always have.

I avoid trying to keep up with the latest $cool_kids_front_end_framework for just that reason. It’s about knowing where a technology is in the hype cycle.


Yes, but depending on what you are looking for that might not be a bad thing. It usually means that the technology is mature to a certain degree.


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.


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.


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.


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.


Whether something is used by others may be more a gauge for whether there is motivation to support it / whether it is here to stay, than whether it's the best solution to my problems.

When I'm trying to choose between competing technologies, I often choose based on popularity rather than isolated merits, as want to build upon something which other people will be contributing to, rather than something marked for death.


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.


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.


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.


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.


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.


Same principle when redecorating our house: Will I still like the colour after a week? a month? a year?


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.


Does this tech bring me joy?


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


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


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.


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.


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.


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.


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.


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.


1. Who uses it and what have they done with it?

2. Is it actively maintained? (How) are issues dealt with?

3. How popular is it and what is the trajectory?

I don't want to be the first person to run into all the issues. I'll let the kids do that, they love shiny new technology.

I don't want to invest into a stopgap technology (like Coffeescript). My gut feeling is that Elixir is one of these technologies, it has some good ideas that will probably show up elsewhere in due time.

I do value "XYZ sucks" posts to some degree, but unless I already know the technology reasonably well I probably won't be able estimate the impact of the issues.


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.


How useful is this tech? Some tech is just pointless or part of someone's scammy business.

How Eternal is the knowledge? Math is Eternal in the true sense, while that new webpage framework will be around for maybe just 2-5 years, and is thus not worth learning. (Although I am sometimes happy that people sacrifice their lifes on stuff like that, I would never do it.)

Vendor lock-in? I steer clear from that.

Is it being maintained? (Some things are okay not being maintained though. It depends on the type of tech.)

Surveillance potential. I am somewhat paranoid in my own personal life.

When procuring network-attached tech I usually dig through exploit-db and the CVEs and try to make myself a picture of how their security is being handled. Small companies are difficult to judge from this because they have little recorded history. (So I didn't buy any mikrotik router because of their shenanigan attitude to security, for example.)

Do the creator of the tech try to keep my hands away from digging into the machinery? Like hiding that it is really just a Linux/bsd box underneath? I stay away from that, if possible. (It's not always possible, almost all tech runs on Linux nowadays.)

I can be bribed to ignore any of these things that I usually avoid. For example, I learned MS Windows and some of their tech because I got bribed.


When I’m choosing a new technology, it’s almost always for a specific project, and I’m almost always choosing between 2-3 fairly similar options (Django or Rails? React or Vue or Angular? Swift or React Native? Redis or RabbitMQ? Java or Scala? Etc.)

There are few cases where one technology is objectively and universally better than another. Most of the time, each has strengths and weaknesses. Often there is overlap between use cases but one is better for one type of usage and the other for another type (such as Redis/Rabbit). In other cases they’re pretty much interchangeable, but one may match more closely to my particular mental model (my experience with React/Vue/Angular); or one may be easier to get started with.

With that in mind, I’m usually looking for balanced information about specific trade-offs. What is this technology good at that the most similar alternatives aren’t as good at? Where do the alternatives excel that this tool struggles. How do the philosophies of the tools differ? What’s the learning curve like? What limitations did you stumble over only after using them for a while? How do the ecosystems compare?


In some ways, the pairs of options you presented are fairly similar in that they solve similar problems and the solutions take a similar approach One of the interesting properties of the pairs you presented though is that in many ways picking one vs. the other is not a single choice, but a swath of choices you make collectively.

Pick Django? You're also buying into the system of Django packages vs. those for Rails. Same with all the others. Although I think for the most part in the examples you selected, both choices could be equally valid for different projects which is why there are multiple strong choices for those application areas. I think that also means you probably won't go too far wrong picking one vs. the other. I find the choice is often made by how well the stack integrates with other stuff I'm already working on.


Agreed. And I find that with tools that similar often the trade-offs aren’t obvious until you’re fairly deep into the project.

Or that the trade-offs have to do with differences in project philosophy (Rails’ convention over configuration vs Django’s explicit over implicit), which in turn impacts in what ways they’re flexible vs rigid in subtle ways, or what sorts of ecosystems grow up around them.

Often there isn’t a right choice or a wrong choice, but there are still trade-offs. And you or your particular team may be able to more easily absorb certain trade-offs than others.

Even if two technologies are fully equivalent, you’ll need some basis on which to base your decision and to use to build consensus so that you don’t spend the next three years fielding “we should have gone with Laravel” complaints twice a week.

Which is why those in-depth comparisons up front can be so valuable — if you can find them.


Examples. Documentation is great, but without practical examples, it's useless to me. I learn from example, not trying to decipher man pages.


Basically, I'm interested in knowing that adopting this tech will make my life happier and less complicated.

* Look at the open issues -- Is it full of buggy edge cases and "3d chess"?

* Quality and maturity -- Stuff works, as documented, under all possible conditions. Maintaining existing features / "tech debt" is prioritized over new features.

* What problems does it solve? What problems might it introduce? Does it actually solve the problems it's claimed to solve?

* Is it designed in a way that will totally break a possible future use case?

* How much of a "custom ecosystem" is there (bad), and how much of it is "open standards based" interfaces (good)

* Is it getting more or less complicated to use it over time? Can you learn it as a "simple cognitive model" or do you learn it as a "huge collection of random facts" e.g. "a cognitive edge case LUT"

* Documentation must be okay (no elasticsearch)

* History and sustainability -- How long has it been around, is it updated regularly (regularly != often), do updates break stuff (no pipenv)


It depends how core to what I'm doing the tech in question is.

Programming languages are their own category. They tend to not just be a project investment but a career investment. I generally at least get a feel for the language by reading some projects written in it and looking at code that does things I know how to do in the languages I already know. If there's some known strengths to the language (eg. "Go is good for servers", "Rust is good for system programs", …) I may be tempted to use the language for one such project as my first experience with it.

Software tech, things like what framework/DB engine to use, proprietary services such as AWS/GCE services and what not: Those I'll find when looking up how to solve a technical challenge I'm having at a particular moment. Reading up on it (documentation, known use cases, success stories, failure stories) is the only way to really decide. Then it's a matter of choosing the best fitting solution from the ones I found.

Important criteria:

- How well does this solve the problem at hand?

- Is it open source?

- If closed source, is it hard lock in or does it have open source tooling? (eg. Redshift uses postgres-compatible tooling/syntax, a huge benefit)

- How good is the code? (And what's it written in?)

- How good is the documentation?

- How popular is it? (= how likely am I to find help when faced with an obscure bug) / Is it an easy tech to hire for?

- How much do I trust its maintainers? (Especially: How much do I trust them to keep maintaining it and keep the project healthy)

- Is the pricing/licensing compatible and affordable for my use case?

The most difficult part of this process is knowing when not to use your own shitty hammer when there's much better hammers available for the current nail. It's easy to get stuck in a mindset of "The current tech, which I know, doesn't work really well for this use case but it can be made to work somewhat and that's good enough, no reason to look up better alternatives".

I'm always blown away when I discover a new piece of equipment I might have completely missed, were it not for actually googling/asking around for solutions to a new problem. Immediate discoverability of solutions kinda sucks when you aren't sure what to look for.


Another small datapoint, but I’ll shamefully admit I pretty much only adopt new tech (programming languages, popular libraries, trendy design patterns) if I hear a lot of people talking about them or using them. Programming for me isn’t so much about choosing the right tool for the job, as I as a single human will always be the bottleneck regardless of what tools I use. I’d rather maximize the chances that other people (hopefully better than I am) will come along or be hired who can help. I’ve experimented with most programming languages or interesting frameworks as I’ve heard about them, but I don’t really ever use them in projects as it feels counterproductive towards my goals. What point is there in choosing a slightly better niche technology that 1000 people know when the mainstream equivalent has 100,000 or even millions?


One that I've found increasingly important:

Documentation specifically addressing how to use in multiple different tech stacks. More generally, not assuming that everyone has the exact same pipeline as the core developer(s), and some evidence that they've made good faith efforts for the tool to work in other situations.


For the most part, most tech is usually good enough for everything.

A lot of the things people hate about a tech is workable. It's better to pick something unusually good at something with multiple flaws (e.g. PHP/JS) rather than something with no flaws but isn't particularly good at anything.


Popularity feeds hype. Hype feeds popularity.

Never mistake popularity for quality. Most of the time they have negative correlation.


Popularity is a quality in its own right. If something is popular, there are experts who know how to deal with the issues. There are clients who need issues solved. There is a market.

Just take SAP, probably a pile of garbage in terms of quality, but it's paying its consultants handsomely and customers keep rolling in.


> If something is popular, there are experts who know how to deal with the issues.

Just because a lot of people use it, it does not mean that any good people do.

Some technologies are very good in selecting novices only, and some others in selecting experts only. The first ones will always be more popular.

In fact, the average "expertness" of the documentation for the tech and its ecosystem is one of the things I pay most attention to when selecting tools. I've said "expertness" here because I have no better term for it, it does not mean extensive, correct, complete, or any such usual quality. It's more related to "are advanced uses documented?", "is it at the correct level of abstraction?", "are the examples for doing hype or real things?", "do the descriptions pose the proper point of view so they become simple?", and stuff like that.


>> If something is popular, there are experts who know how to deal with the issues

It is implied here that the product must have issues which are so complicated that you need experts to solve them.

I think it's often the case that hype is not correlated with quality, it's correlated with marketing, social networks, perverse financial interests, click farms, voting rings, etc...


> It is implied here that the product must have issues which are so complicated that you need experts to solve them.

No it isn't. It's orthogonal. If there aren't any issues requiring experts, that's great. If there are issues that require experts, there better be some experts available.

> I think it's often the case that hype is not correlated with quality...

Hype isn't the same as popularity. Hype helps popularity. I'm not saying you should jump on the hype train right away. Let the hype do its job, wait for some critical mass to form.


I'm talking about "quality" as uncountable not about "a quality" (countable).

"quality: general excellence of standard or level."


These days the more hype something seems to get the more skeptical I am. Especially if it is JavaScript related.


I'm actually quite interested in finding out which London tech companies use which languages/frameworks/tools. I write PHP because it's what I work with, but I'd like to learn the language that will help me find the most jobs. Anyone know of a tool that does that?


> Anyone know of a tool that does that?

Just type in the names of the languages/frameworks into a job search engine with "London" as the location. It'll show up in their hiring ads. If they aren't hiring, they're irrelevant.


Does depend on what you want to do and job adds are a signal with a lot of noise ie not all job adds are current or even real


The parent wants a broad picture. Noise evens out with more samples. Old jobs can be filtered out.


Thanks!


I think libraries (API's & frameworks) matter more than languages in a good many cases. Most mature dynamic languages are flexible enough to give you plenty of ways to express things such that libraries are the difference makers. (And they all have their own warts.) Rank and file coders are mostly just "library gluers" anyhow, for good or bad. A "better" language won't change that aspect much.

Thus, with PHP versus Python battles, for example, looking at libraries matters more. (PHP tends to be easier to set up for web-oriented projects. Something to consider for small or often-changing teams.)


1. Does it satisfy my use case?

2. What makes it better/worse than other solutions?

3. How is the project run/what is the maintainer situation like?

4. What is the community like? Will I have a hard time finding someone else to work on this project competently if I use this tech?

5. How long has it been around / will it be around in 5 years?


5.1. Is it grassroots, astroturfed or a company product?


The very first thing I look for is license. If it's not gpl, preferably gplv3+, or a similar compat license like apache 2, it is highly likely I will immediately close the tab and move on. The next thing I look for is what language it was written in, closely followed by when the last commit was, then at how well done the documentation/website is, the goal being to get a general understanding of how much the dev cares about the little things. Then I tend to add it to my list of interesting things and will compare it to alternatives in the same category. If after being compared to existing similar solutions, if still seems worthy, it gets tested, and if still deemed worthy it goes in the main list of my stack of software.


At one point in 2011, I quipped: "There is no dearth of new languages. Everyone who knows how to lex/parse can build one. And they will build one."

It's the same thing with any other piece of technology for me. It's easy to build tech. But In my opinion, when I look at new tech, here is when it is genuinely better tech for me:

  - Cross platform, solves toolchain issues
  - Provides a great debugger/observability interface
  - Integrate well with native/os/hardware. Open interface
  - Has decent basic primitives and not the kitchen sink
  - Well designed that the core is stable and is compatible for 5 years. "It's the design, stupid."
That's it for me.


How well the documents are. If I got to go to stack overflow or a community forum to try and figure something out that should be found in docs then that is a warning sign.

What scope does the technology cover. I believe in the rule of "Do one thing and do it well". If it suppose to do A, but can also be used for B and C is a warning sign to stay away.

Is it something a engineer built or a hacker built. Not saying a hacker can't be a engineer and such, but long term vs short term goals for technology need to be well planned out and executed. I use a ton of technology built by hackers, but anything I put in production is built by engineer.


First, I like to see what language-feature(ish) boxes it ticks. I like to see something that excites me :P

Actor model? Type-classes? Algebraic data-types? Immutability by default? Type-level programming?

Second, what is the tool support? Do I get an IDE? A languace server? A config for vim/emacs? At least syntax-highlighting? How do the error messages look like? Compiler? Testing frameworks? Lint?

Third, I like to evaluate practicality. Can I imagine maintaining a cli app in this? A web server? Would I be able to connect to databases? Easily serialize data-structures?


Community momentum, corporate support, and how significant the changes were between the last two big versions. That last point was a big determinant for me when I was deciding to learn react vs vue. The vue 1 -> 2 upgrade broke a ton of community packages, plus a lot of unhelpful tutorials. In the end I chose React over Vue, and only _sometimes_ regret it :)

Edit: also, active reddit community. I don't ask a lot of questions there, but it's a reasonably good metric of the health of something IMO.


Adding to whats already said in other replies:

Plus:

* is it tech i wanted before i knew it existed.

* tech clear on limitations / being unfit for case XYZ.

* community with low frustration levels.. where clear answers get clear questions.

Con:

* tech that is just the opinionated alternative of the month. Even if it catched on.

* tech website cant (or forgets to) explain solved problem in simple laymans terms.

* not actively maintained, must if facing external dependencies. (includes os, browsers, libraries, etc)

* docs are inconsistent/unversioned, or old versions are not kept available.


The question I ask, that everyone asks, is: "What's in it for me?" and "Why should I care?"

The features? I don't care. I need to understand the problem(s) that it solves. I need to understand the benefits __to me__.

Time is important. Absolutely! And while a free trial is helpful it is not a replacement for crisp and transparent communication. I cannot afford to spead half a day trialing only to find out Solution X isn't a good fit.


* Does it address an area that I find wanting in currently used tools/tech?

* Does it introduce a new way of doing something compared to how I'm currently doing it and is it plausible that it's substantially better.

* Does it do something similar to what I'm currently using but with significantly higher performance or reliability?

If any of the above are true, I will investigate and follow it and try it out on tests/projects matching its maturity.


I always try to find some negative but thorough anecdotes about the new tech. Either where it is known to fall short or even better some unexpected issues.


Mostly how does new tech integrate with existing tooling for the target platform.

Having less IDE features available, lack of graphical debugger, additional build systems, having to manually write FFI wrappers, not exposing all the features available in the platform languages, impedance mismatch to create libraries to be consumed by the platform languages are all issues that I might consider negative when evaluating new tech.


Primarily whether it's a good idea and whether it's supported, ie isn't someone's side project they'll abandon in 6 months.


Docs cause they're like the garden of a nice & clean house and people who love their homes always keep their yards neat and well groomed.


Wow, I love the comparison!


I usually look for what kind of problems will it solve and how it will make the development process faster and/or less costly.


Do I need to give the creator my credit card to test it out? That's normally a hard pass. Do I need to sign up for a mailing list? Or log into something? Pass pass pass. Does the software opaquely datamine me? Is Linux supported as a first class citizen. Not 'eventually', but now and feature complete.


There is no way for me to reply to all of that answers, as I have to work myself. But I really would like to thank all of you for answering my questions. Now not only I know, what information to include in my post, but also what kind of things to have in mind when looking for new tech :)


What yak shaving does it reduce/eliminate? Am I currently having to do that kind of yak shaving?

There's way more tech out there than I have time to learn. If it doesn't make some of my problems go away, then I don't have time for it...

... unless my employer pays for me to learn it.


It usually comes down to how easily I can dive in unless it's something super intetesting.

I examine how easy it is to start playing with the capabilities of the technology today and the possibilities that it could be used for.

Can't learn swimming by study, research and reviews alone.


One of the big things for me is the maturity of the language. Also, what sort of support it has. For example, Microsoft is backing C# so that probably has a bright future.


> Microsoft is backing C# so that probably has a bright future

Not too long ago, that statement would've been seen as satirical. Microsoft has left a huge graveyard of technologies behind. They seem to be on a better track now, but I'd still be wary.


Is it going to make me or my business more money?


Among other things, I like to compare the tool's popularity with other similar tools by using trends.google.com .


Worked examples. And a comparison with the "standard" choice; why is this new thing supposedly better?


I need to be able to run it locally. I will never be interested in cloud solutions (Dynamo, Kinesis, etc.)


So what's the link of your blog?


Hey. My blog is not ready yet. I also didn't mean to market myself. It was quite unexpected to me that the question got so much attention. I'm really happy about it, though. It means that I'm asking correct questions and I can get great feedback like here.

If you are interested in my blog you can contact me: adam@wrestlerman.me and I will send you a link when it's ready:)


* What problem this technology solves?

* How big is the learning curve?

* How is better than the competitors?

* How costly is to use it?

* Is it mature enough?


Go on stackoverflow and see if there's a decent number of activity on related tags


I usually search Google for "things i wish i knew when learning X".


Freedom. Is the source open? Am I free to use it as I please?

If not, I pass.




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: