There’s no question that different programming languages are useful for different projects — it’s hard to justify completing every single project that comes across your desk in the same language, unless you only know the one. But while it’s often a good idea to be able to code in different languages if you’re working on a wide variety of projects, it’s not clear if there’s a magic number of languages you should know.

One, if…

If you work on the same sorts of projects over and over again, you may not need to know more than one language — at least at an expert level. There are a lot of benefits that come with expert-level knowledge of a language (like being able to put together a new app overnight) and it’s hard to reach that level with a single language if you’re constantly switching between other options. On top of that, there are plenty of frameworks that can extend the capabilities of a given language. However, if you’re interested in building bigger projects on your own, you’re going to eventually need to pick up another language or two.

It’s probably better to preemptively pick up a new language now, so you have more opportunities to work with it before you really need it. The Pragmatic Programmer goes so far as to suggest that all programmers should learn a new language every year if they want to stay relevant. Whether or not you need to learn a new programming language every year is a question that you have to answer for yourself, but it certainly makes sense to continue your education as a programmer and make a habit of trying out new languages.

The Right Tool

When you’re running your own company, the number of programming languages you need to know goes up. That’s because you’re the person in charge, even if you’re working with other programmers. At the very least, you need to be able to identify the right tool for any job that comes up. You need to have the right tools for your domain — what languages you need differ dramatically. If you’re working on enterprise web apps, you need different tools than if you’re working on a personal mobile app.

For the broadest set of tools, there are some basic options. You have to know a lower level language (like Java, C or Go) and a higher level language (like Python, Ruby or PHP). That division will allow you to have at least one language to work with core servers and other lower-level tools that may need to interface directly with the operating system. It’s also important to pick up a higher level language that will help you with web development these days, along with a framework — even if you’re not building a web app, you’ll probably need a website or two. Think about what you’ll need in terms of platform-based languages as well: go deeper than thinking about the operating system and consider if there are particular devices you expect to work with.

Image by Flickr user Jon Smith

Too much of anything is injurious to health and this is so true of startups too.

As a startup founder/developer, you are asked to have a blog to let users know what you’re up to, to let other developers get to know you, to enable a marketing campaign that works wonders… the list is endless. Blogging, networking, “github”ing (one of the words that’ll be in vogue by the end of this year): these are productive work, mind you. And as developers, our focus is on “creating” and these productive works involve a lot of creation. This creates an impression – a false one – that we’re actually productive.

I read a post on the state of several projects that never really made it to the finish line. This reminded me of several developers who blog about their upcoming new project and after a few months, there’s no project at all. Did this ever happen to you? Like you started off on a high note – blogged about it a lot in the initial period – and then somehow, the whole thing waned away, ending kind of prematurely with an unfinished project?

Oh and it’s not just blogging that can do this to your project. There are other monsters too – monsters who are basically good but who can eventually turn into productivity-suckers.

Networking: Social networking is an amazing thing that can help your app/project like no one else can (okay, PG, Andreessen and, say, TechCrunch excluded). It can help you build amazing relationships with people who can spread the word about your work, or help you hack some stuff out of Backbone.js so your app kicks ass. But social networking can also drain away your most important asset: time.

A popular hangout for developers is HN. Or even Google+ for that matter. And then there’s Quora these days. These are places where meaningful, insightful, informational and “whatever” conversations take place. These are places I love, too and you get tons of info that is hardly found anywhere else. But developers can – and do – get carried away a lot.

GitHub is funny in a way. You start forking one interesting and relevant open-source project and then one thing leads to another and by the end of the day (or night, if you’re burning the midnight oil to code your project), you’ve seen a ton of interesting code on GitHub but none of this is actually, really going to finish your app.

Startups need to have blogs whether you are just starting out or mid-way into your project. But you should be very strict and disciplined about this aspect of entrepreneurship and marketing. The same goes with your time spent on networking and code-discovery.

A lot has been written about why blogging, networking etc. are mandatory for developers. Let’s just not over-step the line and end up spending time that should have been used to finish that module.

Image by David Precious

You have certain obligations when it comes to security; even if you don’t collect giant piles of information about your users, most of the people who use anything you build will assume that their information is private. A security breach, even a minor one, can disrupt the trust your users have in you and and make it harder for your business to grow in the long run. The only way you can prevent that is to take your security seriously.

Think ‘Security Driven Development’

While security-driven development isn’t actually a thing, thinking about security’s place in your development process much the way you think about testing is useful. You want to be checking for security issues throughout the development process, not just when something goes wrong.

Depending on which languages you’re using, there are tools that check your code for bugs that lead to common security issues, like FindBugs for Java. Such tools won’t catch everything, but they’ll help resolve some big issues. Find the right tools and make them a standard part of your workflow.

If you’re working with a partner, code reviews can help find security issues during the development process. If not, you need to find a way to replicate that sort of review system. It can be expensive but, on top of internal review, arranging for regular security audits from an outside firm can keep your systems secure. Just how often depends on what you’re working on: a financial application needs security audits far more regularly than a social networking application.

Knowing Your Tools

Commonly used tools are an easy avenue of attack, because there’s more reason for someone to focus on finding a vulnerability — after all, finding a security vulnerability in Apache guarantees access to a lot more than finding a security vulnerability in some custom app someone wrote on their own.

At a bare minimum, you need to make sure that you hear about any security flaws that are announced, even if you’re working on a platform that usually notifies you of such issues. Subscribe to the appropriate mailing lists and consider setting up some alerts on Google or elsewhere to email you when keywords related to security flaws are mentioned.

Online Security isn’t Your Only Worry

Not all security breaches are an issue of someone finding a vulnerability that they can access online. Think about how many news reports on major security breaches refer to someone leaving their laptop somewhere they shouldn’t have. Physical access to your systems can also be a problem. Depending on what you print out, you may need to consider how to safeguard your hard copy as well.

You don’t have to go overboard with paranoia. But it is important to take the situation seriously. Buy a shredder. Put your backups in a secure location, not in a buddy’s house in another state. Take the steps you need to be sure that your company’s data is safe.

Image by Flickr user m thierry

I know it’s easier said than done. There are at least as many articles on this as there are stars in our galaxy. Or may be more.

But the hard truth is that the world’s still full of people who find no time to code their pet project into a full-fledged app. And it’s more or less a self-discipline issue.

Finding time to code is one of the hardest things to do if you’re working full-time and doing the code in your ‘free’ time, which is typically the evenings/nights and the weekends. Quite a lot of hobbyists find it easy to code simple “hobby projects” that won’t see the light of day on the App Store (or even GitHub) but when it comes to serious coding, trouble starts at the time-management level.

There’s always a time to code. “I haven’t got the time to code/test/debug” isn’t a good excuse even when you’re in a full-time job and it all boils down to two things: sacrifice and self-discipline.

I’m sure most of what you are going to read is advice you’ve heard (possibly a million times before). For the benefit of those who’re starting the first lines of their app and for those who’re struggling to manage time to code, here are some things you should always, always remember:

1. There’s No Coding in Small Chunks

If there’s one lesson I’ll take to my grave after having spent a considerable chunk of my lifetime writing code, it’s this: there’s nothing called ‘code in small chunks’. This ‘do it in small measures’ thing might work elsewhere but no, sir, not when you’re coding.

A few lines of CSS and jQuery can take away more than an hour of your time even if you’re smart and can write semantic code on paper like Steve Wozniak.

If you think you’ll come back from office, do a little of this and that and then sit to code for about an hour, I suggest you forget that idea. Code is something that takes away a lot of your time and if you want to get it done, you’ll need to, more often than not, forget time. That means forget setting time limits to code.

2. There’s Something To Sacrifice

Evening visits to the gym can be shifted to the mornings if you code well in the night. A handful of weekend parties can be skipped. Webinars/Seminars on development can be missed. Or if things come to a head-on, a dine-out can be sacrificed for those few hundred lines of code that’ll fix the core part of your project.

There’s always something that you can sacrifice. For me, it has been – for sometime – reading books in the night. Club that with a couple of other things like an evening stroll (about an hour) and TV and you probably get more than enough time to code your way to heaven.

Figure out your routine. Then, cut out stuff that can be sacrificed for precious coding time.

3. Set Up A Distraction-free Environment

There’s this thing called Zero Clutter work zone. It’s basically about de-cluttering your work-zone so you can work distraction-free. And while Leo stops at the physical level of de-cluttering, you can (and should, definitely) take it to the next level: your screens.

When you are coding, have nothing more than one thing in focus: the IDE that you’re working on.

It takes a lot of self-discipline not to:

- check email every two/five/ten minutes
- constantly compile the code every time you make a minor change
- open and refresh Facebook/Twitter/App.net or HN every once in a while
- flip your phone to check messages
- munch on a bagel or fries (drink water; that’s a healthier practice)

Everything other than the IDE is a distraction. If you’re writing a caching program, do just that till you get to a point where you start debugging the code (once it’s totally complete). If you’re writing a regex, finish that totally (test, debug) before you even think of opening a new window in Chrome.

Use a blocking program to keep you off from Gmail, Facebook, HN etc. Keep the phone away – preferably in a different room so you get up only to pick a call.

Little but effective disciplinary changes can help you a lot in focused coding: which translates into less time, more code.

Like I said, it all boils down to self-discipline. And of course, a few hacks like a distraction-free environment (Sublime Text 2, may be?) and a lot of burning the midnight oil (or, if you’re a morning person, getting up a lot earlier than before).

Image by Flickr User Toni Verdú Carbó

When you speak of analytics, you visualize data presented as numbers, bars, graphs, pie charts and more. I wrote on why every startup needs analytics but with the diversity of available options, what kind of a dashboard you choose can decide where you’re headed.

Monitoring your startup’s progress is quite important but it’s equally important to make sure you’re tracking the right things in the right way.

Information vs. Action: Reading & Using Dashboard Data

Dashboards can be pretty enticing at first. You’re looking at real, fluctuating numbers that indicate traffic, time on site, conversions, comparisons to past performances, number of followers, social signals, results of an A/B test you ran, revenue generated so far, per-user stats etc.

But information can be useful or useless depending on what you do with it.

We’ve come a long way since counting hits to a webpage and how you read and “act” on your data can be game-changing for your startup endeavor. How?

Choosing the Right Dashboard

The internet is inundated with a wide range of analytics services. The diversity is so enormous that you can literally spend years trying to decide on the right one.

Fortunately, though, you select a dashboard that will take you towards your goals.

Choosing the right dashboard ultimately depends on:

• what goal you set for yourself/your project
• what metrics allow you to track the progress of your project (towards your set goals)
• what metrics trigger “actions” that will help you achieve your goals

It would be a waste of time to have a dashboard that shows number of users at a given instance when that data is of no significance to you.

The Two “Kinds”

I tend to think that dashboards are of two kinds.

• the ones that do most of the “thinking” for you: the action-oriented dashboard
• the ones that let you do most of the “thinking”: the information-oriented dashboard

Nothing explains things better than examples so here we go:

ThinkUp is an action-oriented dashboard. Anil Dash wrote about it (you probably saw it on HN) extolling such dashboards (naturally) and the need for such dashboards. The way it works is it communicates information about the activity around your social profiles in an “actionable” way. Labels connected to data (numbers) tell you where you are headed.

But think of Google Analytics and it’s a whole different ball-game. GA does communicate information to you as charts and numbers but it lets you decide what to track, what to fix as goals, what data to use for triggers etc.

And then think of Geckoboard. It’s a beautiful dash but it’s numbers and graph again which you can configure to a large extent. Ultimately, though, you are in charge of how you “act” on the data or how you are motivated to act upon the same.

It All Depends On You

Conclusively, all of this depends on what you actually need to do. In most cases, you’re looking for data that can help you push your project towards something: more traffic, more engagement, more conversions, more subscribers, more revenue etc.

What I do recommend is this: if you have time to analyze data, filter the fluff out and assign particular triggers/actions to the data by yourself, go for generic and larger dashboards that feed you all the numbers and charts you need.

If you don’t have the time or manpower, you choose dashboards that are “smarter” and get the work done for you. Dashboards that will tell you exactly and explicitly which landing page works better, what time of the day your email has better open rates etc. will fit your bill.

Interesting Read:

• Real-time analytics isn’t really good

Image by Flickr user: Jacob Bøtter

Have you ever used a coding style guide when working with a team? If you haven’t, it’s about time I introduce you to the concept. All well-disciplined teams, regardless of their specialty, have a number of ground rules that keeps them uniform. Every major newspaper and magazine has a style guide. If you’re going to start building a team, you might as well create one before people start getting used to coding all over the place.

A mentor of mine once told me: “Getting a team of developers to cooperate is just like herding a bunch of stray cats.” Coders all have their own personal ways to construct routines and modules. Each of them has a preferred framework, a preferred IDE, and a preferred flavor of doughnut to chew on while working. It’s what makes a coder who he/she is. But you can’t just let ‘em all roam freely. You and anyone you work with have to make some compromises to put a sort of leash around your nasty coding habits.

I’ll give you my bad habits. I coded in C, and I didn’t tab anything. I just swam through, wrote enormous headers with defined routines I would later find myself not using at all, and rarely commented. It was my style, and it worked. The moment someone looked at my code to add something, he said, “Why’d you even bother making this open-source? No one can read half of it!” This isn’t the way to code when you’re collaborating with someone. That’s why you should make a style guide for your team.

Here are a few things you should include in your style guide:

• Comments – Let them know where, when, and how much to comment. Neatly commented work will be easier to navigate.
• Tabbing – Definitely make them tab their code. Every new subroutine (while, if, select, for, etc.) should have its content tabbed even further. Recursive tabbing saves tons of time and makes your team more productive.
• Variable names – Each name should have a prefix. A string for a person’s name should be called “szName” or something like that. This helps the development process by reducing the strain on memory.
• Structure – This is very important. Consider having team members write with a certain “grammar.” In other words, have them include a comfortable amount of white space between routines, and capitalize certain letters in a variable.

When you can read each other’s code with proficiency, you save plenty of time. Communication is also key. Have regular meetings and keep an accurate record of everything everyone adds to the product. Within the meetings, don’t just talk about all the Red Bull you chugged while pulling an all-nighter on the development of a module. Talk about the module itself. If you don’t establish some rules of uniformity, you’ll have a herd of stray cats that can’t finish something on time.

Be careful not to make the guideline too specific, though. Coding is still an art, despite all the computer-related stuff you’re doing. It’s best to let at least a minimal amount of personality seep through the seams!

Let’s get this right: mobile ads suck.

And if you’re planning to have that as your revenue model, you are throwing your app into a gorge unless it’s a really kickass application that people can’t do without. Chances of the latter being very thin in a very competitive world, today, it would be prudent to think of other revenue streams than mobile ads.

The Not-so-curious Case of Facebook Mobile

You’ve probably heard this a million times already but here’s it again: Facebook’s mobile monetization model was decreed “not-so-convincing enough” to encourage investors to turn the IPO into a massive success. Instead, it turned out to be a flawed scenario resulting in valuable lessons about mobile ads.

Facebook is one of the few popular companies that haven’t yet solved the puzzle of mobile revenue models. There are plenty of small-time developers and companies who are still struggling to figure out how their mobile apps can generate acceptably decent revenues.

Why Do Mobile Ads Suck?

1. Real Estate

First off, there’s this huge difference between a mobile screen and the desktop screen. There’s so much less real-estate on the mobile that the content itself is shrunk. Now, if you’re going to put some ads in between, on top, at the bottom or anywhere else, that’s going to steal under broad daylight very valuable space on the small screen. It drives people mad. We, as users, don’t like that at all.

2. Banner Blindness

People are getting used to banner ads. This is a generation that has seen a lot of banners in online advertising and we’ve grown immune to these. Mobile ads that aren’t disguised within the content – and that don’t provide relevant and intensive value – are easily filtered out and completely ignored. This is why there isn’t much to be made out of mobile ads as a revenue model (lower eCPMs)

Users are looking for a high level of value on the mobile platform than on desktop. The mobile being a very personal gadget, users have this subconscious feeling that their experience with any content (in the form of an app) shouldn’t be diluted, disturbed or contorted by ads.

Valuable content holds the key to connecting with your users and anything that mars this experience even by a tiny bit kills the chances of establishing a connection with your users.

With so many paid apps doing great, it’s clear that people prefer paying once to remove ads than to experience a free app filled with ugly ads.

There Are Many Alternatives

Sure, mobile ads do suck and mobile eCPMs are pretty weak compared to their desktop counterparts. But there are various other alternatives that you can think of. Some of these are being successfully implemented.

• if you can provide a truly amazing app and then top it up with an essential feature that people can’t do without, you can try the freemium model. It takes time and experience to crack the freemium model but it’s worth it.
• like Flipboard, you can promote a service/product through specifically targeted ads that are clearly demarcated from the content in a “usable” way.
• Alternatively, you can use your app to promote a related product/service in your industry. Think of teaming up with other service providers.

From the users’ point of view, mobile ads are definitely not the way forward and if users aren’t going to be interested in it, you won’t find publishers either. Thinking of mobile ads as a revenue model? Time to rethink your strategy.

Image © TechCrunch

Users will hand over a lot of data to an application, sometimes without even noticing that’s what they’re doing. Unless you’re working with a particularly savvy group of users, the only time your users will pay attention to what information they’ve provided is when something goes wrong. You have to make the decisions to protect them and minimize those problems ahead of time — a smooth experience means that you can land and keep more users.

As Little as Possible

When you’re considering what information to ask your users for in the first place, and what you need to save, there is a simple rule to stick to: ask for as little as possible. It’s tempting to ask for a lot of data; after all, you can do all sorts of analysis and use it to help you land even more customers. But the reality is that you usually don’t need all that much information for an app to actually work. Since you can’t really predict when you’ll get around to that big analysis project, why ask for data you don’t need yet? You can always get some of it with a customer survey later on, plus perhaps some more useful information.

Go through what fields you’re considering asking your users to fill out when they sign up. Eliminate everything you can — it’s not a bad option if you’re only asking for an email address and a password. Heck, you might not even need that. The same goes for what information you’re collecting that your users might generate. It’s much harder for a security vulnerability to expose information that wasn’t actually saved.

Dealing with Financial Information

Financial details, like credit card numbers, are in a class of their own when it comes to keeping them secure — there’s so much more incentive for someone to try to get ahold of such information. If you’re selling something, you’re going to have to accept payments in some fashion. In general, it’s a good idea to make credit card numbers and other financial data someone else’s problem.

Handing the issue over to a payment processor that has already invested their resources into safeguarding payment information will make your life easier, but it can also make you appear more trustworthy to your users, especially if they recognize the payment processor you’ve chosen.

Your Legal Obligations

Just what your legal situation is when it comes to storing data about your users depends greatly both on where you’re based and where your users are based. In the U.S, for instance, there are laws specifically governing what information you can store about minors, particularly those under the age of 13, as well as about financial and medical data. Do your research so that you don’t have to deal with a legal problem right off the bat.

Security and privacy issues are only going to get more press in the future, so invest whatever you need to make sure that you’re saving user information correctly and safely.

Image by Flickr user Daniil Vasiliev