DogLover_

I wholeheartedly agree about developing/debugging being harder. People advocating for Serverless secretly ignore this and focus on scaleability and pricing. I have worked at two places using Serverless and in those places setting up a local environment was not possible. Instead I have to deploy to a test environment to try things out. It is such a slow workflow.

My problem is that they signal that they hire until this layoff. The responsible thing would be to not hire for the last couple of months.

Go to their job page: https://stripe.com/jobs/search

Almost 700 open roles right now...

Never heard of her before now. Surprising given the impact of assembly.

Because barrier to entry is much lower now than it was for you when you entered the field. What we do is not that difficult and with the advent of youtube, best practices, and better tools it has become much easier than it used to be. It is also easier because to learn it you only need a computer, internet-connection, and free time. Training to become a carpenter for example, requires space, physical work, and some money.

Typing it is not the problem. It is reading at a glance that becomes much harder since lines oftentimes get split into multilines. I get less of an overview.

I agree that in your example it is not bad. Throughout that codebase it is clear though that they don't have a formatter that enforces a char-limit per line. It is when you combine those things it gets messy. Prettier uses a default of 80.

Looking at the code there is an awful lot of 'null's returned which I find hard to work with but that is a different topic.

Typscript: "function area(left: number, top: number, right: number, bottom: number): number {"

Javascript: "function area(left, top, right, bottom)"

In an editor the typescript function would likely be split into five separate lines.

"function area(

left: number,

top: number,

right: number,

bottom: number)

: number {"

None of the functions are complex but the the typescript function with the formatter creates a lot of noise.

I have to disagree. Adding the types will increase the number of the characters/lines of code which with a 80-char formatter limit can make functions look almost gibberish at a glance. Do that on a whole codebase and it becomes a mess to look at.

I feel like I am the only one in the world not liking typescript. It is not that I don't like types, it is what those types do to the readability of the codebase in terms of verbosity. My original programming language was Java but I switched to Node.js because I liked the simplicity of the code written in it. Nowadays every Javascript project seems worse than a Java project in terms of verbosity.

My main gripe with projects becoming verbose is that the code becomes hard to understand at a glance. Functions that usually could be 10 lines are now 15 lines becomes of the formatter and each line looks more gibberish because everything has a type. You have to manually filter out that noise. The best way I can describe it is that entropy is increased in order to get type safety.

Started my career with Java and I will never work with it again. It is mostly the culture around Java. Most Java code is verbose to an extreme but the devs themself will say it makes the code readable. They will say the language is functional because of lambdas but anyone that has used a functional programming language will know that it feels nothing like it, again because of its verbosity. It is so complex that you can't really work with it without having to use an IDE.

Must admit I find it discouraging that I spend years in university years ago when people now just finish some self-learned material in a matter of a few months. It is only getting simpler every year. I don't see the future being bright for this discipline if the sentiment is that that is all it takes.

It is hard for me to understand that big successful companies can hire so aggressively and then in time of a little economic downturn they need to cut people. From the outside, it looks like FOMO on a bigger scale and that just seems unprofessional.

I find it weird/irresponsible that they could not foresee this. Did they really expect the market to grow forever without downturn.

If they want people to come into office willingly, something needs to seriously change. Perhaps change hours from 9-17 to 9-14 for people coming into the office. The output would likely drop but perhaps that's what you need to do if you want people to want to come back to the office.

My guess is that they still pay US higher but I have no evidence of it. AirBnB also allows you to work from anywhere but if you look at their job-listing they still show location as San Francisco for pretty much all of the jobs.

If I have to guess, they mean within US

Bit harsh when many software projects in the world are delayed. Ethereum was released in 2015

It is not that easy. Many job-listings are US-Remote only.

Regarding link to AirBnb[2]. Their job-listing is still country dependent.

We pay taxes in the EU as well. Often the rate is much higher than the US but it depends on the country.

Those are hard to find. If you filter in your 3.link it goes from 1924 -> 38. That is 2% of the jobs.

The example with 'pattern' I really prefer using the variable 'pattern' instead of naming the variable to 'socialSecurityPatterUS'. Variables being too descriptive always felt like a dumbification that don't make the code better on an aggregate level.

Rarely do I see people examine individual commits, perhaps because it is already established that PRs should small and branches short living.

The point about bulled list of changes is a good one.

I find it easier to use rebase for this than having to manage branches.

Its called conventional commits https://www.conventionalcommits.org/

This best practice of committing often never made much sense to me. I find it typical that we as developers come up with such practices that start to control how we work instead of us focusing on getting work done. This practice makes even less sense when we make PRs that once merged are squashed into one commit?!

I try to make my commit history nice but the way people obsess about it, I don't think is productive.

Yes. I have debated with myself before which route I should take. I went with the Github way, just because I felt uncomfortable making a decision like this that goes against all the examples. Perhaps it was the wrong approach. Another problem with the Github way, is that functions/code-reuseability is almost non-existent.

You make some good points and I tend to agree with your approach. What you have to do though is skip using "uses: actions/", "needs", and won't be able to use other actions that has been published to the Github marketplace. So you have to make a conscious decision to go against the way people usually uses Github actions and won't be able to utilize some of their features. You avoid vendor lock-in though, which is what we are talking about :)

Sure, but then I guess you always install the dependencies from scratch, can't utilize cache, and won't have a dependency graph as well.

Parallelising your build/deployment will likely also be harder to do.