AI is just a productivity tool. Productivity tools don't kill jobs; they alter the corporate landscape, changing which jobs exist. The jobs that disappear due to higher productivity get replaced by other jobs that take advantage of higher productivity. This has been observably true through centuries of technological improvements, but there are always ignorant people irrationally afraid of technology destroying employment.

No matter how advanced technology becomes, there will always be work to do. It might be different from past jobs, but the work will exist. I'd advise the historically ignorant Gen Z employee to just learn new skills if AI technology makes her old skills obsolete (which won't necessarily happen in the 3 years she predicts because the most technology forecasts are wrong).

The original purpose of a code review was to fix issues that make future development on the same code more difficult than it needs to be. It's not a QA session to find bugs (so saying that the code works fine is an irrelevant defense). His colleagues are perfectly justified for complaining about style, and he should fix those issues. If there are debates on proper style, then an official style guide needs to be put together to resolve the debates.

Next, you could run web sites and console apps as services using systemd. Some of us are being paid to do that :)

Amazon advertised their job openings extensively, so their high applicant rate is expected. Many of us here probably receive unsolicited job emails from Amazon.

If you're not completely against spending money, the Jetbrains Rider IDE runs great on Ubuntu.

The author briefly touched a large topic: Excessive shorthand. Excessive shorthand is: - Well-known in one subculture (such as C-style language devs) - Initially confusing to outsiders - Problematic for far-off future devs who don't know past languages and frameworks A better example: Lots of C# shorthand in one statement:

public long MyDistance { get; set; } = 0L;

Long-time C# devs know instantly what it means. It looks like garbage to outsiders.

Trump does strange, unexpected things during negotiations, which somehow lets him get his way in the end. I predict that, in the next few months, the U.S. will gain control of Greenland's natural resources and block other superpowers from doing the same. You can call it pathetic, but it seems to always work.

The experts in functional programming run each over with messes just like the novices do. It boils down to functional programming giving people more power than they are likely to handle well.

The first developer writes code. The second developer updates the code, despite slightly misunderstanding the first developer's code, making the resulting code confusing and prone to bugs. The third developer updates the code, while slightly misunderstanding the first developer's code, the second developer's code, and the second developer's misunderstanding of the first developer's code, making the resulting code more confusing and bug-prone. The fourth developer updates the code, seriously misunderstanding the first developer's code, the second developer's code, the third developer's code, the second developer's misunderstanding of the first developer's code, the third developer's misunderstanding of the first developer's code, the third developer's misunderstanding of the second developer's code, and the third developer's misunderstanding of the second developer's misunderstanding of the first developer's code. Etc. until maintenance is impossible, bugs never get fixed, and rewrites are demanded. This problem isn't unique to functional programming, but using a functional style amplifies the compounding negative effects (which is why start-ups have success stories of using functional languages and large organizations don't). When using more procedural styles, the negative side effects of not fully understanding the code being updated are lower. You can read about project successes and failures with LISP; they don't specifically mention the effect I described, but they seem to have experienced it nonetheless. http://www.paulgraham.com/avg.html https://www.quora.com/Does-Yahoo-Stores-previously-Viaweb-still-use-Lisp https://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=31402

The worst thing about functional programming is its poor resilience to non-ideal development situations. When large organizations maintain code over long periods of time, non-ideal practices constantly leak in. Hurried developers updating confusing code may be bad for object-oriented code bases but is horrible-to-fatal for functional-style code.

Functional programming: 1. Is older than object-oriented programming 2. Is well-known and well-practiced in academic settings, where people first learn programming 3. Has been constantly pushed for the past four decades to become mainstream for enterprise development 4. Has official support in both the Java and .NET ecosystems 5. Still only manages to be used as a side technology for special cases Horse-and-car = Wrong analogy.

The idea that white nationalism is becoming a serious problem in the USA when white nationalists are nearly impossible to find is an extraordinary claim that requires extraordinary evidence. Since the evidence is thin-to-none, there's nothing to discuss, other than why political hacks are trying to make a non-issue into an issue.

The sources factcheck.org uses have financial incentives to exaggerate bigotry problems. Admitting a crisis is over is like telling their donors to stop donating. Today, 99.99% of complaints about white nationalism are overblown red herrings not worth noticing.

Majerus wrote:

a time of growing racist white nationalism

White nationalism / white supremacy is at an all-time low (most Americans today have never even met a white supremacist). The idea that it's growing is a political myth meant to slander people with legitimate concerns.

By "unit tests" you probably mean "unit tests, according to test-driven-development standards" (or a TDD variant). Problems with this idea: 1. You can't learn TDD by code snippets and basic intuition; you learn its theory by organized study, and then do lots of exercises to solidify the knowledge. 2. The vast majority of unit tests written in the industry are by people who don't understand TDD basics. The answers with unit tests will be written (and upvoted) by people who don't understand TDD, accomplishing nothing for beginners hoping to gain useful knowledge. 3. TDD is not as widespread or useful to the industry as it appears. People pay lip service to how wonderful it is, clutter their code with useless unit tests not written according to any real standard, and then proceed to ignore all those useless unit tests 99% of the time (except for the 1% of the time where they talk about how wonderful and useful the unit tests are).

The entire issue sounds like dirty politics against Apple; consumers don't file anti-trust lawsuits to make 99-cent apps cheaper. I'm wondering what the lawsuit's real purpose is.

The odds of a highly experienced employee deliberately sabotaging the business in revenge for being terminated are so low that doing nothing to prepare for it is actually reasonable. The company either had exceptionally bad luck or was exceptionally skilled at infuriating people enough to insure mutual destruction. Having no backups of customer data, on the other hand, is reckless and likely to lead to disaster in a number of more common scenarios.

The MySQL team has had a lot more time to idiot-proof their default installations and beginner guides, while the MongoDB team is still focusing on other things first. Read the following article for its side notes (which reveal insights into MongoDB's development): https://www.defmacro.org/2017/01/18/why-rethinkdb-failed.html In any case, (whether you like it or not) a few security disasters won't slow down MongoDB adoption, but slowing down development to handle random things (such as idiot-proofing the product) can have large negative impacts on adoption rates.

MongoDB is the most popular NoSQL technology, and it's marketed to beginners and amateurs more than other NoSQL technologies are. If an inexperienced developer botches security, they probably do it with technology that's common among inexperienced developers.