Tuesday, October 2, 2012

All time favorite!

Following are some of my all time favorite interview questions:

  • What are SOLID Design Principals?
  • What is SRP?
  • What is the difference between HastTable and a Dictionary?
  • How does a hast table or dictionary work under the hood?
  • Why is string class immutable in .net?
  • What is hybrid dictionary?
  • What are extension methods?
  • When to use an interface and an abstract class?
  • When should ConcurrentDictionary class be used?
  • What is yield key word in c#?
  • Why would you ever need to make a custom class immutable?
  • How does Garbage Collector work in .net?
  • How to make singleton design pattern thread safe?
  • Difference between Lock, Semaphore and Mutex?
  • Difference between Auto and Manual Reset Event ?
  • Difference between a hash table and a table variable in SQL?

Wednesday, December 1, 2010

Why work doesn't happen at work

Must go through this 15 minutes video to understand why work does not happen at work. This would convince you how managers and meetings are road blocks in your work:
hope you will enjoy!

Friday, October 15, 2010

6 Things to do - when you are free

Recently my team released the second phase of a project for which the development was going on for more than 2 years. And the first phase is already in production for around 3 years now. By the end of the phase 2 most the development was done thus nothing much of a work left for a developer like me.
Therefore my today's post is about how to keep yourself busy or what to do when you do not have much of a work to do at office:


1. Attend Trainings:


Since now you have time, try and upgrade your skills, try to learn what are the upcoming technologies. Identify some good trainings that interest you. It is not necessarily be some technical trainings, it could any trainings which will further improve your skills/ knowledge. It could be related to time, process, project management. If you are not able to decide then go for the once which you will need once you will reach to next level of your role, ex: How to track defect density, Various Estimation Techniques, How to motivate a team etc.In a lot of IT organisation, it is also mandatory to attend couple of hours of trainings every year. While doing a training you will also be achieving your annual training quota. Who doesn't like to kill two birds with one stone :-).


2. Impart Trainings:


If you think you are good at some things, then why not share with others as well? It is also one of the ways to enhance what you know already. Knowledge increases by sharing it. Other than enhancing your own knowledge you will also get other advantages -

  • You will get visibility in your organisation, who does not like fame anyway?
  • You will help others in those areas which are your strengths.
  • If you could prove yourself to be a good trainer, you can lend your services to other companies which hires good trainers for corporate training needs.

3. Write White Paper:

While imparting trainings cover only a small segment of audience, you can also write white papers on different technology, business scenarios and upload them to local intranet or internet by which a large audience will be benefited. This way you record your knowledge and can easily refer back when needed.



4. Make tools for your project/team:

Identify some problems or manual work of repetitive nature in your project/company and build some tools to solve those problems. There are always some repetitive nature of work in any project where a human being is assigned to do such tasks. For ex: In my project we follow agile methodology and thus we release the executbales to testing team to test. And there were some manual steps invovled where you need to build the exe's, copy it to a destination, raise some IT tickets for the IT department to deploy the executables etc. Thus I went ahead and created a small windows based application to make this entire process automated.I then also took few screen shots of this application, converted it into a beautiful power point presentation and showed it to my managers and client. Received a lot of appreciations as well. This is the tool now I use to do any release, which is now a job of couple of seconds.


5. Prepare Prototypes:

If you have some innovative ideas that you would like to implement in your project. Then get on to building some prototypes, which could be shown to your manager and peer to communicate your thoughts. This will also prove how proactive team member you are. Please do not worry about how big or small your idea is. Please do not think that this idea is not that great, what if my peers or client would not like it. What matters is you can think about ideas, innovation and have the desire to bring it on the table for others to review and comment. Also keep in mind that at least you thought to do so.


6. Improve Existing Design:

It is also possible that you may think that your application have almost everything that a client needs now what should you do? Well, you have an entire project in front of you. Why not go into the details of how an application has been designed? See if you can find ways to make it more scalable, extensible. Or improve it in any way possible. Trying to look for the ways to improve an existing design does not mean that you trying to find fault in anyone else's code. You are doing it for the larger benefit of the project.

Saturday, October 9, 2010

What about uint?

Why is List.Length an int, and not an unit? This bothers me (just a bit), because a length value can never be negative, can it? You will never have Length property return you a value which is less than 0.So the questions is: Is there any use for an unsigned int (unit)? Even Microsoft seems not to use it.
One of my old friends writing a class with several methods that take integer input. The input values cannot be less than zero. Since we are not on .Net 4.0 yet, he is manually writing code contracts (that is, the function checks preconditions, i.e. before doing anything else, actual value is checked)if (EngineNumber < 3)
{
   throw new ArgumentOutofRangeException("EngineNumber", "Engine number must be 3 or greater");
}
This got me thinking: why don't we ever use unsigned integers? Seems like have a uint would better communicate the requirement, and would simply not allow a negative number. The main answer seems to be that casting between uint and other data types, which is inevitable, is ugly. And that uint is not CLS compliant.

Sunday, October 3, 2010

The Boy Scout Rule

Recently I heard aboutBoy Scout Rulethrough one of the presentations by Robert C. Martin. I must say on a high level one may say that this is more of a common sense to follow this rule. And probably there would be people who are already following this rule in the name of common sense and may not know that this common sense is actually termed as Boy Scout Rule. But I admit I could not apply this common sense prior to hearing about this rule...

This post is for those who do not know or hear about Boy Scout Rule already. The basis essence of Boy Scout Rule is to make the code cleaner every time you work on it. Wonder how...? Keep reading...

How often it happens that we may work on a piece of code/ module which you think needs some (if not more) rework. Rework in terms of following code conventions, removing duplicate code, to remodel it to make in more OOAD oriented design, to add comments for a complex piece of funtionality or even remove comments if they do not help much.

But the question is how often do we go ahead and make those changes. Some may say always, some may say sometimes and some may say never - fearing that

1. It may have some adverse affect on rest of the functionality or system all together.
2. Project is on tight timelines and there isn't any time to fix the code which somebody else has written.
3. Or we just do not want to take the pain to fix it (if this is the case then no rule can help it ;-))

I agree with these points and I think this is where Boy Scout Rule can help. The rule simply states that whenever you work on a code file try to make small change in it to make it better before you check it back in. The change could be as small as adding some comments for an uncommented function, variable or renaming a variable to make it more meaningful. So that the next time when a programmer works on that code s/he would get a little bit cleaner code than before. Keep following this practice untill all your code bases becomes cleaner.

Imagine if entire team starts to follow this rule, how quickly your code will start to improve by making small small changes at a time.

If you follow Test Driven Approach (TDD) then this rule can do wonders for you. Because with each code enhancement that you would make, you can simply run your unit tests to see does it break any tests or not.

I have now started following this rule and can easily see the advantages of it.

The other, side advantage of this Rule is: You can break the ice by starting to talk about this rule with-in your project team to impress them with your thoughts :-). However do not forget to give credit to Robert Martin