Hello to the few people persistent enough to be still following me, and also to those that come pay me a visit now and again to see whether I've decided to make up my bloody mind and write another post. Sorry for being so out of sight.

After giving a lot of thought to the idea of writing something, today I landed on a piece of Wikipedia that really struck me, since I naively still keep on searching for that productivity silver bullet that would fix the procrastination issues I've been dragging along for so much time. Here it is in its original form, and I quote:

Csíkszentmihályi identifies the following ten factors as accompanying an experience of flow:[3][4]
1.- Clear goals (expectations and rules are discernible and goals are attainable and align appropriately with one's skill set and abilities). Moreover, the challenge level and skill level should both be high.[5]
2.- Concentrating, a high degree of concentration on a limited field of attention (a person engaged in the activity will have the opportunity to focus and to delve deeply into it).
3.- A loss of the feeling of self-consciousness, the merging of action and awareness.
4.- Distorted sense of time, one's subjective experience of time is altered.
5.- Direct and immediate feedback (successes and failures in the course of the activity are apparent, so that behavior can be adjusted as needed).
6.- Balance between ability level and challenge (the activity is neither too easy nor too difficult).
7.- A sense of personal control over the situation or activity.
8.- The activity is intrinsically rewarding, so there is an effortlessness of action.
9.- A lack of awareness of bodily needs (to the extent that one can reach a point of great hunger or fatigue without realizing it).
10.- People become absorbed in their activity, and focus of awareness is narrowed down to the activity itself, action awareness merging.
Let's pick each one of those and talk a bit about them, shall we?

Clear Goals

Easy one. Unless we know for sure where we're going, we risk getting to a place we don't want to be at. Some times this rule may be bent a little if we're not really sure something is feasible and there's some research to be done. But the primary objective should never leave our mind, or we risk getting lost. You may observe this everywhere, from simple programming and up to the management layers. It's pervasive among the whole soft-dev chain, but perhaps an Architect would need a clearer state of mind than a Junior Developer. The latter may make mistakes and are easily fixed when discovered. The former may also make some mistakes, but those mistakes may steer the whole project into an iceberg.

Ur fridge is me goal, human

Concentrating

Close that goddamn TweetDeck, for heaven's sake! Stop peeking at your inbox tab every 10 minutes just to see if the "1 unread - Gmail Inbox" label has shown up! Deactivate those pesky notifications from your IM program!

Stop those distractions that prevent you from entering a state of mind that'd allow you to delve deeply into what must be done. This is one of the most harmful and destructive characteristics of procrastination. Even breaking out of that state is awfully hard. Some times is like being stoned without you even having touched a joint. The mind jumps from one thought to the other. It's in its nature, and we can't entirely avoid that. But we can train ourselves to be focused, just as we can train ourselves to lift a 100 kg weigth.

Oh, I'm sorry.. did I break your concentration?

One important tool to this is meditation. I don't know of so many people that practice it, and yet it's not an arcane, nor a difficult practice. Even the book "Pragmatic thinking and learning: Refactor your wetware" mentions and recommends it.

Sit down and take a moment. Don’t think about the mistakes you made yesterday or worry about problems that might come up tomorrow. Focus on now. This one instant in time. Right here.
No distractions.
No chatter.
I’ll wait.
It’s not easy, is it? Much of meditation, yoga, and similar practices aim for the same goal: to offer some relief from that gibbering L mode monkey voice in your head, to live in the moment, and to not divide your mental energy unnecessarily. The internal chatter knocks us off our game.
A study published in the Public Library of Science-Biology2 showed that training in meditation could improve a subject’s ability to pay attention throughout the day.
Their testing gauged how well subjects could allocate cognitive resources when presented with multiple stimuli, all competing for their attention at once. Sounds like a normal day at the office....
On a personal note, I practice Buddhism, and even having tried some smart drugs, I've not found yet something that provides a more relaxed and focused state of mind than meditation (smart drugs work, don't take me wrong.. but the mind's state feels unnatural). On the other hand, daily context and my own mind usually drive me away from having a steady regular meditational practice. Paraphrasing a japanese buddhist monk:

To begin is easy but to continue is difficult.
That phrase perhaps sums up every recovering procrastinator's day, doesn't it?

Balance between ability level and challenge

If the task is a tall order, we may feel we're not cut for it. Some strategies may be applied, but if the job still seems daunting, better go learn something and prepare yourself to face it again some time later. There must be an equilibrium, a point where the task seems easy enough to be faced, yet difficult enough to be a challenge and not some boring menial job. An important strategy to achieve this is our famous divide and conquer.

Besides, if you ever get stuck at some point, and can't see a light at the end of the tunnel, go away from the problem. As Isaac Asimov would do it: Each time he felt like he was facing a wall with no exit in sight, he just went to the cinema, and watched a movie that required no thinking whatsoever. That way, he would allow his mind to work "in the background", so when he exits the movie theater, his mind would've been "reset" and is able to see the problem from a different perspective.

So, are really your options just to keep on banging your head to the wall or to quit altogether?
Think again.

Direct and inmmediate feedback

Goes hand in hand with the previous one. Once we have tasks sufficiently small to be approachable, yet big enough to be challenges, we are ready to start working on them. But if we get stuck at some point, or we choose to have nothing to show until everything's finished, we risk losing stamina to keep going in the best case, or just end up building the wrong thing in the worst.

Baby steps. Build something, read something, learn something. Then go check it out and see whether what you built/learned is right or not. Perhaps you're your own judge, but anyway, just take a couple of minutes to look at the big picture now and again. Check your goals. Check your progress. Be prepared for change. This is the agile way.

Consequences

The rest of the items that show up in the list are more like characteristics of being "In the zone", rather than some points that we may use as strategies.

  • - Loss of the sense of self-consciousness
  • - Distorted sense of time
  • - Sense of personal control over the situation
  • - Activity intrinsecally rewarding, effortless
  • - Lack of awareness of body needs
  • - Action awareness merging
Nevertheless, if you can observe yourself at some point and say "yes, those are true now, I feel that way", you know that you're on the ball, in the moment, present, in the zone, in the groove, or keeping your head in the game.
No, I'm not talking about just interpreting the symbols that build our alphabet. I'm talking about knowing your way around a book.

We read all the time. Those of us that are drawn to texts just as moths to fire, are sometimes lost amidst the myriads of texts that we can access today through the Internet. Millions of blogs and newspapers, a handful of them interesting and useful, and yet enough to fill every day of our lives because of the sheer amount of material that's published all the time. It brings upon us a lot of noise and we are the ones that have to filter it so we are left only with what's the most useful and valuable of all of it.


Why can't we just return to books? Some time ago (not that much anyway, I remember it from when I was a child) there was no internet. No everyday flood of information, no Google Reader. Just magazines that came around once every fifteen days, and that gave us the time to absorb all of the knowledge that they could give us. And then there were books.. those time travelers that could reach us from centuries ago in order to teach us important facts and knowledge that the human race thought was important enough to republish in order to make it available to future generations.

Of course, this was not a perfect filtering process. There are books that reached us from a long time ago that I could think are worthless, because they were promoted by the powers at the time, and are still there to do so. But what could the Internet add to this process that improved it? The wisdom of the crowds. As the Internet is an environment were we all can have our say, we all help to produce knowledge and to filter what's worth from what's not.

Therefore, why would we return to books? We must, because they still are the true recipients of ideas. We could read a statement in a blog (perhaps this one), and think that it's right. But the effort that it takes to do a brief statement is very little, and what it takes to write an entire book is a whole other league. That effort also helps so we can filter those ideas that are useful from those that aren't.

I feel stunned by people who believe that books are not worth the effort, or who believe that they can become the best professionals they can be without ever reading a full book, just absorbing passively the knowledge that our educational system imprints on them. And I feel sorry for them.. for they are the ones that will be left behind..

Disconnect for a while. Read a book.

So, can we also use the wisdom of the crowds so we can get the best books out of the enourmous amount that are published every day? Yes we can. And we should. Not to merely dismiss the filter that editorials also provide, but to enhance it.

Ok, so this post has only one goal: to recommend you the latest book from Frederick Brooks, the author of "The Mythical Man-Month". It's named "The design of design, essays from a computer scientist". Go ahead, download it from Gigapedia and read it (of course, buy it if you can, I live in Argentina). Stop wading through your Google Reader and read something useful instead of just watching noise. I promise it'll be worth it.
I can't say that enough: Context Matters. And that advice extends also to the tools that we are using.

Can we listen to music in a cheap mp3 player? Sure. But how's it that an iPod seems better at it? It's not just some extra feature or the audio quality or some social way of saying "hey, I'm trendy and cool". It's also that it conveys an ease of use because it's nice, and that my friends, is context at work.

An excerpt from the awesome book "Pragmatic thinking and learning: Refactor your wetware"

Several studies have conclusively shown that attractive user interfaces are easier to use than unattractive (or to use the scientific term, ugly) interfaces.

Researchers in Japan did a study of a bank’s ATM interfaces; subjects found the aesthetically pleasing button layouts much easier to use than the ugly ones, even though the functionality and workflow was the same.

Thinking that maybe there was a cultural bias at work, researchers repeated the experiment in Israel. The results were even stronger, even in a completely different culture. But how could this be? Aesthetic considerations are merely an emotional response. That couldn’t possibly affect cognitive processing. Could it?

Yes, it can. In fact, additional studies have shown exactly that: positive emotions are essential to learning and creative thinking. Being “happy” broadens your thought processes and brings more of the brain’s hardware online.

So, next time an extra tool is needed, shop around.. find the best one, not just one that allows you to do the job, but one that also allows creativity and ease of use. Your brain will thank you for it.
'morning folks! I'm back in black, so to speak (just served myself some fresh brewed coffee as a sunday afternoon treat).

I'm reading the excellent book Pragmatic Thinking and Learning: Refactor your wetware, and so far the best tip of insight I've had is this: Context Matters.

It doesn't matter whether you're developing software, painting, driving, writing.. whatever you do, it'll be influenced by the environment, heavily. Your mood will be different if the weather is not right, if you're working in a cubicle farm, if music is not appropriate, if the tools are not easy to use, etc.. All of that stuff influences our R-Mode brain, the part of the brain that deals with humour, patterns, interrelations. It doesn't matter if your L-Mode brain (the logical, analytic part) is powerful, it'll be hampered by the other part.

Some time ago, scientists believed that neurogenesis couldn't happen in humans. The amount of neurons of our brains was fixed, and could only decrease as we get older. Today, they think it's the opposite that's true.

Why did they believe that? Well, the experiments showed exactly that. No neurogenesis, but also the death of existing neurons. But.. those experiments were performed on rats captive in cages. There was no sensory stimulation that could encourage and allow the growth of new neurons and connections between them. Now take that knowledge, and apply it to the cubicle farms that were so popular in the 90's. Pretty horrible, isn't it?


If you haven't watched "Office Space" stop reading and go watch it
(if you need an extra incentive, Jennifer Anniston is in that movie)


Today, some of the enterprises understand this. Take Google for example, and the environment they use to nurture creativity in their employees. Regrettably, some do not embrace this kind of positive work environment, and treat their software developers as assets that are interchangeable and resemble something quite similar to an orange that you can squeeze in order to get the juice out of it (Colmena IT, I'm looking at you).

This topic is also related with the mark of the expert: Create an environment where intuition could breed, and you may develop experts. Create an environment where there are only rules to be followed, and you've wasted all of the potential that experts could bring to your enterprise. Experts work from intuition. Novices work from rules and guidelines. Take care of the experts, and treat novices as such, but allow them to grow so they become experts.
Due to recent events at the university where I'm studying, where a server was hacked and the proffessional reputation of a couple of students seriously damaged, I've come to realize how much needed is an education about the ethics of our profession. As far as I know, there's no curricula in any university (well, perhaps the M.I.T. or something like that) that offers even a small subject about what are the best ways to behave with regard to your subordinates, pairs, coworkers, or your boss; and in order to correctly manage the responsibilities that we inherit due to our jobs.

Our orientation is basically a technical one. Most of the people that come out of college (at least this one) with a degree in Software Engineering are glorified programmers, only with a superficial knowledge about what being an Engineer really is, and with absolutely no concience of the profound implications of the work that they will be performing. Who's to blame for that? Well, on one hand, the proffessors that call themselves as such, but are anything but because they do not teach anything. On the other hand, society itself and the kind of knowledge and values the students receive prior to their entrance at college.

We're in the age of information, people. The world revolves around computers and IT. If it were to dissappear, major shit would hit the fan. We're at the heart of that. There's not a chance that we can ignore the ethics and morality associated to our job when we are the ones that have the power and the responsibility.

 
Spiderman's uncle was right.. and also a little corny

This can't be an issue left to the student's good will, or perhaps to the fear that if someone finds out about what you did, there could be serious consecuences. That's what an environment based on fear and law enforcement would do. We're talking about an environment that should promote a change in the inside, and the awareness that IT is about computers, but also about the way those computers are used by the people. An environment where a student should be able to have mentors and examples to follow when it comes down to the proper and correct ways to use the power at hand. Today, we have almost none, unless we search outside of college.

Some people would think that the students should be screened previously, so that only the "ethically correct" may access that knowledge and wisdom (I swear someone told me just that yesterday.. couldn't believe what I was hearing). Some sort of thinking that "bad apples don't spoil the good ones". I obviously don't believe in that approach. Mostly because everyone should have the chance to prove themselves that they're worthy and able to be more than what they are. As Sartre stated: Freedom is what you do with what's been done to you. It's eventually your decision to change. And also because the institutions we would rely on to make that kind of screening are already spoiled, so there's no point in trying to let only the good ones in, while there's corruption inside already. The institution must be changed the other way around, from its base, all the way up.

The episode that happened in the recent months was not an act of someone who was evil, just naive. Here, right now, all of this should be a catalyst for change, not only for the people involved, but also for the institution itself. Some of those lives that were involved could be ruined because of the mistakes that have been made. We ought to learn from this. Not merely to abide to the law, that's just fear at work. We should learn to be responsible for our actions, and to understand the consecuences that those actions may provoke. And above all, we should learn to take care of the people that's involved. It's not ethically correct to save our butts and let our fellow partners go down, on fear that we could also go down, when we could've done something about that. That goes for the professors/managers as well as for the plain students/workers, but mostly to those that have the power to do something. And this not only applies whenever something goes wrong and heads are lining up to be beheaded.. it also applies when you're designing a piece of software that may influence the lives of millions of people and you decide that testing won't be neccesary, or that the cheaper alternative will do because you really don't care. Or merely to treat your coworkers the right way they deserve to be treated, and they deserve not to be treasoned. Because that people will be there for you in order to give help and support, no matter what. Unless you choose to go with a higher power and leave them behind. In that case, you've chosen your path, but it's not the one I'd like to walk.
Well, I'm back to bring you an awesome video of Mary Poppendieck. From that video I got the inspiration to write the previous article.

A little background information about her would come in handy here:

Mary Poppendieck has been in the information technology industry for 25 years. She has managed solutions for companies in several disciplines, including supply chain management, manufacturing systems, and digital media. As a seasoned leader in both operations and new product development, she provides a business perspective to software development problems.
Lean development is just one of Ms. Poppendieck's areas of expertise. She first encountered the Toyota Production System, which later became known as Lean Production, as Information Systems Manager in a video tape manufacturing plant. She implemented one of the first just-in-time systems in 3M, resulting in dramatic improvements in the plant's performance. Ms. Poppendieck's team leadership skills are legendary at 3M, where new product development is a core competency. One team commercialized a graphics interface controller three times faster than normal. Another team not only developed an image database system in partnership with a start-up company, but also set a new international standard for image formats. Poppendieck, a popular writer and speaker, is the author of Lean Software Development: An Agile Toolkit and Managing Director of AgileAlliance.
 And the video. It's a MUST WATCH for any leader in the software development business.

'morning folks!

The entire week I ruminated about what should I write this weekend. I almost began a blog post about some neat group management techniques that may come in handy when we are talking about the SysAdmin way of working, an agile way to improve efficiency and productivity on an area which focus is mainly on putting out fires. But I won't be ranting about that (maybe next week). Instead, I'll try to express some thoughts that come from experience and personal learning, about how leadership should be in an agile environment.

Let's go back in time about 100 years, in order to remember some things about work management a nice north-american fellow said:

   - Workers are lazy, they will always do as little as possible.
   - Workers do not care about quality
   - Workers are not smart enough to know the best way to do they job.

That, in a nutshell, is what Taylor said at the time about which was the best way to manage the workforce.

No, not Roger Taylor.. he rules!

Let's also remember that this was a time of immigration. Lots of people were moving from Europe to America, and those people had to be put to work in the steel mill, the environment where this was mostly applied. That kind of strategy was thoroughly stated in a book he wrote, The principles of scientific management, and it entails the de-humanization of the workplace, de-skilling the worker and pretty much putting as much pressure on your employees as you can, 'cos, hey.. those lazy inmmigrants surely can't speak english, they must be dumb! Can't trust'em.. I tell ya.. (read that in a red-neck tone of voice)

It's amazing how much we've (not) progressed in the last 100 years with regard to this. One of my jobs about 5 years ago, before I landed one in the Software Development business, was at an enterprise that sold alarms and monitoring, and man.. they were exploiters.. It only lasted a month.. couldn't stand this guy who thought that because he was giving me some little money in exchange (and I can't emphasize enough the "little" part), he was entitled to yell and be unpolite with regard to my work.. He actualy believed that pressure only would make me do my job better. That's a fireproof way of driving away the people that you're in charge of.

Another point of view about management of the people and groups that could be added here is this. The historians have formed theories of value, one of which we could call "Spanish Theory of Value". It states that there's a fixed amount of value on earth, and we should extract it all in an efficient way, be this from the earth itself or from other people's backs. Then there's another theory of value that says that value could be created from technology and ingenuity. This we'll call the "English Theory of Value". In history, the results of each of those theories were the Industrial Revolution in England, while Spain exploited the land of the people of South America (and the people) in order to take precious gold to Europe (that backfired on them with a huge inflation afterwards).

Pictured: A modern successful manager that advocates to the Spanish Theory of Value

I'd like to quote a book I've been reading these days, Peopleware: Productive projects and teams. Excellent book by the way:

The Spanish Theory of Value is alive and well among managers everywhere. You see that whenever they talk about productivity. Productivity ought to mean achieving more in an hour of work, but all too often it has come to mean extracting more for an hour of pay. There is a large difference. The Spanish Theory managers dream of attaining new productivity levels through the simple mechanism of unpaid overtime. They divide whatever work is done in a week by forty hours, not by the eighty or ninety hours that the worker actually put in.
That's not exactly productivity—it's more like fraud—but it's the state of the art for many [...] managers. They bully and cajole their people into long hours. They impress upon them how important the delivery date is (even though it may be totally arbitrary; the world isn't going to stop just because a project completes a month late). They trick them into accepting hopelessly tight schedules, shame them into sacrificing any and all to meet the deadline, and do anything to get them to work longer and harder.
So, we pretty much nailed down the kind of managers we are talking about.

How does all of this relate with the Agile Methodology? Well, as the English Theory of Value states, through technology and ingenuity, productivity can be boosted. In this case, the ingenuity of time-management, project management, and above all of this, giving people respect for their work.

All of this should be easy to implement and do in a working environment, but sometimes it is not. Lets remember *always* that we are talking about people, and that people must be prepared to take this philosophy to the full extent of it. Otherway, it won't work.

How should an agile team leader be, and what should he do, in order to better do his job? I think he should:

- First of all, know a lot about the agile methodology. It doesn't end with stand-ups.

- Be able to say "no" to the product owner, if he believes that the amount of work the PO is taking from the backlog into the monthly or weekly iteration is not achievable or unreasonable.

- Know the people he is in charge of. Their skills, motivations, way of working, hell.. even hobbies. The employees must be able to trust him and take him as a reference, he must know what people can and can't do, and devise new ways to bring them up to the challenge.

- If somehow an employee fails to do his job, investigate to the full extent what were the causes of this. Perhaps some guy was left by his wife and has not been able to sleep in a month because of depression, or has family issues, or just can't stand their coworkers because they had an argument or a fight. If the leader is not trusted, people won't open up to him. He won't be able to lead anything, merely to do some clerk work.

- Bring ideas and new ways of working to the team, so things that should be done in a better way will be. And listen to people that give him proposals. Remember, what an agile leader should value the most is the people.

- Protect the team. If his role is to be the leader of a team, he should protect it and nurture it in a way that the people that's in that team really *wants* to be there, not just because they get paid a lot of money. Just giving people more money is *not* the solution. Create a good environment, bring some perks to the office so that employees feel happier. Organize dinners, make people mingle so that when they have to work together, all of the roughness that could be there is wiped away, then they trust each other and know the person that is their daily wingman. We're talking about a team, not just some workers thrown together.

And perhaps build a diverse multi-ethnic group.. those always seem to be happy

There is certainly more that should be put on that list, but those are the basics. It's Leadership 101. If you have a team leader that:

- Says "yes" to everything the product owner asks, and then puts pressure on the team so they work unpaid overtime in order to be able to make it before the deadline.

- Does his job the way he knows, but never bothers to find out how to do it in a better way, or is not genuinely interested in learning more in order to be the best proffesional he could be.

- When the product owner puts pressure on him, he only knows to turn and put that same pressure on the team.

- Doesn't think of any ideas so that productivity gets boosted.

- Doesn't really care for the teamworkers.

You don't have a leader. You have a problem.
'Morning! (or whatever form of salute that suits better your time zone)

Today I'll be blogging about my thoughts and quite brief experience to this day as a developer who is learning whatever is needed, in order to become a systems administrator ambassador, and I'll do this in an attempt to better understand what this role entails, and to try to describe to you why is this middle-man position is so much needed in the world of software development today.

At present day, I work for vLex, an online legal information platform. This enterprise is located at Barcelona, Spain, and it's been growing since its birth back in 1998 (this I read from their page, I've only been working there for 3 years now), but I believe that the growing curve has taken a steep step since an argentinean IT team was formed about 6 or maybe 7 years ago.

This team, of which I'm part of, consists now of seven persons, and works closely with a smaller team in Spain in order to improve and maintain the platform, solving the needs of the clients and learning whatever technology is required along the way. A part of the team in Spain consists of the much scorned but needed systems administrators. Those kind of employees you've probably heard being characterized regularly as practical nazis (even from a professor at my university) because of their jealousy when it comes to managing the IT infrastructure of the company, with regard to the developers that use that infrastructure in order to add value and build the product that the enterprise is trying to sell. If you've ever read any of The Daily WTF articles that have anecdotes about the adventures of IT workers around the world, there seems to be an infinite source of short sightedness in this kind of fellows.

Nevertheless (and before my colleagues from spain kick me out of the sysadmin team if they ever read this), their job is clearly a must have at any enterprise that needs to maintain an IT infrastructure in order to provide a layer of service to any other part of their staff. From the developers that use that infrastructure to maintain and develop new software, up to the management layer, and back to the sales team that engage in.. well, sales. The productivity of those other parts of the enterprise sinks (if it doesn't completely cease to be) when they have to deal directly with the intricacies and gears underlying the tasks that they've been hired to perform.

On the other hand, and perhaps so we can balance this out, we as developers have certain vices that don't come easy when we are talking about taking care of that infrastructure we so much need, so the labour of the team that keeps the circus running in the background is easier, or at least not so much a pain in the arse. From security measures we never bother to take, to shortsightedness when it comes to assesing the resources, profiling our creations, and measuring the impact we could have in order to safely execute a program we just developed so that it won't tear down the entire system and ruin the party for everyone. We also sometimes do our fair share of the mistakes.

In summary.. come on, let's admit it, we need that layer of technicians so they can save our butts when somethings falls apart (being this a webserver, an oracle database, or anything else that requires some level of specialization and experience in order to get it working smoothly), because even if we developers could work our way around to solve the issue at hand, we may also break something else because the mentality of a developer is not the same of as that of a sysadmin. The sysadmin is more concerned with security and performance of the system, whether the developer seems to lean more to "let's just get this thing working so we can get back to coding".

Perhaps all of this, combined with the distance that comes when there's a team working for you overseas, brings a storm of lack of communication that pretty much difficults the work for both sides of the pond. For the last two years of work I've been a witness to all kind of misunderstandings that provoke friction, animosity and distrust between members of both parties. It's not easy to overcome this, and I believe that productivity has been sometimes hindered because of those events.

This year a different approach has been brought to life from the upper layers of management that kind of address this issue. Some practices of the Scrum agile methodology are being followed, and I've been appointed as "Systems Ambassador", a position that didn't exist previously. My job is to specifically address the issues that concern both the sysadmin team and the development one, as well as having a view of the entire picture, something that up to this day only the C.T.O. had.

Extracted from my job description:

- Help in the transference of essencial information between the Sysadmin and Dev teams, at stand-up meetings.
- Maintain the local development environment of the argentinean dev team running smoothly.
- Lead on the research of new technologies regarding systems architectures, write improvement proposals, develop new pilot projects on them.
- Gain trust from both sides, but mostly from the Sysadmins through a careful administration of the tasks at hand related to that specific area.
    This last point is related mainly to politics and the issue I've been ranting previosly about: smoothing all the roads that come and go between people that have different scopes, and improving the communication among them. It entails being "politically correct", and also able to perform nicely on both sides, as a developer, and as a sysadmin. It involves some kind of interdisciplinary art, although we are only talking about IT. It also involves getting in touch with the people behind the proffesional, so whenever shit hits the fan, we will have the necessary trust in the work that our colleague is doing and not start blaming each other.

    In addition to all of this, there's another aspect that has come to life recently with the new tools that a Sysadmin needs in order to maintain and report the status of the systems, and focus on the big picture instead of being consumed by petty tasks. I'm talking about administration tools like Chef or Puppet.

    This tools provide a framework that puts up a layer of abstraction between the sysadmin and the system itself, and they do it by giving the administrator an API where he can code his needs. There's a real need to think as a developer in order to be able to do this, so in the long term there must also be some kind of transformation of the Sysadmin mentality towards the Developer one, just as my job is to take the road on the other way.

    I haven't had any experience yet with those tools, but from what I read, there's more to them of programming language than of the old configuration files, so they should be treated the same way we treat we treat our source code: with repositories and versioning systems. And they are a must now as the infrastructure keeps on growing and growing, and the team is overwhelmed with all kind of incidences and troubles that arise on an everyday basis. We need to see the big picture and manage it accordingly.

    In the end, the line between our worlds is getting blurried, and that implies that there'll be more learning to do and communication skills to shape up. But this ambassador stuff not only applies in this kind of scenarios between two teams that do different kind of work. It's a must whenever there are groups of people that need to work together and there's a big gap between, be that 1000 kmts, or just that they work on different perspectives of the same problem. We must improve our communication skills, precisely because we don't want to, and have always been more comfortable dealing with a computer than with a human being.

    I'll be blogging about my experiences this year on this subject, but also on other stuff... at random, but always about IT, so I stay on topic with the name of the blog.

    Hope you learned something from reading this! :-)
    Related Posts with Thumbnails