There are few big questions as big as "Why death?" and "Why getting old?" and "Why sex?. And it's surprising that the answer is probably parasites.

After a lifetime of fighting disease and random damage, it becomes more efficient to give up and just start anew. Death comes just as a natural consequence of a body that has (or should have) achieved replication already and is out of warranty, so to speak.

Sex is similar. Once a parasite finds a way in, it makes a whole lot of other parasites that know that way, too. If an entire population is the same, clones of the same splitting creature, they are all just as vulnerable. Sexual reproduction mixes things up and leads to more variety, jump starts evolution and maximizes the chances that a portion of a population is immune to any one attack.

And I've been thinking today, as a tangent, that another big question might have the same answer: "Why are there sociopaths?". If societal development and cooperation is the solution for gaining supremacy over individualistic populations, why aren't we all social and empathetic and nice? And I am thinking: empathetic people want to help others, especially sick and hurting people. Instead, they get sick themselves and help spread the disease. It helps to have a small, but significant minority, of assholes who only care about themselves. In case of a major outbreak, they stay clear and survive.

I am going to try something new with this blog post. Usually, when I go somewhere on vacation, the things that capture my attention are not what interest about anybody else in my entourage. I am also not a very lyrical writer, so what's the point of enumerating the places I've been from the perspective (oh, so much used!) of the casual tourist. I imagine myself writing one of those horrid "10 things to do in..." articles, promptly vomit and desist from thinking about it.

With this post, though, I am going to tell you of the wild (but accessible) area that I've explored and where to find it, how I felt and, if I can find the references, what plants and animals live there. You see, when I go somewhere, I avoid people and take really bad pictures of flowers and plants, butterflies, weird things and sometimes landscapes.

The place

I've been to Cheile Bistritei Valcene (the canyon of the river Bistritza from Valcea - there is another one in the north of the country) and in the valley of the Luncavatz river. The vegetation and insects are very similar, so I am going to treat this as a single area, even if their locations are 20 KMs apart:

• Cheile Bistritei: from 45.189828, 24.039859 to 45.197871, 24.030284
  
• Raul Luncavat: from 45.186682, 23.917856 to 45.190084, 23.914488
  

The area is very nice, easy to get to by car, but not very touristic yet, so not a lot of people having picnics and listening loudly to music. Leave your car and walk on the sides of the river(s) and the scenery is verdant and quiet. I have to warn you that even if in Romanian they are called rivers, they are more like creeks, especially at this time of the year. You can even find some caves in the area and if you are the long walk type of person, some 4-5 hour hike routes to more remote areas. Some flowers are white, but the vast majority of them are either yellow-orange or violet in color and probably are much more interesting in ultraviolet than human vision.

Animal life

I haven't seen any animals other than birds, a running lizard and a lot of insects.

I saw several species of butterflies, the most common by far being a medium sized orange with black spots, a fritillary, probably the Silver-washed fritillary (Argynnis Paphia) or mantia imparatului in Romanian. They were frolicking on these tall yellow flowers with large leaves: the yellow oxeye (Telekia speciosa) or brusture and ochiul-boului in Romanian. The next most common was a shy dark butterfly with a crimson edge on its wings. Probably the Woodland ringlet (Erebia Medusa), I have no idea what the Romanian popular name for it is.

Some other butterflies: the cabbage white (Pieris rapae) or fluturele de varza in Romania, the peacock (Aglais io) or ochi de paun de zi in Romanian, the swallowtail (Papilio machaon) or coada de rindunica in Romanian and even one glimpse of what I think was a marbled white (Melanargia galathea) or tabla de sah in Romanian.

One fascinating specimen looked similar to a peacock butterfly from afar only for it to settle in a triangular black and white shape when it stopped. It must have been a moth! I've identified it as a Jersey tiger moth (Euplagia quadripunctaria) or fluturele urs dungat in Romanian.

What I also found fascinating is a tree that had apparently been colonized by ants. A lot of wood dust was on the ground and a lot of activity was inside the trunk. Still, there was another hole in the trunk that was filled with wood dust, but no ant activity. Could it have been some sort of other factor, termites or perhaps a disease, that destroyed the tree trunk's interior and the ants were just opportunists?

[youtube:5ewcsMPzSm4]

Plants

Now, plants are easier to photograph, but harder to identify. I've mentioned the oxeye. Then there was the touch-me-not (Impatiens noli-tangere) or slabanog and bradulet in Romanian, which appears to have been used traditionally for its medicinal properties, mostly related to kidney or gynecological issues. The Spreading bellflower (Campanula patula) was there, together with its close relative, the Creeping bellflower (Campanula rapunculoides) - both are called clopotei in Romanian. There was the mountain geranium (Geranium robertianum) or napraznic and priboi and iarba sfintului Robert in Romanian, which appears to have anti-stress, anti-cancer and fertility related purposed in traditional medicine.

Field mustard was present as well (Brassica rapa). This plant was and is used for a variety of reasons in many cultures. The leaves and roots are rich in oil. In Puglia they use the buds as cimedirape in the making of orecchiette pasta. It is a plant from the cabbage family of plants, probably explaining the presence of the cabbage butterflies.

A very interesting flower has a very weird name: the Viper's bugloss (Echium vulgare) or iarba sarpelui in Romanian. It has blue flowers but the filaments of the stamens are red, contrasting with the petals and giving it a violet color per whole. It has medicinal uses as well, as an antidote for snake bites and for its antibiotic and astringent properties.

Another violet flower, with uses in homeopathic medicine but also in poisonings, is aconite or wolfsbane (Aconitum napellus) or omag in Romanian. It contains powerful alkaloids and at one time it was forbidden to grow this plant anywhere in the Roman Empire on penalty of death. Death from intoxication with the plant can occur in as little as half an hour!

And since we are talking about a violet flower with medicinal properties, how can we ignore the heal-all (Prunella vulgaris) or busuioc salbatic in Romania. The young leaves and stems can be eaten raw in salads; the plant in whole can be boiled and eaten as a potherb; and the aerial parts of the plant can be powdered and brewed in a cold infusion to make a beverage and it is used as an astringent in folk medicine.

Not often, but when it happened it was a whole field of them, I found the Orange mullein (Verbascum phlomoides) or luminarica in Romanian. It is also a medicinal plant, used for the calming, sweat inducing and expectorant effects.

I've seen some daisies in the area and also another flower from the same family: the fleabane (Erigeron annuus) or bunghisor in Romanian. Used in salads as well as against the common cold or stomach aches in folk medicine.

Last, but not least, the evening-primrose or sundrop (Oenothera biennis) or luminita noptii in Romanian. It started as an American plant, much like the fleabane, but it was brought and naturalized in Europe. It has been used medicinally by the native Americans for all kinds of ailments, as it is an edible plant containing an oil with anti inflammatory properties.

There were a lot of plants without flowers, but I haven't had the time or patience for them. There was one with huge leaves and I photographed it for identification purposes. It turns out it was either the butterbur (Petasites hybridus) or the burdock (Arctium lappa) both called brusture in Romanian, but different species altogether. It's probably the Arctium, but I can't be sure!

Resources

It would have been a lot more difficult for me to write this post if it weren't for sites like:

• Pl@ntNet - upload photos of plants and get an instant AI driven identification
• Butterfly Conservation - a comprehensive list of common butterflies
• Butterflies from Romania - from a blogger brother (Cătălin Murgocea)
• Revista Radio Guerrilla → Casca de cultură → Insectar - not expecting that there, but high quality stuff and a lot of passion
• ... and of course Wikipedia and Google, which will let me find the correct association between a Latin name and the regional names

Even with these great resources, it was obvious that not many people will publish nature related posts in any systematic manner. Even this post, three hours in the making, is a random mess of blurry pictures and random observations.

There is this old joke about how having a senior developer around is like having a little child sitting next to you. "How do I do that?", you ask. And the SD asks "Why?". "Well, the boss asked me to" "But, why?. "The client wants it" "Why?". "Because he needs this other thing" "Why?". I am afraid the joke is very true. Usually, at the end of the exchange you get to the real need at the base of the request and understand that it is the thing that must be fulfilled, not the request as it came through several filters, each adding or removing from the real purpose of the task. And if there is something I want to impart from my extensive experience as a software developer it is that you must always start from the core need and go from there.

However, I am not here to discuss how to write code, for once, but on how to organize your team (or yourself as a team of one) from this need driven perspective. And please don't call it NDD and read it NEED or whatever, because this is just a general principle that can help you in many domains. So let's analyse Agile. It's been done to death, so what I am trying to do here is not summarize what others have done, but to simplify things until they don't even need a name anymore.

First, what is Agile Development? Wikipedia says: "Agile software development is an approach to software development under which requirements and solutions evolve through the collaborative effort of self-organizing and cross-functional teams and their customer(s)/end user(s). It advocates adaptive planning, evolutionary development, empirical knowledge, and continual improvement, and it encourages rapid and flexible response to change. The term Agile was popularized, in this context, by the Manifesto for Agile Software Development. The values and principles espoused in this manifesto were derived from and underpin a broad range of software development frameworks, including Scrum and Kanban."

So Agile is not Scrum, but Scrum is underpinned by Agile principles and values. That is important, because many shops want to do Agile and so they do Scrum or Kanban and they either try to follow them to the letter (purists) or adapt them to their requirements (which is more in line with Agile principles, but the implementations usually suffer). One wonders how come there are not a lot of different methodologies out there, just like there are software patterns or programming languages. The answer is that no one starts off with understanding their need for Agile and in fact many don't even know or care what it is. They do Scrum so that they get the Agile badge, they tell everyone they "do Agile" and pompously ask their candidates if they "know Agile".

But if someone asks "Why do you want to do Agile?" the answers are not so easy to get. Of course there are advantages in the approach, that is why it's so popular, but you don't get advantages for your collection, they need to drive you to some kind of goal. One might say that for every process you need metrics in order to analyse your progress. Scrum does that. You don't need metrics for the efficacy of the metric system, do you? But still you need some way of gauging the usefulness of your methodology itself, otherwise we would still be using imperial units.

I am more accustomed to Scrum, but I don't want to analyse it, instead I want to measure the usefulness of Agile as a concept by asking the very simple question "Why?". As we've seen, its attributes include:

• self organizing teams
• cross functional teams
• collaborative effort between teams and customers
• adaptive planning
• evolutionary development
• empirical knowledge
• continual improvement
• rapid and flexible response to change

Why self organizing teams? That's the first and one of the most important and complex aspects of Agile. If the team self organizes, then everyone in it shares responsibility. There is no need for micromanagement from above, the team acts as a unit, you get it as a neat package that you don't care about. In theory when a team is inefficient from the organization's point of view, you should fire the team, not individual people. If one member is not performing as expected, then it's the responsibility of the team to fix them or get rid of them. Also theoretically, an Agile team doesn't need a manager.

But in practice I haven't seen this implemented except in small startup teams. There is always a manager, a director or more of them. There is always micromanagement. There is always some tendril of HR or organizational graph that affects people individually. Why is that? Because teams are cross functional, too. A developer doesn't need or want in any way to have to measure the work efficiency of their colleagues, have to tell them how to do things or get to the point where they have to push for firing them. A developer doesn't want to administrate the team. So what is a manager in the Agile world? That's right, a member of the team. If devs would not have a manager, they would probably hire one, as part of the self organization of the team. Moreover, for teams inside larger organizations like corporations, the "customer" is the corporation, so the manager role is often combined with the one for "customer representative" or "product owner" or "producer" or something like that. They're the people you go to in order to understand what it is you have to do.

And since I've started talking about cross functional teams, this means that Agile doesn't need or indeed recommend that people be interchangeable, having the same skill sets. Whenever you hear someone say "everyone should know everything" that's not Agile. It's just a sign that someone from above wants to micromanage the team without having to know anyone in it or ever decide the direction it should work in. It's the sign of a top-down approach that is ultimately inefficient from both directions: the team feels pressure it doesn't need while being restricted in what it can do and the management has to perform tasks that they don't need to do. I haven't seen one team of people treated as interchangeable units be efficient, nor have I heard of any. So why cross functional teams? Because people are individual beings and are different and, for every skill they have, they put in effort to first reach a basic level of knowledge, then more effort to become good or even expert at them. An Agile team needs to be flexible enough to accommodate for any type of person, within reason.

As an aside, think of the skills of a challenged person. The legislation of many countries requires now that software be accessible to a wide variety of disabled people. So whenever you hear that people should be versed in all aspects of the team's business ask them for Braille courses.

Cross functional also includes the skill of knowing what the customer wants, whether they are a member of your organization or someone sent by the client. It's one of the most necessary roles to be filled in a team. If a team were a living thing, the product owner would be the eyes and ears. You can be strong, fast, deadly, but it doesn't help if you can't find your prey.

So why collaborative effort between team and customers? Because you need to know why do you what you do. This entire post is dedicated to the question of why, so I won't press this. Just remember that if the team doesn't know why something is required or necessary, then it is not yet fit to perform that task. People are going to hate me for this, but we've already established the need to understand the client and that in large organizations the customer is the organization, so the logical conclusion is clear: office politics, psychopathic displays of power, idiotic decisions coming from up high are all part of the requirements. There is a caveat, though: the need of the customer needs to be clear, not the want. If the liaison to the customer is withholding or unaware of the real reasons something needs to be done, then the team suffers.

As an aside to all manager or high corporate types out there, it's way better to explain to a team that they have to scrap a project because you hate the guts of the person who proposed it, than to invent business reasons that are clearly bullshit for destroying months of loving work. In the first case you honestly admit you are an asshole, but in the second you prove you are one.

Now, what's this about adaptive planning? If you already know what is needed, someone should let you do your job in peace. You come to them when it's done. That was the fallacy of the Waterfall system. That is also why Waterfall still works. In a situation where needs are clear and do not change, there is no need for agility. Unfortunately, these situations are rare, especially since I've included in the list of customer needs the legacy of us being descended from apes. That means adapting quickly, without regret, changing direction, sometimes turning back completely, abandoning projects, starting new ones that you recommended starting years ago and was laughed out from the room for it and so on.

It's not only that. Adapting to your client's need is something that you would have to do anyway, in any realistic scenario. But it also means that you have to adapt to the technological changes in the world. Maybe you have to rewrite your code with another technology or explore new ones that just appeared out of thin air. Adaptation means that a big part of your job as an Agile team is exploration. This is emphasized by the empirical knowledge attribute above. These two go hand in hand. You adapt by understanding and for this you must be in the loop, you need to know things. Well, one of the members of the team needs to, at least. Adapting means "rapid and flexible response to change".

Therefore, whenever someone asks you if you are Agile or demands that you are, you can tell them about all the new tech that is rumored to come out this year and how you can barely contain your enthusiasm to be working for someone who enables exploration in the true spirit of Agile. Preferably after you've signed a contract, maybe.

But I talked about adapting to new requirements and changes in the environment, not adaptive planning. Adaptive planning is planning for all the things above. In other words, when you start a task, plan for the possibility of it changing, having to be abandoned or having to be redone in a different shape. And here is a point of much contention, because you can do this as any level. If you do it whenever you have to change the color of a button, you will overestimate all your work. If you do it at the level of the entire enterprise suite of products, you might as well do Waterfall. In any respect, it is the entire team that needs to know and decide what they plan for drastic changes.

Yet there are two types of reacting to change: planned or chaotic panic. Adaptive planning refers to planning for change, not preparing for working in complete chaos. That is why Scrum, as an example, splits planning into small periods of time (2-4 weeks) called sprints for which the work planned needs to be finished. If anything drastic (like a task losing its relevance) happens, the sprint is aborted. The sprints themselves can be in relative chaos, but inside one planning and order prevail. It doesn't mean planning for an irate boss man to come and tell you every day to change this and that. It means having a list of tasks that you can edit, whether by removing or adding tasks, rearranging their priority, or even adding tasks like "how to deal with this insane man coming into the office and spouting obscenities at me", then execute them in order. In no way does it mean that you do things by the ear or plan for something and then ignore it.

Two aspects remain to be discussed: evolutionary development and continuous improvement. Both strongly imply awareness of the development processes through which the teams goes. It's the team equivalent of introspection commonly referred to as retrospective. What did we do? How does it compare with what we had planned? What does it mean for the future? How can we do better? and the Why of it is obvious, you've got a good thing, how can you get more of it? Yet this is the point that is hardest to put in a box. Various methodologies attempt to introduce metrics to measure progress and performance. Then, with the function of the team properly computed and numbers assigned to its yield, one can scientifically tweak the processes in order to get the most out of the resources the team has. This is a wonderful concept and I agree with it in spirit, but in practice frankly, I think it's bollocks. It pure shit. It's circular logic.

Here we are, discussing a beautiful philosophy of doing work for maximum benefit by letting a team of very diverse people organize themselves towards a common goal, being ready for anything, adapting to everything, pushing through no matter what by leveraging their individual strengths. And then we come and say "Wait, I can take all this, name it, measure it, put it into equations and then tell you how to improve it!". Well, why didn't you do that from the start, then? Why bother with all the self expression and being able to adapt to anything new? If all is old under the sun, why do Agile at all?!

I believe this is the part where Agile methodologies fail utterly and miserably and can't even admit to themselves that they have. I agree that progress needs to be visible and the ability to compare it with other instances is essential, but from here to measuring it numerically is a large distance. Forget the usual arguments against measuring team success: the team composition is not fixed, the type of work it different, team dynamics means people behave differently, personal and local events, and so on. It's bigger and simpler than that. I submit that since the entire concept of Agile rests on the principles of flexibility, the method of gauging success should also be flexible and especially the way the team processes are tweaked for the future.

And I have proof. In every company I've ever been or heard of the Agile methodology of the place didn't quite work in various ways and that was apparent when people were laughing or disrespecting that part to the point of ignoring the rules in place. And the common bit that didn't work for all of them is the retrospective. The idea of asking "what problems did we face?" and then immediately finding and enforcing solutions with "what can we do about it next time?" has become such a mantra that it is impossible to ask these questions separately. It's become reflex (to the horror of wives everywhere) when you hear "there is a problem" to ask immediately "what can we do to fix it?". There is an intermediate question that must be inserted there: "Is this really a problem or do I just have to be aware it happened? Can we ignore it?". This is another topic, though.

A short summary would be:

• responsibility is shared between all the members of the team and decisions should be taken as a team
• any member of the team is valued for their contribution towards reaching the team goal
• the manager is not your boss, it's just the role of a member of the team
• the Scrum master or Kanban master or whoever does the accounting in whatever methodology you use is still a member of the team
• having a member of the team understanding the needs of the customer is essential; they are the people you go to ask "Why?" all the time
• adaptation need to be written in the DNA of the methodology; the team must plan to change its plans, but still do things orderly
• experience should guide the team to define progress and improve itself
• transparency of the team goal is necessary for the team's success
• there is no improvement of the development method (or the code) without exploration and the entire intentional participation of the team
• never be afraid to ask why; if you work in an environment where you are afraid, consider changing it

Let me tell you the typical story of the development team. First there is chaos, someone decides they are a quick and dirty team and they can do anything, fast, cutting all corners into a straight line to hell. Mistakes are made, blame flies around, people are fired, emotions get high, results go nowhere. There is need for order, all cry out, we need to use the holy grail of software development and the greatest human invention since fire (that week, at least). And then a specialist is called. He either becomes part of the team, with the role of teaching and enforcing rules, or just teaches a few courses, gets their money and leaves before hapless fools try to put in practice whatever it is they thought they understood. The result is the same: developers first like it, then start grumbling about the indecency of having to fill out documentation before any code is written, or updating it, or adding tasks in whatever software is used (or Post-Its on a whiteboard, if you are a purist and still haven't figured out developers can't use a pen to write). So either morale plummets and the operations continue with diminishing results, or the grumbling becomes a rallying cry to make a change. And the change is... chaos again.

In short, just like a revolutionary South American country, they can't decide if they want freedom or dictatorship, because both options have big damn flaws and anything in between is sucking their life away.

But why?

It's because even methodologies are subject to change, to human whim, to altering conditions. If you look at the beginning of this enormous post, it all started with the main goal and meandered from that, just like an Agile methodology in a real firm does. What is the goal of the team? And don't you look at your manager to tell you. As a team, responsibility is shared, remember? If the purpose is to turn perfectly enthusiastic software developers into soulless drones... you should run away from there. But if it is not, think about the things you are doing. Are they helping or are they not helping? This week at least.

In conclusion (or retrospect?) I believe Agile is a great idea, but its underpinning principles of always being aware of the situation and adapting to it are a more general and useful concept to remember and live by. Truth and knowledge comes before adapting and many software shops fail there, so the methodology is irrelevant. Then the method of work chosen should reflect the flexibility it enables. I don't believe in a pure anything, and certainly not pure Scrum, pure Kanban, pure Agile, but whatever you cook up, it should work towards the real goal of the team, as known and acknowledged by everyone in it. What's your function in life?

No natural phenomenon, except maybe fire, seems more alive than the mist. But while fire is young, angry, destructive, mist is an old grumpy creature, moving slowly, hiding itself in contradictions. It doesn't hide distant features as much as it reveals close ones through contrast, it doesn't absorb light as much as it lets itself glow around sources of illumination, it makes sounds crystal clear by covering the constant hum of far off noise, dense and yet immaterial, its blanket like qualities offset by its cold embrace. Never more life like than when it clings to a still surface of water, the slightest gust of wind prompts annoyed tendrils and every move of another living thing elicits mirror acts, dream like, half finished motions forgotten before they even end. If mist could only remember...

It is said that the great theory of relativity of Einstein's doesn't apply to things moving slowly. Today I realized that is not true. There is a direct relationship between space and time and speed affects space, so it must affect time. Here is a practical example: a car moves faster than a person walking, so its speed makes distance shrink relative to time. Inversely, that means that it makes time expand, become more expensive, from the car's point of view.

That is why, when you see a car approaching and you have the option of walking in front of it forcing it to stop, you wait, because the driver's time is more expensive than yours. Stopping the car and wasting time would impact him much more than it would you. It also has the side effect that it saves your life if the car doesn't stop for some reason.

Just a thought.

The Romanian language has a word: deștept. It means smart, but it leans into knowledgeable, so it means both "knowing things" and "thinking fast". There is no relation to wisdom and this is the case in other languages as well. Sometimes wise is used to denote knowledgeable, yet I don't think they are related. While to know things means to be able to recall things you have learned, wisdom, I've come to realize, means to understand what little you know. Someone might be wise and know very little and think rather slowly. Wisdom is the maturation of the soul, like a well kept wine it provides subtle flavors.

Even a superficial and forgetful person as myself can gain wisdom in time. It is important to note this, because as people get older, stuck between that limit of usefulness and the onset of senility, we tend to dismiss them, flaunt our new found (and invented) knowledge to their faces, ignoring a very important aspect of their evolution: wisdom. Sure, their wisdom might not apply to your field or need, but even if it were, are you acknowledging it?

Just a thought.

Siderite's Razor: "The simplest solution/explanation is often somebody whining"

We are changing the furniture and repainting the walls in the apartment, so naturally, the first order of business is to dig into closets, drawers, bags, boxes and various regions under existing furniture and throw away as much as possible. It is a strange feeling, one that makes me remember a past and dead self, one that was hopeful, smart, crazy, in love, using technology and doing stuff that I can't even begin to comprehend nowadays.

I dug into old CD albums, remembering with much nostalgia the movies that I was watching and intending to keep forever. The movies are still around, CD players are almost gone. I had to use my wife's laptop to read the CDs, as mine would only accept a few of them. Well, that's because it's broken, but still. Among the CDs I found old source code and material that I had gathered from friends, jobs, the Internet, hacking. I felt like an archaeologist digging through the remains of old civilizations, ones we hold dear and towards which we feel a strong sense of ownership, but with which we have nothing in common.

Here it is: the Palm VX PDA that was built in 1998 and still works now, with the same battery, if you can just find a way to connect it to a computer so you can upload new stuff to it. Here it is: the Nokia E60 phone that worked flawlessly for more than ten years. I bought a smartphone to replace both of them just five years ago. But also, here it is: an external modem I had forgotten I had; I still wonder where I used it, if ever, and how I got hold of it. Same for the audio/video/infrared wireless transmitters and receivers that allowed me to watch movies from the computer to the TV in the other room. Tens of meters of Ethernet and all kinds of connective cables, forgotten in an age of ubiquitous digital wireless connection just forgotten in the odd corners of the house. Remains of two desktop computers (that I could still make work if I had the inclination) linger like the fossilized bones of extinct creatures.

I feel a mix of gratefulness, nostalgia, loss and that I am fucking old, all at the same time. I wonder where I could find people that still value these things that I dug out from my past and that otherwise will soon become anonymous and amorphous junk. Geez, look at the 6 CDs of utility software, stuff I still remember fondly and stuff I have never used: antivirus, archiving, communication, VoIP, OCR, document processing, all software that is in heavy use today but you would be hard pressed to find people still recognizing these particular incarnations. Music that I still have in my playlist on CDs almost twenty years old. Games that I had worked on that I have forgotten ever doing. Random writing from when I was so young I feel embarrassed just to remember.

And this is just from a 50 square meter apartment that we moved into just ten years ago. I can't even imagine how people do this when they move out from their childhood home, where they and their kids have lived for generations. What do they find? Do they even recognize it? What happened to all the people that I once was?

Occasionally I ask myself if I really am an "ist". You know: misogynist, racist, classist, sexist, bigot, and so on. Or maybe I am "one of the good guys", a progressive feminist antiracist. And the answer is yes. I am both.

I've just read a really long feminist article that - besides naming white bigoted men "the enemy" and showing them the smallest bit of empathy just because "if you mess with them, they mess with us women when they get home" - had the author wonder how come so many of the people who got outed by the latest wave of misconduct allegations were people who declared themselves progressive and even wrote or shared content towards that. And the answer is really simple and really uncomfortable for all purists out there: we are all a bit bigoted. More than that, sometimes were are really leaning towards a side and then we change back, like reeds in the wind. I think that's OK. That's how people are and have been since forever. The answer is not to pretend we are different, but to accept we have that side and to listen to it and converse with it in order to reach some sort of consensus.

The animal brain has one job and one alone. It has to heavily filter all the inputs from the real world and then create a manageable model of it in order to predict what's going to happen next. Shortcuts and pure yes and no answers are heaven to it. If you can look at one person and immediately infer things that will help you predict their behavior from simple things like sex or color of skin or the way they dress, the brain is ecstatic. Try telling it that no, that's not good, and instead of the limited statistical experience model that it uses it should instead rely on the morally curated amalgamation of acceptable experience of other people frustrates it. It's not a human thing, it's not a mammal thing; if you could express this idea to an ant, it would get angry with you. The brain wants - if not even needs - to be racist, sexist and other isms like that. What it wants is to take everything and put as much of it in small boxes so that it can use the limited capacity it has to navigate the things that are not labeled in one way or another.

So yes, physiologically we are too stupid to not be bigots. All bigots are stupid. We are all bigots. In order to not be, or at least not behave like one, you have to be motivated. Messing one's entire life in a matter of days with an onslaught of sympathetic and coordinated allegations would do that quite well. That doesn't mean it's the right thing to do, any more than it would be to "kill off" people who disagree with you. Therefore in matters such as these I cannot help feeling sympathetic towards people who are quite literally dicks. It doesn't mean I agree with what they did, it means I don't agree with what anybody did. And in such moments of sympathy I hear the parts of me that current society wants erased shouting for attention: "See, we were right! We are dicks, but these moralists are überdicks!" I listen to bits of me that want everything wrong with the world to be the fault of poor people, women, people from other nationalities, races or religions, certain jobs or certain types, having certain cars or behaving or dressing in a certain way. It would be so easy to navigate a world like that: just kill off the Jews and black people, put women in their place, write code only in C#, rename the island of Java to DotNet, be happy!

Yet it is obvious it doesn't work that way. Not even white males wouldn't want this to happen, most of them. How do I make the voices shut up? Clearly witch hunting offenders until their lives are more upended than if they stole or ran someone over with their car does not work. And the answer, from my own limited experience, seems to be contact. Whenever I am inclined to say all Chinese or Indians are stupid (which is numerically much worse than being antisemitic and so many people from my background are guilty of it) and I meet a brilliant Asian programmer or entrepreneur or simply an articulated and intelligent human being I am forced to revisit my assertion. Whenever I think women can't code and I meet young girls smarter and more energetic than I am I have to drop that, too. Whenever I want to believe black people smell or are violent or are genetically faulty and I see some Nubian Adonis talking high philosophy way over my head, I just have to stop. If these people would all go hypersensitive, get offended by everything I say or do and gang up on me for being limited in my view, I clearly won't be motivated or even have the opportunity to grow out of it. Of course gay people and Jews are responsible for all evils on Earth if they are the ones making my life hell. And it is also easy to remain bigoted if I surround myself with people just like me. I've read somewhere a statistic that showed racists usually live in areas where they lack contact with people of color.

Basically, what I want to say is that I see no reason why someone would want to be paranoid. Either there is something wrong with them or people are really out to get them. And it is so easy to label someone "the enemy" and just pound on them, so easy to blame anyone else for your troubles, so easy to enter the flight or fight mode that is encoded in our very beings. I see this with my dog: he avoids big dogs since a big dog attacked him. If he continues this trend, he will certainly avoid getting attacked again by a big dog, while trying to get acquainted with them might result in injury or even death. It's so easy to decide to avoid them, however nice they smell and how nice they play. For him it is a very limiting, but rational choice.

Hide your inner bigot, cage him in the darkest depths of your soul, and it will grow stronger, malignant, uncontrolled. This is what civilization, especially the forced kind, does to people. It makes them think they are something else, while inside they are cancerous and vile, just waiting to explode in the worst way. Instead, I propose something else: take your bigot for a walk, talk to it, introduce it to people. Maybe people will start avoiding you like the plague, but that's their own bigotry at work. And soon, you will probably be the progressive one. It's hard to be a racist if you have a black friend and difficult to be a misogynist when you meet wonderful humans that happen to be female. You will make the bad joke, you will expose your limits and the world around you will challenge you on them. But in the end, your limits will expand, people who matter will understand and appreciate your growth, and frigid feminazi Jew lesbos can go to hell.

You know that joke, about the guy who wants to become progressive, so he is searching for a gay friend? Why not try it the other way around? Find a bigot near you and make friends.

A year and a half ago, as I was going from miserable job interview to the next, I was asked what I think about code review. At the time I said that I thought it was the most important organizational aspect of writing code. I mean you can do agile, waterfall, work on games or mobile apps or business applications, use the latest or the oldest, the best or the worst technology and still code reviewing helps. I still think that way now, but recent experiences with the process have left me thinking of refining my understanding of it. This blog post is about that.

The Good

Why is code review good? The very first thing it does is that it forces you to acknowledge your work. You can be tired and fix one little thing in a lazy way and forget about it and it might work or it might break something, but when you know you have to publish what you did you do things less lazy, more documented, more thought out. It doesn't matter that no one will ever look carefully on the review, as that you are thinking there is the possibility of it.

Second, and obvious, is that any mistakes you made are more likely to come to the surface when someone looks at the code. It doesn't mean people blame you for mistakes, it means the mistakes don't come and bite you in the ass later, when your work is supposed to be making money for some poor bastard somewhere. This is very important because we tend to work on systems more complex that we can or are willing to understand. If a group of people who together understand the system is reviewing work, though, you learn not only about the inevitable code errors you introduce, but also about the errors in judgement or understanding or in the assumptions you made.

Then there is the learning aspect of it. Juniors learn from seniors reviewing their work, they learn from code reviewing each other and everybody learns from reviewing work made by anyone else. It opens up perspectives. I mean, you can review some method that was copy pasted four times in order to do the same thing to four different objects and learn how not to that, ever! No matter how much you would want to when coming in at work hungover and hoping for death a little. For example, I've only recently learned to comment on my own code review before submitting it. Some might say comments in the code should do that, but sometimes you need more, as anchors for discussion, which obviously cannot be carried in code comments. (well, they can, but please don't do that)

And there is more! You get documentation of the code for free. When someone doesn't understand what the hell is going on, they ask questions, which leads to you answering in whatever code review software you use. This will remain there for others to peruse long after you've left the company and went on to slightly RGB shifted pastures. I still dream of a non intrusive system that would connect reviews to the code in your IDE, so you can always see a list of comments and annotations for whatever you are looking at.

One of the benefits is that code review makes everyone in the team write code in the same way. For better or worse. I will detail that in a moment, but think about what it means to read a piece of code, trying to understand it, then switch to the next one and see it written in a completely different style. You waste a lot of time.

Finally, I think the confidence code review gives you can lead not only to better code, but also faster code. More on this comes next. This is controversial, but I think you can use code review to check your code, but only if you trust the reviewers. You might fire off commit after commit after commit, confident that your peers will check what you, normally, would have to double and triple check before committing. It's risky, but with the right team it can do wonders.

The Bad

OK, so it's a great thing, this code review stuff. I knew that, you knew that, why are you wasting your finger strength? Well, there is a dark side to code review. I've heard some purists insist on some rules for code review with which I am not completely comfortable with, for example. I invite said purists who also read my blog to come rant in the comments below. Also my recent experience which touches on said rules and introduces others. Let me detail the bad.

There are programmers and programmers, projects and projects, management and management. Where one developer writes some code and hopes people will look at it carefully and instruct them on what they could improve, some people just lazily write something that kind of works, thinking whoever will do the code review will also do the work of making their code remotely usable. Where in some projects developers remain working after hours because they want to see their code do good and the project succeed, in others people couldn't care less: they do their time and break the door when the bell rings. Don't expect careful code reviews then. And there is the management issue, which might protect the developers from anything unrelated to coding or they might pester them with meetings and emails and processes that break concentration, waste time and surely do not help with the attention span of a code reviewer. But in all of the worst cases above, code review is still good, just less effective.

One of the rules I was talking about above was to never commit code unless its code review was accepted. Note the bold font on the never. It was like that whenever I heard the rule. Sounded bold. But I completely disagree with that.

First, if you have developers that you can't trust to commit something, don't let them commit. Either find someone better or do something with their privileges, a system that prevents them from committing. Same goes for people you can't trust to read the code review and update the code afterward a bad or defective commit.

Second of all, you might work on a file that should appear in more code reviews. No, the system where you do the work, ask for review, then shelve the files so you can work on the next thing doesn't work! It takes time, concentration and leads to bad resolves that break your code. Just commit the first thing and move to the next. When your review comes back full of bugs, just finish what you are working on, commit that, then return to the code and implement fixes for the issues found. That is a problem for code review software that can't understand a file committed after changes were made to it doesn't mean you want to include all the changes since time immemorial. That's a software issue, though. Just create a new review and somehow link it to the other, via comments or notes. Creating a personal branch for all developers or other crazy ideas like that are also crap.

Not committing work that you've done means delaying your other work, testing, finding problems in it, etc. Having to juggle with software in order to submit to a rigid process that is indifferent to the overall pace of development and the realities of your work is stupid. Just work, commit, review, test, rework. It's what we do.

It's also, I think, an error in judgement to force code review. As good as I think it is, you can work without it. It is an optional process, so keep it that way. Conditioning development on an optional process makes it mandatory. It might sound like a truism, but people don't seem to realize things unless you articulate them.

And then there is human nature. If you ask me to code review for you, I will stop what I am doing and perform the review, because if I don't, you can't commit. It hurts my work, because it breaks my concentration. It hurts your code review, because I am not focused enough. Personally I am best at reviewing in the morning. None of the organizational crap happened yet, no meetings, no emails telling me to write other emails, no chat messages asking questions that I have no desire to answer. I am rested, I am a bit pumped from making the minimum physical movements required to get me to the office and so I am ready to singlemindedly focus on your review. It shouldn't matter that you committed the code yesterday. I'll get to it when I get to it.

The Ugly

The ugly is not only bad, but also disturbing. It's not a characteristic of the code review per se, but is more related to the humans involved in the process. Code review has some nasty side effects on certain people and in certain situations. Let's discuss this for a bit.

I was saying above that it's good everybody writes in a certain way. That actually may stop people from innovating in the writing of code. Do it this way, that's the pattern we're using, you will hear, without the slightest hint of the possibility to improve on that pattern. Same thing might happen with new ideas that you might feel need to be introduced in the project, or some refactoring, or some other creative work that would make you proud and motivated to continue to do good work. As I said above, it's a people problem, not a process problem, but when it happens, it stifles innovation, creativity and ultimately the fucks you give on what happens to the project as a whole.

Code reviews, like any other communication medium, may be abused. People may be attacked or shamed by others who don't really like them. They might not even be junior and senior, as it might involve time in the firm rather than technical skill, or some other hierarchical or social advantage. Ego fights can also erupt in code reviews, which can exacerbate the problem if they are blocking reviews. Arguments are good, pissing contests are ugly, that kind of thing.

Reviews waste time. That's really not a people problem, it's a process problem. All processes, that is. You need to put in the work to do a good review. Just glancing over and saying "it looks good", without trying to understand what the code is supposed to do, is almost worse than refusing to do the review. I am plenty guilty of that. Instead of thinking about what the guy did and trying to help, part of my brain just keeps rummaging on what my current development task is. This is another argument to separate reviewing from code writing. You need your zone for both. When code review waste rather than spend time, that's ugly.

Finally, I think one major issues with code review is that it encourages lazing off on unit testing, proper testing, refactoring and even simple writing of the code. This is a management issue, mostly, and it's ugly like vomited shit. When people write horrid code filled with bugs assuming that code review will fix their lack of interest, that's ugly. When you are urged, more or less vigorously, to skimp on the unit or manual testing because the code review was accepted, that's ugly. But when you are trying to improve the general quality of the code and the answer is either that you don't have time for this or that any change is unnecessary because the code review passed or even when you are unwilling to do the refactoring, knowing what a hassle will be to send it through review, that's damn ugly. It means you want to do more than your share and you get stuck in a process.

And on that note, I end this wall of text. Process before people is always ugly.

Comments and opinions, if you dare! :)

There are two girls standing right in front of me on the subway escalator, riding up towards the gray, unforgiving, cold Bucharest weather. I am standing there, looking at their backs and my mind starts to wander. I imagine their long young hair hiding one of those smiles to yearn for, expressing both calm and potential, contentment and desire, purity and mischief. I imagine the skin on their back and neck, clean and unmarred, smelling faintly floral, not because of some stupid perfume, but coming from its rose petal smoothness and their very inner nature, tasting like heaven. The long coat and pants hide the perfect ass, not fat and not muscular, not big and not small, not even sexual, the ideal origin for two perfect legs. One of them turns to the other and they start talking and in a completely involuntary act of political correctness they become human, ordinary, just like me, and I resent them for that. Why couldn't you remain goddesses? What is wrong with you?

People know that I sometimes like to hold controversial opinions, sometimes just for the kicks. So first I will ask some questions, ask you to find your own answers, then read about what I think.

Why is sexual harassment different from any other type of harassment?
Why is leaving from a job where your boss or colleague is an asshole any different because they are sexual harassers as opposed to regular assholes?
Why is offering sexual services, including just dressing or behaving a certain way, a natural way of expressing oneself, but asking for them is illegal?
Why do these things seem to happen only in the US?

Now, I am a technical person. While I am certainly not for sexual harassment at work, I need to understand why some types of behaviors are punished so differently from others that are very similar. Consider an employee who is humiliated and disrespected publicly at work, but not in a sexual manner. How could they ever support this outcry against sexual harassment, when their own plight is getting ignored? I mean, do we need laws to tell us when we crossed the line while being jerks? Why is there a legal segregation of jerkness? Why is someone abusing their power more or less guilty based on the type of abuse they chose to exercise?

And, as you might think, my opinion extends to a lot of these special exceptions to civilized behavior. They are called positive discrimination, affirmative action, employment equity and so on, but they boil down to one thing only: another type of discrimination. In the end, like any sort of forced empowerment, they will get abused. The rallying cry of Gretchen Carlson will fizzle out in a sea of false claims and malicious law suits. In fact, it only takes a few to invalidate all the others. It's like trying to make a drink less bitter by adding sugar, rather than removing the bitter ingredient. Or paying someone after you had sex with them against their will, if you see what I mean.

But what am I advocating? Certainly if we abolish the special rules, then all one can do when sexual harassed is to find another job. The asshole in power will hire more and more people until some are weak or desperate enough to accept their advances. If we extend the rules to cover any type of harassment, we expose employers to abuses and tie their hands in how to run their business. Neither option is acceptable, but neither is cherry picking which type of behavior is bad enough to be illegal based on its popularity. This entire issue is systemic: there is no way for the system to self regulate.

When all this #MeToo business started going on, I went and asked women about this. And girls here were supportive of the women who were coming forward, but not supportive of the ensuing publicity circus and these arbitrary lines being drawn in the sand. While the virality of discussion inspired so many people to come forward, which is a good thing, we have to consider why they failed to do so in the past and what will happen when fatigue will inevitably remove this from the public interest. Company policy and employee training, harsher laws? No formalization of common sense (which doesn't seem to be so common anymore) is a good idea.

To summarize this, if you behave like a douchebag and people around you don't call you out on it, then it is culturally OK to continue. It is not right, but putting it into a law won't stop it from happening. The recent publicity around this seems to be coming not from the gravity of the behavior, but from the number of people who suddenly came forward to expose it. If that would have been naturally possible, it would not have been news, it would have just been the normal process of weeding out assholes, so it is clear to me that the problem is not as much the specific type of harassment, but the system that makes difficult the public exposure of it and a subsequent moral censure.

I don't have a solution. I am sure if I could figure it out, so would a lot of other people, and this would be solved already. However, it doesn't hurt to look at these cases from a different perspective from time to time. Like from a different country, with a different culture. Or from high enough to understand which of the social values you foster lead to assholes in power getting more and more power and then abusing it. Let's not get hung up on local solutions for specific problems, turning everything into a legal and moral labyrinth where no one is comfortable, and solve the big problems first.

Growing up I always had this fantasy of writing a journal. My sense of privacy - being sure someone would read and judge it - stopped me from pursuing that, as well as the simple fact that I didn't need a journal, I just saw it as a cool thing I should do. Little did I know that in my older years I would want some sort of record of my forgotten youth and find none. Yet the idea persisted.

I started an actual journal as soon as I had a computer and I understood the concept of encryption. It didn't really work, either. It was full of self serving bullshit and it described a person that I really wasn't. One could (and should) read between the lines in order to understand the smug and ignorant state of mind of the author. Later still, I started to write a book, something called The Good Programmer or something of that sort. Phaw! Even if I could have gotten past my chronic impostor syndrome, being a good programmer is nice, but not my goal in life. If it were, I would have made other life choices. And again, it was full of self serving bullshit.

You may detect a pattern here and it might inform your reading this blog post. Anyway, its point is to generalize my experience as a programmer, as fast and as clean as possible. Hope it helps.

Every time I write software - that I care about and have influence over its technical quality - I tend to generalize things: reuse components, refactor duplicate code and so on. In other words, find similar problems and solve them with the same tool. It is not Golden Hammering problems away, that's a different thing altogether, since it is I who is shaping the tool. So how about doing that for my life? I should care about it and have influence over its quality.

First time I started writing code I was actually writing it on paper. I didn't have a computer, but I had just read this beginner's book and I was hooked. The code wouldn't have worked in a million years, but it was the thought that counted: I played around with it. Later on I got a computer and I started using the programs, understanding how it works, not different from getting a smartphone and learning how to phone people. Yet, after a while I found issues that I wanted to solve or games that I wanted to play but didn't have, then I made them myself: I found a problem and solved it. But writing code is not just about the end result. As soon as I explored what other people were doing, I started trying to emulate and improve what they did. I played around with compression and artificial intelligence, for example. And I was a teen in a world of no Internet. I went to the British Council and borrowed actual books, then tried the concepts there a lot.

It was years before I would become a professional programmer, and that is mostly because the hiring process (in any country) is plain stupid. The best HR department in the world is just looking for people that have already done what is required, so that they do it at the current company as well. But that's not what a developer wants. Software is both science and art. The science is a bit of knowledge and a lot of discipline, but the rest, a very large chunk, is just intuition and exploration and imagination. People who want to do the same thing over and over again are not good developers; instead they are probably people that just want to make a buck with which to live their "real" life. For me, real life has been writing code - and I still think I am being paid for putting up with the people I work for and work with, rather that for doing what I love.

Professional work is completely different from the learning period. In it you usually don't have a say on what you work on and the problems that software is supposed to solve are at best something you are indifferent to and at worst something you wouldn't understand (as in will not, even if you could). Yet, the same basic principles apply. First, you are required to write good code. By this your employers mean something that works as they intended, but for you it is still something that you feel pride in having written, something that is readable enough so you understand it a few weeks later when you have to add stuff or repair something. You are expected to "keep up to date", by which they understand you would keep studying in your spare time so that you do work that they don't know they need done, but for you it is still playing around with things. Think about it! You are expected to keep playing around! As for the part where you see what other people do and you get to emulate or improve on that... you have a bunch of colleagues working on the same stuff that you can talk to and compare notes and code review with. Add to this the strong community of software developers that are everywhere on the Internet.

Bottom line: Just keep doing three things and you're good. First play around with stuff. Then find a problem to solve (or someone to provide it for you) and write code for it. Finally, check what other people do and gain inspiration to create or improve your or their work. Oh, did I say finally? This is a while loop, for as long as you are having fun. Hey, what do you know? This does scale. Doesn't it sound like a good plan, even if you are not a software dev?

It seems to me that there are more and more crazy people around me. They are relatives, friends, colleagues, random people on the street and I have no idea where they came from. I don't remember as much insanity from when I was a boy, but then again I was even more oblivious then than I am now, and that's saying something. Yet, since then the population of the planet grew from 4.5 billion to 7 billion and, more importantly to me, the population of my home city of Bucharest grew from about 1.5 million to a city where just as many people come from outside the capital to find opportunities. But the percentage of mentally afflicted seems to have more than doubled. But what is crazy?

I mean, I just saw an old lady, looking like she was chronically homeless, shouting obscenities to no one in particular. Who else was she to talk to except herself? She can't even trust another human being enough to talk to them, even if the thought came to her mind. And if she has an audience of one, just as sane as she is, who is to say she's talking crazy? Or when you see some company executive make stupid after stupid decision, then boldly coming on stage and presenting it as the best idea since fire was invented. Do they know they are sociopaths? Does anybody else know? Do they even care? There is a quote in the Mindhunter TV series: "How does a sociopath become the president of the United States?", asks the young FBI agent. "How does one become president if they are not?", responds the psychology professor. And I am reading this book, that I am going to review in a few days, about the counterculture in America, during the 60's. If those people would appear in front of me right now, foraging through mall trash and explaining cosmic truths while loaded with speed and LSD, I would probably catalog them as insane.

Maybe insanity is not a state, but a perception. It's just a socially unacceptable behavior. It does hurt the person using it, but that's mostly because they can't fit (or maybe they fit too well). Have I become more sensitive because of the carefully constructed shell that protects me from hardship? Anything going through it hurts like hell because I am not used for stuff to come through. I have thin skin covered by layers of callousness. Maybe society is more exclusive now? It is easier to become crazy, as you only have to fall a little bit before you get into an unstoppable spiraling decline. Certainly you can't experiment now with personal freedom; it's almost gone, taken away bit by bit, not (only) by repressive governments, but by our willingness to waste time and resources until there are none left. Open relationships? Life on the road? Chemically expanding your mind? Forget about it! You get homeopathy and holotropic breathwork and feel enlightened.

There is another hypothesis worth exploring. Maybe people are not crazy at all. Perhaps I am the mad one. At every stage I expect the full weight of social scorn to come over me and crush me like the bug I am. How dare I? I wouldn't even know what I was guilty of - which, paradoxically, would prove I am even more guilty. They would come at me with carefully crafted smiles and expressions taken from shows or movies they have all seen and burn me alive, giggling all the way, like they are making the greatest joke in the world while providing me with the help they know I desperately need. All these people that apparently speak only to themselves, yet somehow communicate with others by methods unseen, they would suddenly all turn towards me, pointing their fingers and letting out inarticulate cries. Then, of course, I would know that I am insane, because I would never be able to do any of that.

I just don't know. Where does this vomitous mountain of madness come from? Maybe more importantly, where is it going?

Cool people are those who respond to your opinions with condescension. Anything different from what they believe is ridiculous, pathetic, laughable or dangerous. I mean, they could even be right: you might have said something really stupid. But while you can handle finding out that something you were thinking is not true, they cannot. Their whole world view is based on them being right. While you might see them as a little hurtful and a bit annoying, they see you as a threat, because their truth is something they desperately cling to and any type of difference challenges their way of life.

You will usually meet them in positions of power. They are not enough of a sociopath to be top leadership, but they will be somewhere in the middle, telling themselves the story of how in control of their life they are. They clump together, because a tale is easier to believe in a group than by yourself. They drink together, they watch the same sports, they play the same games, they go in the same vacations, they have the same gods and the same rituals. Their information bubbles existed way before Facebook and while you might see them as ridiculous bubble people, they always fear you are carrying a pin to burst theirs. Cool people always know "how the world works" and to pretend otherwise would only mean you are not as savvy. Major changes leave them helpless and in search of a narrative that explains that away from their view of the world. Beware a former cool person for they are desperate.

They will applaud each other vigorously at every little success as they feel it's a validation of their own. Unfortunately, that means they will stand in the way of your success, as they feel it invalidates theirs. Cool people live on a narrow ladder, where everybody is clearly ranked on a vertical scale. Not being on their ladder makes them feel superior to you. Not wanting to be on their ladder makes them feel threatened by you. While you are exchanging information you possess, they only coerce it out of you in order to judge and rank you on their scale. When they are exchanging information is from a feeling of generosity, allowing you to know where the cool is; not being grateful angers them.

Cool people keep in touch. They cannot allow coolness to exist in different flavors. They maintain contact in order to synchronize their shared concepts. Socially it is easy for two cool people to communicate, because they are very similar. It is important to make other people feel not cool enough, because a cool person can't handle a conversation that doesn't follow a familiar pattern. While the problem is mostly theirs, they need to shift the blame onto others. They smile easily as a well trained skill, not an expression of how they feel. Smiles and laughter are tools and weapons for them.

Uncool people are essential to the well being of cool people. A careful dance of keeping people just far enough to indicate superiority, but close enough to make it visible to any outside observer, is essential to the lifestyle of cool people. While you either despise, pity or envy them, but you could easily do without them, they actually need you.

So how cool are you? I am not cool. I am better than cool. Me and my kind.