When I was two years old, I could barely say mama, or take accountability for any action, but I was destined for greatness, smashing against a keyboard coding my very own “Hello World”. Well, I wish that story was true. Most of it is true, apart from the age.

Most software developers may have a similar story of how they always knew they wanted to be software developers. That’s simply not my story though as I probably programmed my first “Hello World” when I was 20 years old. That doesn’t take away that I’m good and very passionate about what I do.

I’ve worked on various technologies/platforms, coded in various languages, given my expertise where needed and passed on the knowledge to various devs.

I continue to do this the best way I can. I’m not a code monkey (I don’t sit in front of my laptop and code 24/7) completing one requirement after the other.

I care about my users and I have a life apart from programming such as enjoying the sunshine so I do not stay cooped up all month without any vision or dreams apart from the laptop and getting that unit test to pass so that I can get my days worth of dopamine.

Let’s dive into the main objective of this article. There are some tips I truly appreciated at the beginning of my young career. The knowledge I obtained built and equipped me for whatever challenges that had laid ahead and that is the same even today as I am still learning.

So hopefully you can do better than I did by reading more and getting out of your comfort zone to truly experience the life of tech. These tips are as follows:

Remember your basics

Never forget your programming principles, SOLID principles (I will not be covering SOLID principles, so watch out for my next article) and the four pillars of OOP.

These principles and basics are still powerful and are vital to anyone’s growth. They should become part of your programming DNA as they never become null or void in any programming language. They enable code that is clean, readable, quick to understand, maintainable. Just stay disciplined to them.

Programming principles:

I won’t be listing all 10 of these programing principles but only a selected few:

KISS (Keep It Simple, Stupid): encourages programmers to keep it simple not to over-engineer but to solve the problem in it’s the simplest form. In the below example you have two ways of solving one issue yielding to the same output. B is an example of what it means to keep things simple, there was no need for a local variable; it was unnecessary.

Exhibit A:

public int getTotal(num1, num2) {
    int total = 0;
    total = num1 + num2;
    return total;
}

Exhibit B:

public int getTotal (num1, num2) {
    return num1 + num2;
}

DRY (Don’t Repeat yourself): duplications are a common mistake that should be avoided and there are so many tools that can assist in ensuring that code is not repeated in a codebase, some smart IDE’s also assist in this by highlighting or showing some form of a flag to show duplication.

The below makes use of the DRY rule as well as the KISS rule. The getFruit() method is meant to provide a fruit-based on the alphabet, the return of the apple fruit string is represented twice when it can be summed into one return statement as represented in B.

public int getFruit() {
    switch(fruit){
        case "a":
        System.out.println("apple");
        break;
        case "p":
        System.out.println("apple");
        break;
        default:
        System.out.println("no fruit");
        break;
    }
}

public int getFruit() {
    switch(fruit){
        case "a":
        case "p":
        System.out.println("apple");
        break;
        default:
        System.out.println("no fruit");
        break;
    }
}

Document your code: this is done to understand what the specific unit of code does as much as you should be writing readable code. It’s also important to know that many people will be taking over your work. It also makes it easier to track any issues. While others turn to comments I would truly recommend adapting into writing unit tests.

Why this recommendation you may ask, well below are some of the reasons why unit tests are more ideal:

• Commented code doesn’t offer anything else apart from it being text but with tests, you can find issues that could have been found in production and having to fix those issues after the initial release requires money, so you get the chance to save costs
• The facilitation of code changes
• Code quality
• As already mentioned documentation

I’ve only covered three of ten programming principles, to read up on more I’ve provided links at the end of the “Remember your basics” topic.

The four pillars of OOP:

The following forms part of the basic key elements of Object-Oriented Programming and should be used for a more effective design.

Encapsulation: a way of turning data and the methods the data is used into a single unit (data binding). For example a simple class with data fields, accessors and mutators, this would allow data fields that are made private allowing them to be only available in that particular class but those private data fields can be accessed through the public methods if usage is needed within any external classes. Reusability and data hiding are amongst the reasons for using this approach.

Example: You will notice with the example that the variables are private and they can only be accessed through the getters and setters because they are public.

public class ExampleMain {
    public static void main(String[] args) {
        User obj = new User ();
        obj.setFirstName("Nomcebo");
        obj.setLastName ("Nzimande");

        System.out.println(obj.getFirstName())
        System.out.println(obj.getLastName())
    }
}

Abstraction: a way of hiding complex implementation details from the users and providing the simplicity of the system at the level the user will be engaging with the system; this can be achieved through abstract and interfaces.

Abstract – We can accomplish this through the abstract class. The abstract class will consist of methods with no implementation as well as those with implementation. The class can then be inherited and the classes that inherit it can override providing that implementation for abstract methods (methods without the implementation). In Java, we use the “extends” keyword to initiate this process.

public abstract class Building {
    public void getBuildingDesc() {
        System.out.println("Building description")
    }
}
public class House extends Building {

Interface – The interface is a class that consists of methods and the implementation is left out for the inheritors of the class, in Java we use the “implements “ keyword to initiate this process.

public interface IBuilding {
    void getBuildingDesc();
}
public class House implements IBuilding {
    @Override
    public void getBuildingDesc() {
        System.out.println("Building description")
    }

Inheritance: refers to when a child object obtains the properties or/and behaviours of a parent object. The parent class is referred to as a superclass and the child class a subclass. Overriding methods is among the reasons for using this approach.

Example: A class called Building is a superclass and the subclasses will be House. I am then able to access the methods of the building class and also add additional methods in the House class.

public class Building {
    public void getBuildingDesc() {
        System.out.println("Building description")
    }
}

public class House extends Building {
    public void getAddress() {
        System.out.println("Richards Bay, 3900, Kwazulu Natal"
    }
}
public class ExampleMain {
    public static void main(String[] args) {
        House obj = new House ();
        obj.getBuildingDesc();
        obj.getAddress ();
    }
}

Polymorphism: also known to most by its definition of “many forms”. The ability of a specific output to be displayed in more than one outcome. This can be achieved through the use of a parent class (superclass) that has been inherited by child classes (subclass) that make use of the same method name with different implementation yielding forth-different results, by using this approach you can achieve runtime polymorphism (method overriding). There is also compile-time polymorphism and it can be achieved through method overloading.

Method overloading - having a method with the same name but accepting different types of parameters (it can be data type or length in parameter changes).

Example: The following is an example: it contains runtime and compile-time polymorphism, take note of the override annotation within the House class it is overriding a method that already exists in the parent class. In the execution, I am executing the getBuildingDesc() within the parent class and I am also executing the getCalculation method which can have two or three parameters which makes use of method overloading.

public class Building {
    public void getBuildingDesc() {
        System.out.println("Building description")
    }
}

public class House extends Building {
    @Override
    public void getBuildingDesc() {
        System.out.println("Building description only for House")
    }

    public double getCalculation( int value1, int value2) {
        return (value1 * value2);
    }

    public double getCalculation(int value1, int value2,
        double value3) {
            return (value1 + value2 + value3) ;
        }
    }

    public class ExampleMain {
        public static void main(String[] args) {
            Building buildingObj = new Building ();
            buildingObj.getBuildingDesc();
            buildingObj.getCalculation(123, 200);
            buildingObj.getCalculation(5000, 200, 12)
        }
    }
}

For this article, these are the only programming basics I’ve decided to cover but there is plenty more to learn for in-depth understanding you can continue to read up more from these links:

• 10 programming principles
• The 4 pillars of OOP

Don’t chunk out your Quality

Being a developer shouldn’t revolve around getting things done quickly with lacking quality. I’ve been on many teams and what I picked up in most instances is the sense that things should just be finished with no care for tomorrow and that type of mentality will cripple you, in some instances, some other teams need to integrate with your service and this shouldn’t be misery for them or any other individual.

As much as ‘your’ piece of work is completed faster, lacking quality and little to zero thought process to the engineering and design of the entire approach to functionality, will cause issues in maintaining and might introduce the issue of scalability (unable to add new code/feature). which might end up in a rewrite of the application or cleaning up your code before adding more features which means more time and money. that overall work.

Yet again getting your piece of work in a longer duration due to fear of failure won’t assist you either. Quality is the main objective here. Quality and code that is appealing to the next set of eyes and bringing life into something that will be stable in prod.

Don’t be afraid to fail

There are a couple of people I know who have made big no no’s! such as deleted the PROD DBs completely wiping customer information (luckily there was a workaround) and have turned into the greatest most experienced professionals I’ve ever met and it was their fallouts and their mistakes that made them legendary.

I’m not saying wipe out a DB but don’t be afraid to be wrong, to be given feedback that doesn’t sound musical – take that feedback with open arms and if you feel it is something you need to work on then take it upon yourself to do that. If feedback is not something that has been presented to you, request it from your colleagues/ the people you engage with regularly.

I can’t emphasize this enough, there is nothing wrong in being wrong, you stand a chance to be corrected. I don’t know about you but in class, I never raised my hand, I would rather go to the teacher afterwards to enquire because I was afraid of being wrong. This, my friend, is not wise in this industry, as much as you are a programmer you are not chained to your laptop you will be required to speak unless you desire to be a code monkey.

I’ve broken things and I still do because how else could I learn, I’ve also said things I regretted and for that moment I wish I could take them back but during my retro state, I realize those were the best mistakes I ever made and there are still more to be made. Just breathe and take it easy and start again!

Experience is the best teacher of all

A very wise software engineer once told me that ‘Experience is the best teacher of all’ and not that I was hearing it for the first time but it sunk in so deep this time because of its truth. What you struggle with now and feel as though the rocks are caving in on you won’t always be the beast you know it to be today. Nowadays some of these monsters that taunted me have become mere puppies.

When you are faced by these challenges, you could adhere to the following steps:

1. Breathe!!
2. Try to tackle it yourself but make sure you time box it - I encourage solving your problem and if you have a pair even better! but make sure you time box it, set aside a time and if you are still unable to get traction within that time move on to step
3. The following might assist in this step:
   • Stack overflow
   • Medium
   • Pluralsight
   • YouTube videos
4. Get Help – It’s okay not to know, even when you do get provided with assistance do try to grasp as much as you can in understanding the solution
5. Share the knowledge - don’t horde all that information, share it with others if the opportunity allows you

Read, read and read some more

There are no shortcuts if you feel some information is just going to crawl out of nowhere with no effort – think again. I might have brought forth certain concepts that are new to some of you, make sure you get a deeper understanding of those concepts, this will also instil confidence in how you relate to your peers offering guidance to them and a more proficient way of communicating.

I’ve highlighted and summarized a few but there is much more to learn and these are not the only concepts that a DEV should know, you have to ensure that you read even more and broaden your understanding. Buff up on your basics to enable a balanced foundation and growth will form from there. There is an article I most recently read about writing robust code, the article speaks about how difficult it is to write code that is bug-free and also speaks to having a proper design, naming conventions, etc. amongst the many other subtopics, I feel it is essential to know this as an individual. Have a read through this as well:

• How to write robust code by Elvis Thelemuka

The Internet has simplified so much for us and provided so many tutorials online, so be the best you can be!

Nomcebo Nomcebo