I am speaking at Seattle Code Camp and my session topic is “How to use Agile correctly“. It’s totally FREE community event. Please register and spend the weekend in learning all you can.

My session will be in Room#204 at 1-2 pm.


Technical Debt is a term that is commonly used in agile-scrum team process. Technical debt is used for the work which team or an individual didn’t prioritize upon while pushing the deliverable, and  either left some unwanted code in various project artifacts, such as – .cs, .config, .cshtml, .js, .sql etc. or didn’t use the right technique to accomplish the goal. But in real world software development process this is expected and totally fine as long as team takes the responsibility to pay off the Technical Debt.

How is Technical Debt created?

Technical Debt is like financial $$ debt; if you don’t pay off previously owned $ amount but keep borrowing more than you are getting into messier situation. I assume you are not the one who like debt that much; whether it is technical or financial. Anyways, just to be aware; if you don’t take good care of the following items then you are potentially seeding “Technical Debt” situation in general, later on which needs to be paid off.

  • First and foremost poor coding style and standards.
  • No unit test cases.
  • Not following OO design principles.
  • Developing long monolithic classes and code libraries.
  • Not envisioning on proper candidate technology, architecture or approach and then hitting a wall. I.e. when application is little bit mature you start to feel the hit on User experience, performance, scalability, code maintenance etc.
  • Over engineered application. I.e. things which can be done in simpler way are done using very complicated mechanism. For instance, to do encryption data, custom code is written or taken from internet which causes a lot of security holes and performance hits.
  • Code files has a lot of comments. I.e. code is completely documented. Many developers write few lines of comment for each line of code.
  • Code is not self-documented. I.e. Classes, functions, variables etc. are given improper names. For example, a function is named Salary instead of EmployeeSalary or a variable is called double sal instead of double employeeSalary.
  • Shortcut approach is taken to push the functionality to meet the code complete deadlines. Such events trigger further refactoring to be performed later. For instance, created one thick bulky Model class with a lot of classes within. Or hard coded various paths and endpoints into the .cs code rather than putting those into a web.config and reading web.config Key in the code for the related value (key-value pair).
  • Dead code in project. You must have seen or left some commented code in various code files. This is dead code and needs to be cleaned up.

Based on above mentioned points, now you will be able to understand that why Technical Debt is also known as Code Debt or Design Debt. In addition, anything in your software development work; which slows you down or looks odd, or can be improved is a “Technical Debt”.

How to handle Technical Debt

First step is, not to cause any technical debt from your end; if at all possible. However, in agile development it’s common to have some technical debt accumulated over the period of time, if so then move to second step. Second step is to report any technical debt which you have either caused or came across.

Please don’t get into blame game or point finger to any individual. Let’s say you come across some code blocks in a file you are working on and then you see some dead code. Rather than start cleaning it up, I recommend create a Technical Debt item and let the team decide.

How to Report Technical Debt

Technical debt items are usually reported as Issues or as a “New Product Backlog Item”. Also, Technical debt items are supposed to be logged in a separate backlog. I.e. don’t report those to Production or sprint backlog. In many teams and as per my experience with agile-scrum I have always worked on a separate dedicated “TechnicalDebt backlog”

Having a separate TechnicalDebt Backlog allows the team to stay focused on Sprint backlog and don’t interfere with business requirements which are logged in the Product Backlog.

Creating Technical Debt backlog

Creation of backlog and modifying process templates etc. are usually done by an admin on your team project. In an agile team setting this duty is usually performed by the scrum master.

If your team doesn’t already have a Technical Debt backlog, then it’s time create one.

  1. Go to VSTS (Visual Studio Team Services) Team Project’s Web Portal and in control panel under work, click on Areas.

  2. Under the “Areas” click on “New child”

  3. Name it as “TechnicalDebt_<YourTeamProjectName>”. TechnicalDebt prefix helps you differentiate it with other areas and makes it self-explanatory.

  4. It will now appear under your Team Project as an area.


Let’s see it from Developer’s angle

Developers usually interact via Team Explorer from within Visual Studio IDE.

Select Work Items and then click on “New Work Item” and based on your team process template; usually either Agile or Scrum, you can select Product Backlog Item or Impediment or Issue as item type to report the Technical debt.

Filling in the details

Usually, any item in any backlog needs to have ample information to describe what the issue is. In the below example, it is briefly pointed out that some classes need code cleanup. Some questions might still be unanswered and those will be discussed during backlog grooming and sprint planning.

When to work on Technical Debt

Just like Product and Sprint backlogs, Technical Debt backlog also needs to be groomed I.e. each “Technical Debt” item needs to be reviewed and groomed by the team to identify its validity, impact on overall team’s development experience and software quality team is producing. Once, team is in agreement to pay off a technical debt item or items then those items are transferred to Sprint Backlog and many times a new User Story is created for each technical debt.

Many Agile experts say that a team must not carry Technical Debt beyond a sprint, just like you should not carry Credit Card balances over to next pay period. I.e. pay off full Credit Card debt in the same billing cycle. But, it’s not always possible, so it doesn’t happen in software world for Technical Debt as well.


I personally recommend that as a developer you should not cause any technical debt due to the code you have written or currently writing. Be honest, about any improvements your code might need and explicitly call out what changes can be made to make it better. Avoid any over engineering or unwanted design patterns and technology implementations to be called out as Technical Debt. If you are not sure whether a particular code / technique is Technical Debt or not, call out a short brain storming session. In today’s software development industry it’s not easy to avoid technical debt, we all live with it, but be aware that you have to get rid of technical debt to achieve complete Technical Freedom.


Please Rate and comment the Video on Channel9



.NET Core is new Microsoft Platform for cross platform development and many more other features and great offerings to developer community. Read more on .NET Core in my previous article on my Blog or on C# Corner .

“Today 06/27/2016 Microsoft has released .NET Core RTM, this is a great milestone for .NET Core team and entire .NET Community.”



Let’s prepare to install .NET Core RTM

If you want to install .NET Core on Windows then follow the URL www.dot.net or https://www.microsoft.com/net/core#windows all the dependencies are mentioned on the download page but one extra thing which you need to have it Visual Studio 2015 Update 3. You download Update 3 from https://msdn.microsoft.com/vs-knownissues/vs2015-update3-rc

Launch the .NET Core RTM setup

Once you have installed Update 3 and downloaded the DotNetCore.1.0.0-VS2015Tools.Preview2.Exe then just launch it and you will see setup going through following steps.

Accept the License terms and conditions


Installing .NET Core 1.0

Installing ASP .NET Core 1.0

Installing Nuget- Visual Studio 2015

Installing ASP .NET Web Tools

Preparing Visual Studio

Hurrah, Setup Completed

Let’s fire up Visual Studio 2015

When you will launch Visual Studio 2015 what you will be looking for is “.NET Core” templates as shown in the image below.

Also under Web you will notice .NET Core templates

Create a new .NET Core Application

When you select a new .NET Core template and proceed with it, you will see a new project artifacts which are specifically designed to keep .NET Core’s cross-platform vision in mind.


What is .NET Core

.NET Core is a new Microsoft platform. Which is modular, cross-platform, open source and have better support for cloud. .NET Core will continue to run on Windows devices, as well as on Linux and Mac OS X. In addition, unlike the .NET 4.6 which is installed machine wide as single large block, Windows-only runtime environment, .NET Core can be used to create modular libraries and applications that can target multiple platforms and deployed (per-application) along with the application itself.

Why .NET “Core”

Microsoft’s vision of .NET platform evolved over the past 15 years and many technology enthusiasts, leaders and influencers wanted .NET to be open-source, available to other platforms like Linux and Mac in addition to currently and widely supported Microsoft Windows.

To accomplish this broad and such a large goal and vision it was necessary to have a “fork in the road” and create a fresh and new version of “.NET” which is named as “.NET Core 1.0”.

Hence, Developing application using “.NET Core 1.0” will enable and empower the developers to write applications with one platform for instance Microsoft Windows and when all ready that can run on multiple platforms in this case Mac, Linux and Windows of-course.

Why Version “1.0”

Current and latest .NET Framework version is 4.6.x and so next major release version was supposed be “5” and initially it was called .NET Core 5. Similarly next version of ASP .NET 4.5 was named ASP .NET 5 and next version of Entity Framework 6.1.x was named Entity Framework 7, fair enough.


But this numbering order conveyed the message that these are just next version of the same framework and technology; whereas the reality is different. “.NET Core” concept is totally new, YES! Its brand new concept hence numbering has to be re-started and so…

  • .NET Framework 5.0 is now known as “.NET Core 1.0”
  • ASP .NET 5.0 is now knows as “ASP .NET Core 1.0”
  • MVC 6 is now known as “ASP .NET Core MVC”
  • Entity Framework 7 is now known as “Entity Framework Core 1.0”

.NET Ecosystem

With new launch of .NET “Core” wave of framework and technology, old version .NET 4.6 (which are mature and fully grown) will continue to co-exist. .NET Core can be installed on the same machine. However, .NET Core will have its very own personalized core libraries etc.

.NET Core Includes CoreCLR, a more lightweight runtime that provides basic services to your application including automatic memory management and garbage collection, along with a basic type library. Unlike .NET 4.6 which has such a large footprint for the same.

.NET Core also includes CoreFx, a set of modular assemblies that you can add to your project/application as per demand. Unlike the .NET Framework 4.x, which always had to make the entire .NET Framework Class Library aka BCL (base class library) available, with .NET Core you can select only the assemblies that you need. I.e. Windows doesn’t need Web and vice-versa.

.NET Core implementations

Following technologies are currently available in .NET Core wave.

  • ASP.NET Core. ASP.NET Core is a modular version of ASP.NET that combines ASP.NET MVC and the ASP.NET Web API. It runs on both the .NET Framework 4.6 and .NET Core 1.0. It is custom designed for building high-performance cloud applications. ASP .NET Core should not be considered and taken as a replacement to ASP.NET 4.6 in the .NET Framework 4.6.
  • .NET Native. .NET Native is a compilation and deployment technology for Universal Windows Platform (UWP) apps written in C# and Visual Basic .NET. “.NET Native” compiles apps to native code, and statically links into an application’s assemblies only those code elements from .NET Core libraries and other third-party libraries that are actually used.
  • Universal Windows Platform (UWP) apps. The Universal Windows Platform allows you to build a single app that can run on the Windows desktop, Windows tablet devices, and Windows Phone. These apps can also be placed in the Windows Store. UWP apps are compiled to native code for their target platforms by .NET Native

Supported Environments

.NET Core is supported by Microsoft on Windows, mac OS and Linux. On Linux, Microsoft primarily supports .NET Core running on Red Hat Enterprise Linux (RHEL) and Debian distribution families.

.NET Core currently supports X64 CPUs. On Windows, X86 is also supported. ARM64 and ARM32 are in progress.

A wide array of all the supported platforms is shown in the Table below.

OS Version Architectures Configurations
Windows Client 7 SP1 – 10 x64, x86
Windows Server 2008 R2 SP1 – 2016 x64, x86 Full, Server Core, Nano (2016 only)
Red Hat Enterprise Linux 7.2 x64
Fedora 23 x64
Debian 8.2 x64
Ubuntu 14.04 LTS, 16.04 LTS x64
Linux Mint 17 x64
openSUSE 13.2 x64
Centos 7.1 x64
Oracle Linux 7.1 x64
Mac OSX 10.11 (El Capitan) x64


Which one to choose .NET 4.6 or .NET Core

.NET Core is not yet mature, until it’s fully mature and time-tested; in my view it’s not advisable to start building Enterprise LOB (line of business) applications using .NET Core. Hence, .NET 4.6 and ASP .NET 4.6 are more mature and time-tested until .NET Core becomes mature.

The Future of .NET

“.NET Core” is certainly the future of .NET Platform. But we are not there yet, it will be a while until this is widely accepted and industry really start to mold and accept its advantages and become more open to build light-weight, cross-platform applications using .NET. However, Microsoft envisions to continue with ASP .NET 4.6 as well. Reminder, ASP .NET Core 1.0 is NOT AN END for .NET 4.6 /ASP .NET 4.6 instead it’s a NEW BEGINNING.

Introduction to VSO

VSO (Visual Studio Online) a cloud based collaboration tool (can be considered as TFS online). VSO provides a set of tools that work with Visual Studio to effectively manage your application.

VSO Capabilities

VSO offers various capabilities which various team can utilize to build great software and really depend upon.

  •   Version control.

  •   Tools for Agile Software Development teams

  • Continuous Integration

  • Support for even Non-Microsoft Languages and Tools

  • Integration support for various 3rd Party Tools

  • Infrastructure Grade SLA

Note: All above images are taken from https://www.visualstudio.com/products/visual-studio-team-services-vs

Back in 2008

I do remember the earlier days when Microsoft 1st started this concept of VSTS (Visual Studio Team System).

You can click https://www.microsoft.com/en-us/download/details.aspx?id=16338 to visit the page as shown in image above

On-Premise VS Azure

Many work places have applications which they want to have access to anytime, anywhere and continue to build the applications using integrated, powerful, cross-platform, enterprise-level Agile tools ; so team(s) can share source code, build often, test early, and ship faster with less time to market.

Like many software companies “on premise” source control in form on TFS on their own servers has served the business need. Whereas for many cloud was the choice to set up a Team Services account,  connect their dev tools, share code, invite team members, and start working.

In these business scenarios TFS and VSO has been an answer respectively.

Rebranding made is meaningful

Recently, Microsoft re-visited the Branding idea of VSO and renamed/re-branded it back to VSTS. But now “S” is not System instead it’s “Services” as this is Azure based solution hence, Services make complete sense. I.e. VSTS (Visual Studio Team Services) which is Software-as-a-Service offered by Microsoft for organization’s ALM needs.

  Note: This image is taken from https://www.visualstudio.com/products/what-is-visual-studio-online-vs?WT.srch=1&WT.mc_ID=SEM_MqzVAfsq


In my view VSTS provides better value to development team(s) and better ROI to management; as it enables and empowers the developers to collaborate anytime from anywhere. In addition it helps the organizations to reduce / cut-down the DevOps cost and needless to mention Zero investment into serves/disk spaces. Whether you are a dev using VSTS or on-Premise TFS you are not missing any features and capabilities from any of the flavor, VSTS is just a preferred/better way (in my view).


This article provides a broad overview of review process for the code written in C# using Visual Studio 2015 and also uncovers best practices for code review. Code Review is a very important part of any developer’s life. Code review is a technique which allows another developer (not necessarily working in same team or same feature within a team) to go over-n-through your code line-by-line and identify areas for improvement or point out holes.  Hence, code review is a process and not a technology. However, there are some tools available (covered later in this article) which can enable a developer to write good quality code.


There are numerous guidelines and best practices software development teams follow and depend on. This article will uncover most of those but it may not cover all the best practices around code review. However, I want to assure you that all the guidelines mentioned below will help any individual to practice and apply good coding principles and perform a quality code review.

Is it must to have my code, reviewed by other dev?

Well, you must. But it depends on your team’s development methodology and ALM (Application Lifecycle Management) tool settings. There are ways to by-pass the code review by simply just not doing it and straight checking-in the code. It’s not recommended though.

What if my code is not reviewed?

It’s hard to say, but at times and in some cases it might cause serious issues and raise concern for the whole team. For instance, a condition check is missed, or null is not handled properly or not all error situations are being handled by your exception handling block. Well, these examples might sound very simple and most of the developers do write defensive code and cover such aspects. But what code review can also provide value towards is your “design”, “techniques”, “patterns”, “approach” etc.

How to find a code reviewer

I have worked in various team settings and work environments. Many times I have been invited to perform a code review for a developer who is not part of my team or rather I am not part of their team. But what I admire and appreciate here is the fact; that someone reached out to another dev in case of their team’s developer is either not available or busy with critical production issue etc. Such mindset empowers the team to deliver the best written code.

Let’s Begin with Best Practices of code Review

Here, I am going to list out some areas which are critical from code review perspective. I tried to highlight the core best practices which are must in any code review. I have seen many times that in a code review developers are more focused to look for code design patterns or some areas in code review and then try to convince

1- Project and File names

Many times developer’s only focus on code, but in my view your Project name, file name etc. also matters a lot. It’s not sufficient to deliver well written functional code; a well-defined project and file name is equally important and brings a lot of clarity by offering a sense of purpose being served by solution, project or a file. For instance see the solution and project name in as shown in the image below.

Figure-1: Properly named Solution and Project

2- Always begin from the top

Before you really start scanning through the code blocks/statements in a class (.cs) file; I would recommend that you must 1st look at the “using” statements in any .cs file. I have personally observed that many times developers add numerous “using” statements while trying various code blocks to achieve the functionality. But once that functionality is accomplished; many developers tend to forget about cleaning up references of those “using” statements which are no longer needed now and must be removed. Visual Studio 2015 show unused using statements in grey color which can be safely removed as shown in the image below.

Figure-2: Un-used using statements are grayed out by default in Visual Studio 2015

3-  Sort all the using statements

Usual development practice is that we keep adding new using statements at the end of previous ones, for instance as shown in the image below.

Figure-3: Newly added using statements

Let’s assume that code is consuming all of the added using statements, but the issue is that these are not sorted. One of the coding best practices is to Sort all using statements. To sort using statements right-click in code editor windows and click on “Organize Usings” then click on “Sort Usings”.

Figure-4  Sort Usings option in Visual Studio 2015

After performing the “Sort Usings” all the using statements will be alphabetically sorted (this is the only order A – Z) and will be arranged as shown in the image below.

Figure-5 Alphabetically Sorted Using statement

4- Don’t just ignore warnings

As a developer we are more focused on compilation errors and want to see that project/solution build successfully. For instance, consider the code as shown in the image below.

Figure-6 sample code

This is a very simple code and project will build successfully without any compilation errors. However, as you can see that “j” is used nowhere in the code and so this will cause a warning; which many developers doesn’t seem to care about. In my view and as many software companies including many Microsoft teams I have worked with enforce 0 warnings policy before check-in. Hence, it is very important to look in detail at the “Error List” View menu à Error List, and then observe Warning Tab and must try to have that also show “0 Warning” just like we always work to only see “0 Errors”.

 Figure-7 Error List, highlighting warning in the code

5-  Code Consistency

One very important quality of well written code is “Consistency”. I.e. stick to one style. Let’s say that you want to declare an integer variable and it’s obvious that different teams and developers will have different coding guidelines. Many times developers ignore this and code has scattered instances of types/keywords Int32 or int and String or string, this demonstrates that code consistency is violated. However, using mixed statements will successfully compile the code but makes your code base completely in-consistent. 

Figure-8 Code consistency violation

6-  Do care for Null all the times

Null has catastrophic impact on your code functionality. Simply a null check ignored and you will face the consequences. This is why many developer productivity tools like Re-Sharper prompt for any potential “NullReferenceException” which can be triggered from your code. Make sure that all your if/else do take enough care of null and have guard(s) in place, most of the times IsNullOrEmpty or IsNullOrWhiteSpace will come really handy.

7-  Dead code

Many times I have seen that as a developer we are mostly interested in our own code; to be specific, code we are writing. At times we do observe a block of code which is commented for long, but we don’t seem to care, but why not?  Well, in my view there are two reasons for this. First, I don’t care as long as my code works. Second, I am working in an agile team and I am committed to finish my task in committed timelines. First one is an attitude problem, second is timeline and hours remaining to complete the work. But both can do one thing for sure. Open an item in Technical Debt backlog with details to have that file cleaned up.

8-  Naming Convention

All developers today are well aware of Camel and Pascal casing and when to use one over the other. For instance variable and parameter names must follow Camel casing and for class, function, and method names Pascal casing must be used. Make sure this basic principle is applied consistently.

9-  Code Readability

Many times code is written in a way that anyone can hardly make sense out of it. I.e. all code is so jumbled up and one line after the other that it’s barely readable. Make sure that code has proper Single line spacing wherever applicable between the code blocks.

 10-Handling Unmanaged Resources 

Even though .NET Framework takes good care of Memory management via GC (garbage collection) but there are limitations on what all garbage items and from where those can be collected and what not. Many times, it’s wise to handle cleaning of expensive resources like File I/O handles, connections, Network resources, etc. by yourself. Such items can be disposed of once their usage is over and this can be done using the “using” block for unmanaged code, if you want to automatically handle the disposing of objects once they are out of scope.  Another good place to handle such code is finally block for example, File I/O operation to read a file as shown in the image below.

Watch my YouTube channel video on FIle I/O here:

Figure-9 Handling unmanaged resources by .NET’s StreamReader

11-    Write Defensive Code

.NET Exception Handling is the key to write defensive code and protect your application against any runtime anomalies. Three magic words to solve most of your problems are try/catch and finally. Proper implementation and usage of Exception Handling and logging any exception messages and details can add a lot of value to application in terms of application monitoring and troubleshooting.

12-    Declare access specifiers explicitly

C# .NET has default scope defined for various types for instance a variable is private by default and so in a class we like to write just “int i” but it’s more appropriate to be declarative and instead write it as “private int i”.

Do you know what default scope of a class is in C #? Watch my YouTube channel video here 

13- Self Documenting code

Many times developers do follow naming convention (camel or pascal etc.) but the given names to variables, methods, functions and class etc. are not meaningful at all. Hence, at times developers write long code comments to describe what is the  purpose of each function or variable for instance. In my view, giving “self-describing” names will add a lot of value and also save developer’s time in documenting the code; as many software teams have a practice of writing comment above each line of code to explain the objective of code below. For instance, instead of “int age;” you may want to declare “int studentAge;”. Similarly, instead of just writing a function with name “GetData()” it will be preferred and more helpful to say “GetStudentsReportData()”. Similar techniques can also be applied to class names, functions and Unit Tests etc. But in case of unit tests, name(s) might get really lengthy, but this is totally fine and acceptable. Hence, a unit test method name “TestSuccessWithOneStudentRecordAddedToDb” will be much preferred than just saying “TestOneRecordData”.


Above mentioned code review guidelines are light weight, easy to look for and easy to apply techniques with larger impact on any code base.  Mostly it has been evident that simple things are either ignored or not cared about. These best practices can be added up with more guidelines or in combination with other techniques as applicable. Happy Coding…

Sybase is another Relational Database Management System (RDBMS), it has long well established history.  Today Sybase is part of SAP (Since November 2012). But in earlier days Sybase and Microsoft has worked together.

In 1986 Microsoft and Sybase worked together to build a product called Ashton-Tate/SQL Server 1.0. Later in 1993 they dissolved partnership and Microsoft got the code base of SQL Server side of the product and continued their investments into it to have it more adaptable for Windows.

As Sybase and SQL Server has same roots and the core code base which is closely tied with each other then it’s safe to assume that their syntax is very close to each other if it is not 100% same to same.

Besides, I have worked on Oracle in quite detailed level and then I completely focused on Microsoft Technologies. While working with SQL Sever I learned that all databases are derived from some standards like ANSI SQL. Hence, syntax of any two database won’t be much different and besides all of those have support for same database constructs like JOINS, SETS, Query Operators etc. including db objects like Tables, Indexes, Views, Triggers, Stored Procedures etc.

However, I can say that some database may showcase different syntax over another, for example I recall that in Oracle 7.3 for Left Outer Join the operator was “*= ” whereas in SQL Server you can say “LEFT OUTER JOIN”.

So, if someone is really focused on Syntax part and hard core fundamentals concept then it is very easy to reduce the learning curve of any new technology.



After many years in IT industry I have personally experienced and learned from other’s experience that; it’s up to us that how someone can make us feel about our self. In my long tenure in IT industry there is not a situation I have not been through. Today, I thought of providing some insight and share some common issues and counter approaches to those.


Be informed that I didn’t mean to target any person or group or a title or role in IT industry. All the points below are my personal experiences and what I keep hearing from my connections in various continents across the globe.

I hope you will be able to read between the lines and apply some of the suggestions and work on building a better career.

My wish for you

I do wish all the success and happiness to all of you, and I really do. I also wish that you have a great future and career path.


Learning from Past

Resolution for New Year 2016

1 Don’t sit late in office. When you do that, you encourage wrong expectations. However, there are always exceptions. Reach the office on time and leave the office on time. This will allow you to spend time on yourself or with family. Be aware that sometimes critical deliverable, production issues, etc. may push you to start early and finish late.
2 Don’t be afraid of losing job and live with this fear year after year. Always remember that companies need good resources, so your job is to bring value to the company and team and stop worrying about it.
3 Be nice but not weak Don’t encourage bossy behavior in the team from anyone. Be nice and polite, but stay strong at the same time.
4 You say “YES,” when actually you wanted to say “NO.” Listen, plan, and then act accordingly. Even if you have to say “Yes”  then understand the expectations before you commit on such a task.
5 Asked to work on an unrealistic deadline Your hard work bring value to company and team. Many times working on tight and critical deadlines require a lot of planning, dedication and focus. Be ready to go above and beyond and if this is not your cup of tea, then let your superior know.
6 All your work’s credit was either stolen or given to others. Make sure that your work is properly recognized and appreciated. Don’t allow anyone, I mean anyone, to steal the credit of your GREAT work and white label that with their name.
7 You don’t think proactively and plan your career. Come out of this “job” mindset and think more in terms of  a long term career.
8 You learned nothing, or very little. Learn the technology of your focus area;  this year buy more books and read at least 50% of each book(s) you have.
9 You didn’t focus on your weaknesses. If you know your weaknesses, then work on those this year. A little progress on a daily basis will reap great results.
10 You don’t have a link with LinkedIn. LinkedIn is a good social media resource to connect with like-minded people, join technology groups and read articles etc.
11 You have no time after your job. I would agree that you must have been very busy with office work. I suggest that stop time-management; instead, manage your focus this year.

Shift your focus from job to career, and every day when you go to work, look for what will help you build your career.

12 Everything is good and you are comfortable.
Remember, the enemy of the best is not the worst, it’s what is merely good. So if you think you are doing well and you’re comfortable then you are at the wrong place, and this comfort zone is a sweet poison. So seek knowledge, challenges, and growth in your career.
Seek challenges in your current role, try to learn what it takes to own/observe more responsibilities.
* Learning Resources Read More Career Related Articles Here…
Listen Career Realated Podcasts Here…


Based on above points, I trust that all of the points may or may not be applicable to everyone and it would rather be case to case basis; and upon self-realization of an individual. Hence, I do suggest that use this information as a tool and seek if you can get benefited. It’s very important that you read between the lines and get the right context from each suggestion I have provided.