Category: self-improvement

Mine Mine Mine

In any work environment you here things like “Don’t step on my toes”, “Do not touch my desk or my projects”.  Walls are formed to protect what they believe is their own best interest; protecting their job in essence.  Is this really the case though?  Software developers seem particularly protective because they believe someone may mess something up on them, break something or take credit for something.
I believe it is time to rip down those walls that we have formed.  Let others come into our space and collaborate.  Yes it is sometimes a shock to come back from vacation and find someone has messed with “your” code, work or tells your customers something different.   Reality is though it is not your code, work or your customers.   The customers belong to the company you work for along with the code and your work.   It is to our best interest to let others do things for us.  They may find something we had missed, done wrong or have a better way of doing it.   From time to time it can even generate a good laugh as we are reading through the code comments.
Another advantage of not keeping all of the work to ourselves is we can drop the old in favor of new work.   You cannot do everything so you must give up something.  Old work can get boring sometimes and you become complacent and dull.   You need to stay sharp.   If you don’t give up some of your old work / customers, you cannot take on new.   Taking on new work and customers allows your mind to stay sharp.   Allows you to investigate new things rather than dwelling on the old.
If a Senior Developer shares their work with a junior, the junior then has an opportunity to learn from the senior.   They will be reading through tried and true code and learning “best practices”;  alternatively, the junior than can challenge the senior and perhaps show an old dog new tricks.
It is to everyone’s advantage to share work.  Teach someone else what you are doing, so that they can do it to.  This will cut the number of hours you need to spend after hours and it will allow to take stress free vacations, knowing someone else besides you can do the work.
It is not job security to keep things close to you.   It can actually burn you out as an employee and because you cannot take on anything new, it makes you less of a team player.   Drop the “mine, mine, mine” mentality and share the love.   You and your fellow work mates will be better for it.

How To Be Awesome

Being awesome is not the same as being perfect.  Being perfect is not possible, so you may as well shake that notion out of your head.  Being awesome is being the best you can be.  It is bringing everything you have to the table and doing it well.  You cannot be good at everything, so be awesome with what you enjoy and what you know you are good at.
There are reasons people do what they do and it is because they are good at it.  I am not good at plumbing and I know that I am not, so I hire it out.  If I chose to do plumbing, I would sit down and learn it until I know it.   I would look up to see what the building codes say.  I would watch how to movies.  Practicing soldering on small pieces of pipe would probably even happen.  I would be the best I can be for this job and learn everything I can about it.   I would be awesome.
Everyday I go to work and do the best that I can.  I work hard, learn new technologies and listen to everyone around me.   I work hard at being a leader and being a team member.   I take my time and do a good job.   I am awesome with the work I do, because it is the best I can do you.
Steps to Being Awesome
  1. Know your subject, read, watch videos, ask those who know

  2. Be in the right frame of mind.  Shake off the nerves, the stresses and give the job or project 100% of your focus

  3. Don’t limit yourself.  You can do anything if you put your mind to it.  Look past what your limits and reach for the sky.
  1. Listen to people.   There are a lot of people around you that know stuff.  You cannot know everything, but you can know what you need to know.  Use knowledge found around you to help you.  Being awesome is all about attitude.
  1. Remember – There is no such thing as perfect.
  1. Practice, Practice, Practice.   Practicing every day will help you do better every day.  Without practice you are limited to the abilities you hold today.
  1. Learn from your failures.  Failures only mean there is another way.  Search out the other way and try it.  You may fail multiple times before you find the right way.
  1. There is always someone who says you cannot do it.   Ignore it.  Use it as a prompt to only try harder.   If it is getting to you, pause take a break.   Proceed when your head is clear.
Challenge
Learn something new every day.  I can be learning something to build on what you already know, or learn something totally new.  Learn it well, practice it and do not move on until you have a good grasp of it.   If it takes longer than a day, don’t fret, it will be worth it.

Effective Listening

A skill that seems to be lacking in a lot of people is effective listening.  Effective listening is not 100% listening to others, but it is also the art of listening, asking questions and evaluating what you are hearing.  Lately it is not just the spoken word that is getting missed, but also the written word.   I have recently experienced people only reading the first line or two of an e-mail.   Too often people are quick to respond verbally or written.

Steps to Effective Listening ( verbal )
1. Relax and filter everything else out.
2. Look at the person in the eye who is speaking.   This guarantees a focus of concentration.
3. Make a mental note of key points.
4. When the person is done talking, ask for points of clarification where required.
5. Evaluate everything that was said.  Be slow to act on what is said.
6. Note taking can be used as a tool.

Note:  Do not interrupt the speaker.  This could be a distraction that would result in loss of information.   Wait for a proper break to ask questions or comment.

Steps to Effective Listening ( written )
1. Carefully read the message or email.
2. Remember, there is very little to no emotions in most written word.   Read it accordingly.
3. If uncertain of meaning or intent of the message or email, read it again.
4. Ask questions, but remove your emotion.  Be thorough with your questions or comments.
5. If uncertain about content of your reply, type it up, close it as a draft.   Come back to it later.
6. If you are not in the frame of mind for processing what was said in the email, put it into a folder to reply to later.

Note: Remove your emotion when replying or typing emails.  When reading and email, remove the other persons emotion.   Read at least twice.

A Call To Senior Developers – Rise Up

Every year is there is an influx of newly trained developers from our local colleges.  They have paid good money to become book smart and if they are lucky maybe some practical from their co-ops.   They enter the work force with nothing more than a smile and a piece of paper; often not knowing where to turn.  They look around, but there are no “Help Wanted” signs.   Once they are in, they are thrown projects with very little guidance.
I was asked a question recently and I gave my opinion on how it should be done.  After, I had instructed the person to go their senior developers for some guidance of how they would like to see it.   I was told they do not care as long as it works.   I thought this is crazy, how could they not care?   We are the Senior Developers with the experience.   We know how it should be done and how it should look.  Sometimes the “how” is more of a company culture, but it makes the code easier for everyone to read after the fact.   If we do not teach them how to do things, style and logically; we will essentially create ourselves more working fixing things that could have been done correct the first time. We are the guides for the young people.  If we know of a job in the city, we should promote it.  If we know how to do something or how it should look, we should teach it.
There is far more to being a Senior Developer than years of service. I believe deep down inside they are afraid the younger developers will steal their positions.  It is a possibility, but not likely.  If we stand up and take the younger developers by the hand and guide them.   Teach them to do their jobs to our standards; we will essentially create a little job security for ourselves.  The employer will see that we care about the projects and we care about the mentor-ship of others.  
We are a team and together we will make things happen within our employment.  The Senior Developer is the leader of the team.  Stand up, take your job seriously and help those who are starting out.  In-turn, you will gain the reward of lesser work, a developer you can trust and the respect of your employer.
Probably more to come on this topic… but not today.

Code Simplified

Working with junior developers through out my years, I have seen some funky and fun ways of coding.  The three styles I have seen the most are the following.    I have come up with BEFORE and AFTER examples.  Now the AFTER is just my opinion on how the code should be rewritten, but is not necessary the only way.

BEFORE

           String strDelim = “;,”;
           Char[] delimiter = strDelim.ToCharArray();

           String[] emails = to.Split(delimiter);

AFTER

           Char[] delimiter = new[] { ‘;’, ‘,’ };

           

String[] emails = to.Split(delimiter);


EXPLANATION
I prefer this rewrite because it is smaller in number of lines and it is less instructions to the compiler.  Although this example was 3 lines rewritten as two and seems small; in a large program, it adds up if done enough. 

BEFORE
           String answer = “”;
           if(rdButton.Checked == true)
           {
                      answer = “Test 1”;
           }
           else
           {
                      answer = “Test 2”;
           }

AFTER
           String answer = rdButton.Checked ? “Test 1” : “Test 2”;

EXPLANATION
This rewrite uses an old C style called Immediate IF.   This takes your simple if block statement and breaks it down to one line.  The other change is the == true was removed. Since the rdButton.Checked already returns true / false, it is not required to conduct an additional check.

BEFORE
           String rpt = “Error at Line: ” + lineNumber + “n” + “Description: ” + 

AFTER
           String rpt = String.Format(“Error at Line: {0}nDescription: {1}”, lineNumber, Description);

EXPLANATION
This change uses the String.Format command to take a pre-written string and inject the variables into their appropriate position within the string.  This is probably more of a preference of mine, but I think it looks cleaner.   The code does run faster when you are not adding string after string together, but with today’s processors and memory capabilities the savings is probably not much.  The main benefit is you can define these pre-written strings once and used them in this manner multiple times throughout the same piece of code. It will look cleaner overall.