Tech Tips Digest: 6

In today's post we'll be discussing interesting subjects covering communication, end-users and other interesting topics

I might be not be posting tips over the next 10 days as I'm going on a business trip, so I might not find enough time to post, but I'll sure be back soon hang on with me :)

Previous Tips: Tip No. 1 | Tip No. 2 | Tip No. 3 | Tip No. 4 | Tip No. 5

Tech Tip No21: It's doesn't happen on my machine! It's either a config issue or an environment related bug!

The worst excuse of all time, as software engineers we write applications on our own development stations, and then comes the time when we have to deploy them for the general public. And it so happens that most of the time, the target environment doesn’t really match our own, in terms of hardware and software, Duh!

To avoid this, what we should generally do is, first make sure our code doesn’t have environment specific code (This is even more valid for Java as a cross platform language), and then make sure the application is properly deployed to a staging environment that is configured very much like the end target environment and test your application on it.

This’ll make your life a tiny bit easier.

Tech Tip No22: Think of the end-user, unless you're creating apps for yourself. Most engineers fail to cater for user friendliness

Yes we tend to do that, we more used to having complex UIs’, think of your IDE, it has plenty of configurations and sub-configurations.

It is true that there are people specialized in user experience design, but if in your case you don’t have access to such a person, try to think of the user.

Think of an application you enjoy using, you’ll most probably like it for what it does, but then if it had presented you with a useless or hard to navigate interface, I’m sure you wouldn’t like it as much.

Tech Tip No23: Communicate in clear & precise manner, lack of communication with your team lead or team mates will cause issues

Communication has to be the most important part of our industry, after all we write systems based on requirements, and how do we get those requirements? Yes, they are communicated to us by the customer, and the guys who gather those requirements will communicate them to the various people in your organization until it reaches your team lead and then yourself to work on.

As you can see, there are plenty of breaking points here, and any flaw in the communication process will lead to a nasty case of the customer saying, I didn’t ask for that, or I didn’t want it this way!

Make sure to confirm back every piece of information you receive, and keep a documented record of all of the requirements you receive, this has to be carried out by all people involved in the requirements gathering and propagation process.

Tech Tip No24: Avoid nested loops, especially when dealing with dynamic collections having unpredictable sizes

Whenever you write code that involves nest looping, I encourage you to reconsider, especially when the nested loop contains expensive logic. Also, you might be using static maps for caching and with enough luck you’ll end up abusing your memory if you use such maps within your loop, think memory leak!

If you really have to use nested loops, make sure the sub-loop has very minimal logic that is not so expensive in terms of memory or CPU.

Tech Tip No25: When using static Collections or Maps, make sure they're well managed. Otherwise you'll be wasting memory!

Mentioned in the previous tip, you might need to cache certain information on application level through using static maps. Those are very handy when you don’t need a very well managed cache with clustering capabilities.

But, if this map isn’t managed well enough you might be using up more memory than you really should, and to avoid this miserable situation, you should make sure you remove data from the map when you no longer need it.

Some people using Java might recommend the use of a WeakHashMap for instance, this is a very nice map to use, except it’s not a cache in the sense you might be expecting.

It uses weak references as keys, meaning that if the GC runs it might just remove those keys and the associated values, this kind of caching mechanism might as well be very useful to you. But, you have to make sure you check for the values you fetch being not null in which case you might want to re-cache them.

Hope you enjoyed this post, if you have feedback don’t hesitate to comment.