Code Reviews

Developers often seem scared to allow another person to look at their code.  It is like they have a fear of someone stealing what they had done or that someone is looking over their shoulder.  Software developers and web developers often hold tight to their projects.  In almost every business work is proof read or reviewed.   It is not because a lack of trust, but rather many eyes will catch mistakes.

Why do we do code reviews?
The reason for code reviews may be obvious, but since the resistance it needs to be mentioned.  Code reviews are primarily to catch logic mistakes, missing business rules and team coding standards.

When a developer is so close to a project and looks at the same code for days, weeks or months, it is easy to invert logical expressions or entirely miss basic variable checks.  Assuming both purposely and by accident that routines return the perfect values is often the biggest mistake and we are suddenly surprised when a NULL value sneaks in.

Often when we start a project we are handed pages and pages of business rules and requirements.  It is very easy to miss the small things and even the big things.  As easily it is to cross items off a list, it is just as easy to entirely miss one.  It is very viable to have a second set of eyes to review what we had just written.  Better to catch mistakes before the customer does.

Lastly team coding standards;  they are standards that either the team lead or the team together decided they would follow.  These standards are to ensure that the team writes the code in the same structure and using the same variable naming convention.  Having coding standards allows the team to work together and have the ability to read each other’s code.  It allows quick debug and editing by any team member.  Without these standards projects would be a wild wild west and would differ from team member to team member.

Types of Code Reviews

  1. Team Code Reviews – Team members together would focus on a method or a group of methods.  The team together would offer suggestions and ideas to enhance the code for which they are reviewing.  It is not a time to rip the developer apart, but to offer constructive suggestions.  If a developer gets out of line, that person should be asked to leave the room.  A projector should be used if available; otherwise printing off the code or have each developer view it on their laptops are adequate methods as well.  The team lead should take a leadership role in this method guiding conversation and making notes to send out after the meeting.
  2. Colleague Code Reviews – These reviews should be done by a senior or a team lead person.  The senior can be greater or equal in experience.  Same as a team review, everything should be done in a constructive manner.  If a senior developer is doing the review; the senior should be assigned by the team lead to prevent a biased review.  When the review is complete – the review should be covered in person with all developers involved.

Tips for the Reviewer

  1.  Ask questions, do not make statements
  2. Do not be too critical, remember to praise
  3. Be sure you have your company coding standards available as a reference
  4. Keep the review on the code and not the coder.   Do not make it personal
  5. Keep in mind that there is more than one way to do something

Tips for the Developer

  1. Remember, you wrote the code, but the code is not you.
  2. Make a check list of things that are often found in the code reviews
  3. Be involved in the maintenance of the coding standards
  4. Always do your best and do not look for short cuts

Building a C-Sharp Class

I have created this example of a C# class to demonstrate one way of creating a basic class cbject representing one employee.  This class could be used as a starting point for just about any object.

Take note that there are no business rules in this example.  It is of my opinion that you create a basic object first and create a business class second which extends the basic object.  In the business class you may put an EmployeeNumber generator, MaxLength controls on the fields, Phone number validation and other rules that may apply based on your business practices.  A business class will be demonstrated in a later blog.

You may also want to create a collection class.  A collection class or a manager class would manage a collection of objects with Add, Remove, Select, Sort type functions.  This too will be demonstrated in a later blog.

    /// <summary>
    /// Class Object Representing Employee
    /// </summary>
    public class Employee : Dictionary<String, Object>, IEmployee
    {
        // ***********************| Properties |***********************
        /// <summary>
        /// Employee Number
        /// </summary>
        public String EmployeeNumber
        {
            get { return (String)this[GetName()]; }
            set { this[GetName()] = value; }
        }

        /// <summary>
        /// Employee's First Name
        /// </summary>
        public String FirstName
        {
            get { return (String)this[GetName()]; }
            set { this[GetName()] = value; }
        }

        /// <summary>
        /// Employee's Last Name
        /// </summary>
        public String LastName
        {
            get { return (String)this[GetName()]; }
            set { this[GetName()] = value; }
        }
        /// <summary>
        /// Employee's Address Line 1
        /// </summary>
        public String Address1
        {
            get { return (String)this[GetName()]; }
            set { this[GetName()] = value; }
        }

        /// <summary>
        /// Employee's Address Line 2
        /// </summary>
        public String Address2
        {
            get { return (String)this[GetName()]; }
            set { this[GetName()] = value; }
        }

        /// <summary>
        /// Employee's City
        /// </summary>
        public String City
        {
            get { return (String)this[GetName()]; }
            set { this[GetName()] = value; }
        }

        /// <summary>
        /// Employee's Province / State
        /// </summary>
        public String Province
        {
            get { return (String)this[GetName()]; }
            set { this[GetName()] = value; }
        }

        /// <summary>
        /// Employee's Country
        /// </summary>
        public String Country
        {
            get { return (String)this[GetName()]; }
            set { this[GetName()] = value; }
        }

        /// <summary>
        /// Employee's ZIP / Postal Code
        /// </summary>
        public String ZipPostal
        {
            get { return (String)this[GetName()]; }
            set { this[GetName()] = value; }
        }

        /// <summary>
        /// Employee's Home Phone Number
        /// </summary>
        public String HomePhoneNumber
        {
            get { return (String)this[GetName()]; }
            set { this[GetName()] = value; }
        }

        /// <summary>
        /// Employee's Cell Phone Number
        /// </summary>
        public String CellPhoneNumber
        {
            get { return (String)this[GetName()]; }
            set { this[GetName()] = value; }
        }

        /// <summary>
        /// Employee's Full Name ( ReadOnly )
        /// </summary>
        public String FullName
        {
            get { return String.Format("{0}, {1}", FirstName, LastName); }
        }

        /// <summary>
        /// Employee's Start Date
        /// </summary>
        public DateTime StartDate
        {
            get { return (DateTime)this[GetName()]; }
            set { this[GetName()] = value; }
        }

        /// <summary>
        /// Employee's TerminationDate ( Nullable )
        /// </summary>
        public DateTime? TerminationDate
        {
            get { return (DateTime?)this[GetName()]; }
            set { this[GetName()] = value; }
        }
        // ***********************| Constructor(s) |***********************
        /// <summary>
        /// Constructor
        /// </summary>
        public Employee()
        {
            Initialize();
        }

        /// <summary>
        /// Employee
        /// </summary>
        /// <param name="employeeNumber">Initial Employee Number</param>
        public Employee(String employeeNumber)
        {
            Initialize();
            EmployeeNumber = employeeNumber;
        }
        // ***********************| Methods |***********************

        /// <summary>
        /// Initialize the Class
        /// </summary>
        private void Initialize()
        {
            EmployeeNumber = "";
            FirstName = "";
            LastName = "";
            Address1 = "";
            Address2 = "";
            City = "";
            Province = "";
            Country = "";
            ZipPostal = "";
            HomePhoneNumber = "";
            CellPhoneNumber = "";
        }

        /// <summary>
        /// Get Method Name
        /// </summary>
        /// <returns>First and Last Name</returns>
        public String GetName()
        {
            StackTrace stackTrace = new StackTrace();
            StackFrame stackFrame = stackTrace.GetFrame(1);
            MethodBase methodBase = stackFrame.GetMethod();
            return methodBase.Name.Replace("set_", "").Replace("get_", "");
        }

        /// <summary>
        /// Re-initializes the Class
        /// </summary>
        public void Reset()
        {
            this.Clear();
            Initialize();
        }
    }

Importance of Code Refactoring

By continuously improving the design of code, we make it easier and easier to work with. This is in sharp contrast to what typically happens: little refactoring and a great deal of attention paid to expediently adding new features. If you get into the hygienic habit of refactoring continuously, you’ll find that it is easier to extend and maintain code.
—- Joshua Kerievsky, Refactoring to Patterns

I had recently seen the above quote while sifting through some periodicals that I read and it reminded of the importance of Code Refactoring. Refacotring is a mindset that you must put yourself into. You have to decide that you do not write perfect code the first time and that there may be some room for improvement. An hour or two a day may be all you need to review your own code.

I recently spent two hours reviewing code from one of my modules that I had written. It had the same or similar code written in 5 sections in the code and had the same purpose to these sections. Each section had 11 or more lines of code in it. I took one of those sections of code and converted it to a function and then replaced the 5 sections with this new function. Ultimately I had eliminated 51 lines of code out of one module.

Reasons for Refactoring Code
1. Consolidating and eliminating “Like” or “Similar” Code
2. Breaking out a extraordinary long function into more manageable bites
3. Make error trapping easier to handle
4. Make code more readable and maintainable
5. Removing nested IF or logic Loops
6. Make it easier to document
7. Create Reusable code
8. Better class and function cohesion.

The benefits now are the following:
1. Similar code is now the same which is the way it was meant to be ( coded over three days, the code morphed a bit ).
2. Since the code had the same purpose, it looks the same now and behaves the same.
3. Code is in one spot instead of 5 – makes it easier for a base change
4. Error trapping is much more controlled.

If you cannot review your own code ( some people cannot and should not be ashamed for it ), you should get yourself someone you can trust to review the code for you. The do not have to modify the code, they can either insert comments to you, print out and scribble on the pages or meet with you. Never take it as bad thing if someone wants to change your code; take it as a learning experience. If you are using someone else, challenge them back. Make sure they know what they are talking about. A face to face meeting is always a good idea. A mentor, or team lead should be taking on the role of code reviewer. Code reviewer should be recommending ways to refactor your code. This should be done prior to release, deployment and ending a project. The review should always be done with the developer(s) responsible for writing the code. Should never be done without as that undermines the developer(s) and no one learns anything from it.

Project Manager – Team Lead – Manager of Development

I have been asked a few times for resources and tips for a new Project Manager, Team Lead, Manager of Development type position.
My tips are a generalization as I can pull out more resources for certain situations.

Tips 
1. Have an open door
2. Don’t tell your team everything that you know. Be selective
3. Be positive in all your dealings
4. Lead by example. Do not ask your team to do anything you would not.
5. Speak clearly
6. If a developer says it will take a week, say two. If a developer says a month, say 6 weeks. Always buffer time.
7. Be real with expectations
8. Be kind, not too strict, but strict enough
9. Careful planning of project details
10. Listen to those above you and below you. You will learn stuff from everyone.
11. You are not the end all be all.
12. Fight for those who deserve it, help those who need it
13. Stay Organized
14. Meet with your team weekly with an agenda, so everyone can be prepared
15. Know what your superiors want from you
16. Know your place
17. Make sure you keep developing
18. Code reviews are a must, even yours ( can be fun for the team )
19. Earn your trust, trust your team
20. Know each team member’s strengths and use them. You cannot be everything to everyone
21. Failure is always an option – learn from each failure and success
22. Reflect on everyone project as there is always something to learn
23. Find a mentor or mentors – they can be good sounding boards

Online Resources 
http://www.fenman.co.uk/activities/training-manual/team-leaders-development.html
http://andrewtokeley.net/archive/2008/05/02/how-to-become-a-development-team-leader.aspx
http://www.atlassian.com/agile/people/teamlead.jsp
http://en.wikipedia.org/wiki/Lead_programmer 

Books to Read 
Project Management in a Week By Mark Brown
Survival is Not Enough By Seth Godin
Made in Canada Leadership By Amal; Morissette, Francoise Henein

My Blogs 
http://unlatched.com/blog_What_is_Leadership.aspx
http://unlatched.com/blog_Effective_Listening.aspx
http://unlatched.com/blog_How_a_Senior_can_Help_a_Junior_Developer.aspx
http://unlatched.com/blog_Can_Senior_Developers_Learn_From_Junior_Developers.aspx

Remember: Have fun or you will not like it. Take time off – you need breaks.

Shortcut To Creating Properties in C-Sharp – Revisited

Based on my earlier an post, a I had a question about my technique and if there was a benefit, or could you use MethodBase.GetCurrentMethod().Name. Truthfully I did not know the answer until I tried it. I found this new way works, but I also find it is a little tougher to look at style-wise. You need to use stack frames if you nest the routine like I had in my original post.

public class ErrorLogRecord
    {
        public Hashtable _hsh = new Hashtable();

        public DateTime DateOfOccurance
        {
            get { return (DateTime?)_hsh[MethodBase.GetCurrentMethod().Name.Replace("set_", "").Replace("get_", "")] ?? DateTime.Now; }
            set { _hsh[MethodBase.GetCurrentMethod().Name.Replace("set_", "").Replace("get_", "")] = value; }
        }
        public String ErrorText
        {
            get { return (String)_hsh[MethodBase.GetCurrentMethod().Name.Replace("set_", "").Replace("get_", "")]; }
            set { _hsh[MethodBase.GetCurrentMethod().Name.Replace("set_", "").Replace("get_", "")] = value; }
        }
    }

Original Referenec Shortcut To Creating Properties in C-Sharp

When a Developer Leaves

To start; I am not saying this is me, but I did talk to a few developers for research.

Employers are often left scratching their heads when a developer leaves. The unfortunately truth is when one leaves another often follows not to long after. It is very hard to understand why the first developer left let alone the second or third. I believe as a employer, team lead or VP, you should know some of the “WHY” for a better understanding of a developer’s behavior. I admit we are a strange brew of employees.

Developers like to be challenged and appreciated. When the challenge is gone, so is the developers will to continue. Developers need to know that they will not be doing the same thing day in and day out. They really need to mix things up a bit. They need responsibilities, new tasks and freedom to try new things on their own. They also need to know they have the company’s support to continue education, and not just a pat on the back. Try to hire from within the team before you look for that new manager. Sometimes you have the perfect leader within the company already.

Developers also have a keen sense of appreciation. They do not need a thank you, or a pat on the back from their employer all the time, but they definitely know when they are being exploited and taken advantage of. More and more companies are introducing foosball, video games and fun activities to show their developers that they can have fun and are appreciated. It is the little things that go a long way. A BBQ in the summer with some good laughs and keep the spirits a little brighter.

These are just brief explanations of why a developer may leave a company, but very rarely is it just for more money. There is often more to it. An exiting interview may shed more light on the “WHY”, but more likely you will never know. An observation that I have made recently; there is a real misunderstanding of junior developers. Junior developers are ones that leave their company the most. Junior developers leave because they are treated poorly by senior staff, paid unfair salaries, no or little vacations and benefits and simply they often do not feel apart of the team. Junior developers add value to any team for a couple reasons.

  • Successorship for senior developers
  • Brings new ideas and techniques to the table
  • They still absorb new information at a fast rate

Why would other developers leave shortly after?
Loyalty is often a factor. Developers are social creatures who form a tight community that is often hard to break into. They often congregate at bars and coffee shops after hours or on breaks to share and implement ideas. This form of interactions creates a tight bond. If a company hires one developer, it is not uncommon for that developer to want to take a few of his trusted colleagues with him. This is a practice that shows the tight bond and trust between the development community. Developers like to work with people they know and trust. It is also becoming a more common practice for the new employer to try to take an entire team of developers that are linked by a common employer or group. This helps create a stronger team.

What Not to Say to a Developer
I was once told that I would never be able to advance out of my position because I was too good at it. These words are like knives going into the heart. A developer likes to be challenged and advance through their career like anyone else in the workforce. Developers are often known to put their heart and sole into their work; often giving 110% of themselves. Advancement is often equal to being similar to being appreciated and/or trusted. Nothing kills a employee’s will to continue faster than words. Chose your words wisely.

Strange Creatures
Developers are strange creatures. They are creatures of habits ( generalization ) and often do not like change. Exception here is developers often embrace changes as in new technology and ideas. When I say they do not like change, they do not like to

move homes, place of work, parking spots, watering holes, etc. They like their every day habits and routines. When a developer leaves it is often a big decision and they did not take it lightly. It is often not a personal reflection on the company, but rather a personal reflection of themselves.

Quick Points

  1. Find out what other companies are doing to keep their developers engaged and happy
  2. Talk to your developers often on a personal level
  3. Create a trust with your developers. Do not give them a reason to not trust you.( Example: monitoring internet usage and emails )
  4. Give them freedom. Allow them to occasionally work on projects of interest ( Google often does this and then makes money from the side projects )
  5. Let them use social media to keep connected and build the communities. You do not want your developer to feel isolated. Non-techie people often do not understand a developer
  6. Do your hardest to create real expectations, and not push crazy hours. Developer burnout is rampant in small companies
  7. Do your best not to call your developer all hours of the night and every day when they are on vacation. You would not want this for yourself.
  8. Treat your developer as you would want to be treated

What is Trending – Are you listening

Do you know what is trending today?   Do you know what is new?  Do you care?

As developers we live in a crazy world where technologies and ideas fly at the speed of light.  If you are not paying attention you will miss out on the new ideas.

Hash-tags, Twitter, blogs, LinkedIn and Facebook; these are some tools of the modern world and they can help define our chosen professions.  If you have not embraced these fore mentioned tools, you will miss out.  How are you keeping up?  Are you relying on your everyday work or are you digging into the realms of social media to see what is trending?  The printed press like magazines, journals and newspapers are not cutting any more because of the pace of change.  By the time you read it, it is history.

Social media is trending the new ideas, tools and techniques at a pace that is baffling.  If you are a developer and you have not embraced social media, you are probably missing out on a lot of great stuff.  Managers are now asking you in interviews; How you are learning new things and keeping in the know?  If you are not saying social media as a tool, you would be foolish.  It is great to ramble of magazine names and school courses, but most of what is learned there I consider as historical background knowledge; you need social media to enhance your knowledge.

Are you looking for the next great idea?

Here are some interesting trends to watch:

There are a million of trends happening every second of every day.  Pick one or two a day and watch.  If you find something interesting dig for it and dig deep.  LinkedIn also has groups that could help you define who you are, what you want to do and how to do it.    There is a lot happening and you will never know what will trigger your next big idea.   Once you have watched, participate and that is the ultimate way of learning what is new.

Can Senior Developers Learn From Junior Developers

I relate this back to when you are listening to grandparents tell story after story.  Somewhere in those stories you learn from their history.  Now when they ask about you, they learn more modern things.   Like the time I showed grandpa how to tour castles from my computer.   He learned that there was a tremendous amount of information at their fingertips, if they embraced something new.

It is important to listen to each other.   We as senior developers have lots to teach, but we also have lots to learn.   Most of us have been doing the same thing day-in and day-out.   We have learned new languages and new technologies, but not necessarily to the extent of the new developers joining your team.  They have recently exited their programs to join the work force.  During their college or university days, they had a hunger to learn.  Most of them soaked up everything their teach taught them and then explored other avenues and ideas to a greater extent.  New developers are little sponges and you never know what they have absorbed during their school.  Most after graduation have continued their learning either through their senior developer, through further schooling or simple through other means like reading or internet.

I am a believer that I cannot know everything and that everyone has something to teach me.   I have had some very good junior developers show me some cool new tricks.   Through those new tricks, I am able to show them how to refine those tricks into something truly amazing.   There are some great minds out there.

Remember, today’s junior developers are doing things that we did not even fathom at their age.   I went to school with Windows 3.1, OS2 warp and COBOL programming.   They went to school with DotNet, PHP and Windows 7 and Linux.

I currently do not have a junior developer working with me, but when I did; I used to have Monday mornings as a sharing time.   We would meet in the boardroom (breakfast sometimes) and share what we have learned or done.   We also used to discuss issues or choices.   We used this opportunity to learn from each other.

Listen to what your juniors have to say.   You may just learn something as well as teach them something.

Related Reading: Can Senior Developer Learn From Junior Developers

How a Senior can Help a Junior Developer

Senior developers have a responsibility to help those who are new to the profession.   We are the one group of people that the junior developer can turn to after college.  Essentially the college gave the new developer 2 years of education, a piece of paper and tossed them out to sink or swim.

I personally do not like to see anyone sink.  I believe no matter what the skill set is, a person could be a little better if a helping hand is given.  I am not suggesting a babysitter, as no one really wants that.  I am suggesting an open door, an open mind and a little patience.   Juniors will make mistakes and they will often be a little cocky thinking they know it all coming out of school, but we need to remember their minds are still in the stage of learning.

Juniors can learn much more at their stage in life.   Their minds are like sponges and soak in the good and bad habits and knowledge that we share with them.  The best thing we can do for them is to teach them everything we know, encourage them to do extra learning on their own and to listen to them.   When I last managed a small team, I asked for a weekly report, which consisted of:

1. What are they working on?
2. Where are they on the schedule of tasks?
3. What obstacle have then encountered?  Are they still stuck, if not how did they over come it?
4. What is one thing they learned new this week?

During our weekly meeting, I would get one or two of the developers to talk about either the obstacle or their new found knowledge with the rest of the team.  This way all new and old developers had a chance to share and learn from each other.

In summary, help them learn in every aspect.  Listen to their ideas and new found knowledge.  Have an open door for questions.  Lastly; be cautious of your bad habits.

Related Reading: Can Senior Developer Learn From Junior Developers

Do Not Get Boxed

As a developer, it is important to look around and experience new things, as it helps you to stay sharp and marketable. This doesn’t mean that you need to quit your job.  Just do not get boxed in as single purpose developer.

It is important not to be just a developer of one kind. Do not just be a PHP Developer, DotNet Developer, or a SQL Developer. Strive to be more than what you are currently doing.

As an example; when I was just starting out as a developer I had two unique jobs. First job was a Visual COBOL Developer and the second job was a Factory Automation Integrator specializing in database and Visual Basic integrations to Allen-Bradley PLC. If I had allowed myself to be boxed into either one of these developer types, I would not have had the opportunities to do more. With the Factory Automation Integrator, I would probably be pumping gas as the firms I used to work for and see around are mostly gone now and who the heck is using Visual COBOL anymore?

As a Web Developer working for a web development firm, you may be asked by a customer to do a mobile application or a windows application to complement their other work you may have done.

I strive every day to learn something new. I learn it until I know it well enough to be productive. I also practice what I have learned in the projects I work on in my spare time. .

In my current job I am a Web Developer, SQL Developer, Windows Developer, Mobile Developer and a Support Specialist.  I have also worked where I had a single focus as a Web Developer at a web development firm, but I stretched myself to do business needs analysis. It is important to be forever evolving as a developer. Just don’t speak of the new technologies. Learn the new technologies and know and practice what have you have learned.