atomicity

They are implicitly comparing media sources to non-"media staples", such as your gut or your dreams. There may be "general information sources" better than those.

Seems like Node.js isn't the only language where people notably introduce dependencies.

So, global-yet-Western corporations outsourced manufacturing to to China, some "unfair" trades that have long-term benefits for China happened, and now Chinese companies can now compete against those corporations (at least on Amazon).

I don't see how the West is lost, even after the author claims that if there's a war against China, "You’d need to walk around naked because you have no shirt, pants, socks, or underwear". Global-yet-Western Companies that outsourced manufacturing to China like Nike and Apple seem to be doing very well.

Furthermore, why is the fact that Chinese companies can compete after 30 years (while following the CCP rules) a bad thing? Did globalization go wrong because this wasn't supposed to happen? Was China supposed supposed to just be the world's cheap manufacturing for eternity? If so, a better title for this article would be "How China Was Not Lost".

The commenter you replied to seemed to be comparing 2 situations. That seems normal to me. Comparing things seems to be great way to understand complex issues.

What makes the comment a wrong way to discuss? Is it a bad form of comparison for some reason?

Nice anecdote, I tried to speak more to the point that I think that most US citizens are right to support the US escalating the conflict against China. Their values align with their actions.

Furthermore, people that think they can convince US citizens that they should not escalate the conflict are focusing on a lost cause. This does not mean no discourse should happen, but people should understand that differences in opinions are due to very big differences in values.

I did not look much into why a Chinese citizen would support China escalating the conflict against the US nor have I done much research on how China builds up anti-US sentiment.

My assumptions:

1. Hedonism is "fairly correct". In a well-fed and low-violence society, the pleasure/pain axis explains >40% of what every human cares about, especially chronic pleasure/pain.

- 1a. Both the US and China are low-violence and well-fed.

2. Obesity is responsible for a high amount of pain. Furthermore, there are few things in society that don't kill you which are worse that obesity.

- 2a. People don't die that much in societies like China.

3. Modern entertainment is a good painkiller. However, obese people that consume it still experience great amounts of pain throughout the day. Entertainment that distracts people from fixing the chronic pain they feel is a negative to society.

With these assumptions, the US doesn't look like a significantly better place than China. In theory, the freedom enabled by the US allows people to do well on the pain/pleasure axis. In practice, the US enables companies to do things that lead people into greater chronic pain.

Note that I think that Taiwan could be a significantly better place than China by this logic.

I've never understood why people support the escalating US-China conflict since it's so easy to just keep focusing on win-win collaborations but your comment gave me an insight.

Please let me know if this is wrong, but I think this is the argument:

1. The US is a better leader than China because it is a significantly better place. Notable US problems that cause lots of suffering are significantly less severe than notable Chinese problems.

2. As a result, the US government should put a lot of effort into making sure that China doesn't become too powerful. It is ok for the US to publish articles that are less reliable than those on Iraq WMDs because if China becomes too powerful, the world will be far worse. In particular, China should not become powerful enough to project its values on other countries as much as the US does. China also should not be able to non-democratically reform international, democratically-decided rules such as International Maritime Law.

For most people in the US, it would take heaps of evidence and learning could to even make them doubt that US might not be a significantly better place than China (Note that I'm not arguing that the US is not far better). On the other hand, many people in China doubt that the US is significantly better as China because of how much better they see their life compared to the past. So, they don't understand why people in the US are confident about their conflict against China.

I personally can't buy into this argument though because I lack the confidence in my personal philosophy to know what a "better life" truly is. However, many people in the US have a more stable philosophical foundation and could never be convinced that the US is not a significantly better place than China.

The author seems to be say in the article that writing readable code, at least for yourself, is still an important goal. I think they are arguing against why a writer shouldn't be expected to take it further.

For example, should a new grad be able to read your code without help? Should a 5 year old? At some point, you are spending more time writing design docs, refactoring the code, simplifying the tests, and gathering learning resources than you are just writing code that works.

Newer engineers rarely hear about how much they need to learn to read good code, and how much disagreement there is about what good code looks like. As a result it is easy to get into the mindset that "surprising" or "complex" code is bad. Instead, it would be a lot better if engineers are encouraged from the start to see reading code as a challenge. Nobody starts off knowing grep, folder organization conventions, go-to-definition shortcuts, and architectural design patterns needed to understand certain pieces of code.

To improve yourself, you are better off focusing on writing code, but at the organizational level, it's better for the team if people are willing to assume that reading code and writing readable code aren't an easy tasks.

Except that people are too lazy to use exceptions that are checked at compile time.

The main benefit of Go is that the people that defined the library ecosystem actually decided to handle errors. It's the bare minimum, but it's better than just forgetting that the error exists and not documenting it either.

The language is ... not the best, but the libraries tend to be more robust.

I think the larger problem is that everybody expects that they have to get better, and they have to get better quickly. That's why people injure themselves doing pretty much anything requiring physical exertion.

Recovery is important. Maybe it will be better if people see exercise as a secondary tool for improving their health/recovery rate, rather than the primary tool for becoming more powerful.

I've heard stuff before about the fact that conglomerates like Tencent make it hard for Chinese startups to get money. Is that true and potentially the larger factor?

Given that it's so easy to spend 3+ hours a day on internet entertainment, I find it logical that ad-driven social media is a productivity drain. However, are they simply addressing a symptom of why people get hooked to social media? What's stopping people from watching TV for 5+ hours a day like certain older, retired generations?

Is China doing anything so that it's worthwhile for students to learn practical skills rather than focus on getting into a college?

It's harder to get society to value college degrees less, but I don't see much changing unless there are many stable, low/medium-risk business opportunities available to those with degrees from lower-ranked schools.

It feels like they are just addressing a symptom, and not trying to tackle the larger issue...so I'm curious why they would do that

Do you mean that Chinese education must involve Western values? For example, is logical reasoning a Western value, and the Chinese government cannot exist if their citizens think logically? Maybe freedom is something that is universally desired by all humans, and the Chinese don't know that.

I'd actually guess that a ban on for-profit tutoring is a larger risk for the CCP. Students spending their time unsupervised could lead to more "unwanted though" than students spending their time memorizing and reasoning around well-vetted facts about how governments work or about the history of Confucianism.

It's sort of hard to compare these approaches, since it's not like Amazon and Apple only have 1 principle that they follow. I'll try to analyze them in a generic way. Disclaimer that I don't have experience in marketing or executive leadership.

Apple's focus on design allows it to charge higher for its products and to build new high-margin products that people end up buying. It allows them to "scale" revenue by entering new markets with new products.

Amazon has a similar focus on the customer which is centered around customer support. This approach also gives them the "brand reputation" to build new services (that businesses will pay for). You may note that Apple's approach works better for customers who pay without much planning/budgeting (like consumers/households), scales better with the number of customers (again like consumers/households), and scales more poorly with # of products (making it a worse fit for SaaS).

Amazon's API mandate value is felt in how it allows them to make software development more efficient. Customers do not feel the impact directly. Instead, since data is exposed through well-defined APIs, new service (or product) development can be done with far less human communication, as mentioned in the article. However, while this makes inter-team efficiency better, it reduces intra-team efficiency by forcing developers to build things that they don't need. If services are too small, the APIs are not high-quality, or the service boundaries change too frequently, then it's possible that this approach doesn't make software engineering more efficient at Amazon.

This is something I try to mention a lot, but mostly focused on the importance of onboarding.

Either, your company makes sure that almost everybody contributes above their salary, or you need to fire often without hurting your "culture".

I feel like this mindset is actually responsible for a lot of modern-day unhappiness. Why are 1st world countries somehow more lonely?

Something I've noticed while talking to my older relatives outside of the US is that their social life often are the people that they meet in their (first) job in the location they ended up staying in. It feels straightforward that the people that you spend 8+ hours a day with are going to be the people that you feel like you know and can trust.

It seems like some odd modern/corporate idea that work is just for work. Imagine if we had the same mindset for school, and tried to make things "productive" by eliminating all breaks and the assumption that students should get to know each other during class/free time.

I think we need to accept the idea that work is really going to be much of your social life when you move, work friends are not your best buds, and only later on can you have a social life that doesn't deeply involve people at work.

Yeah, what exactly makes the 36k US lives lost more important to focus on during Memorial Day?

The best arguments I can think of:

1. This memorial must be acknowledged or practiced by the Hackernews community, because it's _mostly_ US-based and English speaking. So by association by language, we are expected to talk about a United States federal holiday?

2. All human lives are equal, but there is a day and place for everything. On May 31, the world should practice the Unided States federal holiday. On May 18, well... May 18th is just a Korean holiday. Not everybody needs to be aware of it.

3. US citizens and other English speakers should observe US holidays because that's just the way the world works. Just like how you do more for the funeral of your family, you should discuss US federal holidays more than Korean holidays. Holiday practice is a like zero-sum game, as there isn't that much time to just think about holidays and there are too many holidays. Using the same logic, some people's lives are worth more to you because they affect your life more. Sometimes with this approach, we mess up and overvalue one race more than another...but that's just a side effect of "the way things work".

I can't see the logic. Saying that we should focus on Memorial Day sounds like a talking point that riles up emotions to me.

A recently completed starter task for the project you are working on usually is a good idea. However, you need to make sure that the task is truly a starter task, not just a task that doesn't require much code. It is easy to create a task that requires too much time to do.

As for simplification, I think it's a trap and not worth thinking about. The problem with LeetCode is that it's the result of oversimplifying. People focused too much on a "hard" part of software engineering, that, over the years, they filtered out all of the other skills that matter: making sure that the new functionality makes sense, figuring out how to make code testable, reading other people's code, already knowing existing protocols, making progress even if you don't know everything, knowing when the quality isn't good enough, and asking good questions.

I do not understand how you cannot easily "spin" a prototype that the company wants to sell into a good thing.

When you write that awesome prototype, your management will be thinking about rewarding you, not blaming you. They will listen to your concerns.

So, you can say that it's not ready. You can mention that you alone are not enough to fix the bugs that come up in greenfield code right away. You can even ask for people to help on your project. Why would management say no if they want to sell it?

Then when a manageable amount of bugs come down the road and everybody is happy, you are now in a far better position to negotiate a higher salary. You have far more responsibility. You have a great track record. Nobody wants you to leave.

The cost of developing a prototype when you handle every error you see along the way, set up all of those dev tools (tests, logs, CI, formatting, etc.), and test every branch like a madman is too high. You'll probably end up taking weeks to develop something that you could "code in a weekend". Then, since you never verified, it may turn out that nobody wants to use the prototype for obvious reasons

If you have a PBs of data that you rarely access, it seems to make sense to compress it first.

I've rarely seen any non-giants with PBs of data properly compressed. For example, small JSON files converted into larger, compressed parquet files will use 10-100x less space. I am not familiar with images but see no reason why encoding batches of similar images should make it hard to get similar or even better compression ratios

Also, if you decide to move off later on, your transfer costs will also be cheaper if you can move it off in a compressed form first.

The term "batch job" (as opposed to "service") appears frequently in the Google K8s-like scheduler papers:

https://research.google/pubs/pub41684/ https://research.google/pubs/pub43438/

In other words, jobs seem like the go-to way to take advantage of unused CPU/memory.

What happened to the "average programmer" over time? They seem to be building things that make more money now. Isn't that the main reason companies pay for software engineers?

I believe the "decline" is due to the fact that being a software engineer nowadays is more like being a sysadmin or DBA than a programmer of the past. You spend 80% of your time using frameworks and systems that you don't fully understand (or even understand a bit).

Yeah, like the other reply, I'd mostly say testing DAGs was an issue. Airflow-related configuration is easy to get wrong and it silently fails a lot.

Now that I think about it though, most of the time I spent on testing wasn't caused by Airflow. Testing data pipelines just isn't easy with the current well-known tooling.

Nothing is more popular yet, but there are better architected options out there. It's hit 17k GitHub stars and was used by the team I was previously at. I don't think anything will beat it unless something from the CI/CD or "cloud native" world moves in unexpectedly.

The operators and scalability are somewhat useful. I was happy with the UI compared to cron. Testing is a mess. Also, Airflow isn't CI/CD-friendly (but it's possible to get it to work).

I'd recommend a managed option unless you have a skilled ops team. It reminds me of Hadoop in terms of how exciting it is to get set up, which isn't a good thing.

But we don't value things solely based on their natural resource composition; we pay far more for "labor" and other intangibles.

As a result of the above, the value of a natural resource changes over time. For example, natural resources used in electronics and batteries are relatively more expensive now than they were 100 years ago.

So, you can be technically correct by saying that wealth is zero-sum, but that's pretty much the same thing as saying "the world's 'wealth' traded for natural resources sums up to 100% of all natural resources"

I don't know if this means something is truly wrong. AI is a mix of engineering and scientific research, just like most CS subfields. Recently, the emphasis has shifted towards engineering, as the applications of neural nets have skyrocketed after a few breakthroughs in performance.

It's similar to computer systems research. For example, a research paper on filesystems might tell us a simple trick which leads to better performance on NVMM. The paper may go into why the trick works, but it doesn't (and shouldn't need to) generalize and try to improve our general understanding of how to design filesystems on different hardware. We've been designing filesystems to this day and well, we are always still guessing about which approaches to use and hoping for the best. In the same vein, we don't even have a widely-accepted theory of how to use data structures yet.

So, I don't think that neural nets aren't scientific enough means that it's all BS. We have gaps in understanding, but the power of the models warrants a lot of continued work on finding useful applications.

Doesn't mean I don't think AI is over-hyped/overfunded though...

Nightly to seconds = developers can see the data generated within seconds.

This generally has implications on data quality, because you aren't fixing data quality issues once they occur in prod.

This also makes it far easier to develop ETL pipelines. You don't need complex tooling to see whether your ETL pipeline works.

You can technically fix data quality and dev velocity issues without low data freshness, but a quick glance at the data engineering landscape tells you they aren't being solved enough.

It's ok to not forcefully grow your income, but stagnating income is correlated with your skillset becoming outdated. If you haven't worked on your network or your interview skills, you can find it hard to find a new job. In addition, a less career-oriented person would find working on those less enjoyable than keeping their skills up to date and likely do them even less.

The reality is that software engineering automates software engineering jobs the most. As a result, people in this industry do highlight the importance of not neglecting your skillset.

However, I wouldn't take that as them trying to maximize their revenue. They've simply found that they need to do a deeper analysis on skills to not get automated out of a job.

This is downvoted but I found it interesting that the English word "slave" is derived from Slav.

From the Wiki article [0]: "In medieval wars many Slavs were captured and enslaved, which led to the word slav becoming synonym to "enslaved person

https://en.wikipedia.org/wiki/Slavs_(ethnonym)

For the same reasons people argue against abusing terminology like "retard" or "gay", you could argue that using the word "slave" affects people's perception of Eastern Europeans.

Did you misread? The author wants readable code and accepts "style" differences.

I've seen a lot of engineers that rely on their intuition and end up just creating shit that works and is surprisingly maintainable. I've also seen a lot of different ideas on what a "clear and sound thought process" is.

In fact, someone who is clear and sound in writing might get bogged down when writing code. Good writers are (obviously) not necessarily good coders.

I do think there is potential around the design doc. Design is a big part of a lot of roles. In addition, in a lot of these roles, having the "best" design isn't better than having a design that the rest of the team can understand. Still, I wouldn't do it for the purpose of identifying good "thinking". I would do it because I expect the people I hire to be good (or have potential) at what they will be expected to do.