The reason it is top-rated is because it sounds extremely reasonable. This is enough for most people.

I am not judging on whether the comment is correct or not, just answering why it is top-rated. I find nothing weird about it.

That would have been astronomically expensive given the enormous supply chain needed to produce charcoal to get that iron in those times.

I am sceptical on how they figured out iron stains are pothole fillings. I think much simpler explanation would be everyday items or metal pieces of carts getting stuck between stones.

I am tech lead and architect for large financial systems written in Java but have done a bunch of Common Lisp and Clojure projects in the past. I will still avoid any recursion and as people to remove recursion from their PRs unless it is absolutely best way to get readable and verifiable code.

As a developer your job is not to look for intellectual rewards when writing code and your job is not to find elegant solutions to problems (although frequently elegant solutions are the best ones). Your job is taking responsibility for the reliability, performance and future maintenance of whatever you create.

In my experience there is nothing worse than having bright engineers on a project who don't understand they are creating for other less bright engineers who will be working with it after the bright engineer gets bored with the project and moves on to another green field, rewarding task.

Most programmers learn about loops pretty much at the absolute start of their development experience, where they don't yet have a way to talk about recursion. Don't even start about tail recursion or tail recursion optimisation.

For example, one application of this was a long migration project where a large collection of files (some petabytes of data) was to be migrated from an on-prem NAS to cloud filesystem. The files on NAS were managed with additional asset management solution which stored metadata in a PostgreSQL (actual filenames, etc.)

The application I wrote was composed of a series of small tools. One tool would contact all of the sources of information and create a file with a series of commands (copy file from location A to location B, create a folder, set metadata on a file, etc.)

Other tools could take that large file and run operations on it. Split it into smaller pieces, prioritise specific folders, filter out modified files by date, calculate fingerprints from actual file data for deduplication, etc. These tools would just operate on this common file format without actually doing any operations on files.

And finally tool that could be instantiated somewhere and execute a plan.

I designed it all this way as it was much more resilient process. I could have many different processes running at the same times and I had a common format (a file with a collection of directives) as a way to communicate between all these different tools.

For the most part, I can see old books on bookshelves are still unedited. But maybe some other books have been completely destroyed due to not being acceptable to future readers/powers?

But I really hate it. I dislike when people do not understand that moral and social norms change over time and you can't blindly apply your current views to historical people who were brought up and lived in a different world.

I am pretty sure people in some distant future will think about us as heathens for eating meat, driving cars and wearing plastic. I hope they will be wise enough not to cancel us complete for this and hear out other wisdom we might want to pass.

Otherwise, you would have to contend with the fact that "real time" does not exist at all, as information about any event has to necessarily take time to travel to reach you.

So no "real time" coverage of anything -- the information always takes time to travel the distance.

What is not a correct understanding of how time works is claiming that it happened some thousands of years ago. No, from our reference frame it happened now. It is meaningless to say that it happened thousands of years ago because it happened thousands of years ago in some other, arbitrary reference frame.

Look at the changes that happened in the past and ask yourself:

* which people have been successful regardless of changes that happened?

I think almost independently of whatever you do in life, if you are absolutely best at what you do, you are probably going to be fine. Even if what you do is house cleaning, if you are best at houscleaning you are going to be fine. There is always going to be a millionaire or a billionaire who will prefer to have a human sweep the floor rather than a roomba. Or maybe a lab will prefer to have humans to do the work just to not invite potentially dangerous electronics on the site.

There is always demand for top level talent in any area. There will always be demand for human reporters, human drivers, human writers, human programmers, human graphics designers, human managers, regardless of the changes that will happen.

But it is possible that the demand will only be for top of the top of the top of people in each those areas and 99.9% or even more will be replaced and automated.

Another thing that can help is rare specialisation that is not worth automating.

One of the easier ways to find those rare specialisation is at a cross of two largely orthogonal areas of study. I like to think a lot of useful things happen through people who connect different, sometimes distant areas of knowledge / ability.

Another thing that helps people survive change is being a free agent. Don't be an employee -- be an enterpreneur with a mindset to learn and ability to pivot on a moment to moment basis. Learn a lot about life and universe, economics, trends, etc. Learn basis of how enterpreneurship works, how to find new areas that can provide value to people.

---

So if you are a developer, you have some choices:

* become best damn developer while you still can. Spend considerable time honestly learning your craft. Just completing projects is no longer enough to be safe, but outstanding developers who can complete projects will always be needed.

* learn deeply something else that can be connected with development. I know finances and it seems there will always be a need for people who know well development as well as finances.

* you could learn management/leadership skills. The trouble is, there is plenty of technical managers/leaders, just becoming one will not guarantee job safety. You will have to work hard to keep being strong technically while you are also trying to become very competent manager/leader.

* build on your development skills to become an enterpreneur. This is probably the hardest / riskiest path.

Other choices? Please, let me know... I am myself interested in this whole topic.

It means any developer merges their work very, very rarely (20 days = 4 weeks on average...) and that in my experience means either low productivity (they just produce little) or huge PRs that have lots of conflicts and are PITA to review.

My hypothesis is that in most projects, the problems with monoliths are smaller, better understood and easier to address than the problems with microservices.

There are truly valid cases for microservices. The reality is, however, that most projects are not large enough to qualify to benefit from microservices. They are only large projects because they made a bunch of stupid performance and efficiency mistakes and now they need all this hardware to be able to provide services.

As to your statement that deploying monoliths takes time... that's not really that big of a problem. See, most projects can be engineered to build and deploy quickly. It takes truly large amount of code to make that real challenge.

And you still can use devops tools and best practices to manage monolithic applicaitons and deploy them quickly. The only thing that gets large is the compilation process itself and the size of the binary that is being transferred.

But in my experience it is not out of ordinary for a small microservice functionality that has just couple lines of code to produce image that take gigabytes in space and takes minutes to compile and deliver, so I think the argument is pretty moot.

- on the service provider, the implementation provides the actual functionality,

- on the client, the implementation of the interface is just a stub connecting to the actual service provider.

Thus you can sort of provide separation of services as an implementation detail.

However in practice very few projects elect to do this.

The MAIN reason for microservices was that you could have multiple teams work on their services independently from each other. Because coordinating work of multiple teams on a single huge monolithic application is a very complex problem and has a lot of overhead.

But, in many companies the development of microservices/agile teams is actually synchronised between multiple teams. They would typically have common release schedule, want to deliver larger features across multitude of services all at the same time, etc.

Effectively making the task way more complex than it would be with a monolithic application

In pretty much all projects I worked with in recent years, people chop up the functionality into small separate services and have the events be serialised, sent over the network and deserialised on the other side.

This typically causes enormous waste of efficiency and consequently causes applications to be much more complex than they need to be.

I have many times worked with apps which occupied huge server farms when in reality the business logic would be fine to run on a single node if just structured correctly.

Add to that the amount of technology developers need to learn when they join the project or the amount of complexity they have to grasp to be able to be productive. Or the overhead of introducing a change to a complex project.

And the funniest of all, people spending significant portion of the project resources trying to improve the performance of a collection of slow nanoservices without ever realising that the main culprit is that the event processing spends 99.9% of the time being serialised, deserialised, in various buffers or somewhere in transit which could be easily avoided if the communication was a simple function call.

Now, I am not saying microservices is a useless pattern. But it is so abused that it might just as well be. I think most projects would be happier if the people simply never heard about the concept of microservices and instead spent some time trying to figure how to build a correctly modularised monolithic application first, before they needed to find something more complex.

For the same reason I, and a lot of other people, chose to not have sweets and snacks at home. Because we like them and if they were available, we would eat them. We know that this is really bad for health and we also know that we have limited willpower to prevent ourselves from reaching for them. So we elect to help make better decision by just not having them around all the time.

I still eat sweets. I just prefer this to be once a week in a form of a good dessert at a good restaurant, right after a good meal.

And if I need a snack I make sure to have plenty of alternative, healthy options available at all times -- mostly fresh fruit and veggies.

Good luck with that.

The story of the red tape is that every time somebody does something stupid or malicious, there is some red tape added so that future investors face less trading risk.

Risk == cost

So less red tape needs to be translated to investors facing potentially higher risk on their transactions of various stupid or malicious shit others can pull on them.

Corporations are nothing else than collections of directors and managers who have their own preferences which definitely influence their decision making.

More and more companies allow using MacOS. Small companies allow MacOS and then grow into large companies that still allow MacOS.

It is taking time, but don't underestimate the power of power users.

Except I paid for my Windows license.