It doesn't matter if you're a Junior or Senior Developer, everyone uses Google to search for solutions.

What a lot of people don't know, is how to effectively search for the right answer.

Let me help you improve your Google search skills with these 16 tips!

🧵🧵🧵

1. NOT Logical operator:

You use this operator to exclude results if it contains the operand using "-" e.g.

javascript -frameworks
2. OR Logical operator:

This is a binary operator that returns a result if it contains both operands or one of them e.g.

(angular OR react) javascript tips
3. AND Logical operator:

This is a binary operator that returns a result containing it's operant on the left and right hand-side e.g.

html AND css

This returns a result if both terms are in the search result.
4. Exact match:

Use quotation marks to return an exact match in your search result e.g.

python tutorial "full course"
5. Wildcard:

Use the wildcard "*" placeholder to return a search result containing anything in your phrase e.g.

"the * javascript tutorial"
6. Site specifier:

This is probably the most used one. Using "site:" will return searches from that specific URL e.g.

site:https://t.co/c7XaH1z0RU S3

The S3 section of the amazon docs will be returned.
7. File specifier:

Using "file:" returns a search result based on the file type e.g.

filetype:pdf javascript tutorial
8. Related specifier:

Using "related:" returns the root domain of similar websites e.g.

related:https://t.co/cBQZlrwV0X
9. Map specifier:

Using "map:" returns the location of your search e.g.

map:silicon valley
10. Cache specifier:

Using "cache:" returns a cached version of a website e.g.

cache:https://t.co/DJSbcG5Khv

A webpage indexed by Google will have a cached version available on Google's end.
11. Intitle specifier:

Using "intitle:" returns results that contains your searched word in the title e.g.

intitle:best vscode extensions
12. inurl specifier:

This is a specifier that returns results containing its operant in the URL e.g.

python inurl:tutorial
13. define specifier:

This will display the meaning of a word in a card-like result e.g.

define:entrepreneur
14. intext specifier:

Find pages containing a certain word (or words) somewhere in the content e.g.

intext:best way to learn python
15. blogurl specifier:

Find blog URLs under a specific domain e.g.

blogurl:https://t.co/cynZoYUFJ3
16. movie specifier:

Find information about a specific movie e.g.

movie:avatar
You've reached the end of this 🧵

Please RT and Like it, if you found it helpful so you can share it with others.

More from Tech

A brief analysis and comparison of the CSS for Twitter's PWA vs Twitter's legacy desktop website. The difference is dramatic and I'll touch on some reasons why.

Legacy site *downloads* ~630 KB CSS per theme and writing direction.

6,769 rules
9,252 selectors
16.7k declarations
3,370 unique declarations
44 media queries
36 unique colors
50 unique background colors
46 unique font sizes
39 unique z-indices

https://t.co/qyl4Bt1i5x


PWA *incrementally generates* ~30 KB CSS that handles all themes and writing directions.

735 rules
740 selectors
757 declarations
730 unique declarations
0 media queries
11 unique colors
32 unique background colors
15 unique font sizes
7 unique z-indices

https://t.co/w7oNG5KUkJ


The legacy site's CSS is what happens when hundreds of people directly write CSS over many years. Specificity wars, redundancy, a house of cards that can't be fixed. The result is extremely inefficient and error-prone styling that punishes users and developers.

The PWA's CSS is generated on-demand by a JS framework that manages styles and outputs "atomic CSS". The framework can enforce strict constraints and perform optimisations, which is why the CSS is so much smaller and safer. Style conflicts and unbounded CSS growth are avoided.
After getting good feedback on yesterday's thread on #routemobile I think it is logical to do a bit in-depth technical study. Place #twilio at center, keep #routemobile & #tanla at the periphery & see who is each placed.


This thread is inspired by one of the articles I read on the-ken about #postman API & how they are transforming & expediting software product delivery & consumption, leading to enhanced developer productivity.

We all know that #Twilio offers host of APIs that can be readily used for faster integration by anyone who wants to have communication capabilities. Before we move ahead, let's get a few things cleared out.

Can anyone build the programming capability to process payments or communication capabilities? Yes, but will they, the answer is NO. Companies prefer to consume APIs offered by likes of #Stripe #twilio #Shopify #razorpay etc.

This offers two benefits - faster time to market, of course that means no need to re-invent the wheel + not worrying of compliance around payment process or communication regulations. This makes entire ecosystem extremely agile

You May Also Like