Working as a Team

When you are working with really junior engineers, you are stuck with the burden of training them on a lot of aspects; especially if they are working remotely.

Here are some great guidelines I encourage the team members to follow to keep us all sane

 

1.       Get yourself trained.

o   If you do not have enough knowledge about technologies you are working on, get yourself trained

2.       Get the tools.

o   If you do not have the right tools or enough business knowledge about the product, let your manager know

3.       Do not wait for task assignments.

o   If you know something needs to be done, bring it up for discussion.

4.       Listen to the requirements carefully before starting out. Avoid rework. Document and share the requirements before starting if necessary.

5.       Write code that meets specified guidelines set by Architecture.

6.       (For offshore) Do not expect the onsite team members to provide you every bit of information required to work on your tasks.

7.       Do your own R&D when required.

o   (For offshore) The onsite team will provide you the information they have, but the rest you will have to figure out yourself by doing some R&D.

8.       Present your own ideas.

o   (For offshore) When you are dealing with new technologies, the onsite team themselves do not have all the answers. For some pieces you may have to present your ideas on the best approach.

9.       As a rule of thumb, before asking someone else, spend some time trying to work issues out yourself. If you find yourself stuck, then approach someone.

10.   Take the lead.

o   All members of a team are valuable and each person’s role shouldn't be simply following directions, but rather leading the project in the right direction.

 

A rule of thumb when writing comments in code

When you're writing code, ask yourself if someone else could come in behind you and understand it. If not, refactor the code and/or add comments to explain what you're doing.

Protected vs. Private methods in Java

Unless you have a specific reason to make the method private - like you expressly want to prevent subclasses from accessing the method - methods should be protected. This way we can subclass this tag.

if/else vs. switch

When writing code that branches on enum values, instead of if/else blocks, use the switch statement like so:

    switch (selectedTab) {
    case (Tab.SITES):
        //do something for sites
    case (Tab.CATEGORY):
        //do something for category
    case (Tab.DEMOGRAPHIC):
        //do something for demographics    
    case (Tab.ALL_SITES):
        //do something for all sites
    }

Lengthy and nested methods: Methods should small, atomic and easy to read. Break it up like so:

    switch (selectedTab) {
    case (Tab.SITES):
        renderSitesTab();
    case (Tab.CATEGORY):
        renderCategoryTab();
    case (Tab.DEMOGRAPHIC):
        renderDemographicsTab();
    case (Tab.ALL_SITES):
        renderAllSites();
    }

Comparison in Enums

Tip on Enums

Instead of using id to do equality comparisons for enums, use the enum itself.

Example: Instead of
if (selectedTab.getId() == Tab.SITES.getId()) {
use:
if (selectedTab.equals(Tab.SITES)) {

StringBuilder vs. StringBuffer

A tip on StringBuilder vs. StringBuffer

• We should be using StringBuilder over StringBuffer. It’s a drop-in replacement, all the method names and arguments are the same.


• StringBuilder is not synchronized and therefore doesn’t require object locks everytime a method is called. The only time we’d use StringBuffer is when it’s a member variable with a possibility of multiple threads writing to it.

Check the version of applications running on Linux

OS version: uname -a cat /etc/redhat-release Apache version: httpd -v /usr/local/apache/bin/httpd -version Jrun version For JRun 3.0, look at logs /opt/jrun/bin/jrun -version Perl /usr/sbin/perl -version (-v works too) Sendmail /usr/lib/sendmail -d0.1 -bt cat /proc/version