Category: Developer

Eleven Items That Makes a Developer Great

Here are a few items that makes a software / web developer great:


Updated to twelve items thanks to some input.

  1. Knowing they are not perfect
  2. Listens to business needs
  3. Always evolving by striving to do better
  4. Never hides a mistake, but acknowledges and learns from it
  5. Does not blame the user for the error
  6. Always tries to learn something new
  7. Makes notes
  8. Listens to teammates
  9. Does not blame the previous developer
  10. Willing to dive in and do the work no matter what
  11. Ask questions when they do not know [ Shawn Adamsson rTraction  ]
  12. Thinks and plans before coding. Know where you’re expected to go and plan the path to get there carefully [ Shawn Adamsson rTraction  ]

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.

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.