Archive for the ‘Work Related’ Category

Are You a Sharp Developer?? (Part 2)

August 12th, 2007 by Sameer | No Comments | Filed in .NET articles, Work Related

This is the second post in the series "What Makes a Sharp Developer"
The next article in this series will discuss keeping up with the bleeding edge – Visual Studio 2008 (Orcas), Silverlight, .NET 3.5, LINQ, .. and more

This post will focus on: balanced lifestyle, staying away from drugs, and keeping a healthy balance between learning and working.  Overall this article discusses how you can become a more valuable resource to your team and to your employers.
 

 

Lead a Balanced Lifestyle

Many of us in the development or business field unfortunately tend to overwork ourselves.  We work late nights at the office surviving on Java alone (caffeine, that is, not Sun Microsystems JavaR).  We take our work home in the evenings, or we might be doing stuff on the weekend that is work related so that we have a head start during the week.  I feel this tendency to overwork ourselves is part of our human nature.  We have to protect ourselves against this and yearn to keep a balance.  Although there is some overlap, I like to divide my time into three categories – Work time, Time for God, and Time for my family (don’t forget Time for Myself).  The difficult part is keeping the three in balance and perspective. 

If we start doing fifty or sixty hour weeks consistently, our quality of work will definitely go down.  It is unfortunate that some companies do not understand this, and push their developers to work longer and harder despite the fact that inevitably their performance will suffer.  As well if your family life suffers, that will not be good for you at work.  Your wife (or husband) might end up putting extra hot sauce in your sandwich because you didn’t spend time with her for the last six weeks and your stomach isn’t going to like that.

 

Stay away from the drugs

One of the keys to success is to stay away from drugs.  That includes alcohol, nicotine, and…. that includes caffeine, man (Bummer!).  Actually caffeine is one of my favourite drugs :( .  But keep it in moderation.  If you overdo it, or if you become dependent on caffeine to survive, you are going to be at a weakness to those who can survive without their daily injection.  Also it hides your tiredness, especially if you start to use it regularly even when you aren’t working, you might not realize just how tired you are.  If you notice you are coming home with bad headaches, or are feeling dizzy or other strange things are happening, THOSE ARE NOT A GOOD SIGNS.

 

A balance between working and learning

This one is a tricky one.  It depends a lot on your work environment and how tight your deadlines are.  I am suggesting that you make sure that no matter what, each day you learn something new.  Do not spend so much time on your task so that you are completing it as fast as possible without taking the time to investigate or find better solutions.  Don’t assume that just because you did this four times before, that the fifth time you should do the same thing.  It could be possible that you did it a silly way four times and you are just going to make it the fifth now!  There have been so many cases where I have been repeating my same noobness (i.e. lack of expertise) by declaring my SQL parameters as an ArrayList for example, whereas I could do it without the additional memory overhead and then conversion into an array by declaring my SQLParameters directly into an array with the exact size I need!  Sometimes employees think that they are not doing their company a favour if they "waste" time reading stuff like this. 

Infact, I beg to differ!!  On the contrary, you will be a MUCH more valuable employee if you insist on taking the time to learn things.  An employee who consistently learns is the last one to get fired, whereas the old dog who can’t learn new tricks is going to be the first one to have to sleep outside (so to speak).  Please, this is so important.  If your boss doesn’t give you time for this, either get a new job, or work late so that you can spend an hour a day on this.  As well, this will give you a bit of job security incase you end up being the one who is laid off, because you have been keeping up with the improvements and constantly sharpening your skills, you will be more in touch with the technology than the ones sitting on their old skills.

As a PS, I would also recommend looking at current job postings to see what technologies are in demand, and as well try to see if you can figure out trends (i.e. which direction the market is heading and what technologies are up and coming.)

Growing Pains of a Software Company

July 16th, 2007 by Sameer | 2 Comments | Filed in Software Engineering, Work Related

There is a particular small software company that has been in business for more than 10 years that builds a web application similar to say PHPNuke.  Here are a few characteristics of this company: They have survived this far using Microsoft Visual SourceSafe for their source control (which is probably okay for small teams but starts to have problems when you start to use it extensively), they have not used any unit testing, they do not have any form of automated testing or regression testing.  They have sales in the millions of dollars, and they have about 6-10 developers and 2 QA (as well as many QA overseas).  Every time a build is made, the overseas QA team has to "crash test it" (meaning to run the site and click frantically until something breaks).  This does not mean there is no test plan, but rather this method of testing is very unreliable and prone to errors.  As well the number of customers they have is less than 100, and we can reasonably assume that simultaneously less than 10 users would be logged in for each application.   Now that the company is growing each one of these issues is going to bite them in the butt. 

The boss might wonder, "if we got along this far without doing any of the following, well… why should we??".. But as a "soldier" on the front lines, you start to see the problems that can come up with this sort of thinking.

 

Not using unit testing

This means that QA receives a page that is not unit tested.  It is ad-hoc tested by the developer, meaning that they try to click and break their new code, but there is no form of automated manner to this testing.  As well, every time the code is updated, the developer has to re-test and re-re-test it manually.  As well there is no real confidence in the code other than the fact that the QA team has tried their best to crash it and it did not crash.  It might even be very time consuming and painful to set up the test each time.  Without unit testing, this is a lot of time wasted that could be used in development. Read up on Test Driven Development for something else that you can gain from proper Unit Testing.  By the way, what does unit testing software cost you?  FREE if you use NUnit.  Or like $14,000 if you use IBM Rational Test RealTime. Its up to you. Just Do It.

 

Not using proper Source Control

Trying to implement branching ,sharing, multiple releases, with Visual SourceSafe! You will find it is very difficult.  As the company is growing they needed to be able to release and develop multiple versions concurrently.  This is near impossible with SourceSafe, if not very difficult, and they need to move into using a better source control software such as Team System, Subversion, Perforce, etc..  This will give them features such as atomic checkins, shelving (if required), cheap labels, etc..

 

Not using automated testing

This comes back to the earlier topic of unit testing…  Without automated testing, there is no confidence in the code.  Each change, even a minor one, can possibly break some unknown piece of code in the system. 
To hear a real story, making a change to a general object in the system caused a crash on a Report that was only somewhat related to the general object. 
 
This was not noticed until on a live customer demo, but due to slickness on the part of the presenter, it was overlooked.  This is a deadly game of cat and mouse, that can result in lost customer confidence and eventually lost customers.  AUTOMATED TESTING is FAR TOO IMPORTANT to not use, especially if your company is growing and growing.

 

Small number of customers

With a small number of customers, there are some problems that you have in your code that will not be noticed until you start to grow.  For example, if your code is not thread safe, and you are using shared/static variables that are not meant to be shared on a specific page, problems that might not show up until you have multiple users loading that page simultaneously.  This will happen as your number of customers grow.
 
 
As well as load issues.  As a small shop, you can throw the most horrible piece of inefficient code and in most cases it will not cause a problem because your server can most likely handle it.  As you start to increase in size as a company, and as you have more people hammering your server, your inefficient code is going to start to tear at the seams and you will have to go back and re-organize it.    Sometimes code can survive and be in use for more than 5 years so its well worth your time to build it properly.   Look at your own code set and see how old it is.  If it’s been years and years and you are still using it, re-consider that the time you spend to build it properly is well worth it.  Tell your boss to make sure he knows who he is hiring, as bad apples can spoil the whole pie.

Are You a Sharp Developer?? (Part 1)

July 11th, 2007 by Sameer | 6 Comments | Filed in Software Engineering, Work Related

Many studies have shown that there is a 10 to 1 difference between good developers and bad developers.  How can you become a better developer?  Well,  there is many things you can do, and this is how you can improve your quality, and therefore get more return on your investment in terms of better jobs, and you can also be more selective about the jobs you take. 

1. Improve your communication skills – both speaking and writing.

One of the most important things you can do to become a better developer is to improve your communication skills.  This is a win-win situation.  You will find you will be able to better relate to others, to your boss.  You will find that you can explain yourself (or maybe defend yourself) against your boss and colleagues.  You will be able to knock them out in interviews even if you don’t really know what a deconstructor is or how on earth to deconstruct your class.

2. Constantly learn and improve your skills and yourself

You can only become a better developer if you are constantly learning.  The world is changing so fast, that you need to be constantly reading books, articles, going to conferences, and asking from others.  An easy way to do this is to find some nice sites you like, and subscribe to their RSS feeds on GMail or on your favourite RSS reader.  Make sure you always have a book by your side.  Even if its not a technical book, develop yourself personally.  Find out your weaknesses and improve them.  For many of us that might be our presentation skills, so build those skills!  Practice talking infront of a mirror or to yourself.  I have made so many suggestions to our current process just by keeping up on .NET blogs.  It will make you stand out from the rest of the crowd.  For example I suggested converting our site to a Web Application Project which will allow us to do tons of things like get a build script (automate our build process), break our project into multiple subprojects, etc, etc..

3. Share your knowledge and experience

There are different ways to do this.  Don’t think that keeping everything to yourself is going to help you.  Infact, sharing your knowledge and experience with others always pays off.  Don’t be stingy, and you will find much in return.  One way to do this is to once a week email your co-developers with some ideas on how to improve the code quality.  Another idea is to start a blog!  This will also result in an exchange of ideas and your bad ideas will be weeded out.   You can also contribute to forums or start a discussion.  If you aren’t willing to do this, you might think you are the smartest piece of cake until you realise just how shallow your ideas are when you discuss with others.

4. Learn from your mistakes

Back when I was doing my first web development job (4 month internship), I decided to make some changes to the ASP application.  However, I did not make any backups.  Let me tell you I learned really quickly to always make a backup.  Don’t be bit from the same snake hole twice! Learn from your mistakes and grow as an individual.

What are some of the other benefits to becoming a sharp developer?