CEO Character Traits

Tags

CEO, Citrix, Corner Office, Interview, Mark Templeton, Paul Maritz, The New York Times, VMware

As I begin to think about my future in IT and all the possibilities of where I will end up down the road as I travel and work my way through the industry, I cannot help but think about one day having the possibility to lead a group in a corporate setting. It may be a small group, or over time it could turn into a larger group. I decided to read some interviews that the New York Times have done along with CEOs and executives of companies about what they feel a leader does, or what they did to be picked up as a company’s executive.

The first interview I read was titled “Does your team have four essential types?” by Paul Maritz. In this interview the interviewer asks him to describe lessons he has learned to become the leader that he is today. Paul Maritz is the CEO of the software firm, VMware a huge contributor for online cloud computing and virtualization of computers and servers in the enterprise industry. He makes a point about the more people you are in charge of the less in touch with your employees you are. As he started out his first leadership role, he was in charge of 13 people, and now he leads over 10,000 people. With the bigger group, it makes it hard to get that personalization he used to have with his employees. I can see why it is such an issue to be personal with people who you are the boss of, especially when the scale of employees to executives is in the thousands of employees range. If I were to make it to the level of CEO or executive, I would try to make my job as personal as I possibly could. I think personalizing your relationship with co-workers, would make a world of difference, it could also be used as a good morale booster.

Another article I read was titled, “Paint by numbers or Connect the Dots” which was an interview with Mark Templeton, who is the CEO of Citrix Systems, who specializes in cloud computing and networking technologies. The point to me that was most interesting was that Mark never really wanted to be a CEO; he did not like the idea of having to be responsible for people getting fired from work while it was under his control. He points out that even though he never wanted to be picked as the companies CEO, over time he realized it was something he could enjoy doing. He noted that hard work and determination on his behalf helped him to be selected for the job of CEO. Mark believes in being vigilante and paying close attention to detail, and I think he has the right idea to be a stand out in any situation you’re in, in life.

Starting off small and taking it one step at a time is the best way to go about your working career. Even though thinking being a CEO or high up executive could be out of your reach as of now doing the hard work and showing your passion or dedication for a company could help you in the long run and enable you to move all the way up to the ranks of CEO depending on those factors will help you move up to be very successful in any career you decide to go with. As a young technology student just starting out I am going to take what I read from these two articles and make sure ZI apply them to my career in IT.

FOSS projects

Tags

Contributors, FLOSS, FOSS, Mifos, Ohloh, Open source, Open source projects, Technology, VUFind

Today I’m going to take a look into Free and Open Source Software projects, and analyze two different projects that are currently open and being worked on in the IT industry field. The two projects are VUFind

and Mifos. VUFind is an open source library search browser that allows someone to look through catalog records, cached journal entries, digital library items, institutional repository’s, and many more items. Since it is open source, you can modify it and add more modules to it, allowing you to extend the resources you’re looking through. Mifos is a micro-financing company that is into distribution of loans into all different areas of the world, most are in low income areas. Here they are able to give loans of small amounts such as $40 to allow them to open up and grow their business with their help starting out. Using the website Ohloh, I was able to analyze both projects and gather some basic information about the two open source projects. I found the VUFind is a rather small project in comparison to Mifos; VUFind has about 22 contributors working on about 177,763 lines of code throughout the project. Mifos has 147 contributors working with about 2,644,987 lines of code. On both projects there is the ability to help out and become contributors with the projects. VUFind takes a little more hunting around to find where you can go to get involved with the project, where Mifos gives you a link to follow right in the center of the home page that allows you to get started. Some tools I found that developers utilize to communicate on the VUFind website is developers call, conferences and presentations to keep contributors up to date with information. While Mifos uses mailing lists, live chat IRC using the #mifos as their channel name. They also use screen sharing, as well as Skype and drop box for information sharing. VUFind also provides a list of documents for installation as well as for modification. To find out what issues are being worked on and are open you need to do a little hunting around to find what you are looking for. Under core developers there is a list of open items provided. For VUFind there are about 10 open items currently being worked on, they are set up in a grid pattern where there is a good amount of information provided about the open jobs. Mifos is set up a little differently, their documentation is grouped together and a little easier to find. As well, there issues and bugs are located in another section grouped together. Mifos has about triple the amount of open items compared to VUFind and they are listed in rows detailing what their status is and who is assigned to it and who it is to report to.

VUFind and Mifos both seem like quality projects for beginners to work on. They are both rather small in size, I think Mifos is probably a better project for a beginner because the site is laid out better, everything is easy to find and there are a lot more open jobs for you to pick up and start to work on. It really depends on what you’re into doing though. If you want to help people in other countries reach goals of owning their own business, or if you would like to work on a local project where you may be able to meet with a team of workers that would be entirely up to you to decide. Overall, these projects are both free to work on and there is no obligation to anyone who signs up to be a contributor.

IRC – a “new” collaboration tool

Tags

Collaboration, Freenode, internet relay chat, IRC, Linux, Open source, Ubuntu

IRC, also known as Internet Relay Chat is an older method and way of collaboration it was created in 1988 with the idea of allowing people to share their thoughts openly with one another. I found this to be a very interesting concept, as many people are now working in remote locations and they don’t always have their groups or teams around them to talk about current projects that are being worked on.

I decided to take a look into what goes on inside a typical IRC conversation, so I went onto Freenodes web chat site. This allowed me to sit in on conversations about specific interest topics. The topic I chose to follow was about Ubuntu, I created a nickname titled Ubuntu_1. This name sounded fitting for joining a conversation about Ubuntu. After my nickname was created I then joined the Ubuntu chat by entering #Ubuntu into the text box on the Freenode interface screen. After the chat room loaded I began to observe the environment and the conversations that were being carried on.

I started observing the Ubuntu IRC channel at 4:38 p.m. on Thursday November 15^th and observed the channel till 5:53 p.m. During my time of observing the channel, I noticed there was an enormous amount of people that were logged into the channel as well. I also noticed a few people with a plain channel name such as the one I had, this made me feel like I wasn’t the only one just sitting in on the conversation. Over the first 20 minutes or so, I noticed that there were a lot more people joining and leaving with minimal conversation going on. However, there were a few small conversations for me to follow amongst all the traffic of people joining and leaving the channel.

One conversation consisted of a main contributor who seemed to have a depth of knowledge in the field of converting audio signals from PC coding into Ubuntu coding, and someone inquiring help with this type of conversion. Another conversation was about patching updates in Ubuntu, I think I caught the tail end of this conversation as it seemed to have wrapped up a few minutes after I joined the channel.

Over the course of the hour while observing what was going on within the Ubuntu channel I noticed there was a good amount of questions being put out on the discussion board and if there was anyone watching with some sort of expertise they would step up and answer the questions that were being asked. I think this is a great tool for someone, or a group, that is trying to gather information about a specific topic, or putting information out on a channel could help other project teams within the IT industry, not just in Ubuntu but any company willing to use open source collaboration tools to gain information a lot quicker.

Quality Requirements

Tags

Karl E. Weigers, Process Impact, Requirements, Requirements designer, Software Requirements Specifiction, SRS, Technology

The article Writing Quality Requirements was written by Karl E. Weigers, who is a consultant at the company Process Impact. The article starts off showing an example of how poorly written requirements documents can lead to confusion and rework for the requirement writers if they don’t know how to write quality and clear statements. Weigers explains the characteristics of a quality requirement statement, which are to be correct, feasible, necessary, and prioritized. He also explains how to write a quality requirement specification, by keeping the requirements complete, consistent, modifiable, and traceable.

Out of all the characteristics Weigers talks about throughout his article, I felt that being complete was really the most important characteristic he talked about. For me, being thorough and complete is something I attempt to do in everything I do. After reading this article, I can understand why it is important within a requirements specification as well. To write a good requirement specification, no information should be missing, to help you do this, focus on what the user would do rather than on specific system functions, doing this will allow you to cover all possible requirements instead of overlooking them. Another point that is important while going through writing the requirements, when you do not have the information you need mark it as To Be Determined or TBD so you know to come back to it when you have the information that is needed before you proceed with construction.

I think this is the most important part of requirements specification building, because completeness is key when writing requirements, you want to be able to produce a requirement that is easy to read, understand, and full of the information that is needed.  As a professional I can see why this type of attention to detail is so important. Completeness is something you can use not only in writing requirements, but also in many other aspects of an IT professional career, from simple emails to writing intricate pieces of code. You want to portray yourself as a professional, and making sure everything you do is complete before you hand it off is very important.

Weigers, Karl “Writing Quality Requirements.” http://www.processimpact.com/articles/qualreqs.html