A not too serious conversation between me and Jimmy. He wants to be a programmer and later a developer. He started to learn JAVA and he asks me some interesting questions about it... Actually its all about why I think stuff like the beautiful looking DSL code like new ScalaTest won't survive by more than 2-3% of average developers we have. Its just too scary and unfamiliar and way too far away from good old C syntax. I've experience for many years in a wide range of languages, including scary ones like Smalltalk, Python, Tk/Tcl and Ruby...

So I finally got some time to sit down and write, after being knee deep in work the past month or two. And without a doubt, I wanted to write about what has been heckling and annoying me over the past month. I am an ardent defender of Java as a good language, especially defending it from Misko day in and day out, but even I will agree that it does suck at times. So today, Java, the gloves are off. I love you, but this is the way things are

It’s fashionable, or perhaps inevitable, for tech communities to trash their competition. The Emacs folks like to mock vi users; Windows folk look down on us Mac users (and Linux users mock us both); and everyone likes to mock PHP despite PHP’s dominance in the web world. We geeks make arguing over minor technical points into a kind of art. This is all pretty understandable: it’s easy to define community in terms of what we’re not. A common enemy focuses and drives us. Competition can take a positive form: when it’s friendly and constructive both communities benefit.

I wrote this article as a “master guide” to productivity. Well OK, I don't know about a "master guide" but one thing is for sure: implementing these steps will help you increase your output if you implement them towards the tasks that you’re passionate about.

Apple have revealed their opinions about Windows 7. It's not complimentary, but do Apple need to resort to uninformed Microsoft bashing?

Some of my random observations and rants about BAD managers and bosses…

Do you dread going to a convention and meeting new people? Do you sit mum in meetings, overpowered by others? Do you gape at the self-promoters in the office who seem to get ahead beyond their worth? If so,

I’ll bet that it felt like a momentous achievement to get a group of very well-known bloggers, analysts and technologists to agree on a “manifesto” for services-oriented architecture (SOA).

To become a really successful manager, you have to have time and patient. You need not to go to the best business school to learn how to be an efficient manager.

People make plans. But if a plan is to pan out the correct way, you need to be able to execute it right. But how do you implement a plan to achieve everything you had set out to do?

With daylight savings time ending today, I thought this was a good time for a post. How to handle time is one of those tricky issues where it is all too easy to get it wrong. So let's dive in. First off, using UTC (also known as Greenwich Mean Time) is many times not the correct solution. Yet many programmers think if they store everything that way, then they have it covered. (This mistake is why several years ago when Congress changed the start of DST in the U.S. you had to run a hotfix on Outlook for it to adjust reoccurring events.)

What are the holes you must plug to make your job-hunt successful? Try these tips:

Note: The following material and presentation was prepared for students of the Indian Institute of Information Technology (IIIT), Allahabad. The aim was to get them excited about contributing to open source projects and in particular about Apache Lucene, Solr and Hadoop. The first talk was titled "Why you should contribute to Open Source" and was aimed at freshmen and has no technical content.

We developers are constantly barraged with an overflow of activities and information we don't possibly have enough time for, and we're given very little guidance on what is and isn't worthwhile. This morning on my drive to work, I was reflecting on some of the things I'm involved with, questioning the usefulness of each. Some of these activities (other than the act of coding itself) include: