onetimeuse92304

Weird that this is the top-rated comment,

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.

Call me sceptical.

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.

Or the person is sensibly trying to make the code easier for other people to understand.

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.

How is this unfortunate?

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.

Used something very similar many times in my past without knowing it is formalised as a pattern.

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.

It is hard to me to understand how much this revisionist tendency is just a recent invention and to what extent it has been present throughout the history.

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.

It is not hilarious, it is actually the correct use of the term.

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.

There is no single solution this problem.

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.

50 PRs with a thousand developers is definitely not healthy situation.

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.

Yes. There are costs to having monoliths. There are also costs to having microservices.

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.

Well, technically, you can construct the microservices preserving type safety. You can have an interface with two implementations

- 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.

Oh, it is even worse.

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

Not specifically about event-driven, but the most damaging anti-pattern I would say is microservices.

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.

Why on earth would anyone buy one?

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.

with less red tape than NYSE or Nasdaq

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.

What should and what does happen at large companies are completely different things. I worked for a lot of large companies and I can tell you things like this happen every day, usually not out of malice. Corporate behaviour at all scales is not necessarily governed by logic.

It is the professionals, power users who in the end shift markets.

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.

I can see how this can happen at a large corporation. The way companies operate, they usually order somebody (most likely a contractor) to create media. Then pass these to another team that creates website, press materials, etc. A picture is a picture is a picture, and information about which camera took it is probably not passed.

Yeah... we kind of already have billions of machines efficiently spreading it all over the globe.

You cannot compete with the best for free

Except I paid for my Windows license.

I have decided a long time ago that Windows is no longer an operating system to do work o. I have one that is relegated to being a game console and its days are numbered, too.

There is only so much BS I can take. Microsoft is driving off professionals with their sheer ineptitude at product development.

It does requires realistic collisions.

The point is you fly in a small spaceship in an arena, you hide behind obstacles, you shoot with a small variety of weapons and you use your weapons to either shoot the enemy directly or rearrange the map to make life difficult for your them. The collisions need to be realistic because you need to be able to predict what is going to happen when you hit things a certain way.

It is just a concept we are playing with.

Another part of that concept is that this game is meant for small kids that can't read. There is not a single letter or digit in the entire game. No menu. You just start the controller and get immediately pulled into the game.

And another feature is we wanted the game fun because the control feel fun and immediate. So we are experimenting a lot with what it means for the controls to be enjoyable.

Yeah, I am also suspicious about people with radical opinions. Truth is USUALLY somewhere not at the end of scale.

BUT, have you noticed yours is also a radical opinion?

The reality is that sometimes, a radical opinion is actually a correct one.

Which is to say heuristics are useful but they still do not replace critical thinking.

The problem with Microservices is actually that IMO most developers simply have no time, willingness, experience or mental capacity to think critically about all that stuff. People frequently need to make decisions efficiently. The theory of efficient decisionmaking I have is that frequently enough it is more important to make a decision than to make a perfect decision.

And it kind of makes sense because I also suspect majority of the population (and that includes developers) are simply unable to think critically or retrospect about their own performance.

And what you do when you have little experience in the field and can't yet think critically about things? You use training wheels.

In case of IT (and business in general), a powerful training wheel is imitation.

So what happens is that somebody at some company will publish a paper about how they solved a problem and suddenly a bunch of people will try to jump on that bandwagon ("you can't go wrong if they succeeded with it") but without the hassle of having to actually think through it, understand what were the circumstances at that other company, how those circumstances are different from own use case, etc. They will imitate what others have done before but without realising a lot of important things about the problem. Which is how we got to this whole microservices mess.

Anyway, I am personally rolling back microservices implementations pretty much every project I join. People do not realise how much time they spend solving problems that are simply due to the fact they have partitioned large application into hundreds of small services which need to each be maintained separately. We have dedicated teams to do stuff that is simply unnecessary (they usually call them "devops", but really they are just ops because more frequently than not they are not actively developing the functionality). All the performance problems, all that inefficiency usually vanishes when you roll all that functionality into a single application and just scale that one application instance over multiple servers.

My current team is even more funny. The microservices were originally meant to allow teams to work independently, but at my current team they work hard to bind all of the development process into a single stream of work. So there is some 80 people in 10 different teams all working on same set of environments, applications, with the same monthly release process, coordinating their work everywhere. But there is about 1 service maintained for each developer which means people spend half the time dealing with complex configuration. And the other half of the time figuring out how to improve performance of an application which copies all of its data from service to service.

One side project I am working on right now is a 2d space shooter I am developing with my son. The idea is to have top down look, have each player control some kind of ship and fly in an enclosed area filled with space debris and shot opponents. An important aspect of this game is that the space debris can be moved around the arena and used creatively to capture opponents, prevent them from achieving their goals, etc.

As part of the project I was thinking we will skip game engine altogether because I wanted to teach my son a bit more about how to structure the application, etc. I thought in future we would use a ready game engine but at least once we would go through the exercise of implementing everything.

Everything was fine until we approached the problem of collision detection and handling. That's when things went downhill pretty quickly. Even with my theoretical math background I was soon consumed with just enormous amount of corner cases and finally decided to relent and use Box2d for this.

I am not a professional game developer, but I have over 20 years of development experience + math background and I still made the mistake of underestimating the problem. It really seems easy problem when you state it and just becomes exponentially more and more complex as you start digging into details.

Actually, for the past two years I was using the coding task I got to do when I joined the company. This helps me appreciate how I felt when I have seen it for the first time.

You are right on point.

As an amateur EE it is so annoying that they reuse names of already existing ARM chips.

ARM Cortex-M4 or simply M4 is quite popular ARM architecture. I am using M0, M3 and M4 chips from ST on a daily basis.

Honestly, as somebody who is hiring senior devs I can't imagine not doing a coding interview.

Unfortunately, it is very hard to judge somebody's coding ability in discussion alone. You can sort of get the idea whether they have or don't have experience and whether they have luck being asked about topics they know (although you can help your luck just knowing a lot of stuff).

I have seen a lot of candidates who were quite smooth talkers but could not code their way out of a paper bag. Mind I do not mean remembering some complex algorithm. The task is usually some relatively simple data manipulation so that I can see the person approaching the problem, asking questions, getting involved in some discussion, etc.

The task is usually ambiguous a bit and this is explicitly stated so that the candidate is actually expected to get stuck, don't know things and have to talk to me to get the problem solved. You would be surprised how many candidates do not listen or can't follow simple advice even when I am almost giving them the solution on a platter.

The trouble is there is a lot of interviewers and many interviewers do not have a basic plan of what they want to achieve with the coding interview. What they want to learn about the candidates. Those interviews tend to suck.

What also sucks is candidates who come to the interview completely unprepared, unable to answer most of the questions or get any progress on the programming tasks and then spew misinformation on the Internet about how supposedly all coding interviews are stupid.

I guess if you can code you may have some misses, usually along with some hits. Sometimes you are out of luck. The point is not that you need to get every job that you apply to, it is enough to get one of them.

But if you can't code at all or you apply to positions that are clearly out of your league, you get rejected on all these interviews. And then what you do? Some people go to write on the Internet how all interviews are stupid without ever considering how they contributed to all those failed interviews, how real life works (ie. 90% of everything is crap including 90% of interviews) and how the situation might look from the other side.

As an amateur sailor, the idea that they discussed wearing lifejackets INSIDE the craft seems completely stupid. One of first things any sailor learns is that you do not wear lifejackets inside the craft.

It is not possible to swim through submerged openings (windows, doors) in a lifejackets as it is simply pulling you up and preventing you from diving down.

A lifejacket is also very bulky and offers a lot of opportunity for snagging on equipment.

If they had lifejackets on, probably nobody would save themselves unless they were able to untie themselves in time.

Just imagine the hell of trying to free yourself from the snagged seat belt WHILE in a life jacket that constricts all your movements and makes reaching your legs very difficult and pulls you constantly up putting continuous force on whatever snagged on your feet.

I am pretty interested in weight loss (but I am not a professional), I will try to explain.

First, the stance of medical profession is to treat diseases. There is not much effort on preventing diseases. They will wait until you get sick and then when you pass a magic threshold will assault you with a battery of treatments. We know that diabetes takes decades to develop, yet our description of a person who is halfway to developing diabetes is still "healthy". You need to wait until your body gets so devastated by your bad diet and habits that it gets completely disregulated and you put on a lot of fat before suddenly being considered a subject for treatment.

Second, the dissemination of knowledge in medical profession is glacially slow. Even if the research progresses quite fast, it takes a generation of medical professionals to die out and newly trained people to replace them to actually update the knowledge as it is being practiced. We are still in the "fat is bad" times even though we know and have known for a long time that it is actually carbs, processed food and bad fats that are major contributing factors to the obesity epidemic (that plus sedentary lifestyle, stress and bad sleep).

Third, people in the medical profession are heavily penalised for having a different view on things to the point that most are scared to speak up. For the most part, practicing anything that is not in line with mainline view will get you expelled from the profession and barred from practicing medicine ever again.

Fourth, the dieting, while sounding nice as a solution, does not tend to work well. Most people are unable to stick to a diet long term. Managing early diabetes with a diet would require sticking to it religiously and permanently. Medical professionals are not stupid and know that that's something that very few people can actually do.