Friday, April 19, 2013

What is hot?

There is an ocean of programming languages out there that can drown any software engineer. Having worked only in java and OOP, I honestly don't think I'm even qualified to call myself a software developer! Have touched upon several languages time to time, (read a little and coded a little) but that's not at all sufficient to say I have several baskets to put my eggs in.

As a first step in finding more baskets (other than the Java n OOP basket), I thought why not find out the most popular programming languages these days. Who knows, I might even step on a gold mine.

Wikipedia listed several indices I can use to find out what's hot.
  • TIOBE Programming Community Index 
  • Language Popularity Index
  • PYPL PopularitY of Programming Language
  • RedMonk Programming Language Rankings

TIOBE Programming Community Index for April 2013
The TIOBE Programming Community index is an indicator of the popularity of programming languages. The index is updated once a month. The ratings are based on the number of skilled engineers world-wide, courses and third party vendors. The popular search engines Google, Bing, Yahoo!, Wikipedia, Amazon, YouTube and Baidu are used to calculate the ratings.

Language Popularity Index
The Language Popularity Index tool is a fully automatic, transparent, open-source and free tool to measure the popularity of programming languages on the Internet.

PYPL PopularitY of Programming Language index
The PYPL PopularitY of Programming Language index  is created by analyzing how often language tutorials are searched on Google : the more a specific language tutorial is searched, the more popular the language is assumed to be.

The RedMonk Programming Language Rankings: January 2013
Derived from a correlation of programming traction on GitHub (usage) and Stack Overflow 

Tuesday, April 16, 2013

Why did I do the things I did?

I can see that a lot of people question my sanity looking at certain things I do.

Why did I not apply for a lucrative telecom job when I graduated? Why did I give up a posh financial analyst post to take on a meekly software development job? Why did I quit that job too and stayed at home reading books? Why did I say no to a lead interview and cut my chance in a promotion? Why did I choose tech track when I have a MBA?

Everything above has a common answer. But it's not very easy to put it into words. So when people ask why and why, I find it very much easier to skip the questions.

When I saw this Foreword in "The Passionate Programmer", I found my answer put into words by someone else.

I believe that everyone has remarkable in them but that it takes finding something they truly care about to draw it out. You can’t be remarkable if you don’t love your environment, your tools, and your domain.
Before I had my spark lit with 37signals and Ruby on Rails, I went through a series of jobs and gigs that certainly wouldn’t fit the bill as remarkable. I was treading water and just letting one day eat the next.
Before I knew it, six months were gone, and I didn’t have anything to show for it.

That’s a terrible feeling of regret. I hate the feeling that my presence doesn’t really matter and that the world would have been exactly no different in a meaningful way if my work hadn’t been done. To become remarkable, you have to believe that you’re making a significant dent in the universe.

When I wasn’t making a dent at work, it spilled over to my personal life too. When I didn’t feel like I was having an impact during office hours, it was that much harder to muster the effort to have an impact afterward.

To me, leading a remarkable career is the best way I know to kick start that same desire for leading a remarkable life—one where you don’t just become a better and more valuable worker, but you become a better human too.

That’s why this book is so important. It’s not just about making better widgets and feeling secure in your job. It’s just as much about developing the skills and sensibilities for leading a more rewarding life filled with many remarkable aspects, with work just being one of them.

—David Heinemeier Hansson, Creator of Ruby on Rails and partner in 37signals

Monday, April 15, 2013

Driving it to the ground

Many years ago at Microsoft, there were a couple of leads who, when a project was not running smoothly, would round up the development team and proceed to tell them that they were the worst programmers at Microsoft, that they weren't worthy of calling themselves Microsoft programmers, and other such nonsense. I'm not sure what those leads were trying to accomplish, but if their goal was to get the teams to rally and try harder, they picked a pretty strange way of doing it. As I'm sure you can imagine, those leads only succeeded in angering and depressing their development teams.

Furthermore, in every case of which I was aware, the problems with the project were management related—the projects had no clear focus or were simply too ambitious. The programmers on those projects weren't any better or worse than other programmers in the company, and berating them didn't change anything for the better—only for the worse.

- Debugging the Development Process by Stephen A. Maguire

It's such an obvious fact. But still it's amazing just how much people fail to apply it practically.

I remember how some PMs threatened and tongue-slashed a team of completely exhausted and overworked team of developers for everything from breaking the build to extended deadlines. They eventually ended up with a large pile of code that made it into the garbage.