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 twenty years.
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?
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 quad-core (8 thread) 3.2GHz i7 Brix Pro with 16G RAM and a 500G fast-write Samsung SSD 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 and almost all my source code is hosted by Microsoft's TFS Online. I use VS2013 exclusively.
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 compatible with all major browsers and mobile clients, backed by ASP .NET MVC. I've also used (and am very impressed by) the Xamarin framework to build cross-platform mobile apps using C# and Visual Studio.
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 comments.
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 rewrite."
So comment your code. And update your comments when you change code. Your 2:30 a.m. critical bug fix will thank you.
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 time).
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 know you.
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 my apps.