SharpDeveloper

Change of atmosphere is actually a much faster way to learn, as I recently found out due to a job change.  A lot of time spent in the same environment working with the same people and learning stagnates.  If you really want to learn something different, be bold, take a risk, and change jobs.  Another factor is type of company - changing company types can increase learning speed by working in a different environment.  Technical skills are not the only skills that matter, so keep that in mind.  By looking at how different companies work together and achieve goals is a learning experience in itself.  I was concerned that moving from a team with many talented developers to moving to a team of one developer (me) my learning would stagnate.  However, this is not the case.  I feel like I’ve learned so much in the last few days just by being in a different environment.  Take risks!  Be bold!

Factors to note

- Background of those you are working with
- People who you are working with (non technical)
- Location of new job/environment
- Number of work hours
- SMALL or LARGE COMPANY
- Technology used (is it old, is it new… )

You can find a lot of these things out by asking in the interview.  There are implications for each one of the factors above.  For example, large companies are more resistant to change.  They are usually late followers in adopting new technologies.  However, some people feel that in large companies they have job security…  So it all depends.

I think Justin of CodeThinked (a nice .NET blog that I subscribe to) sums it up pretty well why he changed jobs.

Keep in mind we humans are fussy beings.  We don’t like change (most of us, anyway).  You might find a lot of things uncomfortable in your new position.. It will take a while to adjust to the new area, new coworkers, new boss, and so on.   But hey, life is about taking risks, right?  Can’t be complacent all the time.

1. Appoint a Leader
2. Leader makes council with the team
3. Leader makes a decision
4. Team supports leader in his or her decision

To management, the idea of outsourcing sounds very sexy…. The idea of producing the same content (code, or what not) at 1/2 or 1/3^rd the cost is almost a wet dream for management, if I may be so bold. Even though it sounds great in theory, it’s actually a very tricky function to master. Here are some things I have learned with my outsourcing experience.

Keep in mind I am not discussing the outsourcing style of passing requirements and getting the end product complete. I am discussing the style of hiring outsiders and working with them on a daily basis.

You have to start by looking at what is the purpose of outsourcing. Is it to save money? Or is it to improve quality? Or is it so that your team can focus on other things? Get this straight first before going any further. My points below are in the context that you are a software company (or at least do some software development) and you are considering outsourcing to save money and cut costs.

From friends, I know that some very popular companies outsource, such as E-Trade Canada, Accenture, and recently the new online T.V. web site Hulu which outsourced its development to China.

1. Before you start outsourcing, have your process solid - i.e. have regular scrum, know how much code you are generating each week, and so on. It’s very important that you have some idea of costs for developing software for your local team. If you have no idea, you won’t be able to see if you are really saving money or wasting it.
2. Know velocities of individual team members so you can measure cost effectiveness of your outsourced work.
3. Build your estimation skills. Read Joel’s article on estimation and his second article on estimation (which is really a promo for his bug tracking software but still worth reading) and Steve McConnell’s book on Software Estimation (highly recommended, very easy to understand).
4. Get smart/able/competent guys. This can make or break your outsourcing project. If you are going to get developers that need baby sitting, then hire a baby sitter on their end to clean up their code, otherwise you are going to waste your valuable resources fixing and re-fixing and re-fixing their code. In this case you might not be actually saving money.
5. Review their code. Someone on your side is going to have to review their code to make sure that they aren’t purposely obfuscating it in order to secure their jobs in the future. I have seen a Flash application that was built in this manner, the team overseas purposely messed up the code in such a way that it would be difficult for others to continue where they left off.
6. Learn from those who have done it before. If not, you are going to mess up big time, in many ways. Might be worth getting a consultant who has been successful with such projects. Another idea is to find someone who has connections "back home", and go there to see how some of the shops work.
7. Turnover is really high in India/Bangladesh/ and so on. This is because jobs start at really low salaries (like $200 a month) and go upwards to like $3000 a month (comparable to working in Canada or USA). You will need to find a way to solve this problem. Somehow you will need to get them to commit that guys will not drop like flies. This is so important because there is always an upfront cost to learn an application, and it becomes more as the complexity and lines of code increase.
8. Consider a cross-cultural learning program, you send some people there for a while, they come over here for a while. A lot of big companies do this. It’s almost a must.
9. For the team overseas, its important to spend your valuable time together in the beginning to ask lots of questions and understand the requirements as much as possible, in case there is a task that you run into questions, then leave it and work on something else.

Hamid, Axosoft CEO claims that Outsourcing is for Dummies. I think this isn’t true in all cases, as I have been able to apply outsourcing successfully on some small projects. However, it all depends on the case, and for building complicated software with a (geographically) fragmented team, you may just end up proving his point.

My initial thoughts on pair programming (definition).

Normally at our shop, we don’t do pair programming.  Each developer is assigned his or her own tasks and they are responsible for completing them.  If they require assistance of explanation from another developer who is more familiar with that system they need to go and request that assistance on their own.  I believe the vast majority of offices work in this manner.

However, yesterday we decided to try pair programming.  We have a complicated CRM application where it takes months to learn the application, and the situation is that another fellow who works on the reporting side of things and I worked together to solve a few bugs in the system.

As we worked together (with a slightly decreased speed than the two of us seperately working) we managed to eliminate two instances of duplicate SQL code in our application and instead used a view that already existed which I was not aware of.  As well, I am very confident you that this resulted in a much higher quality of the application, even if it took longer.  You are far less likely to end up with bugs when you use pair programming.

I am still skeptical if it really was slower or not, because when you work on your own, you can get stuck on a particular problem and waste half a day, whereas when the other person knows it, you can immediately solve the problem and move on.  As well, you are less likely to waste time checking the news, weather, etc, because the other person is sitting and working with you.  Also, keep in mind that "task switching is expensive".  When you are working on a piece of code and you are "in the zone" and then you have to stop to assist someone else, this lowers your productivity, whereas when both of you are concentrating on one issue, you don’t have this issue.

Pair programming can also be used to train or "rough in" new employees, and as well it results in increased code awareness (i.e. both of you are trained on the same piece of code, incase one of you quits or is sick, the other person also has a good idea of the code).

While the jury might still be out on this principle, and maybe its still too "extreme" for most managers to allow it, give it a shot when you have a chance and see how it goes.

Being a person who believes in continual improvement, and being proactive instead of reactive, I suggested to one of my employers that I worked for that we should implement ELMAH (Exception Logging For .NET) to handle our uncaught exceptions.  They weren’t too interested when I made the suggestion and so I did not push it.   I had found this gem of code here because I spend a bit of time each day doing research and improving my skills. (see point 2)

However, we had this continuing problem where customers would have a problem with the .NET site, maybe they had a crash and we had no way to diagnose the crash other than to remote into their machine and try to reproduce the error.  What made it worse is that they had debug mode off, and we could not even see the exact crash details.  Often we would have to take a risk and modify their file to put debug on (I say take a risk because if you make enough modifications, the application will restart and kick everybody off the system) and this was a live site with real customers.

So once the problem was large enough that it was passed on to the development manager.  When he queried the team for possible solutions to that particular crash, I jumped at the opportunity to suggest ELMAH.  The sale was immediately closed, and within a week we had ELMAH up and running on some of our customers.

Lesson?  Wait for the right time to make your suggestions.  it can be very effective.  Otherwise your advice may be falling on deaf ears.

Also.. this had the same result again when the timing was right we were able to successfully convince our development manager to make the switch from SourceSafe to Subversion.  We had discussed it many times but we had to wait for just the right time and when this time came (since they already knew about it and liked it, but were just waiting for a good time), getting approval from management was easy as pie.

This article is based on Canadian vacation laws.

It seems that most people don’t understand that by law we get 4% vacation.  So where does this number of 2 weeks come from?

Well If you calculate 50 weeks * 4%, you will end up with 2 weeks, what that means is in 1 year, you get 2 weeks paid vacation and 50 weeks of work.  So if your employer prorates your vacation for the first year, meaning that after 3 months they give you 3/12 of 10 days (i.e. 2.5 days or 25% of your total) but you need to take off 2 weeks and they refuse to give it to you, you shouldn’t worry about because either it means at the end of the year thats all you took (2.5 days paid), and by law they will pay you for the other 7.5 days or 3.75% of your total salary at the end of the year (or whenever they reconcile their accounts which could be a few months later)

The other case is that you will still get 7.5 days vacation after those 2.5 paid days, so in that case you didn’t lose anything and you ended up getting about 2 weeks extra unpaid vacation. 

So make a decision, and enjoy your vacation!

Here’s how I heard it.  This is an example of social/psychological experimentation and there is something we can learn from it.

Researchers in a lab were carrying out an experiment.  There was a cage with monkeys, and there was bananas at the top of a ladder on a platform.  Every time a monkey tried to climb up the ladder, every monkey in the cage would get shocked (how cruel).  Eventually, if anyone tried to climb up the ladder, all the monkeys would get mad and tackle the monkey down to the floor and beat him up.  Eventually, what they did is they removed 1 of the monkeys, and put a new monkey in the cage.

Obviously, he had no idea what was going on and when he tried to climb up the ladder, the monkeys got mad and beat him up.  And then the researchers continued doing this until not a single monkey was there from the initial experiment (they were all green monkeys). 

Now, if anyone tried to climb up the ladder, they would all beat him up, yet none of them had a clue why they were doing it……

Sometimes at my job I am reminded of this.  We are doing things which make no sense, and if anyone asks why…. the answer is, well, "because that’s how we always did it."

Bananas anyone?