stakeholders

Architecture – Its all about ...

In this three parts article, I will introduce the concept of how the success of an architecture depends on the relation with the Stakeholders. Par...

lemmings, culture, dummies, life, success

The culture of dummies

There is a kind of a popular trend saying for you to win you should lose a lot of times, that all the fails somehow lead you to success. Really? Do yo...

gambit in argumentation and concession

Argumentation tools – Concess...

In a period of my life I worked for a big company, my job was at customers site doing some advanced product troubleshooting and configuration. Some cu...

Managing

lemmings, culture, dummies, life, success

The culture of dummies

There is a kind of a popular trend saying for you to win you should lose a lot of times, that all the fails somehow lead you to success. Rea...

Architecture & Developing

Gamification

MC900439598

Gamification in the family

One of these days I went out to lunch with my family. My daughter does not like to eat, it is complicated to sit an entire meal just to eat....

Social Marketing & SEO

future mega trends

50 Powerful Statistics About Tech Mega Trends Affecting Every Business

Great Slideshare presentation about present and future mega trends. Contains very useful statistics if you want to understand the future of...

Others

MP900049738

The twin paradox

One of the most fascinating things to me are the paradoxes. Its something that’s true but its false, its something that’s right but it...

Architecture – Its all about Stakeholders – Part II

<">viewpoints views

In the previous post, we have seen the importance of the stakeholders in the development of an architecture. Because stakeholders aren’t all fluent in technical language we must find a common ground to communicate.

Views and Viewpoints

An architecture is a very complex system. If you try to create one big diagram to show all the elements of the architecture and its relations, it will be a big document, only useful for the ego boost of the architect. The stakeholders don’t need do know everything about the architecture, just the parts with interest to them. For instance, users of a bank application, they are more concerned with the user interface, performance, available information and in many cases with security. They don’t care how the database server exists or how is it connected with web services, integration tiers, etc. The architect should create a set of views of the system, for each set of concerns of the stakeholders. To this set of views, we call it Viewpoint, a part of the architecture. One view always belongs to a Viewpoint, and a Viewpoint can have multiple views. Examples of viewpoints are information, development, concurrency, functional, deployment and so on. We can observe there is a set of stakeholders with an interest in each of these viewpoints.

Let’s see an example. When building a house, you don’t want a unique blueprint with every element of the house, the exterior, the interior, the materials, the flow of the light, water, electricity, streets around, halls, etc. You expect to have several views of the house. You will have some views for the exterior like front view, side view on the afternoon, or if you want to see how the interior will look, you have a view of the living room, another for the kitchen, rooms, toilets, and so on. Other concerns could be how you circulate inside the house, and you expect to see views from the entrance, hall, the accesses between rooms and living room and toilets, etc.
The views about the accesses are a viewpoint related to the circulation of people inside the house. The other views are more related to the context, how the house is presented from outside, for instance.
The house is the same, but the views are different, and directed to specific concerns and different persons (stakeholders). When the architect talks to you, shows how the house will be at the end, but when he talks to the company that builds the house, the concerns will be completely different, they are interested in exact measures, materials, ground, time. These diagrams will have information you don’t care because they are too technical.

Again, the stakeholders are the fundamental piece of the architecture, besides the project being developed for them, even the management activities are around them and depend on them. Your strategy as an architect should have the stakeholders as the main actor on the scene, and all the tactics should include them in every decision.

Now, we know how to talk with stakeholders during the development process of the architecture, it is time to include in these views quality attributes, or sometimes called cross-cutting concerns, like security, performance, cache, etc. We call them perspectives (it is not a consensual term in the architecture community, but the main idea exists and is shared). We will see more about this in Part III of this article.

Architecture – Its all about Stakeholders – Part I

stakeholders

In this three parts article, I will introduce the concept of how the success of an architecture depends on the relation with the Stakeholders. Part I will describe the influence of Stakeholders in the success of an architecture, then Part II e III will describe how to communicate and create a common ground between the architect and the Stakeholders.

Stakeholders

A Stakeholder is: “individual, team, organization, or classes thereof, having an interest in a system” (ISO/IEC 42010).

From the definition, we can observe something all Stakeholders have”…interest in a system”. This interest can be from a perspective of the customer who is buying the system and follows closely all the steps in the creation of the product, until someone, anonymous, who just uses it, like a person or system buying a ticket to a game. So, the objective of an architect should be building a system maximizing the satisfaction of all Stakeholders.

An architecture is, therefore, built around the Stakeholders needs. The majority of the Stakeholders are people, so the human variable enters in scene very strongly in the construction of the system. Things like negotiation, agreements, meetings, communication, expectations management, are skills the architect should dominate.

An architect is not a Project Manager but should work very closely with him. The success of a project from the Project Manager perspective is the satisfaction of the Stakeholders, as so for the architect. That’s the reason, for some many times we see the architect as a project manager too.

The process of developing an architecture evolves thinking, technical skills and a lot of communication with Stakeholders. The Stakeholders, usually are persons who don’t understand technicalities. It is necessary, for the architect, to create a way to expose his/her views to them, to create a common language of understanding. For that, we need Views and ViewPoints, something I will talk about on the Part II of this article.

The culture of dummies

lemingThere is a kind of a popular trend saying for you to win you should lose a lot of times, that all the fails somehow lead you to success. Really? Do you fail to win? I love paradoxes, really, I love them, but I don’t agree with this. It’s like saying if you are in a dark place, you should go against the walls until you find the exit. With luck, you can find the doors, hitting the walls over and over again. This is the plan? I don’t think it is a good plan, a very hurtful one to follow. it makes me remember a game I played when I was young, “Lemmings”, these little creatures, they moved to all kind of obstacles until someone (the player) could guide them to the exit door.

It is normal to “fail” a few times, but only if it is a part of a strategic plan, where the outcome of some tactics didn’t reward us as we though they could, but this is not failing, it is fighting against the uncertainty. Failing is bad, makes us wish to quit the endeavor. But having a mindset about victory and became very upset because something didn’t go as we wanted, makes us trying to improve our strategy, without losing our focus on the goal.

Maybe this is just about semantics, but makes all the difference by saying someone should lose to win, against the mindset that he just have to improve until he wins. In the first case we are saying you are a loser but maybe with luck you can get it, on the second, we are saying, you have the right to fight for what you want, but revise your strategy and the tactics as necessary while you are using them. You are making the person feel he/she is already there, but should adapt better to the environment to keep going.

The true of all of this, is that a lot of people will really fail, there are no space for all the people to be the owners of big companies, managers, leaders or references in their fields. In the end, only some of them will reach the success. Some people will say they are the ones who never quitted (“besides the falls along the way”), I will admit that some of the credit was due to the persistence (of falling and get up again), but the luck, time, the right people at the right time, context, environment, friends, family, money, they had a lot of saying in the final outcome.

I am not trying to steal your dreams, or steal the motivation that leads your life, but I think each people just have to try to find what their natural qualities are, where they can be great, and try, in that space, to fight to be great, not hitting walls until finding the success but enjoying the ride of overcoming the obstacles of improvement, again, not the walls, just obstacles, where your natural skills can help you to overcome them, and the victory is almost certain.

First, find yourself, then find your happiness.

Argumentation tools – Concession

In a period of my life I worked for a big company, my job was at customers site doing some advanced product troubleshooting and configuration. Some customer employees always had this predisposition to gently degrading the image of the company products, referring the quantity and severity of bugs in them. At first I was upset by this, and I tried to defend with all arguments I knew, however, my manager told me to not do it that way. He told me to accept the critic from the customer, and telling them that they were right. Really? What? He said to me: First, the comments are true, you cannot say it is false, its a fact, if you defend this you are creating breaches in your character reputation (more about character in a future post). Second, after telling them this, they don’t have any more arguments to say, it is out of the way, now you could talk about the qualities of the product when compared with the other vendors products. You could focus your argument in the advantages over other products and why the customer chose our products and not the others. So, you conceded, for a while, the “advantage” to your audience, but then you get the upper hand, because the “bad quality” issue was already resolved and there is nothing more to talk about it! A kind of jujitsu in the language! It is like a sports game, you accept an attack from the other team just to open their defense, and then counter-attack.

You can apply this kind of tool to anything in your life. Usually a good salesman never say no to a customer, he hears the customer, accept his arguments (for a while) and then he counter-attacks with his sales tools, and it works quite well! “Yes, the car is expensive, but have you observed all you can get with that price?”

Another angle is, when someone is trying to win some kind of argumentation against you, and you know that its just something that he/she doesn’t really know well, just keep hearing and let them talk, concede the “advantage”, for a while, and you will see how they hang themselves in their own argument.
By curiosity, this tool was used by Gandhi (at least in the movie) when he cites the Christian Bible “If someone forces you to go one mile, go with him two miles.” (the argument is more extensive, but the idea is the same)

In chess, we call this a gambit, sacrificing something for future advantage.

Being a better architect – Developing for several markets

apple_microsoft_android

An architect should always be ready to increase is knowledge considering the actual market tendencies, because it is his job to present solutions to his customers, which are always considering solutions to decrease their costs using IT. With this vision, as an architect I am always pushing myself with new challenges and learning more and more. Since the beginning of the current year I have bought books, in subjects like IT, social behavior, strategy and soccer. I like to develop myself in different subjects in order to acquire other perspectives and expand my way of thinking. I believe it increases my creativity and give me thinking tools to handle challenging projects.

Two weeks ago, I decided to develop an application and publish it in different App Stores, I want to know the software production lifecycle in all these markets:

  • Android Play Store
  • Apple Store
  • Google Chrome Extension
  • Firefox Add On
  • Windows Metro
  • Windows Phone
  • (Maybe) Android Watch
  • (Maybe) Apple iWatch

The idea was to learn how these markets/stores work. What is to develop an application in different languages, different technologies and different paradigms.

After some analysis, I decided not to use popular developing frameworks, where your code once and they will produce code for the several markets. I wanted to use the native environment/language, Developing using HTML5/JavaScript is about design, not about acquiring some know how in each environment. I wanted to use the knowledge I already had in languages like Java, C#, JavaScript and HTML, XAML and little bit of Objective C, and maybe learn the new Swift Apple language.

At the end, my expectations are to be happy with the result. Knowing I have learned how to develop to the most important markets and be a better technical team leader, architect and have increased my know how to manage these kind of projects.

The process

I already started with this professional project/program. I have used a three step approach:

First, what kind of application to develop.

I have a lot of ideas for apps, so I chose one where I could develop more than one screen, should have some utility and a basis for increments and upgrades. For version 1.0, I just wanted to release it, not earning money or using traffic or Ads, just be in the market to get the know how about planning, developing and publishing it.

Second, decide the target markets/platforms.

I chose the six platforms/markets above, I believed they were the big ones.

Chrome and Firefox extensions are in the list to improve the knowledge in the browser arena, I think it is important for an architect having a little bit of knowledge in the user applications/tools we use daily. It helps understand the end user needs.

The “watch” items, lets see if I have time and energy. The issue with developing for several markets, it’s the management, not the developing.

Third, the order of development.

I started with the Chrome Extension, after researching how to develop one. It is simple, just HTML, JavaScript, and a manifest. Some screenshots and marketing images, and it is done. A good basis of know how for the future developments.

Next steps

I am now developing the windows version for Windows Phone and Windows Metro. I have already developed the Android App and Chrome Extension. You can follow all these apps on my blog at “Give Me Numbers – Apps”.

In future posts I will describe the process I have followed for each app. Including, at the end, a comparison between all technologies from the perspective of a developer/publisher and manager

In doubt, you almost certainly start to look around you

groups

We don’t realize how powerful some unconscious things we do in our life are. One of them is our decision process. How many times we don’t know what to do when taking some kind of decision and we just start to look around us, trying to find similar examples in other people, histories, and somehow unconscious, taking examples from books and movies (be careful with what you feed your memory, but that’s another subject).

This behavior is common to all people when deciding in a non-critical thinking mode. It is a very powerful weapon in a lot of different business contexts, and is used for persuasion, negotiation, and social contexts. Let’s see some examples:

- If you hear in a commercial situation that you probably must wait to buy something, most of times is not true, it is just to give you the idea that a lot of other people is buying the product, and the probability of influencing your decision is above average. Why? You are not sure about to buy it or not, but a lot of people is buying or doing it, so it should be a good thing, you think. It cannot be the case that everybody is wrong (well, sometimes they are)

- The kids. Almost every one of them, they take decisions considering what the others have. I have a daughter, I was a kid once, and I know it by experience. The kids don’t have enough data to create a reliable decision process, they are still building it. For the adults, the trick is to put them as “kids” or “zombies” first, question their decision process and then let this “doubt” arise.

- Announcing a product some weeks ahead and saying there is a big waiting queue. A variation of the first example above.

- “The response may take some time due to the increasing number of orders made”. You can see this in TV sales shows, some internet e-commerce web sites, etc… You will really feel confident about buying the product, after all, everybody is buying it!

- If you are an outsourcing company, you can try to explore this persuasion trick by “dropping” the idea to a customer in doubt about some expensive specialized resources that you are having a lot of requests from other customers for them. (I have observed this technique and other variants is some companies, I have worked with, with some success)

- If you are someone looking for a job, you can use it too. Don’t look too desperate or already available, try to drop the idea of other companies interested in you, but let the door open saying something that you value in the company you are trying to work with. (I know, it is not so simple, but it is a tool to use)

There is a lot to explore about this little persuasion trick, but my intention was just to let you a tool hoping you can avoid “bad decisions” and hoping too you can use it in your business. Hope it helps you!

A simple great argumentation tool to improve your work and professional environment

argument

When I finish my computer science course in university, after some time working in big companies, I realized that I was somehow prepared for the technical challenges, but I didn’t know how to work  socially in the companies. One thing is to know how doing the technical work, another is about working with people. And the issues, are always about people, how to influence, persuade, office games, power control games, silence wars, etc.. It’s a very different role than the technical one, but it is the one that makes you grow in the company. Even if you are a tech lover, you must get soft skills.

I am not trying to give a pessimistic vision of the work, actually I am working in a quite good work environment, but this is how these things are, because people like to grow in the company, they like to feel safe, but for that, they start a  “fight” with their colleagues, they try to know their intentions and act accordingly considering their own intentions (sometimes it’s not a conscious intention, it is just us: humans!). You can observe these moves around you if you try.

In this post I just want to give you a small piece of soft skills, improving your way of managing your verbal and written argumentation, in a way that will improve the quality of your arguments, in a constructive way, so the work and personal environment around you will be better. And when people feel good around you, it’s a good thing for you in every way.

There are a lot of argumentation tools (really a lot), but today I only want to write about one of my favorites: The Tense.

When you are in a conversation, or just hearing someone on a TV show or movie, the speech is always in one of 3 tenses:

–          Past

–          Present

–          Future

Obvious! But it tells you a lot, even without knowing what is being said! (It is a kind of nonverbal language in the verbal language)

Whey are they important?

Past Tense

A conversation in the past tense is always about blaming, forensic analysis, reporting things, telling about something that’s happened. You can observe this in movies or TV shows about criminals, police, investigation, or in divorce talks. Most of the argumentation, it’s about trying to find the guilty, blaming something, trying to conclude that something or someone did something, right or wrong, analyzing what has been done or happened, is was good or not,  it was finished or not.

When 2 people are arguing badly, you hear a lot about the past! If you are/were in a relationship you probably (very high) had conversations in this tense! “You did that! Not it was you! I was just”… And go on and on and on ;)

This kind of tense it is not constructive, avoid it. (Of course, this is not a rule, sometimes you have to talk in this tense, for instance, every day in my daily scrum meeting I have to talk about what I have done in the previous day, but not in an discussion about something to be cleared, where you want to be viewed as constructive)

NOTE: In the past tense you can win an argument, but: You don’t use argumentation to win but to persuade. You can win an argument, but you could lose your relationship, friend, reputation, job, etc. Try to persuade, lead someone to do what you want, and not doing it by force. You can win by force, but in the end you will lose. Be wise.

Present Tense

A conversation in the present tense doesn’t go anywhere, it is when you are talking about what is right or wrong, giving opinions or stating a fact. It tends to finish conversations, because you are not going to anywhere in the conversation, it is not open to discussion, it is just about facts. It is very used as a politician’s tool, to say the obvious but not giving any solution. Observe the people that talks in the present tense, if you analysis the content of their discourse, they will not present a solution to things, just stating facts and issues (usually coming from the past), however, during the discourse it gives the illusion to the audience they are talking about solutions (which is in the future tense).

You want to use this tense to stating facts about what are you doing, but try to add a future tense (see below) to improve the quality of your speech. Something like, I am doing this and will improve the quality of the final product, or build a good relationship with the customer, etc.

NOTE: However, it can be a great tool when used to “create” an extremely bad situation and propose some relief out of that situation to the audience by just using a transition from present to the future tense – it is used as a persuasive tool. Ex:“The water is very polluted, very bad for our children and our health, but there is a solution, with this water purifier machine, your body will be healthy from now on…” See: Present/Past (bad)->Future (good)! It works great for salesmen! You are welcome for the tip ;)

 

Future Tense

You should always try to argue in this tense. When you talk in the future, you bring options, choices, hope. You bring people into conversation, you make people think. You are showing that you are interested in the progress of your company, you are trying to value their future, you are really hearing about ideas because you ask things about it, you promote choices and hope, ignoring possible “blames” of the past, because there is nothing to do about it. You are the solution person, not the troubled person. You talk about growing, not guilty. You talk about future, not past.

You can observe this type of discourse in the people who are winners. “I am doing my best and I will keep working to improve myself”, “Yes, we can”, “I will work everyday to be the best…”, “Things will change, we will make the change together” – There is always a sense of future and hope in the messages. You can try to improve your discourse during the day be changing a little bit at a time.

NOTE: Be careful, however, with too much future, because the future aren’t facts, just choices, hope and desire, be careful if someone is always talking in the future but without any real solutions. In this case, ask how.

 Final notes

You can construct an argument considering transitions between the past, present and tenses, but always try to start from the past to the future, like: “We were in a bad situation without knowing what to do, now we are fighting it and with effort and your help, we can do this and thatwhat ideas can you propose?”. Probably you heard similar discourses with this pattern in the past and they seemed great!

This is not a formula and not by any means a complete course in the subject, there are other considerations in the points above, but I want to show how simple is to improve the quality of an environment only considering the tense in a conversation.

TIP: Don’t forget, you can use this knowledge as an argumentation tool to improve your soft skills, but you could and should use it too, to understand how and why someone is talking about something.

Hadoop in 5 minutes for beginners

01_Hadoop_full

So, you don’t know nothing about Hadoop and want to have just a simple picture of it? This post its for you!

So, you have a lot of data (TBs or more), spread all over the place sometimes structured sometimes not structured and you want to query these data. You are thinking by now, I will need a lot of power to query data “organized” like this. Yes, you need, you need Hadoop and all the Big Data techs around it.

What is Hadoop?

Wikipedia has this interesting fact: “Hadoop was created by Doug Cutting and Mike Cafarella in 2005. Cutting, who was working at Yahoo! at the time,[6] named it after his son’s toy elephant

As Apache states “The Apache Hadoop software library is a framework that allows for the distributed processing of large data sets across clusters of computers using simple programming models. It is designed to scale up from single servers to thousands of machines, each offering local computation and storage.”

What?

You have a system (that can be logically organized in  cluster >> racks >> nodes) with several components to handle distributed processing and files between a lot of machines. You have, between others, HDFS, a distributed file system, and an implementation of the Map Reduce pattern.

HDFS is a file system that works over all machines in the system, but you only see it as one file system, because is is distributed over several machines. How about my local file system? Still exists, the HDFS works over your local file system. (ex: “hadoop fs –ls“ a command in your local file system to runs a “ls” in the HDFS)

The MapReduce is a pattern (see here) to process large data sets (ok, you can use for small data sets too, because it’s a pattern, not a product, and you can implement it in any language you want with very little code). Hadoop uses this pattern to run your queries over the data. (It uses tasks, jobs, etc. for your requests, but always using this pattern in the execution)

So, by now you have a Distributed File System and an engine of tasks and jobs to run applications implemented using the Map Reduce pattern. Yes you are right.

So, how can I query all this data? Well, you can implement applications in any language, usually Java where you control the tasks, jobs, the Map and Reduce functions for the Map Reduce pattern, etc. A lot of work to do. Well, you can use other techs of Big Data that will help you to implement these queries and handle operations over your data, these are some of the languages(platforms) you can use and simplify your programmers life:

PIG (yes, it is this name) – example extracted from Apache. Loading and saving data…

/* id.pig */

A = load 'passwd' using PigStorage(':');  -- load the passwd file 
B = foreach A generate $0 as id;  -- extract the user IDs 
store B into ‘id.out’;  -- write the results to a file name id.out

Hive (“The Apache Hive™ data warehouse software facilitates querying and managing large datasets residing in distributed storage.”) – some examples from Apache? More SQL like but it is not SQL as we know it.

CREATE TABLE invites (foo INT, bar STRING) PARTITIONED BY (ds STRING);
LOAD DATA LOCAL INPATH './examples/files/kv1.txt' OVERWRITE INTO TABLE pokes;

Jaql – A JSON Language used now by IBM BigInsights. An example from the Project Page

//
// Bind to variable
$log  = read(hdfs(“log”));
$user = read(hdfs(“user”));

//
// Query 1: filter and transform
$log
-> filter $.from == 101
-> transform { mandatory: $.msg };

// result …
[
{
“mandatory”: “Hello, world!”
}
]

Others –The are other projects and languages but for a introduction I think these 3 shows different ways of querying the data.

The overall picture

You install Hadoop, you will have an HDFS and Map Reduce engine. For querying the data you can develop yourself code or you can use languages like (PIG, HIVE, JAQL, …) to handle all the Map Reduce stuff behind the scenes. Yes, all the querying from these languages are always translated to tasks which run Map Reduce patterns, you don’t have to worry about the Map Reduce implementation, that is why its fast and your processing and data could be spread over thousands of machines!

It is time to respect your professional colleagues

It is time to respect your professional colleague

I have been in the software industry for some years and I always see the same behavior over and over, lack of respect to professional colleagues, not the ones that are present in every day but the ones that are not there to defend themselves, who have developed the current version of the software and now are the excuse to the errors, bugs and problems that arise in the new team.

It is always the same behavior pattern:

A new team (or new developers) arrive to a company to continue the development of a software project, because there were some developers who changed their job and “accepted a new challenge” (well, they have gone to a better place! At least they hope!)

The new developers started to code and continue the previous work

They have difficulties, as we all have when we work in another’s code, because coding is somehow a creative process and each person has his own style, even when following code guidelines.

They want to impress the new bosses, so they will not want to show any weaknesses in their image

So, they blame the persons that aren’t there anymore

I will not say that the new developers aren’t right, but it is always the same path of behavior, and let me tell you, most of the times, and I am sure you will agree with me, the things aren’t right because the development context forced them to develop with those problems, like lack of time, bad management, no requirements, scope undefined, and so on. They have done the best with the tools and information they had at the time, and probably they left the project, not because they were bad professionals but because they get tired of the bad conditions, and so they “have accepted a new challenge”.

There are good developers and persons whose developing shouldn’t be included in their CV, and others who born to be developers: But there are great projects developed by bad developers and bad projects developed by skilled developers.

In the current days people rotate a lot between companies, so remember that after you leave the project the next guy will say the same thing about your work.

You shall respect your professional colleague as yourself.

The Startup developers syndrome

MH900422589When I was studding in college there were these projects that toke me a lot of nights sleep just to deliver them before the deadline. They were database, programming and network projects, the usual preparation/education for the future job or Startup company.

After finishing the college I started to work for IT Companies, and let me tell you I was lucky because I didn’t suffer from “The syndrome of the Startup”. What is this syndrome?

Let me start, first describe how I have observed the IT world.

Along these years since I left school I started to see, that most companies pay for 8 hour/day job but they “ask” for more than this to their developers/workers without any compensation for that, like if it was an obligation. Why?

  • They do not work the 8 hours in a fair way?
  • They deserve less than a car mechanic or a mason? Because these guys if they work 12 hours you must pay them those hours, or your car will not get out from from the repair shop!
  • They don’t deserve the salary?

Of course, the reasons are most of the time others, and I can enumerate some of them:

  • The project manager probably is incompetent, because it couldn’t develop a project plan with the right resources, time and cost, so he hides it with more hours in the project.
  • The sales people just sold a project without questioning the experts to give them the right numbers for resources, time, etc..
  • The analyst team did not collect correctly the requirements so new ones started to pop as popcorns.
  • The manager just wants to improve his revenue in his Excel sheet so his commission at the end of the year can get him to take holidays in a better place, or buy a new car, or get a promotion!
  • “There are a lot of people looking for job these days, if they don’t like it, we can get other’s that are available to work more hours.”

But, for me, the main reason its because the IT workers accept this! Why?

  • Some of them they just think its normal.
    • Why is it normal to be paid for 8 hours and work 10/12 a day? Besides the low quality of life your salary just decreased between 25-50%!
  • They have afraid that if they don’t work these extra hours the managers will not promote them or they will start to talk negatively about them to other managers.
    • First, you will be promoted by your technical and soft skills. If you are very good in these skills, even if you work just the regular 8 hours, against some cultural trends in your company, the company will promote you anyway, because you are good and bring money to the company. Its not the time, it’s the quality and ROI.
    • Second, I know there are companies that talk negatively about the employees who don’t work the hours they expect, they say “they aren’t working as a team”. Well, there is a fallacy here, because if you work more hours and your salary it’s the same, the managers they get a raise because their revenue raises, but the only think you can get it’s a small raise in you salary, so if really you belong to a team everybody should win right?
    • Third, if the company have customers where to put you working, or projects to develop, that fits your qualities you will have work even working only 8 hours. If the company doesn’t have a place for you, you return to the office and after 2-3 months you will be invited to leave, event after you work more than the 8 hours/day.

Other reason that I see a lot, and that’s why I started this post talking about the college is that most developers they have his mind context to start a Startup company, and they work for IT companies with this thought that they are building something for them, like if they will get a reward after the project is finished. But it is so wrong, they haven’t build anything for them, just acquired experience. If in that time they have applied their knowledge to build a project for them then they have acquired not only developer experience but sales, marketing, leadership, entrepreneurship and managing experience, and they have done a great step in their professional life’s. Even if their project/startup didn’t work they have now experience to reach a higher role, like a team leader or manager?

I call this the “The Startup developers syndrome”, because most developers work with a mind set of a Startup but they are working for others where the only reward will be the salary.

NOTE: I am not trying to say the companies are bad and workers explored. There are bad companies? Yes! There are bad workers? Yes! There are great companies? Of course, As I said above, I had the luck to work in some of them! There are workers who just want a career, a job role, and they work extra hours to show to their bosses their dedication expecting a promotion. Sometimes workers need to miss a day or other just to handle private things and lot of companies they don’t discount from their salaries this days or hours, so its fair that the worker offer extra hours when the company need it, I think its very healthy for the relation between the company and the worker. What I think it’s not fair is the company, systematically creating the idea that working always more than 8 hours its normal and an “obligation”.

Bad Behavior has blocked 740 access attempts in the last 7 days.

Hyper Smash