views:

232

answers:

6

As people trying to broaden our knowledge and become better developers... when should we turn down a project and say "I don't know how to do that"?

Obviously there are extremes that are obvious e.g. new developers shouldn't be coding life support equipment.

But what about a new web developer that hasn't tried working with databases yet. Should he turn down a job that requires some database design/coding?

What about a mid level developer that hasn't had any experience with payment processing? Does he turn down a job that deals with sensitive information like this?

How do we know whether or not a project is too much?

+1  A: 

If there's just a component or reasonable portion that I don't know anything about - I'd go for for it anyway. If you really get stuck you must have friends and colleagues that could help out. And there's always stackoverflow - anxiously awaiting....

Paul
+3  A: 

If it's only about some aspect or component of the system you more or less know, then no, don't turn it down. It is the nature of the job to face challenges all the time, to learn new components, systems, integration strategies etc.

You can learn how to integrate payments in one evening. It's very easy.

It is more difficult with databases, but you can't really be a web developer and do not know databases. Do some small personal project, try out databases after which you will have at least basic knowledge.

And sure, assess what you can and what you can't sensibly do with your skills in the amount of time allotted. If your guts telling you you'll screw it, then don't start it in the first place.

If someone wants you to write some blog engine that's fine. Not difficult. But if somebody wants a Facebook clone, that is clearly too much for a beginner.

Developer Art
A: 

NO, never. If as you state

What about a mid level developer that hasn't had any experience with payment processing? Does he turn down a job that deals with sensitive information like this?

I do not see this as a problem, how many times have you found yourself in a situation where you might have felt out of your depth (looking back at your career), but you would never have gotten where you are today, without trying.

And i do aggree with

Obviously there are extremes that are obvious e.g. new developers shouldn't be coding life support equipment.

But ingeneral, take it and work as hard as you can to succeed, and learn something new. X-)

astander
+1  A: 

If there are legal liabilities if you screw up, that changes the equation, and the degree of unknown-ness definitely factors in. But normally, you disclose that there will be some research required on your part to the client and accept the job anyways. General rule of thumb: Avoid e-commerce, mission critical applications, military stuff, etc. if you haven't done it before. There is always a first time for everything, but you always want at least a couple people on the team to have done it before if you're handling anything like that. Otherwise, generally everything else is fair game as long as you've given the client the heads up that you're going to have some degree of learning curve so that they can make an informed decision. Sometimes you have to alter your rates as a result, but I don't generally recommend that if you can help it. And be sure to carry liability insurance if you do get into e-commerce or anything else on the list of caution areas.

With e-commerce in particular, it's not as dangerous these days because there are auditors usually involved in the process, and it's their job to catch your mistakes. Additionally, most payment gateways will allow you to store the credit card remotely on their servers. This dramatically reduces your risk and liability. If you're going to start doing e-commerce, read up on what's required for PCI DSS compliance, and ideally, subcontract with (or even hire) someone who's done a few billing systems before. Perhaps use an off-the-shelf billing system and turn the project into a matter of integration.

Bob Aman
Good point, subcontracting is a possibility.
Paul
A: 

I would say no to a project only if

  • I have little or no interest in it which might stop me from putting my 100%.

  • After looking at the project and timeline you feel you would not be
    able to do justice to the project.

Perpetualcoder
A: 

First, you need to be honest with yourself about how long it will take you to remedy your deficit. And is it appropriate for whoever is signing the checks to pay you to learn, when if they found someone else more suitable, and paid them, they would receive productivity right away? Also, you should decide this about yourself now, this is not the last time this will happen and you need to know where your ethical lines are drawn. Lastly, if you do decide to pass on the project, don't just turn it down, but if you know of someone suitable, recommend them. If it works out, then it is a win-win and both will remember your part in putting them together.

Ken Lange