Welcome to our continuing series of CodeProject interviews in which we talk to developers about their backgrounds, projects, interests and pet peeves. In this installment we talk to Ravi Bhavnani.
Who are you?
My name is Ravi Bhavnani. I moved to Toronto, Canada about half a dozen years ago. I’m a Lead Software
Developer at Dayforce, a company that enables businesses to manage virtually all aspects of their human
resources needs from a single interface. Before Dayforce, I worked at Dundas Data Visualization, a market
leader in business intelligence and data visualization technologies. At Dundas, I was part of the team that built
Dundas Dashboard, a platform to power dashboard solutions to help companies quickly spot key trends and
make better business decisions. Prior to Dundas, I worked in the software industry in the Boston area for about
Since 2000, I’ve worked solely at startups and early stage companies, as I feel they provide a dynamic
environment and energy that’s not often found at large corporations. I feel the culture of a well-managed
startup allows developers to significantly contribute to the success of the company by directly influencing the
capabilities and functionality of the product they’re building. Working at a startup also provides developers a
close (and rare) look at what goes into turning a good idea into a successful product. It’s what I like to call
"the stuff that comes after the semicolon".
Apart from a three year foray into Java, I’ve been developing for Windows since 1992. Before that I wrote AI
applications in C/C++, OPS5 and Lisp.
What do you do?
At Dayforce, I work on the company’s enterprise product, Dayforce HCM. My daily work involves writing code
in a variety of ways: designing platform components used by other developers, building new functionality,
fixing bugs, and investigating newer technologies that will be used in upcoming versions of the product. I work
exclusively with the Microsoft stack (i.e. SQL Server, C#, .NET, Silverlight, WCF, ASP .NET MVC, WPF, Windows
I also run my own company, Matrix Software, through which I sell FooBar, a collection of more than a dozen
personal productivity tools for Windows, nicely integrated into a toolbar. I’m also known for several popular
freeware Windows apps, in particular WeatherMate and TakeStock.
What is your development environment?
At work I use a quad-core i7 with 10G of RAM running Win7, a 128G SSD and a 7200 RPM 1TB hard disk (plus all
the network storage I need) and dual 1920 x 1200 panels. This is standard issue for all developers. Our boxes
are set up with a standard array of development tools (VS2010 + VS2012, SQL Server 2012, Silverlight Spy,
Fiddler, Beyond Compare, etc.) and all devs are issued an MSDN subscription. We use TFS for issue tracking
and configuration management.
At home I use a Dell 1720 laptop with 4G RAM and a 160G 7200 RPM hard disk running Win7, and a 23" 1920 x
1200 panel. I also have an old box running WinXP, which I use for testing. Most of my data sits on external
Western Digital drives. My home development environment includes Eclipse, which I use for Android
What new tools, languages or frameworks interest you?
At work I’ve changed my focus from the Silverlight/WCF/SQL chain to working on a multi-client framework
Dojo) and consequently spend more time in the consoles of IE and Chrome. It’s a bit like having to program in
Assembler after years of working with object-oriented languages and their mature development environments.
What is your coding pet peeve?
Actually, I have two.
Peeve # 1: Real developers don’t write comments
There’s a popular legend among developers that speaks of ninja programmers who code for weeks with little
sleep, sustained only by caffeine, beer and pizza, and who churn out amazingly performant code that works
great the first time and has very few (if any) bugs. Well, ninja programmers, I bow to thee. But if I’m the
poor sod who has to consume or maintain your code, it had better be commented.
Many developers respond by saying intelligently chosen class, property, method and argument names don’t
need comments. Some even go so far as to grin evilly and claim, "the code is the comments". To which I
reply, if you’re the only one who will ever use or maintain that code and you’re convinced you will never, ever
forget the intricacies of your terribly impressive recursive Regex logic when you’re forced to revisit that code
seven years from now because an irate customer called up your CEO and threatened to spread the word about
how broken your product is (regardless of whether or not it’s actually broken), then fine - don’t bother with
Recently, I was part of a decision to drop a large vendor of UI components because their documentation wasn’t
up to snuff. If I’m going to have to spend days trying to decipher how to use something (or figure out what it’s
intended to do), guess what? I’m going to pick an alternative. Or maybe brew my own. It happens all the
time. Get with the program - don’t let it happen to you.
Dentists tell us, "you don’t have to floss all your teeth - just the ones you want to keep." My software analogy
is "You don’t have to comment all your code - just the code you don’t want to have to throw away and
So comment your code. And update your comments when you change code. Your 2:30 a.m. critical bug fix will
Peeve # 2: Dumb users don’t deserve my cool app
My second pet peeve isn’t about coding - it’s developer arrogance.
When I started my first job at DEC in 1987, I knew I was good at what I did. I wrote code that worked right the
first time. I wrote code quickly and usually finished my tasks ahead of schedule. My code had very few bugs
(and it did have comments). I knew esoteric details about the VAX/VMS run time library that awed my peers
and caused engineering managers to take notice. I was a ninja developer. I was cool. I was hip. And I was
completely clueless. Because I didn’t care much about my end-user.
I’ve often heard developers describe their users as "stupid" and "dumb". The general consensus among some
developers seems to be, "if the user isn’t smart enough to figure out how to use my app, they shouldn’t be
using it." And as sure as God made little green apples, that’s exactly what’s likely to happen. Only thing is, if
you don’t have a user, you don’t have a paycheck. Like it or not, it’s the users who call the shots, not the
other way around.
If your product is lucky enough to be a (or the) major player in the field, you may be able to get by with
forcing your users to adapt to how your application works. But eventually, a competing developer (who’s
probably not as smart as you but is receptive to their customer’s needs) will offer your customer an alternative
that’s easier to use, and will steal that customer away from you.
So be humble and keep a big ear open when your end-users speak. Your paycheck will thank you.
How did you get started programming?
I got started in programming by chance.
I’d just begun a degree program in Electrical Engineering and one of my first assignments in a Numerical
Methods course was a Gaussian elimination problem. I understood the theory, but was required to solve a
dozen linear equations in two days. When I approached my instructor, he quickly cleared up my confusion:
"Oh, just write a FORTRAN program and run in with a dozen sets of data." There was only one small problem.
I didn’t know FORTRAN. Or any other programming language for that matter.
So I dropped the course and requested the CS department to recommend a FORTRAN pre-requisite. I still
remember the look of scorn I received when I mentioned "FORTRAN". "We teach structured programming
here", said my CS advisor, "not FORTRAN", and proceeded to enroll me in Pascal 101. The next day, I found
myself in a class full of freshmen, perhaps the only grad student - or at least the only student with facial hair.
My Pascal instructor (who I later tracked down after more than 30 years) began the course with a simple
directive: "Empty your minds - for it is I who will teach you how to THINK". It was love at first sight - the
purity of logic and the mathematical perfection of control flow and program verification opened up a world of
joy hitherto unexplored and unknown to this shaggy haired newcomer.
Anyway, I soon switched my field of study to Computer Science and spent almost every living, waking and
breathing moment soaking up the theory and practice of this wonderful field. Thirty years later, I still spend
most of my free time writing code, building freeware utilities, and updating the odd CodeProject article.
There’s nothing else in life I ever want to do but build software.
My first programming language was Pascal, although by 1983 I’d switched to C (the new kid on the block at the
My first system was an IBM-AT (1985 model, 80286 CPU + 80287 FPA, 6 MHz, 512K RAM, CGA video, 1.44M and
360K 5.25" floppy drives, 20Mb Seagate hard disk), a Princeton Graphics System color monitor and an Okidata
Microline 132 dot-matrix printer that sounded like a dentist’s drill on steroids. The entire package set me back
$5000. The only piece of software I owned (other than MS-DOS) was PC-Write and the Lattice C compiler. The
software cost around $300.
How has the developer community influenced your coding?
I’m constantly amazed and gratified by the free sharing of knowledge by the developer community. Everything
I’ve learned about software development after graduating from university has been due to the generosity of my
colleagues and developers I’ve interacted with on the net. I’ve tried to return the favor when I could, but if
you’re keeping score you’ll see I’m way in the red.
I’m also delighted to be part of an industry that has virtually no bias toward gender, age or ethnic origin. It
doesn’t matter what language you speak at home or what you look like. If writing code is your thing, I want to
Where do you see yourself in 10 years?
It’s hard to speculate. About every five years I’ve asked myself what I’d be doing five years from now, and I’ve
been wrong every single time. But I know what I’d like to think I’d be doing five years from now: running my
own software development shop or being part of a small group of equally passionate developers, building
enterprise apps with a strong focus on mobile UIs. I’ve always enjoyed writing front end code and I’m curious
what the future of tablet/phone/wearable mobile technology holds. I think I’d like to part of that. I also think
I’d like to help kids learn programming.
What advice would you offer to an up-and-coming programmer?
Write code. Lots of it.
It’s only through writing code and sharing your work, that you learn - from your peers, your users (if you’re
lucky enough to have some) and your competition. And don’t be afraid of criticism; it’s the most valuable
feedback you’ll get. While I like receiving emails informing me how much someone enjoys using my freeware, I
absolutely love it when someone reports an obscure bug or provides with me suggestions on how I can improve