This session is intended to be a laid back discussion about the benefits and drawbacks of freelancing as a Drupaler. The main theme here is how the the individual actually represents a community, and clarifying the difference between working as a Drupaler in the freelance world and more 'generic' kinds of web-design related freelancing.
Topics include but are not limited to
- Pitching a project
- Legal paperwork & proposals
- Development vs. design & theming and time management
- How to deal with crazy people
- Q & A
A couple of sites built on a freelance contract will be shared, so we can pick at what's good and what's not as a group. This will also allow us to address the details in said topics such as work-flows, mockups, timelines, dealing different clients, different industries and establishing an identity as a freelancer depending on where, and more importantly who you are.
This is intended for everybody; people that are starting out, have been doing it for a while and those that have been doing it so long they can't remember life before Drupal.
Comments
I can vouch
For the awesomeness of this presentation.
Do not be fooled...
...by his scary avatar, the only people that should be frightened are his clients. :-o
but it does add oomph...
... to the bullet point on dealing with crazy people! Nice juxtaposition.
Jean Gazis
www.jeangazis.com
www.webhostny.com
Sounds good but...
when? where?
DRUPalCampNYC8
DrupalCampNYC8
Totally looking forward to
Totally looking forward to learning "How to do deal with crazy people". Lord knows I've been tryin' to figure this one out for a long time...
I may be a crazy person
I may very well be one of the crazy people you are referencing here. We hire people. They say they can do this or that for us, show us what seems to be functioning sites. We call references. They seem solid for the first two weeks, then the project is delayed, more money, more time. We get anxious/worried. Deadlines are missed, functionality is not working correctly. We get more anxious. We may be trying to manage our own client. We are thinking, "should we fire this person/team now, or keep praying and hope that they can turn this around?" We wait because we are scared and sick because we are missing deadlines, budgets etc. We sunk so much time into documentation and selection of a professional. We hope against hope that a miracle will happen. It doesn't, and now we are looking for the clean up person. At this point, we re bitter and crazy...and looking for you to save our ass. This has happened to me twice.
same here
I've been called twice for "2-3 hours" of "finishing touches" on sites... where I could easily have spent that much time just assessing what the heck had already been done, let alone how or why. I'm not even talking about code, just core functionality (or ignorance thereof) and simple admin stuff.
What's scarier is that I'm now hearing that "it seems like all the Drupal people are this way" - although that may be a case of getting what you are willing to pay very little for.
Jean Gazis
www.jeangazis.com
www.webhostny.com
I'm incidentally right in the
I'm incidentally right in the middle of one of those.
I feel like the majority of the work I'm doing on this specific one is convincing people that "not all Drupal people are this way."
This is incidentally, one of the main points I want to touch on with this presentation; that being a freelancer is one thing, but being a freelancing Drupaler is another. We are technically representing an entire community with the work that we do, and it is not only something to consider and contemplate seriously, it is something to look forward to and grow with. It's also great for a client to know that if something happens, there's a whole world of us out here that can fill in/pick up/continue the job.
Yeah... I think it's a
Yeah... I think it's a problem generally, because of the nature of PHP (easy to code badly) and Drupal (easy to make it work the wrong way), that people looking for Drupal developers don't have good metrics to separate the truly good from the bad. They see a shop's portfolio and the sites seem to work, and not being developers themselves, they don't know the difference. I've seen even huge established shops with great reputations hack core! (And oh the headaches to refactor that for upgrading later...)
Maybe we should have a support group at DrupalCamp for the developers who have to deal with this on the repair side... :)
Drupal people
thebuck stop is right in terms of php and drupal. There are many people claiming to be able to do this sort of work, with no real clue (or some limited clue)and many people with extensive portfolio's doing things incorrectly--functionally, things work, but they are not built correctly. Again, I have been a victim of both. It is very hard to parse a developer if you yourself are not a developer. I would pay to have a vetting service. The vetting service would have to prove beyond a shadow of a doubt they they knew what they were doing, this might be a useful service. Also, as someone who hires developers, I cannot emphasize enough how important good communication is. Sometimes I think it is better to do a quick evaluation--peak under the hood and outline and issues that you might think are significant or important to rework. I don't want to find out after 15 hours of work that something might be wrong with the core.
Vetting
I wonder if, as part of this presentation, we could collaboratively come up with some guidelines that clients can use to judge the quality of prospective developers they want to hire. We could explain them in the context of "we've had to repair this, here's how you prevent it in the first place," and make a document that people can use.
I'm not sure how to make guidelines like that for non-developers to use, however. Any thoughts?
Actually this makes more
Actually this makes more sense for the session Lessons taken from Drupal Rescues, I'll suggest it there.
I think this is a great idea,
I think this is a great idea, but as something more panel or BoF oriented. I was actually hoping to have it followed by a BoF :)
Last time I gave this presentation, we had a nice follow up here: http://groups.drupal.org/node/55403
Hoping this sparks more discussion post-camp too.