10 early signs that someone will make a great leader

Many performance reviews have ended with a conversation regarding advancement opportunities for employees and what they need to do to get to the next level. Most of them think that to advance, they need to become a manager. So naturally I ask them the age-old question “What’s the difference between a manger and a leader?” It usually elicits an awkward pause in the conversation while they try to come up with something profound and insightful, but it ultimately ends up flat.

I tend to look forward to the rest of the conversation because I don’t believe that there is only one answer to the question. Each of us has our own answer, and it’s usually derived from our leadership story, which gets developed over time based on our backgrounds and experiences. Someone’s vision of what makes a leader is one of the keys to how they will act and grow over the years and will usually be an influencing factor in their success. Young leaders in every organization take their cues from those around them by the actions they observe. Realizing this is important for all organizations to ensure they are identifying and providing appropriate role models.

#1: Listening and communicating effectively

Have you ever worked with a person who always says yes but never delivers what you need? Many of us have felt the frustration of that scenario, so it’s exciting to work with somebody who takes the time to understand a problem while also asking the key questions to ensure that all expectations are met.

#2: Being energetic

Employees with energy tend to lift up the people around them. Leaders sometimes need to be able to boost a team when they are working on tough projects, and having this trait can make a big difference in the long run.

#3: Remaining calm under pressure

When big problems happen, teams look to their leaders for direction. When a leader isn’t available, who else do they turn to for guidance and decisions? Usually it’s the person who has kept his or her cool and has been trying to find a solution to the problem. Nobody wants to work with the guy who is yelling, “The sky is falling!” But they will be happy to work with somebody who can see the light at the end of the tunnel when nobody else can.

#4: Taking responsibility for their actions

We all make mistakes. Many of us know it way before our bosses find out. Leaders are always willing to admit to making a mistake when something doesn’t work out as they planned. Usually, they are also trying to learn from the problem to ensure it doesn’t happen again in the future.

#5: Acknowledging the contribution of others

How often do your team members celebrate each others’ successes? Since the business world can be pretty competitive, it’s difficult for us to see somebody else do well and not be concerned about how it affects us. Leaders learn early on that many of their achievements come on the heels of their team’s successes and the contributions of each individual. Understanding this and feeling comfortable with it early in their career is a powerful trait.

#6: Being comfortable outside their area of expertise

Developers may be good at solving problems with applications and hardware, but can they effectively gather user requirements? How about dealing with end users or managing a budget? As leaders mature, they realize that they are asked to be involved with projects and teams of all shapes and sizes. The ability to feel comfortable in a situation while not being the expert gets easier when they realize that they can always fall back on their leadership skills no matter what the topic. After all, they were asked to get involved because someone thought they would add value.

#7: Being willing to take risks

Do you have someone on your team who’s afraid of making a decision or taking any type of risk? Or maybe they aren’t afraid to make choices, but only when they’re confident that the risk factor is small. This will be a problem if they get into a leadership role. Taking calculated and educated risks are daily events in the world of management and leadership.

#8: Being able to convince others

Do you have somebody on your team whom people look up to? Or is there somebody the business likes to work with because that person makes them feel comfortable when discussing tech issues? Make sure you keep an eye out for those people. The ability to influence others and direct a project without actual authority is a great indicator that you have a solid leadership candidate on your team.

#9: Being comfortable reflecting on their strengths and weaknesses

Leaders always need to look forward and many times backward to try to avoid repeating the mistakes of the past. Most people like to get praise, but how do they deal with constructive criticism? Look for those who are comfortable taking time to reflect on their style and actions and how that influences those around them.

#10: Being able to adapt

Things are constantly changing in business today. Technical people who work best with a fixed roadmap will struggle in a role that has ever-changing priorities. Leaders need to the ability to adapt to their surroundings as well as to the needs of the company.

Remember that not everybody is ready (or willing) to be a leader. Plenty of techs are more than happy to stay involved in the nuts and bolts of a project or to just sit back and develop robust applications. But IT organizations need some type of leadership structure to help guide the department and to interface at different levels within the organization. While it’s not common to hear about senior technical managers being good organizational leaders, it does happen. The early identification of individuals who have some of the above-mentioned attributes allows current leadership to groom those people for the future — an important step in making a company effective and successful.

10 early signs that someone will make a great leader

Many performance reviews have ended with a conversation regarding advancement opportunities for employees and what they need to do to get to the next level. Most of them think that to advance, they need to become a manager. So naturally I ask them the age-old question “What’s the difference between a manger and a leader?” It usually elicits an awkward pause in the conversation while they try to come up with something profound and insightful, but it ultimately ends up flat.

I tend to look forward to the rest of the conversation because I don’t believe that there is only one answer to the question. Each of us has our own answer, and it’s usually derived from our leadership story, which gets developed over time based on our backgrounds and experiences. Someone’s vision of what makes a leader is one of the keys to how they will act and grow over the years and will usually be an influencing factor in their success. Young leaders in every organization take their cues from those around them by the actions they observe. Realizing this is important for all organizations to ensure they are identifying and providing appropriate role models.

#1: Listening and communicating effectively

Have you ever worked with a person who always says yes but never delivers what you need? Many of us have felt the frustration of that scenario, so it’s exciting to work with somebody who takes the time to understand a problem while also asking the key questions to ensure that all expectations are met.

#2: Being energetic

Employees with energy tend to lift up the people around them. Leaders sometimes need to be able to boost a team when they are working on tough projects, and having this trait can make a big difference in the long run.

#3: Remaining calm under pressure

When big problems happen, teams look to their leaders for direction. When a leader isn’t available, who else do they turn to for guidance and decisions? Usually it’s the person who has kept his or her cool and has been trying to find a solution to the problem. Nobody wants to work with the guy who is yelling, “The sky is falling!” But they will be happy to work with somebody who can see the light at the end of the tunnel when nobody else can.

#4: Taking responsibility for their actions

We all make mistakes. Many of us know it way before our bosses find out. Leaders are always willing to admit to making a mistake when something doesn’t work out as they planned. Usually, they are also trying to learn from the problem to ensure it doesn’t happen again in the future.

#5: Acknowledging the contribution of others

How often do your team members celebrate each others’ successes? Since the business world can be pretty competitive, it’s difficult for us to see somebody else do well and not be concerned about how it affects us. Leaders learn early on that many of their achievements come on the heels of their team’s successes and the contributions of each individual. Understanding this and feeling comfortable with it early in their career is a powerful trait.

#6: Being comfortable outside their area of expertise

Developers may be good at solving problems with applications and hardware, but can they effectively gather user requirements? How about dealing with end users or managing a budget? As leaders mature, they realize that they are asked to be involved with projects and teams of all shapes and sizes. The ability to feel comfortable in a situation while not being the expert gets easier when they realize that they can always fall back on their leadership skills no matter what the topic. After all, they were asked to get involved because someone thought they would add value.

#7: Being willing to take risks

Do you have someone on your team who’s afraid of making a decision or taking any type of risk? Or maybe they aren’t afraid to make choices, but only when they’re confident that the risk factor is small. This will be a problem if they get into a leadership role. Taking calculated and educated risks are daily events in the world of management and leadership.

#8: Being able to convince others

Do you have somebody on your team whom people look up to? Or is there somebody the business likes to work with because that person makes them feel comfortable when discussing tech issues? Make sure you keep an eye out for those people. The ability to influence others and direct a project without actual authority is a great indicator that you have a solid leadership candidate on your team.

#9: Being comfortable reflecting on their strengths and weaknesses

Leaders always need to look forward and many times backward to try to avoid repeating the mistakes of the past. Most people like to get praise, but how do they deal with constructive criticism? Look for those who are comfortable taking time to reflect on their style and actions and how that influences those around them.

#10: Being able to adapt

Things are constantly changing in business today. Technical people who work best with a fixed roadmap will struggle in a role that has ever-changing priorities. Leaders need to the ability to adapt to their surroundings as well as to the needs of the company.

Remember that not everybody is ready (or willing) to be a leader. Plenty of techs are more than happy to stay involved in the nuts and bolts of a project or to just sit back and develop robust applications. But IT organizations need some type of leadership structure to help guide the department and to interface at different levels within the organization. While it’s not common to hear about senior technical managers being good organizational leaders, it does happen. The early identification of individuals who have some of the above-mentioned attributes allows current leadership to groom those people for the future — an important step in making a company effective and successful.

Measuring Programmer Job Satisfaction

Are you satisfied with your job? Are you satisfied with where your career path is taking you? These are important questions, and I try to take time to think about this every 6 months or so. Its usually trivial to make a general statement rating job satisfaction: “Yeah I like my job.” or “My career is going nowhere.” But what factors influence programmer job satisfaction? How can hackers become more satisfied with what they do?

First lets break down the main indicators of job satisfaction, and look at how to measure satisfaction in each of those areas. In the next post in this mini-series I will write about ways to become more satisfied as a programmer.

Teamwork

According to Jeff Atwood, “The people you choose to work with are the most accurate predictor of job satisfaction I’ve ever found.” This rings true with me. Thinking back, during the times I was most motivated and happy with what I was doing, I was part of an excellent team of hackers. We worked well together. We bounced ideas off of each other. We were aware of each others strengths and weaknesses, and knew how to maximize the strengths while improving the weaknesses. We respected each others experience, knowledge, and all around hacker stardom. Well you get the idea…

Think of the best hackers you have ever worked with. Would they want to be on your team? If not, you are in trouble. If those hackers wouldn’t want to be on the team you are on now, its unlikely that your team will be able to attract other top notch hackers and its unlikely that you yourself are happy.

Good teams are made up of good hackers who work well together. Attracting top notch people is impossible without an environment that cultivates job satisfaction. So if the working environment doesn’t rank well for the satisfaction indicators below, it won’t attract good hackers, and therefore has virtually no chance of cultivating a good team. This is why the strength of the development team is the number one predictor of job satisfaction.

Quality of Projects

Intelligent people get bored doing the same thing all the time. Hackers are no different. If they are stuck with the same language, the same boring CRUD user interface, the same algorithms they learned in their first year programming, they will be unhappy. Most developers crave learning new things and being able to apply them. Difficult and challenging problems excite them.

Taking some time to think about the skills you have learned lately and the problems you have solved will give you a good idea of not only how satisfied you are in this area, but also how well you are advancing in your career.

Work-Life Balance

The hacker stereotype is to work incredibly long hours while surviving on Cheetos and Bawls soda. This death march method of software development isn’t sustainable and will take its toll over time, ultimately leading to burnout and job dissatisfaction.

Taking a look at the number of hours you are working will give some indication of how you rank in the work-life balance area. Many people on the track to burnout aren’t even aware of it, so talk to family and friends and ask them to help you gauge how well you are balancing work with other activities and obligations.

Bureaucracy & Politics

Some amount of bureaucracy and politics is unavoidable, but good management will be able to shield you from it to a great degree. The only time I found myself without it was during University, and that was more because of warped perspective than anything else. University bureaucracy was actually pretty bad, but I never thought of it as part of what I was doing. It just become something totally unrelated to programming; I thought of it more like paying the water bill or taking out the trash.

In general, happy, satisfied hackers are busy coding and are making progress towards a goal. As a group, programmers do not like to find themselves in endless meetings that accomplish nothing, ensnared in budget disputes, or without adequate resources to perform their best work. If projects are constantly stalled or held back by requirements that constantly change or are missing, management decisions, or lack of direction, hackers will be frustrated and unhappy. Worse, if programmers are left with nothing to do due to excessive bureaucracy and policy decisions, they will see that their skills are not being used and are therefore not valued. This leads not only to dissatisfaction with the bureaucracy, but also causes dissatisfaction with the amount of recognition and respect that they have.

Recognition and Respect

People who excel at what they do and are knowledgeable about a subject expect to be taken seriously and consulted with during decision making. This is as it should be. Management that disregards the opinions of their technical people or don’t consult them when it makes sense to do so will be left with uncooperative and dissatisfied developers when it comes time to implement an idea.

Have you been allowed to undertake difficult projects? Is your opinion sought out? Are your ideas taken into consideration? Are you congratulated for meeting important milestones? This are all good measures of your recognition and respect within a company. Are you often forced to implement something you don’t have any control over or disagree with? Are you often contradicted or marginalized by people who are less knowledgeable? (Careful with that one - make sure you are open to sound technical ideas.) These are indicators of dissatisfaction.

Compensation


This is one of the easiest factors of job satisfaction to quantify. Some quick research at online job boards gives a good idea of compensation packages for similar jobs in the same area. Discovering compensation packages for people in you own company can also be valuable information. Obviously if you are under-compensated you will not feel satisfied, and on the flip side if you are compensated well you rank as highly satisfied on this area.

After looking at and evaluating these criteria one by one, I have a much better understanding of my personal job satisfaction. It is easier to see which areas are working well and which I need to take action on in order to improve my own career satisfaction and general well-being. In two weeks I will cover steps to increase job satisfaction for each of the factors listed above.

In the meantime, what factors are important to you?

Use prototyping to visualize project requirements

A prototype represents the shell of an actual production application. Prototypes are built early in the development lifecycle, and they’re used to provide valuable insight into the look, feel, and general workflow of an application. (Sometimes people call the first production implementation a prototype, but that’s not correct. If you have multiple implementations, the first one is more aptly called a pilot test. Likewise, a prototype is not used to validate whether a proposed solution works. This is more aptly called a proof-of-concept.)

The main purpose of a prototype is to gather and document requirements. If you’re pretty confident that you have a good set of requirements, there’s not necessarily a reason to build an initial prototype. After you build an initial prototype you should show it to the clients to validate the work done so far looks okay. You then use the prototype to gather additional requirements. As you receive requirements, you should document them in the same way you would document the additional requirements you’re gathering though other means.

The prototype starts off as a shell that contains the online screens. There should be very little programming of the core business processes and only enough program code to allow the prototype to go from screen to screen. The point of the prototype is to provide a visual representation of the application, not the complex business logic that goes behind it.

What happens to the prototype?
There are two options for what happens to the prototype once it’s built.

1. Complete or partial throw-away. Typically, if you build a prototype, you’ll throw it away after the requirements have been gathered. Remember that the prototype does not have to be the start of the final solution. The main purpose is to gather requirements. I’ve seen online applications that appeared to be running on the web, when, in reality, the team members built the prototype in PowerPoint or Excel. There was no thought that somehow this PowerPoint prototype would be reused further as the project progresses. On the other hand, in many instances you’ll build a prototype using the same technology as the final solution. In this case, there may be some aspects that can be reused. You may be able to leverage some of the physical components of the prototype as a starting point for the Design and Construct Phases of the project.

2. Iteratively develop into final application. If you’re using an iterative development approach, the first prototype should still be put together quickly. However, instead of the work being abandoned or thrown away, the prototype is updated with the new requirements. In the second pass, more business logic is also placed into the application. At this point, it’s no longer called a prototype. Instead, the prototype shell is used as the basis for developing the final solution.
In summary, prototypes are used to gather requirements, and are especially useful in visualizing the look and feel of an application and the process workflow. The useful life of a prototype will vary according to the project lifecycle model. It’s possible that the prototype can be thrown away, or that some components can be reused later in the project. It’s also possible that the prototype can be used as the basis for developing the final solution.

Why do I document Code?



Hello and welcome to another session of why do I document code. Today's contestants are:

1. The Software Requirements Document otherwise known as the SRD
This valuable little document tells the developer what to develop. Is was started by the Carnegie Mellon. It is used as a contract document between the developers and the customer. The customer starts the document by what they expect the program to do. Everyone knows that the customer always changes their mind, well if you use the SRD, they are held by a legally binding contract that specifically states what to develop. You as a developer don't develop anything else except for what this document states. Therefore if the customer changes their minds, well you can either point back to the SRD or decide to charge them more money.

2. The Database Maintenance Manual otherwise known as the DMM
This handy dandy contestant describes every little feature about your applications database. IT describes the tables, the columns, the attributes of the columns, the generated script of the entire database, the user logins, the ways too install and upgrade the database on another machine, the DTS and last but not lease etc... This basic manual describes in detail every single part of the database. The reason for this is if you had a total hardware melt down and nothing works, well you now have a copy of the database that can be recreated using the script that was generated and put inside the file.

3. The Software Design Document also known as the SDD
This massive document describes all the methods, namespaces and functionality of the Code. IT also describes the developers thoughts and opinions to why they code the application one way compared to another. When I say everything, I mean everything. This document has all the developers thoughts and opinions when they were designing and developing the code. Thank god most comments can be extracted via an XML parser. The XML parsed comments can even put it into a nice little help file just like MSDN.com. Where can you learn how to write one, well let me tell you. Our good friends(Not really at all) at Bit Formation has made a great tutorial on how to write one.

4. The User Guide
The user guide plain and simple is the thing users use to get around the application. Every little thing that was EVER created by man has some sort of user guide attached to it. These are a no-brainer, but long and tedious to write just like the other documents listed here today!

Now that you know our contestants, lets find out why you would do such a thing.

Alright, enough with the game show. I thought it would be a good starter. I completely agree that all the documents though rather tedious and considered a time waster by developers is a necessary part of life. Developers need to both COMMMENT CODE and write documentation. That is the way it should be and should end up. Documents are there in case you as the developer get into some kind of horrific accident and are no longer able to continue on. They must find someone else to keep going. Sorry, but that's the way life is. You are writing the documentation incase you have to be replaced. I currently work on a 20 year application and I know for a fact that I will not be working on this same application for another 20 years. I just won't do it. It is too boring and mundane. I do know that some day, they will hire another guy or girl who will have to continue my work and when that day comes, the documents are there.

Things must be documented.

Most Common TCP Ports

Ports are basically divided into three ranges: the Common Ports, the Registered Ports, and Private Ports.

The Common Ports are those from 0 through 1023.
The Registered Ports are those from 1024 through 49151
The Private Ports are those from 49152 through 65535

Common Ports
The Common Ports are assigned by the IANA and on most systems can only be used by system (or root) processes or by programs executed by privileged users.
Ports are used in the TCP [RFC793] to name the ends of logical connections which carry long term conversations. For the purpose of providing services to unknown callers, a service contact port is defined. This list specifies the port used by the server process as its contact port.

Port Assignments for Common Ports:

Port UDP TCP Definition
7 x x echo
9 x x discard
11 x x systat
13 x x daytime
17 x x quote of the day
19 x character generator
20 x ftp - data
21 x ftp - control
23 x telnet
25 x smtp mail transfer
37 x x timeserver
39 x rlp resource location
42 x x nameserver
43 x nicname whois
53 x x dommainlein name server
67 x bootpc bootstrap protocol
68 x bootpc bootstrap protocol
69 x tftp trivial file transfer
70 x gopher
79 x finger
80 x http
88 x x kerberos
101 x hostname nic
102 x iso-tsap class 0
107 x rtelnet
109 x pop2
110 x pop3
111 x x sunrpc
113 x identification protocol
117 x uucp
119 x nntp
123 x ntp
135 x x epmap
137 x x netbios - name service
138 x netbios - dgm
139 x netbios - ssn
143 x imap
158 x pcmail - srv
161 x snmp
162 x snmptrap
170 x print - srv
179 x border gateway protocol
194 x irc internet relay chat
213 x ipx
389 x ldap
443 x x https (ssl)
445 x x microsoft - ds
464 x x kpasswd
500 x isakmp key exchange
512 x x remote execute
513 x x login / who
514 x x shell cmd / syslog
515 x printer spooler
517 x talk
518 x ntalk
520 x x router / efs
525 x timeserver
526 x tempo
530 x rpc
531 x conference chat
532 x netnews newsreader
533 x netwall
540 x uucp
543 x klogin
544 x kshell
550 x new - rwho
556 x remotefs
560 x rmonitor
561 x monitor
636 x ldaps over tls/ssl
666 x x doom id software
749 x x kerberos administration
750 x kerveros version iv
1109 x kpop
1167 x phone
1433 x x ms - sql - server
1434 x x ms - sql - monitor
1512 x x wins
1524 x ingreslock
1701 x l2tp
1723 x pptp point to point
1812 x radius authentication
1813 x radius accounting
2049 x nfs server
2053 x kerberos de - multiplexor
9535 x man remote server

How JSF fits for Web Application

JSF is a framework of best choice for the web applications development because of its support for wide range of qualities like:

Standard Java framework

Easy creation of UI

Capacity to handle complexities of UI management

Clean separation between presentation and logic

Shorter development cycle

An extensible architecture

Support for multiple client devices

Flexible rendering model

International language support

Robust tool support

The article explains all these points clearly. Reading this article will make you clear the idea why JSF is the best selection for developing web applications of different range of complexities.

Read the article at:
How JSF Fits For Web Applications?