I don't know. As I said, in case of events it is understandable (small events can't afford catering and it is probably overkill).
But I am more curious about culture as well. Pizza is very ubiquitous, and from my experience people prefer it even when they can easily choose something else to eat. Of course, many people just like pizza, but it is sort of a no-brainer to order pizza if team stays late, although it is simple to order something else.
Didn't start with the tech industry. If you were a kid in the 80s or 90s, the vast majority of parties were pizza parties. This was also the entire business model of Chuck E Cheeses, which ran a ubiquitous series of commercials in the 80s. Its popularity in late-night hackathons and meetups is likely a holdover from college (where pizza at events is also ubiquitous), which itself is a holdover from childhood.
The history of pizza in the U.S. is itself fascinating. It was largely limited to Italian immigrants until WW2, when soldiers returning from the Italian campaign developed a taste for it. It exploded in popularity afterwards, particularly from the 1960s onwards. This is perhaps related to it being easy to eat without utensils, which made it convenient in the car/drive-in culture of that time period.
I was also surprised to learn that the vast majority of pizza varieties in the U.S. are actually American inventions, and that pizza in Italy basically consists of two varieties: marinara and margherita. All this stuff about pesto pizzas, BBQ chicken pizzas, meat lover's pizza, broccoli pizza, Hawaiian pizza, etc. are North American (including Canadian) inventions.
Ha, very interesting, thanks for the insight. I am not from the US, so I guess that's why it was always fascinating for me. But it makes total sense, given that american culture (I live in the States nowadays) appreciates speed and comfort. Pizza is fast, easy to eat, everybody is easily onboard with the idea.
I found this discussion quite interesting. This package is a low-level polyfill library, and is used in a lot of places (you can tell, according to github by 2,5 millions other apps/libs).
However, the author does not really have any money from it, maintaining it during his free time. Naturally, why people would go here, to such a low-level dependency?
Personally, I think Babel should support the author. But it shows an interesting phenomenon, when low-level libraries don't give you anything, even if half of the JS toolchain depends on it.
I am not a native speaker and not an author, but from my understanding, they mean that we focus on jobs, not on communities (as society), and then try to patch it later (e.g. go to specific clubs, gather in some places, etc). Moreover, it is hard to jump between social classes, therefore hard to change place of living/your surroundings.
So, in a nutshell, making our lives around job makes it hard (for majority) to live a fulfilling life outside of your job.
These people have their experience in one field for all these years, therefore they know a lot about it. They also work with limited number of technologies, which makes them good in them.
So, basically, they are good in certain tasks, so as long as they do these tasks you won't notice their lack of experience in other stuff.
> any skills/traits in those people
There are no patterns, to be honest, otherwise everybody would do it. There are best practices (some of them are debatable, like mentioned TDD) which you can read and try to incorporate, but don't treat them as dogmas.
Solve challenging tasks, reflect on your code, try different stuff, actively talk and discuss solutions with more experienced engineers, and you'll learn (relatively) quickly.
Very useful. Good notes on solving, reflecting, and actively talking.
And that point you write: "They also work with limited number of technologies, which makes them good in them. So, basically, they are good in certain tasks". An interesting observation, thank you.
JavaScript actually handles async IO nicely, and I've never heard this term before (callback hell, yes). So promises and async/await sugar actually make it pretty nice.
> poor ecosystem
Ecosystem is fine, just don't jump on everything new. The well-known problem is standard library, it is indeed a problem, usually addressed with a mix of additional packages.
> For the extra tax you pay in terms of build pipeline
This pipeline is norm in the frontend development, so in case you have people proficient in tooling, it is not that high (of course, it is hard if you have Java developers).
> Typescript vs Javascript as if these are the only two possible options for web development
They are not, but the nice thing about it is that you can have almost the same tooling as on your frontend, if you have some sort of complex application. So that increases speed of development, and TypeScript gives you some sense of scalability.
Last part is that TypeScript can be adopted incrementally, while another languages will require complete rewrite (and different deployment, etc).
I actually just made the term up myself just then to describe my feelings about the fact that all of the methods in our service layer are just `await this(); await that(); await another(); //...` and so on. Please be aware that this post is describing my own experiences in back-end web-app development using Node.
I feel I'm courting more controversy here, but if you're using `async/await` ad-nauseum your app might not actually be as async as you think it is. Of course this is a godsend compared to the callback hell that it replaced, but I can't help feeling that this is the right solution to the wrong problem. In my experience, most of the server-side applications I've seen written in Node are only practically asynchronous at the router level. Once you get into the controllers they tend to become entirely procedural and effectively completely synchronous. With the exception of the rare `Promise.all(...).then(...)`.... If you're using `await` on every single function call, it stops being syntactic sugar and just becomes more syntactic salt.
I completely disagree. Or rather I'd say if you're making a bunch of remote calls, and you need the results before taking the next step, then you're going to need to be doing something like this in any case. FWIW I feel a backend controller in Node is much easier to write, and to understand, with async/await than the equivalent patterns in Java.
As you put it, "Once you get into the controllers they tend to become entirely procedural and effectively completely synchronous" but that's because for most people it's far easier to think about a problem as a series of individual steps. Even then, if you have a bunch of serial awaits it's usually pretty trivial to go back and then await on a Promise.all() if you realize things can be run concurrently.
I think I might not have explained myself too well up there. I was referring to entirely sequential async calls. Like:
```
Thing thing = await loadThing();
Thing other = await thing.doSomething();
thing = await saveThing();
// repeat x1000...
```
"Thing thing = await loadThing(); ": Start loading thing, then await so the main thread can continue doing other stuff while thing is loaded.
"Thing other = await thing.doSomething();": Invoke some other function that does some stuff in the background, then await so the main thread can continue doing other stuff while thing does something.
"thing = await saveThing();": Saving can often be done in parallel so no need to block the App while something is saved. Invoke the save function, then await so the main thread can continue doing other stuff while thing is saved.
This gets you the advantages of async programming while still maintaining a legible coding style that looks similar to common synchronous code.
we have await this() and await that() also in python aiohttp and we will have in C++ co_wait this() and co_wait that()
and we have in C# await this() and await that()
this is not something specific to JS / Typescript...
I agree. Everything should be synchronous unless stated otherwise. The amount of 'await' and 'async' appearing is almost on every few lines but that is Node.js' problem, not TS'.
Other langauges can be adopted incrementally as well e.g. ReasonML and Clojurescript. I am not sure how you concluded that other languages need a different deployment. On the front end everything gets delivered to the browser...
I think it is a consequence of globalization. I don't have any statistics to prove it, but I think that people in general are not very keen to dig very deep, therefore everybody knows about certain number of "cool" cities, which everybody travels to and tries to move.
So, all popular big cities experience this influx of people moving there; expats have more and more options nowadays, so they also move to only cool places, therefore, it creates this problem. Not only it raises rents, expats can bump them a lot! They earn a lot of money, so for them extra $100 is not a big problem.
And urbanism – I guess more and more people move to cities nowadays, so it brings even more people who want to live there. Nobody really wants to live in the outskirts (unless it is USA), so major hubs, subway stations, downtown gets huge demand.
For some people cost of owning – property tax, various services is not a big deal. Also, in some places property rises in prices just by itself (like in San Francisco), you just have to wait.
Sometimes people lose money, but at the end of the day they can sign a good deal on it (let's say couple of years), and it will compensate their losses extensively. But they will have this "ready immediately" sign all this time.
But I am more curious about culture as well. Pizza is very ubiquitous, and from my experience people prefer it even when they can easily choose something else to eat. Of course, many people just like pizza, but it is sort of a no-brainer to order pizza if team stays late, although it is simple to order something else.
edit: bad grammar :\