So you clicked on this post because you thought that:

  • I was smart enough to know how to be better than anybody else
  • I could summarize all the ways to become so
  • I would generously share them with you
  • You would understand what I am telling you in 3 minutes or whatever your attention span is now

While I appreciate the sentiment, no, I am not that smart, nor am I that stupid. There are no shortcuts. Just start thinking for yourself and explore the world with care and terror and hope, like the rest of us. And most of all, stop clicking on "N ways to..." links.

The Nazi officer smirks, as the prisoner begs for his life. Instead of any human feelings, he just revels in the pain he inflicts. He is powerful, merciless, and stupid enough to be foiled by the heroes who, against their better interest, came to liberate the helpless victims of this evil butcher. Change the channel! The heartless businessman pushes for more sales of the opioid drug his company produces, destroying the lives of honest, hard working Americans living in flyover country. Change it again! The evil general commands the destruction of a helpless village, laughing maniacally while the future hero of the story vows revenge in Japanese.

You've heard it before, you've seen it before and you've read it before. The mindless, unreasonably evil character who has two purposes only: to be totally unlikeable, an example of what not to be, and to be defeated by the hero, an example of what you should be. But it's not enough! The hero must be a "normal" person, someone you can relate with: powerless, bound by social contracts, connected with people in their community, wanting nothing more than to live their life in peace. But no! This evil asshole is just determined to stand in the way for absolutely no other reason than gaining ultimate power, more than they, or anyone else, deserve. And the hero needs to overcome impossible odds just to have the opportunity to defeat, in an honorable way, the villain. In the end, they will prevail thanks to a combination of friendly help, evolving to a higher level of power (which was always inside them) and sheer dumb luck.

Now, the Dunning Kruger folk will just lap this story up, imagining themselves the hero, but realistic people will just think "wait a minute! If this guy who is well connected in his community, strong as an ox and looking like The Rock, after focused training that he immediately picks up finding magical and physical powers that are beyond reason, has almost no chance of defeating the villain and only gets there through luck, then what the hell chance does a normal human being have?". And a few broken people would ask themselves if the villain wasn't a bit right, wanting to destroy this pathetic place we called "the world".

Where did these stories come from? Why are we suffocated by them and still consuming them like addicts? What is the result of all that?

The psychopathic villain trope is just a version of the old fashioned fairy tale: the knight and the dragon, the peasant and the lord, the girl and the lecherous wizard, the light and the dark. It is the way we explain to little children, who have no frame of reference, that there are ways we prefer them to be and others than we do not. It's a condescending format, design to teach simple concept to little idiots, because they don't know better. Further on, as the child grows up, they should learn that there are nuances, that no one is truly evil or good, that all of us believe we are the protagonist, but we are just a part of a larger network of people. This we call "real life" and the black and white comic book story we call "fantasy", designed to alleviate our anguish.

Yet we stick to the fantasy, and we avoid reality. And it's easy! In fact, it's much easier than any other strategy: close your mind, split your understanding into just two parts, one where you feel comfortable and the other which must be destroyed in the name of all that is holy. To even consider the point of view of the other side if blasphemy and treason. In fact, there is no other side. There is your side and then there is evil, darkness, void, unknown. Which conveniently makes you the good guy who doesn't need to know anything about the other side.

OK, maybe you can't win every battle. Maybe you will never win any battle. But you are a warrior at heart! You don't actually have to do anything. And as you wait for the inevitable defeat of evil at your righteous hand, you can watch other heroes like yourself defeat evil, stupid, one sided villains. And it feels good. And it has been feeling good for as long as stories existed, then books, then plays, then movies and now video games. Yet never have we been bombarded, from every conceivable angle, with so many versions of the same thing.

If hero escapism was a pill that made life more bearable, now it's most of our lives: films, series, games, news. We were raised on them and we are being tamed by them every single day. They are so ubiquitous that if they are gone, we miss them. It's an addiction as toxic as any other. We can't live without it and we pay as much as necessary to get our hit. And this has been happening for at least two generations.

So when we are complaining that today's dumb entitled teenage fuck generation is incapable of understanding nuance, of moderation, of rational thought, of controlling their emotions, of paying attention for more than five minutes to anything, of dialogue, of empathy... it's not their fault. We raised them like this. We educated them in the belief that they are owed things without any effort, that their feelings are valid and good and that it's OK to consider everybody else evil as long as they are different enough. That we must be inclusive with any culture, as long as it is also inclusive, otherwise exclude the shit out of it.

The trope of the psychopathic villain did not teach these people to be heroes, it taught them to be the foil to the people too different from them. And here we are. Psychopaths on all sides, thinking they are good and righteous and that sooner or later ultimate power will be theirs. The only positive thing in all this: they believe the power is inside them and will reveal itself when most needed, without any effort or training. That's what makes them dumb psychotic evil villains, completely unreasonable and easy to defeat.

If only there were any smart heroes left.

  Can we use the scientific method as a guide for life? Let's find out!

  In these times science is either misunderstood or maligned (more often both), but what do you think science actually is? The "simple" Wikipedia definition is "a systematic enterprise that builds and organizes knowledge in the form of testable explanations and predictions about the universe", which is a criminally roundabout way of saying it's the result of the scientific method, the one that you see in the picture there. No matter how little you know or how stupid you think you are, the scientific method is a way of acquiring knowledge and then building upon that knowledge. It has nothing to do with nomenclatures, hard mathematics, quantum mechanics or complex lab equipment. Those are results of science, not components. One may build upon them, but might as well decide they want to go another direction.

  Why am I writing this? Because I am not a scientist, but I feel inspired by the scientific method. It provides a sure algorithmic way of improving... well, anything! All you have to do is repeatedly follow four simple steps:

  • Observe
  • Predict
  • Test
  • Analyze

 And while discussing this with anyone is something I enjoy, this post is not about the entire process, but just about the first step: Observation. I strongly believe that what is missing most from our collective lives is observing the world around us. I was reading something about a plant today and I realize that I have no idea what the plants I see are called, what they are useful for, and furthermore I rarely pay any attention to them in the rare cases I do go out and find some. My wife is different. Her life is based on observation and, while I don't always agree with her conclusions, I begrudgingly have you admit that I mostly analyze her observations rather than make my own.

Imagine you are in a biology class in school, let's say primary school and they have to learn botany. Are you seeing it, in your mind's eye? Where are the students? How does the teacher enter the class? What does he do? What do the pupils do then? What tools are they using?

Now tell me, where did you imagine this class taking place? Because when I did it, I imagined a room at the first floor inside a concrete building. The teacher enters the room and writes something on the blackboard and the children open some textbook. Perhaps it's a whiteboard and children have tablets, because it's the future and I am fucking old. But where are the plants under study? If we are lucky, there are some in the window behind the teacher's desk, because they have a small, but higher chance of surviving there than anywhere else in the classroom. If the school has a high enough budget one can imagine an occasional field trip with the kids, using a bus to go to a botanic garden and walk around for a bit. An artificial and abstract representation of something that is never observed.

How can one study anything without observing it? In an average class what pupils are observing are the opinions of other people, translated into text and pictures in books. They move from subject to subject, always basing their learning on what someone else saw and abstracted away. They are taught, in a consistent and constant way, to base their thinking on what people in authority have chewed and regurgitated for them. It doesn't matter if those people are right or wrong, that's not the argument I am making, it's about what we are actually learning, in schools and then later in everything we do. It only takes one moment of disconnect, of betrayal of trust, for the foundation of entire lives to be shattered, because if you suddenly learn you may not get the right information from the people you thought of as experts and authority figures, then your entire life experience so far may be a lie.

Most people dislike and distrust science because it is presented in an abstract manner, removed from day to day experience. But that's not science! Science is based on *your* experience. The very word means knowledge. And while you are bombarded with information every minute of every day, that's not knowledge unless it fits in your chain of experiences.

Now tell me another thing: what do you want to improve? Your life, probably. How do you define it, what are its components, how do you measure its quality? In the end (or is it the start), how well are you observing your life? How do you observe yourself, the people around you, the world in which you live?

Let's start there, with defining ourselves and our place in the world, let's observe the immediate reality of our existence. We'll wing it from there. It won't be science until we make testable predictions, actually test them and then adapt to what the analysis tells us, but it's a start. The alternative is to try to fix something without understanding how it works. Or worse, waiting for someone else to do it for us and hoping they understand it better than we. We will end up hitting something repeatedly, expecting it to start working as we want.

I was reading an article a few days suggesting that he have evolved to hold opinions that make us "win" not that are necessarily true, that those opinions are there to define our belonging to a social group and not to inform our actions according to reality. The scientific method appears to do away with emotions and instinct, thus feel unnatural, but in the things we choose observe we find ourselves, in the predictions we make we put our hopes and in the effort to test and improve our understanding we enforce our will.

Do you feel lacking control over things? Are you angry and frustrated? You might not have much power, but *this* you can do no matter who you are, where you are and who stands with or against you. Science: see, think, try, choose.

Intro

Four years ago I was writing about being on social media for a year, as a follow up for another post about being on social media for four months. I do promise not to make this into a series. Probably it will be the last post on the subject anyway. Hopefully.

So five years ago I was saying: "I had high hopes that once I connect with all my friends I would share of their interesting experiences and projects, we would communicate and collaborate better, we would organize more parties or gettogethers, meet up more frequently if we are in the same area. Be interesting, passionate; you know... social. Instead I got cute animal videos, big pointless images with texts plastered all over them". That has not changed at all. My hopes waned, but never completely vanished, as I was trying and tweaking various methods of controlling content, but the quality of things has never actually improved. My desire to share in the actual life important events of others is still there, only it's clear I won't get that from social media. Long story short, I intend to stop reading social media, instead trying to find an effective method of getting the connection I need.

Facebook

I have to admit I've had some success in "taming" the platform to provide some interesting content. I've unfollowed every source that didn't give me relevant information, I've followed science, technology and medicine accounts, I've actively used the "Hide posts like this" option until my "wall" became less annoying. I even tried "Liking" stuff that I wanted more of, although that actually seemed to be the least consequential action I was making (maybe because of the algorithm's superficial understanding of what I am actually looking for). However, it was always a tiring activity, having to aggressively fight the system instead of being served by it. Like riding a raging bull to work every day. Inevitably, some click bait or ad post would arouse my curiosity and, after clicking on it, I would be presented with more of that crap, even if I didn't like it. Meanwhile, my "friends" were posting photos of themselves, political rants and useful announcements like when they had their latest baby. I mean, even programmers that I know are active were never posting anything remotely technical or at least news worthy. That, frankly, I don't understand.

At the same time I tried as best I could to post science and software links and relevant content about interesting books and whatever caught my fancy that was NOT funny animals or sarcastic humor (although some of that might have slipped in) in the hope of improving the walls of all my friends. Some seemed to like it. I guess some of you are my *real* Facebook friends and most of you are not! 

But the app itself figured out I was less engaged (or just spammed everybody because why not) and started showing me alerts for absolutely everything. People are live streaming, people are going to events, people are having a shit. And with the new normal for everything to be fighting for your attention, it got annoying. I had to navigate the large (and increasing) number of possible alerts and choose what I wanted because the default is that you want everything all the time to snap you from whatever you are doing. Like that makes sense.

Twitter

There are some things that I want to document, but I don't want to blog about anymore. They are not appropriate on Facebook either, as I believe the audience is wrong. One such example is TV (if one can still call them that) series, where I can throw a small rant, complete with hashtags, for everyone who would be interested in opinions about the show, not my own personal stuff. I guess it might work on Facebook, but I haven't tried. The hashtaggy thing should remain on Twitter, it feels only right. Also, it has this system where you are not friends with anybody, you just follow what they are saying. That's good.

Like with Facebook, I've curated the sources of my tweets and the content is mostly... really really informative. I want to say that I will devote no more time reading Twitter, but it's a lot harder to do than with Facebook. Twitter has a very simple, but somewhat effective filtering system based on keywords. Once I removed political keywords, US president names, everything -ist, -phobe, woke and the like, the bullshit I normally have on Facebook largely disappeared. Actually, I haven't done that on Facebook because on Twitter I mostly follow international accounts (in English) and filtering posts on exact words in Romanian, with all of its conjugations and possible forms and lettering would be a nightmare.

BTW, I've set up Twitter to give me tweets in English, Romanian, Dutch, Bulgarian, Italian, German and some other languages. I think the only tweet I got in another language than English was this year, and only because I has followed the guy myself.

There are issues on Twitter as well. One of things that I had to struggle with constantly is telling the app to show me tweets in chronological order. Instead, it wanted to decide FOR ME what I should be looking at. And, when it finally got it straight that I want all my Tweets as they come, they added a feature to restrict the number of tweets that are loaded. The button to "Show more Tweets" looks exactly like any other link and I may just miss it entirely. I can't mark tweets as read, specify a lower time bound for tweets or disable that stupid button. And even if I use the button, I can only do it a few times until it won't load more things because software developers on mobiles never used WPF and then made fun of it for being slow and working only on Windows. (look up Virtualization in WPF, guys!)

And the same issue I had on Facebook I had here: most developers or movie people or science people share all kind of personal opinions and rarely what they are working on, links on the things that inspire them or anything actually connecting anyone with anything. Meanwhile the platform is going further towards blinky images and large texts and video previews and longer text. Having Dorsey step down from Twitter doesn't help either, as corporate assholes will make the decisions now.

Anything else

I have not been active and I don't intend to become on any of the Instagram, YouTube, TikTok, Twitch, etc. platforms, because they are visual in nature. I am more textual.

But I did start to watch more stuff on YouTube and I've got the feeling that many people have started to express themselves more there, as it feels more digestible for younger people. The new "streamer" fad has become very influential. I've found development, science, movie, chess, nature, medicine, humor channels that entertain me an inordinate amount of time while also being very informative. To me watching somebody speak at normal speed about something until they get to the part that actually interests me is torture. Luckily, YouTube has the option to choose a speed of play. It's not exactly a complete solution, but it does help. However watching, let's say, software development videos at 2.5 speed is tiring and you get no inkling on where to skip to get to the good part without missing out.

Of course, having an ad blocker makes this a lot more fun that it would have been without it. I doubt I could stand YouTube otherwise.

But even YouTube has this system in which it tries to control what you are watching, even if it's your Subscription list. If there are too many videos, I feel like it applies a little filtering or ordering. And the list of items in your subscription is generated occasionally, not whenever you open the page.

The video watching stuff will probably continue to take a lot of my time. It's a passive activity, though, so I will have to limit it in some way. More in the conclusion of the post. 

My blog

As you may know, I've moved the blog to my own domain because Google Blogger just decided to automatically, unilaterally and permanently block my blog account. No appeal request was ever answered. I've only had my blog on their platform for 12 years, so who cares? That liberated me, though, to control the full content and functionality of the blog, but it probably lost me a lot of ranking. The result is that very rarely someone comes on the blog for help or interaction. Sites like Stack Overflow solve the issue of finding answers to small problems and people seem to care less about long form content.

Having lately worked in highly paid yet technically dead jobs and a general feeling of "been there, done that" also made me post less and less on the blog. If you look in the last few years, most of the stuff I write about are the books that I read, and lately I haven't been reading that much (except Twitter and Facebook) either. Surely that didn't help people wanting to connect with me. Yet at the same time, I don't want to pretend I have something to teach when myself have not been learning anything new in ages.

If (I am giving myself an out here) I stop wasting so much time parsing walls of stuff trying to occasionally get to something good (BTW, that sounds like gambling, Belgium lawyers! People are performing the same actions but get content they want randomly), watching videos I don't need to watch (because some of them are quite pointless, even if occasionally entertaining) and not watch news anymore (everybody has some agenda behind their news items, but lately it's been so damn obvious that you can't even call it "hidden agenda" and feel smug about yourself), then I should have at least enough time to read more books. I don't know if I will have the material, inspiration and time to research new software technologies in my spare time to start writing meaningful technical content, though. One can only hope. And I mean me.

Conclusion

Lately I've spent my last hour or more before I go to sleep skimming through Twitter and Facebook items, looking for a good reason to continue doing so. I couldn't find it. If I find something interesting (usually on Twitter, but sometimes on Facebook) I share it with my friends on Facebook. It is a rather significant account of my state of mind, since my personal life is hardly something to publish, and these are the things I am interested in.

Before that, I go through my YouTube videos. Some of the things there are what could be considered high level content: documentaries, expert opinions, etc., but most of the ones I find time to consistently watch are short funny animations, short angry rants and short... you get the pattern already.

Therefore my New Year's Resolution (I know they are considered toxic now, but it comes from a good place I think) is to stop reading social media and instead find a more focused solution on getting only exactly the content I need. That requires defining what precisely is the content I need, but at least vaguely I know:

  • I want to find again (if it exists anymore) the software development community that was so active fifteen years ago: blogs, people that share their work and are proud of their accomplishments rather than their opinions on everybody else's, aggregators of actual work, not sharing obvious derivative content or tutorial achievements.
  • I need to restrict myself to the channels where people choose to share educational content. So even if I know someone is a hot shot in software development, I won't just add him as a friend or follow him and hope some day he will stop talking about systemic racism and instead focus on computer systems.
  • Some things will catch my interest for a limited time, like standup comedy for the last year, but I will feel when it starts to get repetitive or slide into something else and cut them off
  • The method of finding relevant content has to be less manual. Instead of trying to find the gem in the mud, just avoid mud in a sea of gems.

Failing at that, I will have to get my content from the original long form content: books. It will be an activity that sounds passive, but it won't be. Books require effort reading them, a focus of attention and so on. More than skimming two page long Internet content, that's for sure. That, if I don't listen to the books instead of reading them, falling asleep and then pretending to have read the thing. No, I won't do that.

I will also continue to share what I find interesting on Facebook. Sharing is caring after all. I just won't read what everybody else is sharing. I know that sounds more self absorbed than useful, but that's the best I can do. The alternative would be to post everything to my blog and repost the links to social media automatically. I just don't feel sharing a link is actually blog post material, which is traditional long form (like this shitty thing no one will read). I mean, how ridiculous it would be to get a link to my blog in Twitter, than you then follow to get to the link I liked while looking at Twitter?

However, it is clear that, as a principle, what I need to remove from my life is as much passivity as possible. I need to involve myself more, pay more attention, focus, make personal connections. That's also something I will attempt to do, though I will likely not share that on social media, except as occasional blog posts on how great my life is and how yours sucks balls.

At this point I only hope you had the attention span to read this to the end, the emotional involvement required for you to care and that you will understand why I don't Like anything you post. I didn't do that even when I was active on social media, I will certainly not do it now.

One possibility is that I will fail at this resolution completely. I gauge this as very remote a possibility, but it exists nonetheless. I really hope someone will smack over the head if I get to that point. I would certainly deserve it. Not you, wife! (she likes smacking me)

I know it's premature, but I wish you a Happy New Year, as I do indeed intend to have one myself.

Intro

When learning to code we get to these exercises and tests and katas and interview questions using some array and expecting some magical string or number and you hear they are called algorithms. And they are intellectual, complex, mathematical, abstract, annoying and feel completely random. But when you are actually doing something real, code doesn't look like that at all. It took me years to understand what the problem is and I am going to share that with you today.

The short version is this: If your program logic doesn't look like an algorithm you are probably doing something wrong. Programming katas are simple because they need to be able to check your answers and give an unequivocal result. It's good to know them, but you shouldn't need to know them, because they are not meant for the real world, but for controlled short term experiments. Unless you are going to work for a sorting company, that's a thing.

Now for the long version.

What you expected versus what you get

You get your first job as a developer and your tasks sound like "fix the color of the submit button" and "the report page shows title in the right, move it to the left". And you think "why the hell did I go through those manual Bubble sort algorithms and learned Quicksort partitions if this is what programming looks like?!". The answer is that you will get to a point where your skills will make people feel confident enough to let you design and architect the things you write. Only then the algorithmic thinking will help because you will have decided yourself what the button does and why its color or position are what they are.

When you start designing flows and entire systems and how they click together it helps a lot to see a component as an algorithm: inputs, rules and outputs. "But, Siderite, a button is not either of those!" you will say. And that is true, but also completely irrelevant. Your program logic should not care about a button, but about an input. And now you also see why the summing of distinct array items is a poor substitute for real life problems, because a click on a button is not a value in a properly contained list, but an event. And most programming exercises and even entire computer classes don't treat events as abstract inputs at all.

Lately this has started to change, both in how programming languages look at actions and events as first-class citizens, but also in theoretical and programmatic concepts like observables, streams, functional programming, reactivity, event buses and messaging, microservices, etc. It makes sense to not quite get it when you have not begun to touch these concepts and when everybody and their grandmother focus on the latest frontend framework, rapid application dev tools or extensions to VS Code, but at their very core all of these things are solutions to the same problem, following the same principles.

Breaking reality apart

As you start to climb toward seniority (and that does NOT mean going to Mexico so they call you "señor developer") you learn about Separation of Concerns, as a good strategy to isolate changes, improve readability and testing and ease maintainability and deployment. You learn about writing applications in layers: the UI, the business logic, the database access, etc, which is also about separating concerns. And as you go further and further on that path you realize...

Wait! This business logic thing looks like an algorithm! It abstracts all of its dependencies until all that remains is: inputs, rules, outputs.

But there are things to confound you: events, user input, parallel tasks, race conditions, heavy load use, the cloud. You can use the same tools, though! Abstract everything, separate concerns. What is an event but a signal coming from a source? Your input is the observable source object and the events themselves just values coming in. Or just a method that receives an event object and you handle sending the event someplace else. Everything coming from the user can be handled the same way. Concurrency is solved by maintaining as little internal state as possible and, when absolutely necessary, guarding it against concurrent access via clear established methods, like semaphores and transaction contexts.

Once your logic is clear, your data structured and every external dependency abstracted away, you can run and test every subsystem in isolation. You don't care something is supposed to be a click, or an error, or a network message or on Windows or Linux or how it's deployed or if the database is available and what kind it is, what UI is being used and what it does, where in the world you are and what time it is and so on. Your code is now an algorithm: a set of rules applied on predictable input which can then be tested for an expected output.

A new requirement comes: you change just the part responsible for the requirement. You can write unit tests before or after or test it manually without caring about anything outside that piece of code. A bug is reported: you write a test that reproduces the bug, you change the code, see the test pass and you never had to open a browser or an app or go to some external environment or ask some other team for user access or if you can use the database. How does it sound to be able to code without ever having to manually go through application scenarios?

Of course there will be an ugly user facing piece of code that you will have to write, but it should be minimal. Your logic is sound, almost mathematically provable to be correct, and how you plug it in is irrelevant. Yes, you will have to work with the graphical designer in your team and make it so the nicely colored card slides across the screen, but that is a meaningless process that you play with in complete isolation from your logic. End to end testing is sometimes necessary, but it's a human thing to do, as well. Just check the "feel" of things, how they look, how they move, if it works for you. The only reason why you are going through it is because you have not been able to completely abstract the end user, with their stupid requests and complicated needs and ideas of what beautiful means.

Yet that is beginning to change as well. Artificial Intelligence, of all things, has advanced so far that you can create minimal interfaces using human language requests. "Build me a web page with a list of items that can be scrolled and selected to be displayed in a details pane on the right". I can imagine this can be used in real life only when the logic of the application has already been written and one is able to just plug and play such a monstrosity without much effort, while also being prepared to change the requirements, recreate the entire things in a different way, but plug it in the same.

And there will be some sort of deployment framework, with people deploying stuff and checking stuff, with data in databases or other persistence mediums. Your code logic? Doesn't care.

Imposter syndrome

Does this sound like a pipe dream that a snake oil peddler is trying to sell you? Let me tell you that the only reason you are not working like that now is because someone though it was too complicated and decided to cut corners. And they have been paying for it ever since, as well as you.

The only proven way of solving complex problems is Divide and Rule. Life is complex and real problems, too. Separation of Concerns, Inversion of Control, Domain Boundaries are the tools you use to break any problem into smaller manageable pieces. And that brings us back to interview questions and pointless algorithms.

When you go to a code test, you are the algorithm. They give you some input and an expected output and check to see if your internal rules are up to the task. Of course you could google for an easy solution. More than that, what kind of employee would you be if whenever the boss asked for something you would build it from scratch without seeing what others did? What hubris to believe that you could know the answer better than anyone else without even checking!

Test succeeded

The conclusion of this stream (heh!) of consciousness is that once you realize the algorithmic nature of any problem (once you abstract every interface with reality), you can see the actual value of being proficient in writing one. You might start with sorting and fizzbuzz and other bullcrap like that, but they are just steps on a larger ladder that will eventually make sense, just like learning the letters of the alphabet prepared you to read to the end of this post. Also, if you are trying to get a job as a book editor and the HR person is asking you if you know all the letters of the alphabet, maybe you don't want to work there.

P.S.

The links in this article are important, especially if you are a just beginning your journey as a developer. Check out the concepts there and learn to use them in your life, it will get a whole lot easier!

  Half a year ago I was writing a piece about how the system is stacked against you, no matter where on the ladder you are. Nobody cares about you! was part depression and part experience, because I have worked in corporations most of my career and that's exactly what happens in real life. This post will not be in the "What's Siderite going to say to make us hate life and kill ourselves" category, though. Quite the opposite. I am going to tell you what the logical consequence of that dreary article is - and it's good!

  Think about it! Are there nice things in the world? And I am not talking about love, sunrises and cute kittens, but about human acts and artefacts. The answer is yes, or you are a lot more depressed than I've ever been. So, if the world is configured to not care about you or about anyone, if the logical best strategy is to do just as much as it is absolutely required and fake the rest, why is there human beauty out there?

  The answer is: every good and beautiful man made thing that you see in the world is by someone doing more than they were asked to do. It's a simple sentence, but a powerful reality. Every day people, like and unlike you and me, are defying the boring order of the universe to create beauty and to better the world. Let's say you play a game made by a big game company and you are enjoying it. - maybe not the entire game either, just some portion of it - I can assure you that is not the consequence of the money poured in it, but of some person who did a little more than the bare minimum. If you use a program, a boring one, like Office something, and you find a feature that blows your mind, be convinced that no one asked for it specifically and someone actually made an extra effort to put it there. If you like the way the handle of the knife feels in your hand when you're slicing bread, same.

  And yes, there is the theory that every act of altruism comes from selfishness, and you can abstract everything to mean anything when it involves humans, but I am not talking about people who want to make the world better or selfless angels who want to make others happy. I am talking here of the simple fact of doing more than necessary just because you want to. And I am not talking about some kind of artsy philosophical method of improving everything and sparking joy, but about at least one, just one act that is invested with a bit of a human person. They do what they were asked to, paid to, coerced to, bullied to, begged to, then they make another step. Maybe it's inertia, maybe it's not knowing when to stop or not knowing what's good for them, but they did it and in the act imbued something with a piece of their soul.

  OK, I know that this is more of a "diamond in the mud" category rather than a positive message, but have you ever considered that even the smallest joys in life may come from the acts of rebellion of others? Maybe it's not a diamond, maybe it's a shitty opal, but knowing that you found it in the mud gives it immense relative value. Finding the ugliness, the stupid, the petty, the outrageous is easy. Seeing something beautiful and knowing it grew out of this is rare and valuable.

Intro

  Labels. Why do we need them? At first it seems like a natural outcome of people trying to understand their surroundings: good/bad, light/dark, wet/dry, etc. It makes sense to start with a simplified model of reality when it is all brand new. However, as we grow, we soon realize that God/Devil is in the details, that taste is more a matter of subtlety than brute strength and that labels, as useful as they have been, sometimes need throwing away. As the old adage says: a beginner needs to learn the rules, an expert knows all the rules, a master knows when to break the rules.

  So how come, with such a general and all encompassing principle, proven many times over millennia, we still cling to labels? And not only to understand the world around, but to understand ourselves and, ultimately, define ourselves? Not only internally, but externally, as a society? Codifying them in laws and unspoken yet strongly enforced rules?

An innocent example

  Let me give you an example. When we enter adolescence we start getting sexually attracted by other people. So this imaginary adolescent (A) likes one girl, then another, then another. After three girls he decides, with the tacit and active approval of his relatives and friends, he is straight. Another imaginary adolescent (B) likes guys, so he's gay. And now, so that we can identify the usefulness of these concepts, we add a third adolescent (C). A sexy young stud that likes... girls, let's say, and has managed to not only like them, but successfully have sexual encounters with them. He has had sex with 20 girls. So tell me, who is more like who in this triangle of adolescents? How do you split this hyperplane of three people into two parts? How do you cluster these people into two groups? Because to me it seems that A and B are far more alike than any of them is similar to C. Moreover, is the sexual attraction pattern that has been established in early adolescence even stable? What happens if the next person A likes is another guy? Is he bisexual now? By how much? Is he 75% hetero?

  Leaving my personal thoughts aside, can anyone tell me what these labels are for? Because if you find yourself sexually attracted by someone, then for sure you don't need a statistical model to analyze that. Is it for the benefit of the other person? "Sorry, but I am straight", which would translate to something like "Oh, I have to tell you that, based on the statistical evidence for sexual attraction I have gathered, I seem to be exclusively attracted to girls. So don't take it personally. I have nothing against gay people, I just have a biological reason to reject any of your advances". Does that sound in any way useful? Especially since we are being taught that one does not refute another's reasons for sexual or romantic rejection, that they have the given right to unilaterally refuse, regardless of any rational reason.

  One might argue that these labels are like armor to define and strengthen the identity of people. You don't just observe you are straight or gay, you define yourself as such, thus avoiding confusion, minimizing internal conflict and adhering to a community. Then, collectively, one can fight the inevitable "You are weird and must die" situation in which all people find themselves in, at one time or the other, when facing people different from themselves. But then, isn't clearly defining a group of people painting a target on their back? Look at the LGBTQ... whatever community. They are actively combatting the discrimination and disrespect that is thrown at them by finely defining the specific sexual group they belong to, then bundling them all together into a community of completely different people. Because they have a common enemy, you see, the cis people (a term they had to invent to define the majority of people, so they don't have to define themselves as not normal). So if I am gay, for example, I am the G person, not the B person, which also accepts sexual encounters with people of the other sex. Why is that important?

  Why can't I fuck whoever I want to fuck, assuming they agree? Why do I need a label which will restrict my choices in the future?

  People managed to somehow debate gender now. And not in terms of "why does it matter?" but in "you didn't define it correctly. It's spelled Phemail, as per the new gender atlas of 2022!"

A less divisive topic

  And what I am saying is not related just to sexuality. Say race, to take something less divisive. Am I White? How do you know? Because the color of my skin? What if you found out that my parents are both Black and I have a skin condition? Is it ancestry, then? The proportion of genetic code from various (very vaguely defined) groups of people in my own? Then we get to the same thing: if my grandfather is Black, am I 25% Black? What if he was Japanese? What the hell does that matter anyway? Why do we need labels like "Caucasian", "non-White", "person of color", "African American"? Am I a European Romanian as opposed to a South Asian Romanian because his Indian-like race was enslaved in Europe a bunch of centuries ago? Who needs this crap? Is it to define values for eventual retribution for perceived historical slights? Is race an accounting concept?

  I identify as a software developer. I am more alike people writing software that with the majority of men, Romanians, sun deprived people with terribly white skin, guys who like girls or humans in general. And there are a lot of software people that are nothing like me. Is it a useful identity, then, other than for HR people? I would say no. No one cares anyway, except when meeting new people and they ask what I do, I tell them, then there is that awkward "Oh..." and they go ask someone else.

The hell with it

  And the holy trinity would not be complete without religion. Religion is a concept you choose! It's the only thing you are protected by law to believe despite any evidence and to act accordingly. It is the same as the identity shield portion of race or sexuality, but that's where the buck stops. No one can prove you are a Christian or a Buddhist. It's a completely arbitrary belief system that is codified only when interacting with other people. You do to Church and if they start singing, or doing strange hand gestures, you better know the lyrics and the gestures or they won't look positively on you. It's like the secret handshake of the gang in your neighborhood. But when you are all alone and you think about God, it's sure that you are thinking of it slightly different than any other person in the world. So why do you need the label? Why can't you believe in two gods, hedge your bets so to speak? You go to the mosque and then to the synagogue. Surely double dipping would be a worse sin than not believing in the true God, wouldn't it? And then, what God do you believe in more?

  Even nationality is stupid. Does the place where I was born define me, or maybe the one I lived the most in? It certainly influences my culture, my values and one can statistically infer many things about me from them, but they are just influences on the path of my life. Some may be important, some not, I may have rejected some or grew out of them. Other than administrative and bureaucratic reasons, nationality is again a mere choice!

  I agree with people who choose to define themselves in certain ways. I respect every personal choice as long as it doesn't hurt others. I am not against self-defining. What I am against, though, is about giving social and legal power to these labels. And then to redefine them again and again as times change. Think of the tortuous etymology of the word "antisemite" for example. You want to define yourself, fine! Don't impose it on me, though. "I identify as a serial killer. Please don't disrupt me in observing the rituals of my people and let me stab you!"

So what's your point?

  We live in a time where everybody and their grandmother decry divisiveness, extremism, polarization. It seems to me that if we want to minimize that, we should at least renounce placing people in disjunct boxes. One shouldn't care what my race, religion or sexuality is until it's relevant to some sort of interaction. And if they find out, it shouldn't be any more important than any other trivia about my person. I say fight the entire idea of labeling people, as a general principle, whether you do it to hurt them or to declaratively protect them. And if you want to build an atlas to categorize the weird and beautiful human species, do it from a place of observation, not coercion.

Forget canon

  Which brings me to the last point. Some people religiously defend their belief in ... imaginary characters and stories. You hear stuff like "In reality, Star Trek canon says that...". No. I have watched everything Star Trek. There is no canon. Canon is used in the concept of religious writings, where people arbitrarily decide what part of a religion is correct and for which part one should burn other people for supporting. It has no place in fiction. Good writing needs to be consistent. If it spreads over multiple decades, multiple writers, multiple IP owners and different times, it needs to adapt. You can say that something is stupidly inconsistent or that adapting old ideas to new times sometimes is detrimental to those ideas and you'd better start anew with fresh stuff. You might even call people idiots for the way they chose to do any of these things. What you cannot expect is canon for imagination! If you do, you are only helping lawyers carve out the landscape of human fantasy and parcel out terrain and capital for the people who care the least about your entertainment.

Conclusion

  Exploring a new domain always requires defining labels, as a simplistic model for charting the unknown. People are not a new domain, nor are they unknown. They may be unknowable, but they certainly don't belong in nicely shelved boxes in the warehouse of politicians, accountants or lawyers, people lacking all imagination or passion. If you believe the current model of interacting with the world is wrong, maybe the surest way to fix it is to renounce and denounce the labels that define the model.

Learning from React series:

  • Part 1 - why examining React is useful even if you won't end up using it
  • Part 2 - what Facebook wanted to do with React and how to get a grasp on it
  • Part 3 - what is Reactive Programming all about?
  • Part 4 - is React functional programming?
  • Part 5 - Typescript, for better and for worse
  • Part 6 (this one) - Single Page Applications are not where they wanted to be

We cannot discuss React without talking about Single Page Applications, even if one can make a React based web site that isn't a SPA and SPAs that don't use a framework or library. What are SPAs? Let's start with what they are not.

SPAs are not parallax background, infinite scroll pages where random flashy things jump at you from the top and bottom and the sides like in a bloody ghost train ride! If you ever considered doing that, this is my personal plea for you to stop. For the love of all that is decent, don't do it!

SPAs are desktop applications for the web. They attempt to push the responsive, high precision actions, high CPU usage and fancy graphics to the client while maintaining the core essentials on the server, like security and sensitive data, while trying to assert full control over the interface and execution flow. In case connectivity fails, the cached data allows the app to work just fine offline until you reconnect or you need uncached data. And with React (or Angular and others), SPAs encapsulate UI in components, just like Windows Forms.

You know who tried (and continues to try) to make Windows Forms on the web? Microsoft. They started with ASP.Net Web Forms, which turned into ASP.Net MVC, which turned into ASP.Net Web API for a while, then turned to Blazor. At their heart, all of these are attempts to develop web applications like one would desktop applications.

And when they tried to push server side development models to the web they failed. They might succeed in the future and I wish them all the luck, but I doubt Microsoft will make it without acknowledging the need to put web technologies first and give developers full and direct access to the browser resources.

Ironically, SPAs (and modern web development in general) put web technologies first to a degree that makes them take over functionality already existing in the browser, like location management, URL handling and rendering components, but ignore server technologies.

It is relevant to make the comparison between SPAs and desktop applications because no matter how much they change browsers to accommodate this programming style, there are fundamental differences between the web and local systems.

For one, the way people have traditionally been trained to work on the web is radically different from how modern web development is taught.

Remember Progressive Enhancement? It was all about serving as much of the client facing, relevant content to the browser first, then enhancing the page with Javascript and CSS. It started from the idea that Javascript is slow and might not be enabled. Imagine that in 2021! When first visiting a page you don't want to keep the users waiting for all the fancy stuff to load before they can do anything. And SEO, even if nowadays the search engine(s?) know how to execute Javascript to get the content as a user would, still cares a lot about the first load experience.

Purely client tools like React, Angular, Vue, etc cannot help with that. All they can do is optimize the Javascript render performance and hope for the best. There are solutions cropping up: check out SSR and ReactDomServer and React Server Components. Or Astro. Or even Blazor. The takeaway here is that a little bit of server might go a long way without compromising the purity of the browser based solution.

Remember jQuery and before? The whole idea back then was to access the DOM as a singular UI store and select or make changes to any element on the entire page. Styling works the same way. Remember CSS Zen Garden? You change one global CSS file and your website looks and feels completely different. Of course, that comes with horrid things like CSS rule precedence or !important [Shudder], yet treating the page as a landscape that one can explore and change at will is a specifically browser mindset. I wasn't even considering the possibility when I was doing Windows Forms.

In React, when I was thinking of a way to add help icons to existing controls via a small script, the React gurus told me to not break encapsulation. That was "not the way". Well, great, Mandalorian! That's how you work a lot more to get to the same thing we have done for years before your way was even invented! In the end I had to work out wrapper elements that I had to manually add to each form control I wanted to enhance.

In the same app I used Material Design components, which I thought only needed a theme to change the way they look and feel, only to learn that React controls have to be individually styled and that the theme itself controls very few things. Even if there is support for theming, if you want to significantly change the visuals and behaviour you will have to create your own controls that take what they need (much more than what Material UI controls do) from the theme provider.

A local desktop application is supposed to take most of the resources that are available to it. You can talk about multitasking all you want, but normal people focus on one complex application at a time. At its core a SPA is still a browser tab, using one thread. That means even with the great performance of React, you still get only one eighth (or something, based on the number of processors) from the total computer resources. There are ways of making an application use multiple threads, but that is not baked in React either. Check out Neo.js for an attempt to do just that.

You can't go too far in the other direction either. Web user experience is opening many tabs and switching from one to the other, refreshing and closing and opening others and even closing the browser with all the tabs open or restoring an entire group of bookmarks at once. And while we are at the subject of URLs and bookmarks, you will find that making a complex SPA consistently alter the address location so that a refresh or a bookmark gets you to the same place you were in is really difficult.

A local Windows app usually has access to a lot of the native resources of the computer. A browser is designed to be sandboxed from them. Moreover, some users don't have correct settings or complete access to those settings, like in corporate environments for example. You can use the browser APIs, but you can't fully rely on them. And a browser tab is subject to firewall rules and network issues, local policies, browser extensions and ad blockers, external ad providers and so on.

You may think I am taking things to an unreasonable extreme. You will tell me that the analogy to desktop apps breaks not despite, but because of all of the reasons above and thus SPAs are something else, something more light, more reusable, webbier, with no versioning issues and instant access and bookmarkable locations. You will tell me that SPAs are just normal web sites that work better, not complex applications. I will cede this point.

However! I submit that SPAs are just SPAs because that's all they could be. They tried to replace fully fledged native apps and failed. That's why React Native exists, starting as a way to do more performant apps for mobiles and now one can write even Windows applications with it.

Single Page Applications are great. I am sure they will become better and better with time until we will forget normal HTML pages exist and that servers can render and so on. But that's going in the wrong direction. Instead of trying to emulate desktop or native apps, SPAs should embrace their webbiness.

Is Javascript rendering bad? No. In fact it's just another type of text interpreted by the browser, just like HTML would be, but we can do better.
Is Javascript URL manipulation bad? No. It's the only way to alter the address location without round trips to the server, but sometimes we need the server. Perhaps selective loading of component resources and code as needed will help.
Is single threaded execution bad? No, but we are not restricted to it.
Is component encapsulation bad? Of course not, as long as we recognize that in the end it will be rendered in a browser that doesn't care about your encapsulation.
The only thing that I am still totally against is CSS in Javascript, although I am sure I haven't seen the best use of it yet.

React is good for SPAs and SPAs are good for React, but both concepts are trying too hard to take things into a very specific direction, one that is less and less about the browser and more about desktop-like components and control of the experience. Do I hate SPAs? No. But as they are now and seeing where they are going, I can't love them either. Let's learn from them, choose the good bits and discard the chaff.  

  Learning from React series:

  • Part 1 - why examining React is useful even if you won't end up using it
  • Part 2 - what Facebook wanted to do with React and how to get a grasp on it
  • Part 3 - what is Reactive Programming all about?
  • Part 4 - is React functional programming?
  • Part 5 (this one) - Typescript, for better and for worse
  • Part 6 - Single Page Applications are not where they wanted to be

  Typescript is a programming language developed by Microsoft. It is a superset of Javascript that allows a lot of type checking and manipulation, hence the name. React and Vue fully support it while Angular requires it. So what is the reason for the adoption of this new language? What are its advantages and disadvantages?

  First of all, what is it? I would start metaphorically, if you can forgive that. Imagine a vast jungle, grown organically since time immemorial, chaotic and wild. Many developers went in, but few have come out unscathed, some never to be seen again. That's Javascript for you. It was released in 1995 as a basic scripting language for browsers, but it was designed as so flexible and complete that it could be used as a programming language in any context with minor modifications. For a very long time tightly coupled with its (very inefficient) browser implementations, it was dismissed from being a proper programming language. But that ended pretty much when V8 was launched, a performant Javascript engine that could be used separately to run the language in whatever situation the developer wanted. With V8, Chrome was launched and soon enough Node.js, which ran Javascript on the server as a proper language.

  The worst and best feature of Javascript is flexibility. You can do pretty much whatever you want in it, as it is a dynamic language unencumbered by such silly things as encapsulation, classes, types and so on. So if you started in a structured way, you could do a lot, if not - like most people unfamiliar with the language - you created a mess that no one could understand, including yourself. So if Javascript is a jungle, Typescript is Duke Nukem coming to cut the trees, wall off vast swathes of forest and only allow a narrow path for life to exist. Only, on that narrow path you get the same chaotic and wild proliferation. A lot fewer software developers traverse the forest and come out with PTSD, but a lot more people go through than before and mistakes can and will be made.

  I guess what I am trying to say is that Typescript sometimes feels like a square peg forced into a round hole. It is not a bad language. In fact, it is amazing in some parts. The type system introduced by Microsoft acts like a kind of system of annotations that inform on what you are actually doing. Tools are aware now of the types of values you use, can optimize code, find errors, warn devs, autocomplete code, help with development, etc. And I am willing to bet that people working on the language are having the time of their lives, because it has to be fun to work on abstract computer science and getting paid, too.

  But what does that mean for the frontend industry? It means that people are getting pushed on that narrow jungle path, for better or for worse. As a small business, you will have to either accept a shitty website created by cheap Javascript and vanilla HTML cavemen or get a lot out of your pocket to hire people who spend time and effort to understand Typescript and some, if not most, of the frontend frameworks that are fashionable at the moment. As a large company you will get tectonic shifts in technology, leaving a large part of your workforce in limbo, while having to spend a lot on hiring and redesigning flows. As an industry, we become dependent on several companies that spend the effort of keeping their frameworks up to date and documented. 

  Let me give you some Typescript questions (that I will not answer) to test your knowledge:

  • can you tell me what all of these types are and how they differ from each other: undefined, null, any, unknown, never, void ?
  • how can you tell if a Typescript object is of a specific form (the equivalent of the .NET 'is' or 'as' functionality)?
  • what is the difference between a union of literal types and an enum?
  • what are and how can you use BigInt, ReadOnlyArray, Partial, NonNullable, Required?
  • what is the difference between a private member of a Typescript class and one starting with #?
  • do you know how to use unions in interpolated strings?
  • what is the difference between interface, type, class, type intersection, class expression and module?

 I could go on and on. On how the possibility of null is now something you have to declare explicitly, for example. I didn't (dare to) ask about type guards and how narrowing works and what conditional types are. And there are so many gotchas for developers coming from other languages, because the language features have been added by people who worked on C#, so they are kind of the same, but actually not. Type meaning and conversion is a large bit of confusing difference between Typescript and C#/Java. For example you can define a class and then cast some data to it, but you don't get what you expect:

class MyClass {
  public name: string='';
  public sayHello() { console.log(`Hello ${this.name}`); }
}

const my:MyClass = { name: 'Siderite' } as MyClass;
console.log(my); // { "name": "Siderite" }
console.log(typeof(my)); // "object"
console.log(my instanceof MyClass) // false
console.log(my.sayHello()); // ERR: my.sayHello is not a function 

There are still web sites dedicated to the inconsistencies of Javascript. Typescript doesn't solve these issues, it mostly hides them. I am sure it's fun to play with types, but is that the optimal solution for the problem at hand, mainly the many ways you can do Javascript wrong? I would argue no. It's fun to work in, but there is a clear dependency between Typescript and Javascript, which forced so many changes in Typescript from Javascript and the other way around, as they have to be kept in sync. All while Javascript needs to remain backwards compatible, too.

"But what about React? Weren't you talking about that, Siderite?"

Yes, I was. I only looked deeper into Typescript because I did this project in React. Before, I had used it with Angular and frankly I didn't feel the friction that I felt now. Angular is designed with Typescript in mind, the development experience is smoother. Angular also uses two directional bindings to propagate changes and that means less Typescript code. The only code you actually need to write is network API code, for which you have out of the box HTTP services, and some limited interface logic. React doesn't do that.

First of all, React has been designed within a kind of declarative/functional mindset, as I explained in previous chapters of this series. It focuses a lot on immutability and functions that are passed around and declaring what your expectations are. Typescript is fundamentally an imperative language. After forcing it through the round hole, the square peg now has to go through a triangular hole, too. The immutability forces one to use a lot of code for changes coming from the UI towards the Typescript logic.

Then, React is a library. It was designed as such and has less levers to force the developer in a direction or another. Even when following a clear development strategy, there are many of which to choose from, all tried and tested and valid, but very different from one another. The jungle was tamed, but now you must consider a multiverse of jungles, each with a different shape.

Finally, React started out in Javascript. Many documentation pages are still just about Javascript. New innovations in the field of React are developed and tested out independently, by various people with various skills and motivations. The learning curve is not steep, but the paths are many.

So in the end, Typescript is an interesting experiment in programming languages, one that will probably surprise me in the near future with ideas that can only be implemented using it. However it is not perfect and its dependency on Javascript is unfortunate, even if its inspiration was not. The purpose of the language was to guide and help developers mired in Javascript confusion, but using it with React goes against that very purpose, as React is still something relatively new and evolving wildly in all directions, so React doesn't help Typescript. Does Typescript help React? I would say yes. However I don't feel that it is enough in its current form. The friction between the two concepts is palpable and I dare any of you to prove me wrong.

It seems I've talked a lot about the problems of React rather than its benefits. I blamed it on things ranging from confusing and obsolete documentation to inconsistent goals of the library and underlying programming language. That's the way I work, focusing on problems so I can find one I can fix. In the next chapter I want to discuss about React in the wild and what are the good things people are saying about it. The most interesting question however, the one that I want to answer with this entire series, is how can we improve our work by adapting lessons learned, either from React to whatever we do or the other way around. What concrete ideas should we adopt from React and which we should condemn to the pit of failed concepts?

  Learning from React series:

  • Part 1 - why examining React is useful even if you won't end up using it
  • Part 2 - what Facebook wanted to do with React and how to get a grasp on it
  • Part 3 - what is Reactive Programming all about?
  • Part 4 (this one) - is React functional programming?
  • Part 5 - Typescript, for better and for worse
  • Part 6 - Single Page Applications are not where they wanted to be

  React was designed just when classes and modules were making their way into Javascript, so it made sense to use them. Developers that are not coming from the Javascript or dynamic languages world are used to the type safety and hierarchical structure that classes provide. And it also made sense from the standpoint of the product. If you want to encapsulate state, logic and presentation why not used existing functioning models like classes, components and so on.

  However, at the same time ideas like functions being first class citizens of programming languages and functional programming were making a comeback, mostly because of big data. That meant that lambdas (arrow functions) were popping up everywhere. If you are a C# developer, you already are familiar with them. Something like Func<int,int> func = (int x)=> x*2; represents a lambda function, which is the same as something written like private int f2(int x) { return x*2; }, yet lambda functions can be declared inside code blocks, can be implicitly cast to Expressions and manipulated and they are brilliant as method parameters. Check out the lambda version in C# compared to the function version in VB:

// C#
var items = allItems.Where(i=>!i.deleted);
// C# function body
var items = allItems.Where(i=>{
                             return !i.deleted
                           });
// VB
Dim items = allItems.Where(Function(i) Not i.deleted)
// VB function body
Dim items = allItems.Where(Function(i) 
			      Return Not i.deleted
			   End Function)

 Similarly, Javascript had only function syntax, even if functions were designed to be first class citizens of the language since its inception. Enter arrow functions in Javascript:

// before
var self = this;
var items = allItems.filter(function(i) {
  return self.validate(i);
});

// after
var items = allItems.filter(i=>this.validate(i));

Note how arrow functions don't have an internal 'this' so you don't need to bind functions or create self variables.

So at this point, React changed and instead of classes, they implemented "functional syntax" in React Hooks. Behind the scenes a component is still generated as a class which React uses and the old syntax is still valid. For example at this time there is no way to create an error boundary component using functional syntax. The result is a very nice simplification of the code:

// React classic (pardon the pun)
export class ShowCount extends React.Component {
  constructor(props) {
    super(props);
    this.state = {
      count: 0
    };
  }
  componentDidMount() {
    this.setState({
      count: this.props.count
    })
  }

  render() {
    return (
      <div> 
        <h1> Count : {this.state.count} </h1>
      </div>
    );
  }
}

// React Hooks
export function ShowCount(props) {
  const [count, setCount] = useState();

  useEffect(() => {
    setCount(props.count);
  }, [props.count]);

  return (
    <div>
      <h1> Count : {count} </h1>
    </div>
  );
}

// courtesy of https://blog.bitsrc.io/6-reasons-to-use-react-hooks-instead-of-classes-7e3ee745fe04

  But this does not just provide a better syntax, it also changes the way development is done. Inheritance is basically eliminated in favor of composition and people are starting to use the word "functional" in sentences uttered in the real world. And while the overall design of React to use unidirectional binding and immutable variables was there since inception, I do feel like this is just one more step towards a functional programming approach and the reason for so many functional purists popping up lately.

  What is functional programming, though? Wikipedia defines it as "a declarative programming paradigm in which function definitions are trees of expressions that map values to other values, rather than a sequence of imperative statements which update the running state of the program." Sound familiar?

  I will have you know that I have friends that have rebelled and gone to the other side, making applications (including UI) with F# and refusing to submit to the Galactic Imperative. After playing with React I can say that I understand why this approach has appeal. One declares what they need, ignore flow and constrain their efforts inside components that are more or less independent. A program looks and feels like a big function that uses other functions and to which you just provide inputs and out comes UI ready to use. If the same input is provided, the same output results. You can test it to perfection, you can infer what happens with an entire tree of such functions and make optimizations in the transpiler without changing the code. You can even use a diff algorithm on the output tree and just update what changed in the UI.

  But it is time to call bullshit. We've used functions that receive pure data on one side and output user interface on the other side since forever. They are called views. One could even argue that an API is a data provider and the application is the function that uses the data to output UI. You don't ignore flow, you move it up! You will still have to model the interactions between every piece of data you have and all the events that come in. One might even say the unforgivable and assert that React is just another Model-View thingie with the extra constraint that it will forcibly re-render a component when its input state changes.

  That is my main takeaway from React: the idea that forcing re-rendering of components forces the developer to move the state up, closer to where it should be. No one can store stuff in browser variables, in element attributes and data, because all of it will be lost on next render. That is good news, but also very bad news. Let me get you through an example:

  We have data that we need shown in a grid. Every row has an expand/collapse button that will show another grid under it, with details related to that row. The React way of doing things would take us through these steps:

  • create a component that represents the grid and receives an array as input
  • it will contain code that maps the array to a list of row components which receive each row as the input
  • the row component will render a button that will dispatch an expand event for the row when clicked
  • on click the row expanded state will be changed and the data for the row detail grid retrieved

  It sounds great, right? OK, where do you store the state of row expansion? How do we push it to the row component? Let's use a map/dictionary of row id and boolean, why don't we? Does that mean that when you expand/collapse a row only the boolean changes or the entire structure? What will get re-rendered? The row component in question or all the row components?

  What happens when we go to the next page in the grid and then go back? Should we return to the same row expansion states? Where should the scrollbar in the grid be? Should we keep that in the state as well and how do we push it to the grid component? Do row details grids have scroll? Doesn't the size of each component affect the scroll size, so how do we store the scroll position? What is the user resizes the browser or zooms in or out?

  What happens when we resize a grid column? Doesn't that mean that all row components need to be re-rendered? If yes, why? If no, why? What if you resize the column of a detail grid? Should all detail grids have the same resizing applied? How do you control which does what?

  Many grids I've seen are trying to store the expansion, the details, everything in the object sent as a parameter to the row. This seems reasonable until you realize that adding anything to the object changes it, so it should trigger a re-render. And then there is Typescript, which expects an object to keep to its type or else you need to do strange casts from something you know to "unknown", something that could be anything. That's another story, though.

  Suddenly, the encapsulation of components doesn't sound so great anymore. You have to keep count of everything, everywhere, and this data cannot be stored inside the component, but outside. Oh, yes, the component does take care of its own state, but you lose it when you change the input data. In fact, you don't have encapsulation in components, but in pairs of data (what React traditionally calls props) and component. And the props must change otherwise you have a useless component, therefore the data is not really immutable and the façade of functional programming collapses.

  There are ways of controlling when a component should update, but this is not a React tutorial, only a lessons learned blog post. Every complexity of interaction that you have ever had in a previous programming model is still there, only pushed up, where one can only hope it is completely decoupled from UI, to which you add every quirk and complexity coming from React itself. And did we really decouple UI or did we break it into pieces, moving the simplest and less relevant one out and keeping the messy and complex one that gave us headaches in the first place in? It feels to me like React is actually abstracting the browser from you, rather than decoupling it and letting the developer keep control of it.

  After just a month working in this field I cannot tell you that I understood everything and have all the answers, but my impression as of now is that React brings very interesting ideas to the table, yet there is still a lot of work to be done to refine them and maybe turn them into something else.

  Next time I will write about Typescript and how it helps (and hinders) React and maybe even Angular development. See you there!

 Learning from React series:

  • Part 1 - why examining React is useful even if you won't end up using it
  • Part 2 - what Facebook wanted to do with React and how to get a grasp on it
  • Part 3 (this one) - what is Reactive Programming all about?
  • Part 4 - is React functional programming?
  • Part 5 - Typescript, for better and for worse
  • Part 6 - Single Page Applications are not where they wanted to be

The name React is already declaring that it is used in reactive programming, but what is that? Wikipedia is defining it as "a declarative programming paradigm concerned with data streams and the propagation of change". It expands on that to say that it declares the relationship between elements and updates them when either change. You can easily imagine a graph of elements magically updating as any of them changes. However, the implementation details of that magic matter.

  In 2011 Microsoft revealed a free .Net library called Reactive Extensions, or ReactiveX or RX. It was based on a very interesting observation that the observer/observable patterns are the mirror images of iterator/iterable. When the iterator moves through an iterable, the observer reacts to events in the observable; one is imperative, the other reactive. The library was so popular that it was immediately adopted for a bunch of programming languages, including Javascript. It also allowed for operations traditionally used for arrays and collections to work with a similar syntax on observables. This is a great example of reactive programming because instead of deciding when to perform a data access (and having to check if it is possible and everything is in range and so on), the code would just wait for something to happen, for an event that provided data, then act on the data.

  One might argue that Verilog, a hardware description language, is also reactive, as it is based on actions being performed on certain events and it even uses non-blocking assignments, which are like declarations of state change which happen at the same time. Reminds me of the way React is implementing state management.

  Of course, reactive programming is also modern UI and when I say modern, I mean everything in the last twenty years. Code gets executed when elements in the user interface change state: on click, on change, on mouse move, on key press etc. That is why, the developers at Facebook argue, browser based UI programming should be reactive at the core. This is not new, it's something you might even be already very familiar with in other contexts. Code that is triggered by events is also called event-driven programming.

  But at the same time, others also claim their software is reactive. Microservices are now very fashionable. The concept revolves around organizing your product into completely independent modules that only have one external responsibility, which then one wires together via some sort of orchestrator. The biggest advantage of this is obviously separation of concerns, a classic divide and conquer strategy generalized over all software, but also the fact that you can independently test and deploy each microservice. You don't even have to shut down running ones or you can start multiple instances, perhaps with multiple versions and in different locations. This is also distributed programming. The way the communication between microservices is done is usually via some sort of message queue, like Rabbit MQ, but I am working on a really old software, written like 15 years ago, which uses IBM MQ to communicate between different portions of the software - let's call them macroservices :) Well, this is supposed to be reactive programming, too, because the microservices are reacting to the messages arriving on the queue and/or sent from others.

  The observer pattern is old, it's one of the patterns in the original design patterns book Design Patterns: Elements of Reusable Object-Oriented Software, which started the software design pattern craze which rages on even now. Anybody who ever used it extensively in their software can (and many do) claim that they did reactive programming. Then there is something called the actor model (which will probably confuse your Google if you search for it), which is actually a mathematical concept and originated in 1973! Implementations of actors are eerily similar to the microservices concept from above.

  And speaking of events, there is another pattern that is focusing on declaring the flow of changes from a given state, given an event. It's called a state machine. It also boasts separation of concerns because you only care about what happens in any state in case of an event. You can visualize all the possible flows in a state machine, too, as names arrows from any state to another, given that such a transition is defined. The implementation of the state machine engine is irrelevant as long as it enables these state transitions as defined by the developer. 

  Everything above, and probably some other concepts that are named differently but kind of mean the same thing, is reactive programming. Let me give you another example: a method or a software function. Can one say it is reactive? After all, it only executes code when you call it! Couldn't we say that the method reacts to an event that contains the parameters the method needs? What about Javascript, which is designed to be single threaded and where each piece of code is executed based on a queue of operations? Isn't it a reactive programming language using an event bus to determine which actions to perform?

  And that's the rub. The concept of reactivity is subjective and generally irrelevant. The only thing that changes and matters is the implementation of the event transport mechanism and the handling of state.

  In a traditional imperative program we take for granted that the execution of methods will be at the moment of the call and that all methods on that thread will be executed one after the other and that setting a value in memory is atomic and can be read immediately after by any other piece of code and you can even lock that value so it is only read by one entity at a time. Now imagine that you are writing the same program, only we can't make the assumptions above. Calling methods can result in their code getting executed at an arbitrary time or maybe not at all. Whatever you change in a method is only available to that method and there is no way for another method to read the values from another. The result? Your code will take a lot of care to maintain state locally and will start to look more like a state machine, modelling transitions rather than synchronous flows. The order of operations will also be ensured by consuming and emitting the right sort of events. Permanent and/or shared storage will become the responsibility of some of the modules and the idea of "setting data" will become awkward. Keeping these modules in sync will become the greatest hurdle.

  That's all it is! By eliminating assumptions about how your code is executed, the result is something more robust, more generic, more compartmentalized. Is it the golden hammer that will solve all problems? Of course it isn't. We've seen how the concepts at the core of reactive programming have been there since forever. If that was the best way, everybody would already be working like that. The biggest problems of this kind of thinking are resource duplication, as everybody has to keep all the data they use locally, and synchronization, as one cannot assume there exists any source of absolute truth that can be accessed by all at the same time. Debugging the system also becomes a bit complicated.

  In 2014 a bunch of people created something called "The Reactive Manifesto" and anyone can sign it. In it, they define a reactive system as:

  • Responsive - responds quickly
  • Resilient - remains responsive in case of failure
  • Elastic - remains responsive regardless of workload
  • Message Driven - async message passing as the boundary between components

  As you can see, reactive mostly means responsive for them and the concept is more one of organization management than a specific set of programming languages and tools. Note that, in fact, you can create a system that communicates via async message passing between components on the client, on the server, between client and server and so on. There can be multiple types of technology and different stacks. As long as they can react to asynchronous messages, they can be integrated into such a system. 

  This post has reached already a big size and I haven't even touched on functional programming and how it tries to solve... well, everything. I will do that in the next chapter. I have to say that I find the concept of a programming language that eliminates global variable scope and public fields and introduces a delay and a random order of execution of methods or properties from other classes fascinating. Imagine testing and debugging that, then moving the working code to production, where the delay is removed. You will also see that a lot of the ideas above influence how React development is done and perhaps you will understand purists telling everybody how things are not correct until you implement this or that in a certain way. Till next time!

Learning from React series:

  • Part 1 - why examining React is useful even if you won't end up using it
  • Part 2 (this one) - what Facebook wanted to do with React and how to get a grasp on it
  • Part 3 - what is Reactive Programming all about?
  • Part 4 - is React functional programming?
  • Part 5 - Typescript, for better and for worse
  • Part 6 - Single Page Applications are not where they wanted to be

In order to understand React we must consider what were the advantages that Facebook found in the concept when they created the library. There a numerous presentations and articles that they pushed to explain it, but it kind of distills to this:

  • mutation of values complicates flows in complex applications
  • traditional Model-View patterns promote mutation through two directional data binding
  • solution for mutation:
    • use unidirectional data binding and re-render views as the data changes
    • send inputs as events that a higher level entity will interpret
  • solution for slow browser render overhead:
    • code is organized in smaller and smaller components that depend on a few values in the overall data
    • there is an intermediate layer of rendering between React and the actual browser DOM called a Virtual DOM, which only sends to the browser the changes that renders affected

But wait, you will say! How do the values change if they are immutable? The point here is that your components have an immutable internal state. The values that are passed to the components can still change, but on a higher level. They declare a label that have a text and for the label the text never changes. When the text changes in the logic of the application, a new label instance with a new text is rendered. The advantage of this is that the declaration of the render for a component defines the way the component will always render. It's declarative of your intent of how that component should look. They wanted to replace mutation with what they called reconciliation between the previous state and the current state. They almost treated web development like game development or remote access software.

So when you look at a JSX syntax and you see Javascript mixed with HTML and switching back and forth, that is different from the ASPX spaghetti code where server logic was mixed up with UI declarations. JSX is less an XML flavor and more a Javascript flavor. In fact, it is transpiled to Javascript code when executed and the changes to the UI are imperative commands that tell it how to change based on how the render code affected the component. But for the developer it's just a story of how the component should look given some data.

React was released in May 2013 and it went through some transformations on the way. Internally it probably started as an object oriented approach which was cumbersome and fought with the overall design of Javascript. They fixed that by the time of the release by using the JSX syntax, but still with code looking like

var component = React.createClass({ render: function() { return <something/>; } });

And further down the line they came up with React hooks, which move further from the class oriented approach and more towards a functional one with stuff like

const component = (props) => (<something />);

which of course is lighter still. Note that Javascript changed during that time, allowing for more stuff to happen. And now they added Typescript support, so you get something like

const Component = (props:{text:string})=>(<something />);

This evolution of the library is also one of the biggest obstacles against learning how to use it as in your Goggle search you might find solutions and problems from any time in the history of the library. You will find the perfect tool for what you wanted, but all the examples are in Javascript and in Typescript it works differently or the answers refer to previous versions of absolutely everything and you don't know which of them is the one that should apply to your task. Or even worse, some package that you use and it made your life so easy conflicts with the one you just want to use because they were never meant to work together.

As opposed to Angular, which was designed as a framework, to constrain and control what you do, React is a library. And it evolves not only through the efforts of Facebook, but also of a very active community. People would add React to their existing project rather than rewriting it from scratch. This means they will have used any of the various versions of React as well as any of the various versions of all the packages that they use in conjunction with it. And these packages are wild! Imagine a developer coming from the world of WPF or vanilla web design with HTML and CSS as the primary focus and Javascript an after thought or from Angular. They will work with React, but use it in a way they are more familiar with. That means that even if the library has a backing philosophy, there is little it can do to force you to use it in that way.

Let's take just one example: MobX, a package that takes existing data objects and wraps them in proxies that notify of changes. With React you use it as you would a ViewModel in WPF. Instead of sending an event called CLICK from a click event and handling it in some state machine looking code you can just modify the "immutable" property of the data you were sent and behind the scene a setter is executed which lets everybody know that it has changed and so it triggers a re-render which will take the value of the actual property from the behind-the-scene getter. You get your way, React kind of gets its way.

To recap:

  • components live in a tree, rather than a graph, and they all render based on the properties they are passed
  • components declare how they should look like
  • any input from the components is sent up as an event to which the system "reacts"
  • slow browser rendering is replaced with a virtual representation of the UI and updated with specific commands to reflect only the changes from one state to the other
  • React is an evolving beast with many heads and finding your own way of doing things lies at the root of any successful development effort

While exploring development with this library, developers have found various tools and concepts useful to integrate. As we usually do, they started to generalize these attempts and come up with some new principles or get to the root of the underlying flow. I want to spend the next part of the series discussing some of these more general or architectural ideas and try to see what they are worth.

Learning from React series:

  • Part 1 (this one) - why examining React is useful even if you won't end up using it
  • Part 2 - what Facebook wanted to do with React and how to get a grasp on it
  • Part 3 - what is Reactive Programming all about?
  • Part 4 - is React functional programming?
  • Part 5 - Typescript, for better and for worse
  • Part 6 - Single Page Applications are not where they wanted to be

  A billion years ago, Microsoft was trying to push a web development model that simulated Windows Forms development: ASP.Net Web Forms. It featured several ideas:

  • component based design (input fields were a component, you could bundle two together into another component, the page was a component, etc)
  • each component was rendering itself
  • components were defined using both HTML-like language, Javascript, CSS and server .Net code bundled together, sometimes in the same file
  • the rendering of the component was done on the server side and pushed to the client
  • data changes or queries came from the client to the server via event messages
  • partial rendering was possible using UpdatePanels, which were a wrapper over ajax calls that called for partial content
    • at the time many juniors were putting the entire page into an UpdatePanel and said they were doing AJAX while senior devs smugly told them how bad that was and that it shouldn't be done. I agreed with the senior devs, but I really disliked their uninformed condescending attitude, so I created a method of diffing the content sent previously and the new content and sending only the difference. This minimized the amount of data sent via the network about a hundred times. 

  Sound familiar? Because for me, learning React made me think of that almost immediately. React features:

  • component based design
  • each component renders itself
  • components are defined by bundling together HTML, Javascript/Typescript and CSS
  • the rendering of the component is done in the virtual DOM and pushed to the actual browser DOM
  • data changes or queries are sent from the browser to the React code via event messages
  • partial rendering is built in the system, by diffing the existing render tree with a newly generated one from data changes

  At first look, an old guy like me would say "been there, done that. It's bad design and it will soon go away". But I was also motivated enough at the time of ASP.Net Forms to look into it, even under the hood, and understand the thing. To say it was badly designed would be stupid. It worked for many years and powered (and still does) thousands of big applications. The reason why Forms failed is because better ideas came along, not because it was a bad idea when it was created.

  Let's look a little bit on what made Forms become obsolete: the MVC pattern, more specifically implemented by Ruby developers and taking the world by storm and ending up being adopted by Microsoft, too. But Model View Controller wasn't a new pattern, it has been used forever on desktop applications, so why was it such a blow to Forms? It was a lot of fashion elitism, but also that MVC molded itself better on web applications:

  • a clear separation of concerns: data, logic and display
  • the ability to push the display more towards the client, which was new but becoming increasingly easy in browsers
  • a clear separation of programming languages: HTML in html files, Javascript in .js files, server code in .cs files
  • full (and simple) control over how things were rendered, displayed and sent to the server

  Yet in the case of React, things are going in the opposite direction, going from MVC applications with clearly separated language files to these .jsx or .tsx files that contain javascript, html and even css in the same file, mixed together into components. Is that bad? Not really. It kind of looks bad, but the entire work is done on the client. There is no expensive interface between a server and a browser that would make the model, otherwise used successfully for decades in desktop applications, ineffective. It is basically Windows Forms in the browser, with some new ideas thrown in. As for the combination of languages in a single syntax, it can be abused, just like any technology, but it can also be done right: with state, logic and UI represented by different files and areas of the application. Yes, you need script to hide or show something based on data, but that script is part of the UI and different from the script used to represent logic. Just the language is the same. 

  "Is Siderite joining the React camp, then? Switching sides, going frontend and doing nasty magic with Javascript and designing web pages?" people will ask. A reasonable question, considering most of my close friends still think React is for people who can't code or too young to remember the .aspx hell. The answer is no! Yet just as with the UpdatePanel seniors that couldn't stop for a second to look a bit deeper into an idea and see how it could be done and then cruelly dismissing curious juniors, thinking that React can't teach you anything is just dumb.

  In this series I will explore not only React ideas, but also the underlying principles. React is just an example of reactive programming, which has been in use, even if less popular, for decades. It is now making a comeback because of microservices, another fashionable fad that has had implementations since 1990, but no one gave them the time of day. Ideas of data immutability are coming from functional programming, which is also making a comeback as it works great with big data. So why not try this thing out, iron out the kinks and learn what they did right?

  Many people, including myself, automatically think of "the client is always right" when talking capitalism, but that's not correct. In fact, capitalism is defined as "an economic and political system in which a country's trade and industry are controlled by private owners for profit, rather than by the state"; profit is the only goal or driver of the system, even for different systems, which might be controlled by the state, for example. Every social or legislative characteristic of a particular political system is just a patch that tries to fix from outside what is obviously a ridiculously simplistic concept.

  Even so, we still cling to the idea that we are "served" by companies, like we are some sort of aristocrats being catered for by legions of servants. There is a logic to that, as when a company stops catering to their clientele, they are supposed to lose it. But that's just an illusion. In fact, this only happens if some very specific conditions are met:

  1. the client is aware of the bad service, meaning:
    • they know what they're supposed to get
    • they know what they are getting
  2. there is an alternative to the service, meaning:
    • there is at least another company able to meet the requirements
    • the company is accessible to the client
      • the cost of access is reasonable
      • the client is allowed to access the competitor
    • the client knows the competitor exists
  3. the client wants to get better service, meaning:
    • there isn't too small of a difference between various services (subjective perception that all companies are the same)
    • the effort of changing the service is not too large (subjective perception of effort)
    • the emotions of the client do not bind them to the company (subjective perception of the company)

  Now, all of the points above require not only effort, but persistent effort. One needs to get the necessary knowledge and then keeping up to date, avoiding misdirection and obfuscation, then make decisions and then take action. But even so...

  A company is usually a client of other companies. In my job I am usually hired by companies who do management of people for other companies that need software, with any number of intermediaries and internal chains of command inside each. One might think that because the end client is paying for the entire chain, we should all care about what they want. But we do not! And here are a few of the reasons:

  1. the client does NOT know what they want, therefore they will never be aware of what they're supposed to get
  2. the client has spent considerable effort in creating a relationship between them and the company that provides them with the software, therefore the effort of changing to another provider is quite forbidding
  3. the client has spent considerable effort in creating a relationship with just one company, because they don't want to handle ANY of the responsibilities that company is supposed to handle, therefore they are not in contact with competitors
  4. the chain of command inside the client is made up of people who have personal connections with the company in question, so changing to another provider would be in their detriment, therefore the client is not allowed to change to another provider
  5. the company itself is not providing a better service because it doesn't have to, for the same profit; their competitors think alike, so there is absolutely no reason to change
  6. there is an intermediary system to measure productivity: instead of getting paid for value, the company gets paid for hours worked, for example
  7. a smaller nimbler company might rise to provide the same service for less money or a better service for the same amount, but there is point 4. as well as the perception that smaller companies are riskier
  8. a company might want to change, but be unable to because it depends on other companies or it lacks the necessary competency
  9. one might be competent inside of a company, but if the company is big enough, they get promoted to other posts until they reach a position were they are not competent enough to be promoted
  10. clients themselves prefer to cut costs than get better service

  This happens at every level from the top - where you feel you might be, to the bottom - where you actually are. And guess what? When you realize the same effort and care that you expect from others should be coming from you, you quickly find reasons not to provide any of them:

  1. my job is boring, why should I do better?
  2. my boss is an ass, why should I do better?
  3. my clients are idiots, why should I do better?
  4. I never meet my clients, that someone else's job, why should I do better?
  5. whenever I tried to change something, someone shut me down because they are better positioned than me, why should I do better?
  6. I am getting paid by the hour, so working faster means less money, why should I do better?
  7. most of the money from the client remains with the entire chain of people over me and I get the scraps, why should I do better?
  8. my job is not important for me, it's just a means to support my actual life, why should I do better?

  This may appear as a pyramid of interests where you are just a cog in the machine or whatever, but it is not, it's a full circle. You get what you give. The client and the company and the least competent employee is always you. There are no other species of creatures that fill any of these positions. Your boss is human, your employee is human, your client is human. In Romania there is the saying that you're stealing your own hat.

  But it's OK. You can't do any better, so why should you do better? You are only human, so why be more human? You are a tiny cog in the machine so why grow larger? Do whatever you want, I don't care.

  When I was a high school kid it was fashionable among the street thugs of Bucharest to use the insult "slave". I don't believe this was related to the history of slavery of the gipsy people in Romania's past, which was the ancestry of many influential such thugs, as it was something borrowed from the Americans, where that issue is much more aggravating. If I am correct, then the very use of the term denotes the way Romanians relate to other people, especially those who they perceive superior. Of course, if I am wrong, then I am guilty of the same thing, so QED, I guess?

  After the Romanian Revolution against Communism (note the big R we use for that event, being the only real change we ever affected as a people) people from different countries came to assess the opportunities presented by a newly opened territory. One report that I saw with my own eyes was from a Jewish lawyer who said just that: Romania is filled with highly educated people who distrust their own government, laws and look poorly on local products and people. Instead, they revere national brands they never actually had any real recent contact with like the U.S. and West Germany, preferring ideas and things imported from there to things they could get or make locally. He concluded that it was a good place to invest in, since the quality of the local human resource was high and their expectations were low.

  The Revolution was in 1989, 32 years ago, but the mentality is still mostly there, as even the people who teach the children of today are still of the generation that lived through that era. It is funny to discuss education with a Romanian, they all complain about how bad it is related to how it was, because children aren't fed the same amount of unprocessed information that was the mainstay of the Communist education. They are rarely complaining about the lack of technological advancement in schools or of skills that are useful in real life or about how children are not taught how to be passionate and happy. Even so, they don't do anything at all to change anything. The only measure of control that parents have is to which school to pay people for their kids to get into and, more recently, to which expensive private school to send their kids in order to give them what they see as the proper education.

  The heroes of the Romanians are not the successful entrepreneurs. The media rarely mentions them and then it is mostly because they were paid for by those people. In case an average Romanian hears about a successful Romanian businessman, it is assumed they had connections with the people who ruled the country during the Communist era. Since they started with money and/or influence, their success is surely undeserved. Funny enough, people like doctors are not heroes either, because in Romania people usually have to bribe medical personnel to get any of the treatments that are theoretically free. Even when they go to private clinics the instinct is to pay extra to appease the doctors who, in their natural state, would try to kill them. This is, of course, caused by a systemic underfunding of medicine and by the endemic corruption which sees any funds misused or embezzled. Because of this, a medic who saves lives - even when they refuse to accept any extra money, is not a hero, but just incompetent or parasitic. Heroes are not the people who left the country to get abused as cheap labor abroad either. People who went to Spain to pick strawberries or to Greece to pick olives are just poor uneducated people who are clearly poor stock, perhaps even gipsy people. They deserve no respect. Same for prostitutes, who are universally despised as shaming the country and at the same time praised for being amongst the most beautiful of prostitutes.

  There was once a news report about people going to pick strawberries on TV and the mother of a girl going to Spain explained how she taught her daughter to conform to whatever they say there, to not antagonize the boss. Just work hard and make money and do whatever he says. This was her mother!

  Police people are not heroic, either. They don't protect the citizens, they enforce unreasonable rules. Politicians are not heroes, they are either the absolute evil or the person who is opposing the absolute evil, which makes them slightly less evil. The few situations where political fervor is so high that someone becomes close to being considered heroic, their efforts pale in comparison with the expectations put on them, which of course proves they were evil all along.

  No, the heroes of the Romanians are the hard working people who work for other people. Great theoreticians, the army of Romanian software developers that left the country to work for multinational corporations, any doctor who would be despised in the country is a hero when working abroad, engineers of all kinds, any white collar job, even people working in construction - which is somehow seen as a clean job. With the caveat that they must not be gipsy or poor stock, they surely left the country to thieve and steal and they are shameful to us all. If people "from the developed countries" (this is a phrase still very much in use in relation to the Western countries) praise a hard working Romanian, the entire country breaths a collective awwh of pride, like dogs petted on their heads for being good boys. "You see?", they say, "Now they see what we are made of!".

  One obvious exception is any managerial job. If you are a manager, you actually do little to nothing, you are an oppressor, not a hard working individual. Even if you got there through your own efforts (and didn't rely on the people you knew or money you had) you have a dirty job that deserves no respect. Unless you are related to the person who judges the situation, in which case you are the pride of the family. 

  The biggest heroes are of course great athletes, especially if they are part of an international team. If a Romanian is part of a of German football team, the entire country believes he would be the reason why Germans are good at football. Of course, people doing great things in Romanian sports are usually seen as part of the endemic corruption in Romanian sports. They still get the status of heroes, but they are always on trial and any mistake will be fatal to their reputation. An interesting exception is Simona Halep, which is the greatest Romanian hero of all, because she goes to international Tennis competitions and wins some of them against the best international tennis players in the world! The fact that she is reasonably good looking doesn't hurt either. She is of the people for the people.

  There are great Romanian writers, for example, but we only value the dead ones. We learn in school about great Eminescu, or Rebreanu, or Blaga. The more poetic, the better. The more obtuse the better. And in order to verify if children really read these big greats, we ask them to write commentaries. And kids just read existing commentaries and summarize them. With the advent of Google and AI, it's impossible to not automate this, since it requires the lowest level of human inventivity. Current writers are poor unknown quantities, always shorted when negotiating with local publishers. And no one reads books anymore anyway, what are they doing? There are great Romanian actors and filmmakers, but few people actually bother to watch Romanian productions. We occasionally see films winning some international prize somewhere and it's usually some drab and depressing drama about people being treated as slaves and behaving like one.

  All these point to a mentality that can only be called "slave mentality". Anything Romanian is poor quality, therefore we export raw material and import the very things made from it. As an example, we export a lot of apples and import a lot of apple juice. The opportunities for Romanians are to either find a good job in Romania or - much better - a good job abroad. To have a company, make your own money, employ other people, is still seen as something dirty. Romanians are not educated on how to make, keep or invest money, instead they are instructed on which jobs are better paid. When I was a child, I knew that I should go for being a medic or a lawyer. Now kids are probably taught to try to go into software. No parent would ever tell a kid to think freely, pursue their dreams and try to make something of themselves through their own strength unless it first starts with being employed somewhere. Surely, dreams can wait, they say, all sad and depressed.

  Funny enough, people who somehow get to be business owners, employers or managers many times behave like slave owners. This is also slave mentality: slaves don't dream of being free, but of becoming masters themselves. This sadly also encourages Romanian employees to feel that anything Romanian sucks. In my career the most unprofessional, choleric, petty and unethical employers were Romanians. With small exceptions that I will attribute to mental illness and not national culture.

  Even when we go on holidays, the biggest complaint we have is "it was nice, but there were too many Romanians there". When we were most complaining about how poor our country was, right after the big R, we were the country importing most expensive cars and high end smartphones.

  This is a sad sad cycle, Romania is and will continue to be a nation of employees. Nothing in our culture impresses the importance of self actualization, of generating and defending our own values, of pushing to get ahead and then actually pulling people with you. Nothing teaches us to band together under those values and fight for them. From all of the cultures we've had contact with, which mostly invaded our country and enslaved us for most of our history, we only learned to slave or enslave others.

  We had and we still have a lot of potential, smart people, hard working people, but is that relevant without a set of values? I personally feel that the Romanians abroad impress their employers, but also their employees or their subordinates and their friends, not by being hard working, but by being open and by not being complete assholes, by being kind and ethical. It hurts me to see how American we have become, partially because of the malevolent influence of Russia, but instead of going for the American ideal declarations of freedom and equality, we emulate the American actions of selfish individuality and status driven inequality. They also pushed this idea that somehow you are either a Capitalist or a Communist, master or slave. This just in case you are not a Fascist or a Terrorist, which makes you gipsy or poor stock.

  Let's abandon this obsolete thinking of masters and slaves and instead think of the others as simply people. Your employer is your partner not your owner, people from other nations are still just people, dreaming is still OK and when you reach the top, give yourself a pat on the back and help others up. Find something you care about and do it. There is nothing on the other end. Every moment is not the first day of your life, but the very last. Make it worthwhile.