I think it’s not just right to talk about code and the software practices alone. There is more to this what makes the earlier two things go on and succeed. They are skills of different kind. I know that you guys would have guessed it by now – the behavior skills.

Behavior skills in its own is a very vast subject and more importantly it cannot be taught with a chapter in the book for every situation. However, we can make ourselves go through few leanings and stitch them with our previous experience and make ourselves ready for the best and the worst. And every time, it’s the act as per the situation that makes us more convenient and others in the situation more comfortable. So, let’s jump in, but where shall we start? I have the answer!!! Trust me and follow me here.

The first and the foremost of the Behavior skills (BS) is conversing. I somehow don’t want to take the word communication right away and right here, because it’s again a big topic on its own. When we are at a comfortable place, we will start using the word communication. Conversing is between two or more people and in general on a specific topic. So as far as the subject is concerned it’s easy for everyone in the group. However, for the subject to take a route where it realizes (I dislike the word ends-up, because it’s like a narrow mind thought)to become a fruitful discussion is when everyone puts in their thoughts on the subject matter.

But what it takes to make everyone their thought? It’s all about a simple practice of listening to the one who is talking/speaking and the rest giving the full levels of dedication to the one talking. This makes the complete circle of conversing. Yes, A complete life cycle of conversation (sounds pretty similar to SDLC?).

So, we shall put a full stop for this point here and come back with a new line in the next post. Thus, it’s very important that we listen to someone who is talking in the group while we are in discussing, because you might never know that a person who hasn’t spoke at all has a better idea than the rest of the team. See you soon!

Being a software doesn't mean that you always, all time stick to writing code based on the requirements.

Writing code is a job that makes a software engineer stick around. S/E is the one who makes requirements turn into applications. But, how is it that he/she make this change that helps the client's life turn around?

Everything in life is bound to follow step-by-step procedure. Say for example, reaching destination B from A. The step-by-step procedure is get to the nearest transportation mode at place-A. Get into the transport mode and reach-B. But this doesn't merely solve our requirement.

What else will we do? Find what is the best route and the fastest mode of transport available at place-A that makes us reach place-B faster.

Alright, say if this is the requirement for few hundreds of people out there at place-A at the same time. Assume that everyone takes road, hire a car and reach place-B. This leads to blockage of roads at a junction. How do we control the flow? put in a traffic signal and control the traffic. This is called management by laying down few rules.

Thus everything in life has a step-by-step procedure which has some rules that manage the software life cycle so that the life of S/E moves easy and helps him/her develop a better quality product with high quality coding standards.

To achieve this, there are many methodologies/ methods like waterfall, iterative, Agile etc.

Off late the one that gained importance in the recent times in Agile. Though Agile existed for over 2 decades now. management and developers have started believing that releasing little chucks of working code every now and then which shows some result is more important than a disaster that can possibly occur after all the development is done at one stretch.

So in the coming few posts, just to relax ourselves from hardcore programming we shall focus and understand what makes our life easy being a software engineer.

Hi guys,
Wish you and your dear one's a wonderful new year- 2014 ahead.

Continuing our abilities in trying to bring the best of us using our code, we are in the 3rd episode of this. This time around, we will discuss how we can make our code get rid of the red lines.
Red lines? Yes, the hard coded text in C# is in general in red color and so we call it the Red-Color-Phobia.

Red-Color-Phobia.

Many developers have this tendency of hard coding few values, during the process of assigning things, comparing things or while retrieving things.

Example 1:
Say, there is a requirement for an online shopping portal where in, based on the current location of the active customer, a surprise discount percentage has to be offered during the Thanks Giving time.

The developer/ programmer has written this to achieve the requirement.

Var cutomerSurpriseDiscountPercentage=0; Var customerLocation = string.Empty; If(customerLocation == “New York”) {        cutomerSurpriseDiscountPercentage = 10; }

How can we better this code?

Define an ENUM that holds the names of the locations to which the surprise discount s available

enum ValidSurpriseDiscountLocations{ NewYork = “New York”, Detroit, NewJersy = “New Jersy” }

Thus, our code is little modified for a better quality

Var cutomerSurpriseDiscountPercentage=0; Var customerLocation = string.Empty; If(customerLocation == ValidSurpriseDiscountLocations. NewYork) {        cutomerSurpriseDiscountPercentage = 10; }

See you again.

In our previous post episode -1, we spoke on how we can make our variable names can talk and all of them put together can tell their story on their own.

But if we see, in our previous code snippet, we can improve it much more than what it is now. Lets go get it here...

var customersBilledThisMonth; //fill the list here for(int currentCustomerNode=0; currentCustomerNode<customersBilledThisMonth.count;                   currentCustomerNode++) {         if(customersBilledThisMonth[currentCustomerNode].billedAmount>750)        {              Console.WriteLine(customersBilledThisMonth[currentCustomerNode].customerName);         } }

We can see a number in the code, right? Hey, what is this? Have a look at it a little closely...

Yeah!! I get it. It says if the value billedAmount is greater than 750, we enter the IF-condition. 

Okay, now let us make our code better. Let it talk to us on its own.

var customersBilledThisMonth; //fill the list here var currentMonthTotalBillAmount = 750; for(int currentCustomerNode=0; currentCustomerNode<customersBilledThisMonth.count;            currentCustomerNode++) {         if(customersBilledThisMonth[currentCustomerNode].billedAmount> currentMonthTotalBillAmount)        {              Console.WriteLine(customersBilledThisMonth[currentCustomerNode].customerName);         } }

That's it? Not really.
Lets make it little more readable and story telling thing. What if the client want this value to be changed to $900 next month? Open the project, change the code, build and deploy again? NO. So what we do is make it configurable.

Add the below code in config.cs

<appSettings> <add key ="currentBillingAmount" value = "750"/> </appSettings>

change the value assigned to the variable as below

var currentMonthTotalBillAmount = ConfigurationSettings.AppSettings("currentBillingAmount");

Now, add the string that's hard coded into an enum file or a constants file, so that if the name spelled at different areas stay the same and there are no typos.

Observed the change? Now its more easy to understand what the code is doing?

There are many more ways than just this. This is one way of making our code do the right thing than just deliver the mere functionality.

 Yes, its telling its story. Will talk more in the next episode.