ingvul

While I recommend reading DDIA, I think buzzcut_diet may end up disappointed. Reasons:

- it takes a while to read DDIA. Probably around 6 months of focused reading. Perhaps more

- one can learn a really good chunk of theoretical stuff... but probably not applicable to day to day work

- zero practical experience will be gained regarding Kubernetes, Spark, Kafka, EMR, Redis

So, I would recommend a more practical approach:

- start already reading the documentation of K8s, Kafka, Spark, etc. Choose one and go for it. I would recommend Kafka since its documentation is well written

- while reading documentation of the tooling above, one will inevitable stumble upon theoretical stuff that will not be explained in detail: that's exactly when you pick up DDIA (or similar books) and try to find the topic in the index and read it.

Mainly because it's look and feel. I'm not a "power user". Chrome just looks lightweight and feels fast. The only browser that is similar in these aspects is Safari.

Firefox looks bad. For example:

- the spacing between the home button and the search bar

- why there's a line at the top of the current tab? The way Chrome distinguishes the current tab looks "better""

- the "back", "forward" and "refresh" buttons look big

Go + plain html + plain js + postgres (or mysql) + nginx. If I need something more fancy, then Vue.

> be an engineer yourself before attempting to manage some

I've seen this. 90% of the time, the company loses a good engineer and trades him for a mediocre manager. It's a lose-lose situation.

Nowadays, managers are focused on 1on1s. Totally useless.

> However, being able to tackle open-ended problems is a huge value to businesses and it's the reason senior engineers make a lot more.

If you have "open-ended" problems, your managers are doing a bad job. Hell, I know that happens in real life, but then senior engineers are not more just senior engineers, they are jack of all trades (and not only at the tech level): they know about people, they know about product, and sure they know about tech. With these kind of senior engineers, one doesn't need managers anymore.

I feel the same (from time to time). It's becoming harder and harder to be just "a software engineer" in this industry. All of a sudden, the "perfect" software engineer must:

- be "product oriented: "Think big", "Think customers-first", "Get shit done"

- make his/her colleagues better (by mentoring, by leading by example, by giving talks)

- stand up and make himself heard (e.g., working on projects that touch on multiple teams... because staying in your corner is so 90s)

- focus more on "delivering features" instead of making the products more stable (otherwise, no salary increase. Bugfixes don't bring money)

- be on call, because "you build it, you run it, you own it"

- ... all of these, of course, while keeping your tech skills up-to-date (which is in itself quite taxing)

Working as a contractor is not that different. Just find someone to handle your taxes (although I understand that this in itself could be a headache for someone who only has worked as an employee). Also, as a contractor, vacation days are different as well: no work, no pay (whereas as an employee all your vacation days are always paid).

> We have a really high bar for hiring at Repl.it, Dalia and the other youngsters from Palestine performed better than at least half the experienced engineers I've interviewed in the past.

I really don't want to sound negative, but I find this difficult to believe. Sorry if I sound too harsh, but experienced engineers who don't perform better than recent graduates sure it's a thing, but 50% of the ones you have interviewed don't perform better than a recent graduate? Perhaps you were exaggerating? Or perhaps your interview process is really focused on what recent graduates know best (popular algorithms) and not in what experienced engineers know best (how to deal with real world codebases). Again, I don't mean to sound harsh, I think perhaps that "...at least half..." was just a way of saying "Dalia was really good" (which sounds more credible).

Seems to me a better way to do provision containers. Do you find any flaw in this approach? I wonder why not everyone is doing it as explained in the article.

Doing on-call is directly a no-go for me.

Q: As a senior software engineer, do I have to do paid "on-calls"?

A: Yes. Every team rotates on-calls among their senior software engineers.

Then I just leave saying "thank you for your time".

Would love to hear some sort of summary though :)

The average salary for a Software Engineer is $107K per year in United States.

The average salary for a Software Engineer is $66K per year in Germany (~61% less).

Source: indeed and payscale.

I always find a bit funny when US devs in HN talk about getting salaries above $200K/year... when the average US dev gets half of that. (I find it funny because everybody here thinks we are above the average dev level and can get a job at Facebook/Google/Amazon/etc... which is statistically incorrect).

> In 3 years in the US you earn significantly more than in 5 years in France, so the vacation and health coverage arguments do not hold, unless you have an expensive illness (>30k$ per year).

Care to elaborate? Especially the part about vacation. Do you mean that US developers will retire early than their European counterparts because they are earning more in average and by doing so will enjoy more free time? I'd rather prefer to enjoy my free time when I'm in my 20s and 30s than when I'm in my 40s, 50s, etc.

The part about the health coverage: well, that's the thing, you never know if you'll deal with expensive or rare illness... so the European way of health coverage is worth it.

It's a SQL beautifier.

Die Hard, Rambo, Rocky. I thought it was universal.

What about setting secrets in env vars? E.g., gitlab ci env variables.

I guess it's because not everybody can work at the top 5% of companies. Not only because the entry level is higher than on average companies... it's also a question of physics: the top 5% of companies cannot hire 100% of the pool of developers.

So, the vast majority of developers out there (including HN) will never work for a top 5% company.

It's just different. Why would developers in Europe make the same money as developers in China/US/Argentina? Different places, different salaries.

Personally I envy the high salaries in the US (for devs) but I wouldn't move to the US because in Europe I got 30 days of vacation plus public holidays (which makes around 45 days off per year... paid) working full-time (35 hours/week)... and anyway, if one wants to make serious money as a developer, the only way is to bootstrap your own SaSS; working for others (in Europe or in US) only gets you so far.

> It sucks that people keep using gross salary instead of net because it really makes a difference.

Gross is better because what every individual takes home after taxes varies (if you are single, married, have kids, church taxes?, solidarity taxes, etc.).

> In Germany, you would take home £52,911 / €58,117 / $71,102.

Based on what tax group? You see, it's not that simple. Those numbers could be true for people who are single and are living in the east of Germany... but they could be false if they are married and living in the west while paying church taxes.

More or less in the same boat, but slightly different. Since WFH started I don't pretend to be working anymore when I'm actually not.

Before (at the office): arrive at 9am, leave at 17pm. Work (productively) for around 4h. 1h or so for lunch and multiple breaks. 1h or so of socializing. 2h or so wasted doing... what? I don't even remember.

Now (WFH): start at 11am, finish at around 16pm. 30min/1h break. I work the same amount of time as before Corona (in terms of productive hours), but I don't waste time anymore.

Deliverables are still the same, we still manage (as before) to push our products further.

> Do people pretend to be sick to use up their X days?

How would one ever know? And what's the issue if someone pretend to be sick if they have up to X days to "be sick". I don't mind at all what my coworkers do with their lives.

> Like if production is down how can you say: "My 40 hours is up this week, I'll look at it on Monday".

It depends. If it's the first time production is down and I'm already off, I fix the issue. Once it's fixed I'll tell my manager: "we need on-call people. Please don't consider me for that position because I value more my free-time than money. Thanks". The second time production is down, I won't fix it.

If they fire me because I don't do on-call, then again it depends. I would revisit my contract and if it doesn't say anything about being on-call I would point that out. In any case, I would start to look for a new job asap.

In which country are you working? My full-time work contract explicitly says that I will receive X EUR/year for working 40h/week. So, yes, they are paying for hours worked.

> We monitor people's hours...

Here I stop reading.

How does k8s replace docker-compose on local machines? I have used minikube to run a local k8s cluster on my laptop and it's terrible. docker-compose works just fine.

I think tipping in Germany is quite established as well, not as a genuine expression of gratitude but because not doing it "looks bad".

Do you tip at McDonald's then?

Pardon my ignorance, but wasn't Docker supposed to fix this? (disparity of environments). I have read the other recently post as well about "Docker doesn't work on the new ARM based Macs", but I don't understand why. I mean, Docker has this in their website (https://www.docker.com/use-cases):

> It works on my machine! As a developer you know that one of the trickiest problems in software development is having to deal with environment disparity across different machines and platforms. Docker allows you to run containers locally, eliminating disparity between your development and production environments, and everything in between. [...] (Docker) is the ultimate answer to your portability concerns as containers can easily move across machines.

Is that not true?

But you don't need numbers for that. A simple "increased user engagement by refactoring our front-end in React" is more than enough; it tells me that the goal was to "increase user engagement" (that's the greater goal, nice!) and that you know (hopefully) your way around React (tech stuff, nice!). The number strikes me as bs.