I worked for 19 months in Milan as an IT consultant, inside the biggest S.I.M. in Italy (at least to my knowledge). A S.I.M. is such a company, usually owned by a big bank, which handle stocks and cash for other people or corporations. I won't go onto describing the detailed duties of a S.I.M. because it's not interesting to me, and I have very little knowledge in this matter.

My main duty was software development, specifically JSP, Java applications, and PL/SQL code (views, stored functions and procedures) for the backend. Also, this was my first "real" job, since before of that I worked as an intern in a small company in Forlì, Italy. During the time of my work in Milano, I understood many things, which can be summarized as following:

• social environment and individual's motivations must be coherent (in a cause/effect relation);
• working with suits is no good;
• working with non-tech-savvy supervisors can be really bad;
• sharing the code is really good.

Let's examine them.

Social environment

Firstly, let's examine the social environment in which I worked. The entire team was composed by 20-30 people, which included developers, analysts, team and project managers, bosses. The organization was heavily structured, with many "levels" of power. I was the bottom end: an external consultant, doing things as I was told, daily and weekly reporting to project management. Doing my job, I got to see "interesting" things: I saw how other people interacted.

I saw how power is wielded, distributed, exploited, and how pressure can be exerted over less powerful individuals. I saw people getting angry at each other as a routine, even for futile things, like a normal way to react when facing a problem; and after a couple of hours, everything would go back to normality, and the same people were talking as nothing happened. Respect had become an unnecessary option. It was unreal. Not only I knew that wasn't the best way to get things done: I also knew that behaviour was changing the relations between people, and ultimately the people themselves.

In essence, I saw a degraded society. I believe people must cooperate to build something useful to other people. Through work, using my skills, I'd like to create something that can improve the life of my neighbor, respecting her freedom. (With neighbor I intend a class of generic individuals, more indirectly called "people", or "humanity".) Instead, there was nothing useful in the things my coworkers and I built at the SIM. Just a system for handling stocks and cash inside of a bank; which probably uses its revenues for buying or doing things I don't approve and I have no control of.

I'm the first person to blame for all of this. After all, nobody obliged me to take that job. Anyway, now I'm aware of many problems in the way we humans do things today, and it's hard to change that way of doing things. First of all, I noticed that many people were not aware of what they were doing (just like I wasn't when I signed the job agreement); if they were, they simply didn't care about the amount of wealth they were giving to society. Nevertheless they would do the job: they bear stress, humiliation, badly managed work, and frustration because at the end of the month there's a paycheck waiting for them. Money is the one and only motivation. This is the same kind of behaviour of mercenary warriors.

In other words, I felt different motivations. I put usefullness, improvement, increased wealth as main motivations for work. (This *can* match with the goal of a company or corporation.) And I consider fun, creativity, friendship, knowledge as the main requirements for doing the best job. On the contrary, the people I worked with consider work just "work", meaning something that is inherently bad, but must be done somehow. In these assumptions, usefullness, improvement, increased wealth, fun, creativity, friendship, knowledge are not directly related to work. Maybe they can exist inside work, but they are not required to. The consequences are obvious: people accept to work in bad conditions because they think it's normal. The phrase "It's work. It sucks." is common, but it's not depicting an absolute fact; it depicts the most common situation in which we work today, but that doesn't free it from depicting a real perversion.

I sadly noticed that almost every one I talked to didn't get this simple reasoning. As a consequence, they consider "a good salary" as the main incentive and the most important thing for continuing to do the same job, even if the job is stressful, repetitive, and unrewarded from a human point of view (like when noone is telling you "you did a good job!", "I like the way you did this!", "I love your string hack!" and similar phrases). A guy even told me that he would sign a life long contract with the company he's working for, for a double paycheck, a car, a laptop, and a cell phone provided by the same company. As a programmer, and as a human being, I naturally behave in a different way, holding different values.

In my opinion other ways were and are possible to deal with the same problems without losing humanity. It depends on individual attitude, values, motivations. If we do things to improve the life of our neighbors, then it's probable we're going to be successful. If your values and aspirations are a nice career, money, and you just want to be successful, no matter what, then you know you'll have to fight against other people, because you put yourself above all. If many people have these values and have to work together, work becomes an arena, where one forgets about everything because has to fight. A human environment is made out of its composing people.

Working with suits

This is not meant to be a discrimination based on the look of a person. It's just a simple consideration mainly related to the strangulation device suits like to wear: the tie. A tie has no special function at all: in its essence, it's just an ornament that someone finds attractive. The main problem with a tie is that it is seriously unconfortable. In my personal opinion, it's so unconfortable that it affects behaviour. This statement is based on an empirical observation made by me, roughly lasted 19 months, for 5 days a week, 8 hours a day. I noticed that people wearing a tie - usually accompained by a suit and a buttoned down shirt - were more aggressive and willing to yell at people, in particular the ones short of a tie. This is probably related to the fact that a tie increases the ego of the person who wears it, making him feel and believe like he deserves more respect & awe. Actually, this is rather weird & illogical: if you need to wear a tie, that is if you are that important, why do you need to increase your ego? You are already important. If you feel like you need to wear a tie, in my opinion you're not that important. This trivial reasoning leads to a very fundamental theorem:

The demonstration is trivial. (We already informally said it.) Since hackers are important (to understand this, one just needs to look at the hacker's history), and considering that important people don't need anything (e.g., a tie) to show their acquired and deserved importance, it implies that hackers should not wear a tie.

Not wearing a tie improves karma: in fact, a rope around the neck of a stressed out person does not help the stressed out person to free himself of his stress, but rather increases his repressed desire to loosen the knot about half an inch, so to get more air and blood into the brain. Since he cannot do that, his stress increases just because of the lack of logic of his clothing.

I have given practical examples of why wearing a tie is unsuitable for a programmer. On the contrary, I can't honestly think of any good use for a tie as a piece of clothing. I can imagine alternative uses for a tie:

• a tie can be an oddly cut cleaning towel for a pair of glasses;
• a tie can be an oddly cut napkin, always handy; side effects: it may get pretty gross, and other people may be disgusted, especially girls are likely to avoid you;
• a tie can serve as a short rope; (yeah, even to friggin' hang yourself)
• a tie can be an oddly cut hankie;
• a tie can become a very short scarf, maybe useful for a baby;
• a tie can be used as a rag, or recycled as raw silk, cotton, wool, or whatever material it is made of.

As you can see, these uses are rather weird, and maybe should be avoided. All in all, I believe a tie is a pretty darn useless piece of fabric, that should be rejected by everyone who has a normal brain, a good heart and cares about his neighbors.

Working with non-tech-savvy supervision

For the entire work-period at the SIM my coworkers and I worked with no technical supervision. This is not necessarily bad: on the contrary, it could be a measure of trust, independence, efficiency. But it is necessary that your direct supervisor (or senior/leader) has some "basic" understanding of what you're actually doing, just like you have to understand what he wants to realize and accomplish. This was rarely happening - also, our code was reviewd by noone at all. This had some major consequences:

1. developers did not have to strive for excellence;
2. the code was buggy;
3. junior developers were badly damaged because they had noone mentoring them;
4. competition between developers was not based on merit.

Let's examine the consequences. Consider 2 developers, X and Y that have to make the same program. X does it quick and dirty in 2 days: he starts immediately without really thinking at implementation issues, scalability, maintainability, and so on, he just puts up the first thing that come into his mind. Y implements the same sub-system in a smart, brilliant way: he plans the system, he evaluates requirements, costs, performance, choosing the best possible implementation strategies. Since he carefully designs it, he needs 3 days, where he also manage to do a careful test. Let's consider that the project managers have no technical knowledge: so, they are unable to understand the difference between the properly designed system of Y and the "it's-working-somehow" system made by X: in this way, they only see "X, 2 days", "Y, 3 days": X is better. In this way, a programmer is implicitly invited to do his work in the X-way: in fact, the worst thing that could happen to him is that a huge amount of bug fixes are going to be thrown. But let's say that bug fixes are randomly assigned to other programmer, when they are done with other tasks. In this case, X has nothing to worry about. He can throw in some code that maybe works somehow, and say "I'm done", counting on the fact that other developers won't say to the project manager "X's code sucks", because that doesn't happen in Italy.

Since there was noone able to distinguish between good working software and badly working software, one was not compelled to write at his best: it would be better to write some un-documented un-tested code in the fastest possible way. As you can see, competition has been distorted: it's not anymore a race to provide the best product and improve themselves, it's just a race against time.

Also, junior developers could not count on someone with a far deeper seniority: the code they wrote would not be reviewed on a regular basis. A junior developer could only count on his bare forces if he was determined to improve, but that was not always possible because of the 1st consequence.

I did not adhere to this foolish attitude, because I do love my code. And of course I tried to explain these simple reasonings to others, without success. The reply I always got was "we don't have a person that can provide such a skills and seniority".

This way, bugs were an inherent consequence of the strategy itself, and their number was amplified by it.

I saw many other inefficiencies, which I partially tried to solve, especially when they were technology related. For instance, a very central Java application was built with hundreds of unstructured highly coupled classes: every time a programmer had to change something in a class, that would imply the change of a dozen of other conceptually unrelated classes. Having to do the implementation of a sub-project of this application, I redesigned my entire part using "real" OOP, with a couple of design patterns, and a simple development style (``make the simplest thing that can possibly work''). From 105 deeply bound cluttered classes I went down to 10 loosely coupled classes, divided into 2 simple hierarchies based around the ``Composite'' and ``Strategy'' patterns. The development itself was very short: my friend and I (I did mentored a younger programmer even if I'm not very experienced) completed the task with a month beforehand.

No sharing of code

I experienced how frustrating and sad can be to be unable to share the code with other programmers, even when they are suits. In the same open-space, there were other teams working on different projects for the same organization. They were based on the same technologies, and had to implement many similar functions. It was an ideal condition for code sharing, with a direct improvement over development speed and software quality. Unfortunately, different projects were assigned to different consultancy companies, and maybe this was the reason for not sharing the code.

I recall a programmer for another team coming next to me asking how we manage to extend the BC4J framework for our uses, and if he could look at the code. By instinct, I happily agreed, but I was stopped by another coworker literally saying "what the fuck does he want? steal our code? fuck that!". So I had to tell the developer who asked for help that I could not give him our source code without a written authorization from the project manager. After a couple of months I saw a couple of pages that looked like ours, with some slight differences. He could have done the work in 2 hours, instead of 2 months.

Conclusion

The inconveniences here described are partly a matter of principles, and partly a matter way of doing things. It is clear that my ex-coworkers and I are moved by different principles, which is totally acceptable; but above all, I didn't see any passion in them towards software development, any special reason in doing that: it was just "work". Instead, software development is creative, and you must be passionate about creating because there's a special feeling when you build a nice architecture and everything works, and you've helped other people out, and in the mean time you had lots of fun hacking on your computer. Creating stuff improves the world. It was sort of sad to notice that everyone was indifferent about that. (This experience strengthened my inner spirit.)
Beside this, I described something that can give some insights about how problems are solved in Italy.
In essence, I had an impossible mission: to constantly strive to inoculate the holy fires of hackery into card wallopers minds. I failed. Of course I failed.