Employee Ranking System (ERS) – Products and Technology
 

What is an employee ranking?

It’s an ordered list of employees from “most valuable” to “least valuable” derived out of the ERS (Employee-Ranking System)

What’s the purpose of an employee ranking?

It provides a logical and consistent framework for employee advancement, recognition, and rewards.  It can unearth and expose significant inequities.  If used on an on-going basis, it can provide valuable insight into employee performance and development trends.

How is “value” defined?

Different definitions make sense in different organizations.  We will consider three major dimensions – competence, the level of contribution, and value to the business.  In other words, how skilled the employees at what they do, how productive are they at what they do, and how irreplaceable are their specific skills or knowledge.  For each dimension, we will consider both “performance to date” as well as the “potential for the future”.  Since performance to date is less ambiguous than future potential, we will give it greater weight. Potentially this would help you to identify core members of your

What process will we use?

We’ll list all employees in a spreadsheet with some basic demographic information, their previous ladder evaluations, and the staff member they report to.  For each of your employees, you will rate them from 1-4 (4 being highest) in the three dimensions described above. You will leverage the details mentioned in this word document below in order to identify rating 1 to 4.  You’ll do that once for past performance and once for future potential for these three areas.  We will then total the numbers and ladder all engineering employees together, assigning a 70% weighting to demonstrated performance and a 30% weighting to future potential. You can download the spreadsheet by clicking on below link

ERS – Products and Technology Ladder

How should I calibrate my evaluations?

Keep in mind that the evaluations are independent of job level and experience.  The idea is to identify “most valuable” to “least valuable” That is, it is perfectly reasonable and generally expected for junior employees to get lower scores than more senior employees.  In fact, when that doesn’t happen, that’s a sign of either a high flying junior employee or an under-performing senior employee.  In addition, you can look at previous years’ rankings to get a sense of overall calibration.  Then, use the supplementary guidance in the sections below.

How precise will all this be?

Don’t worry too much about the precision of the numbers.  Our goal is to get relative ranking right.  The numbers give us a big head start in aligning our reference points and in creating a single merged list for the whole organization.  Once we have a consolidated list, the leadership team can ensure right people are in the right place.

Any other helpful instructions?

  • Please be careful not to break any of the formulas in the spreadsheet.
  • If you see errors in any cell, please highlight the cell and make the appropriate correction.
  • For the Rating column, enter your best estimate of the numeric performance rating (from 1-5) that the employee will receive this year or whatever your rating system is.
  • For the Promotion and the Performance Improvement Plan columns, enter a “Y” if you believe the employee should be on one of these tracks for the current year. Otherwise, you can leave the column blank.

The ranking would be derived from three core factors

  1. 1. Competence
  2. 2. Contribution
  3. 3. Value to business

Competence

Areas to consider:

  • – Breadth and depth of knowledge and skills
  • – Leadership and innovation, applied to people, processes, and projects
  • – Problem-solving ability
  • – Technical, business, communication, interpersonal skills

Rating 4:
Has mastered all required skills. Demonstrates strong leadership in one or more areas (e.g., technical, project management, process, etc.).  Consistently works to leverage skills for team and larger organization success.

Rating 3:    
Often operates above the norm, with advanced skills in some areas. Often expends extra effort to help meet goals. Has demonstrated leadership in one or more areas.

Rating 2:   
Has all basic skills for job category and uses them effectively to meet project goals.

Rating 1:   
Needs additional skills development to meet job requirements and to attain project goals. May demonstrate inconsistent achievement of task objectives and project goals.

Contribution

Areas to consider:

  • -Ability to meet commitments
  • – Overall productivity and volume of output
  • – Early communication of problems and contribution to workarounds that meets business goals
  • – Versatility – willingness and ability to adapt to new tasks
  • – Teamwork – willingness and ability to help others
  • – Leadership skills such as architecture, project management, change management, communication, and mentoring
  • – Ability to motivate others, manage self, and demonstrate initiative.

Rating 4:  
Someone who has a lot of initiative, is a  leader across the organization, and has outstanding productivity.

Rating 3:   
Someone who excels in 1 or 2 of these dimensions but not all 3.

Rating 2:   
Someone who delivers what is expected (i.e. does not take much initiative to do more), is a team player but not a leader, and has productivity as expected.

Rating 1:    
Someone who is below expectations in one or more of these dimensions.

Value to the Business

Areas to consider:

  • – Knowledge and skills as mapped to needs of the business
  • – Extra points here for unique skills we need

Rating 4:    
A critical person on a high profile project, creating a vision or blueprint for the project or accomplishing critical business objectives.  Without this person, current and future objectives would not be accomplished.

Rating 3:  
A core person on a high profile project.  Without this person, current and future objectives would be impaired.

Rating 2: 
Could be replaced without significant negative impact to the business.

Rating 1:     
The negative impact to the business. Drains resources and causes objectives not to be accomplished.

 

Bloated Domain Objects And CQRS
 

Problem of Bloated Domain objects

In business software applications, the domain objects (entities) are used to represent the business domain. As the application grows and adds more business logic, the service layer, mappers and other patterns gets applied. This sector has held promise for many software developing companies, and has often been touted as the future of work. Often this leads to domain object becomes bloated and the related components become huge & un-maintainable.

CQRS solves the common problem of having a bloated Domain objects. The domain objects get bloated largely because of bounded context. The series of contexts which makes developers think that a single domain object is sufficient to handle all the related things. For example, a large Invoice object for handling Invoice, Shipment and handling change of address for customer . But in reality, these contexts (invoicing, shipment and change) need not be related to same Invoice entity.

What is Command, Query Responsibility segregation (CQRS)?

In order to simplify the Domain objects, CQRS proposes to have two types of domain entities.

  • those serving the command (ordering/assertion services)  – For example, SaveCustomer, CreateInvoice, ShipProduct etc
  • those serving a Query (request) – examples include GetCustomerAddress, SearchCustomer etc

With this separation, the complexity (number of fields, methods) of entities used becomes simplified. And hence the Data mapper layers & the service layers becomes more simplified.

Where can I use CQRS?

  • Largely complex system: Applying CQRS on a simple CRUD operation based system is a over kill. When there is a domain heavy system, like banking and financing systems, LOB applications where business logic, lots of boundary conditions are heavy. Where it makes DDD (Domain driven design) provides high value.
  • Situations where you will apply Microservices, Eventual consistency and Event Sourcing. When we have separation of concerns using CQRS, the microservices becomes much simpler to design and maintain. With Event sourcing we are focused on getting the data (query) from other related sources and is what CQRS propagates.

Final words

CQRS is a carefully thought out pattern for simplifying & solving large and complex systems.

50 Web Performance Tips and Tricks
 

I came across the below video on the web performance improvement tips and tricks. This is fantastic.

In this video, Jatinder talks about Six fundamental principles for improving web application performance. He also talks a lot about how we go about Decreasing CPU time and increasing parallelism on the client machine to achieve faster web performance.

While I went through the video, I captured all the tricks he talks about. And thought will be useful for others while they watch it. Please find below the tricks.

Quickly respond to network request

  • Avoid 3XX Redirections (63% of top websites use redirect)
  • Avoid Meta refresh
  • Minimise Server time for Requests
  • Use Content distribution Networks (CDN)
  • Maximise concurrent connections.
  • Reuse connections – don’t sent connection close.
  • Know your other servers – you are only fast as your weakest link
  • Understand your network timing

Minimise bytes downloaded

  • GZIP Compression Network traffic
  • Persist application resources locally (Windows 8 applications)
  • Cache dynamic resources in the application Cache (html5 app cache)
  • Provide cacheable content
  • Send Conditional request
  • Cache Data requests (jQuery AJAX calls)
  • Standardize File name capitalization convention.

Efficiently structure markup

  • Load pages in latest browser mode
  • Use http header to specify legacy IE mode
  • Link CSS in the top of the page header, never on the bottom.
  • Avoid using @import of hierarchical styles
  • Avoid embedded and inline CSS
  • Only include necessary styles in the page.
  • Always link JS at the end of the page.
  • Avoid linking JS in the header (use the defer & async attribute)
  • Avoid Inline JS
  • Remove Duplicate code (52% of the web have duplicate code
  • Standardise on a single framework

Optimise your media usage

  • Avoid death by too many images
  • If possible use Image Sprites
  • Use png image file format
  • Use Native image resolutions
  • Replace Images with CSS3 Gradients, border Radius
  • Leverage CSS3 Transforms
  • Use Data URI’s for Small Single view images
  • Avoid complex SVG paths
  • Video : Use preview images
  • Minimize media plugin usage
  • Proactively download Future media

Write Fast JavaScript

  • Stick to Integer math (Math.Floor)
  • Minify your JavaScript
  • Initialize JavaScript on Demand
  • Minimize your DOM Interactions
  • Built in DOM methods always more efficient (firstchild, nextsibling methods are faster)
  • Use Selectors for Collection access (document.querySelectorAll)
  • Use .innerHTML to construct your page
  • Batch your markup changes
  • Maintain smaller DOM (less than 1000 elements)
  • JSON always faster than XML (possible myth)
  • Use Native JSON methods
  • Use regular expressions Sparingly

Know what your app is doing

  • Understand JavaScript Timers (setTimeout, SetInterval)
  • Combine Application Timers
  • Ensure dormant timers are not running
  • Align timers to display Frame (16.7)
  • Use window.requestAminationFrame(renderLoop) for Animations
  • Know when your application is visible (document.hidden, Visibilitychange (event))

Conclusion

The web optimisation is not easy and needs exhaustive, deep look and hopefully this check list helps while optimising your pages. Enjoy coding high performing applications. If you have more tips please provide them in the comments.

 

Micro-Services, Eventual Consistency and Event sourcing patterns
 

Microservices is a really becoming a famous architectural pattern that most of the new software written these days, just apply them. One of the most important differentiation between the traditional web services and micro-services pattern is the amount of common stuff across different subject areas. This calls for a discussion on how Eventual Consistency pattern is mandatory for successfully implementing microservices.

The micro frontend if gaining lots of popularity.  You can read about microservices principles and micro frontends at

Microservices and Microfrontends

Micro-Service Pattern

Generally, in a micro-service pattern, the API’s are split into small subject areas. For example for a CRM application, the subject areas are

  • Customer information – like name, address, email, phone
  • Appointment information – which customer, salesperson, when, where
  • Relationship management – sales/manager, what products, interests
  • Campaign data – offers, deals etc

Then micro-services are built for each of the subject areas.  The microservices are logically and physically separated from each other. ie there is no sharing (code, database, component etc) between any of these micro-services of these subject areas. Pictorially its looks something like this.

Applying Eventual Consistency Pattern

In Micro-services, there is no data that is shared across the micro services. In order to synchronize the data across these isolated storages of these services, we need to apply the eventual consistency pattern. You can read more about applying the pattern correctly here. The simpler way we can achieve consistency across these micro-services is through Event Sourcing pattern.

Event Sourcing

Event sourcing is a process of capturing application state changes in the form of events.  An example of events are customer created, customer updated, Deal created, etc.  Other systems listen to these events and they take relevant action. You can read more about event sourcing here.

Conclusion

Event sourcing is the new way of storing changes to systems and help in making micro-services eventually consistent. These patterns together form well maintainable, reliable and scalable systems in the modern world.

 

 

MEAN stack Part 2 – Yeoman and generator-angular-fullstack
 

This is the second post in the Getting started with MEAN series where we start looking at the Node ecosystem for stable web application frameworks for our application. A brief glance through the Express framework showed that express by itself would be time consuming start off with from scratch. On the other hand, the Express.js website links to a number of frameworks built on top of Express. This looked like a good place to start exploring.

Going through the list of frameworks mentioned there, however, we quickly noticed that a number of options were either targeted only (or primarily) towards APIs, lacked sufficient documentation for our needs, or did not appear to have a sufficiently large community behind them. Mind you, the assessment wasn’t entirely objective, as I did have previous experience with generator angular fullstack.

Why generator-angular-fullstack

Generator angular fullstack is a Yeoman generator that provides an application skeleton as well as sub generators that allow the developer to quickly scaffold various UI and API components. The generator supports a number of customizations through questions asked before generating the app. The ones I found most useful were:

Client Side

  • Html templating : HTML, PUG (previously Jade)
  • Angular Router : ngRouter, ui-router
  • Stylesheets : css, stylus, sass, less
  • CSS frameworks : bootstrap (with the option to include UI Bootstrap)

Server Side:

  • Scripts : javascript, Typescript
  • Databases : none, Mongodb, SQL
  • Authentication boilerplate
  • oAuth integration with Facebook, Twitter and Google Plus
  • Socket IO integration

Phew! That was a lot of options built into the generator itself, stuff that teams and products usually like to customize according to their convenience. This by itself is a strong reason to select the framework, because none of the other frameworks that we evaluated came anywhere close in terms of customizability and out of the box functionality. The generator also comes with built in hooks to deploy your application to Heroku or Openshift, although I found that part to be a little broken (more on that later)

A lot of things have changed though, since my last experience. For one, the guys over at generator-angular-fullstack added support for Typescript. Typescript in fact, is a superset of javascript, but brings a number of enhancements (including transpile time type safety) to the table. On the other hand, the generator still works with Angular 1.x, although the alpha version does support Angular 2. But then, working with the alpha version for a project needing quick turnaround times didn’t sound like an exciting thought.

Anyway, coming back to getting started with the application.

Getting Started

Installing Yeoman

 npm install -g yo

Installing the angular fullstack generator and its prerequisites

npm install -g yo gulp-cli generator-angular-fullstack

On a side note, please read node-gyp’s installation guide before going any further to get the application to run successfully. Node-gyp is required to compile native drivers for each platform and on windows, there are a couple of different ways to support the compilation process. Personally, I was able to get option 2 on the link mentioned above working (see: “Option 2: Install tools and configuration manually”)

Initializing the App

Finally! Coming down to the crux of the matter. Initializing the app

Run : yo angular-fullstack

The installer asks a number of questions about customization, including the ones mentioned above, and once the installer has completed, you have a fully functional app (with authentication if you selected it during install) ready for you to work on.

Running the app is as simple as running : gulp serve

You just need to make sure that if you selected a database, it is running on your local box so the node API can connect to it. If the DB is not found, the application will simply crash, but you already knew that would happen 🙂

Stay tuned for the next article about the getting familiar with the code generated by the Yeoman generator

Most frequently asked .NET interview questions for 5 years or less
 
  1. What is the difference between System.Array.CloneTo() and System.Array.CopyTo()?
  2. What is the difference between an interface and an abstract class? Give examples of their use in real life?
  3. Can you use “this” with the static class?
  4. What is the primary difference between “read-only” and “constants”?
  5. What is a garbage collector? Can we force the garbage collector to run? Is that guaranteed that it would run?
  6. What is public, static, void and main?
  7. Can we execute multiple catch blocks written for same try block?
  8. What is the difference between Finalize() and Dispose() method?
  9. What is a sealed class in C#? Explain with examples?
  10. What is the difference between a HashTable and a dictionary? When to use what? Give an example of each?
  11. What is “out” and “ref” parameter in C#?
  12. What is “protected internal” in C#?
  13. What is a “finally” in exception handling? How does it differ from finalize?
  14. What is generics?
  15. What is the difference between a connection pooling and an object pooling? How and where do you set the connection pooling parameter?  What is the default value?
  16. What is multiple inheritence? Is it allowed in C#? How do you achieve that?
  17. What is boxing and unboxing? Give examples of each?
  18. What is a copy constructor?
  19. What is a static constrictor?
  20. What is the difference between overriding and overloading? Give examples?
  21. What do you mean by virtual method?
  22. What types of commets are used in C#?
  23. What is abstraction, inheritence, polymorphism and encapsulation?
  24. What is the relation between data hiding and encapsulation?
  25. What all the access modifiers you have in C#?
SMART Goals – You really have to be smart in setting your goals
 

“Know what you want to do, hold the thought firmly, and do every day what should be done, and every sunset will see you that much nearer to your goal.”
Elbert Hubbard

GOAL – A goal is a description of a condition one wishes to achieve. It is the desired result or possible outcome that a person or a system envisions and commits to achieve.

If there is no goal, there is no direction. “Being happy” is not a goal because it does not describe the specific condition.  Instead, “I would travel to Europe this year” is a goal.

The GOAL should be SMART. This acronym extends to Specific, Measurable, Attainable, Realistic and Timely. This is indeed very powerful tool while hardly used.

S – Specific
If you don’t express your goal in specific terms, it is very difficult to achieve. Moreover, you will never know whether you have achieved your goal or not.

Examples
Ambiguous/Vague  – I want to lose weight.
Specific – I want to lose 5 kg in next 90 days.

M – Measurable/Meaningful
You must have concrete criteria to achieve your goals.  You should be able to measure your result or outcome to ensure you are on track. The goal will be really meaningful when you attach motivation to it.

A – Achievable/Attainable
Goals should be motivating and challenging while do ensure that it’s not virtually impossible.  The moment you define your goals and start working on them, it starts coming closer. Things get easier.  Attainable doesn’t mean choosing very simple goals.  The tough goals stimulate you to do more and expand your comfort zone.

R – Realistic/Relevant
The goals which are not realistic, you are highly unlikely to achieve them. Although nothing is impossible but the exceptions are rare.  For instance, if you decide to go for ACP certification with little agile knowledge, assuming you will read 5 books in 5 days, the chances are fat that you will have a success.

T – Timely/Timebound
It is critical to specify a timeline for achieving your goals. If the goal is for the long term, break them down into smaller multiple goals to hit your ultimate goal. This would keep you motivated throughout the journey. For instance, you want to rank number one blogging site for Agile in 24 months, you can target to get into first 1000 in 6 months, 100 in a year, 10 in 1.5 years and eventually number one in 2 years.

Guidelines

  1. Give a deep thought, identify your goals, discuss if needed.
  2. Write them down clearly.
  3. Review them regularly.
  4. Track your progress.
  5. Update your goals as required.
  6. Take the complete ownership of your goals.
  7. Short term goals need to be more realistic. The long term should be broken down into multiple short term goals.

The “Law of Attraction” principle works very well with your goals. If you constantly keep looking at your goals every day, then the chances of achieving them become very high. According to “Law of attraction”, if you can convince yourself of something, the whole world support you to achieve that.  The self-motivation/self-realization/self-acceptance of accomplishing a goal is more important than putting an effort has been proven many times.

The people will treat you the way you treat yourself.  If you think, you would get promoted and you convince yourself that it would happen, it is very likely that it will happen. In order to convince yourself, you should set SMART goals. This will be one of the inputs for “Law of Attraction” to work. You must have noticed that if you want something desperately and constantly focusing on that, you will just get it. In the process of desperation, you actually work on convincing yourself.

Getting Started with the MEAN stack (Mongodb Express Angular Node) – What is MEAN
 

I’ve been helping out some friends with setting up a new site for their endeavors. The basic requirements were

  1. The site needs to be a ‘single page application’ (SPA)
  2. Should be light weight
  3. Should be easy to deploy to one of the many available hosted environments

MEAN stands for the set of technologies used in application development, much like the LAMP (Linux, Apache, MySql and PHP) stack before it. The technologies and frameworks involved in the MEAN stack include Mongodb, Express Js, Angular Js, and Node Js. From a comparative standpoint, I believe that MEAN is popular today, for many of the same reasons that the LAMP stack gained popularity earlier.

Despite their limitations, both development stacks received a strong push from the community, have ubiquitous ‘Hello, World!’ tutorials, are supported on a number of cheap (and sometimes free!) PAAS hosting providers, and required little to no prior experience to get off the ground, giving instant results with minimal effort. They might not be the best dev stacks of their times, but the sheer inertia from their communities has also played a major role in the two being among the most popular web development platforms in the world today.

Why use the MEAN stack

One of the primary advantages of the MEAN stack that the code is written in Javascript, through all layers of the stack. This means that the programmer’s experience with one language (Javascript), is reused for everything, including persistence and server side code (in addition to the usual client side manipulation using a UI framework, which in this case, happens to be AngularJS)

The other big advantage of having javascript at all levels in your dev stack is that objects don’t need to be marshaled and unmarshaled when moving from one layer to another, usually removing the boilerplate code responsible for such conversions. This also helps developers take advantage of Javascript’s loosely typed nature to manipulate data as and when needed. Considering that Mongodb is a document database, and ‘documents’ don’t really *need* to have a fixed schema, this lines up pretty well with Javascript’s the loosely typed nature allowing us to do some really interesting things.

One of the drawbacks that I have personally experienced, however, of the MEAN stack is that developers with prior experience primarily in relational databases tend to continue to think in terms of tables. Relating collections to tables, and documents to records isn’t wrong, conceptually, but the patterns for relational patterns don’t necessarily lend themselves favourably to NoSql databases. Relational databases tend to have long, mature histories with a standardized set of interfaces and features that a developer can reasonably expect to get if he chooses any of the competing options out there.

Sadly, in my experience, NoSql is nothing like that. Different implementations (read databses) have widely differing ideologies on the ‘Right Way’™ of doing things, and they are correct! This is mostly because each implementation seems to be built for a slightly different use case, that needs different trade-offs to make the system function efficiently (for the chosen scenario). This doesn’t mean the databases can’t be used for anything outside their original intended mainline use cases, just that the default settings for the system may not be the best for you. The minor differences in behaviors also means that again, patterns identified for one NoSql database may not be the best for a different one.

While this may change in future as the stack matures and ‘enterprise patterns’ (I hate that term, but it seems apt for this situation) emerge and become ‘common knowledge’ ingrained in a majority of the developers out there, this is not the case today.

Check out the next post on how we got started.

MEAN stack Part 2 – Yeoman and generator-angular-fullstack