[tags] yui, jquery, javascript, forms, symfony, plugin [/tags]

[tags]nginx, server, symfony[/tags]

[tags]nginx, rewrite[/tags]

I know this, but a lot of people were surprised that this is what I do at Yahoo! When I attended Lunch 2.0.

[tags]infrant, readynas, nv+, redux, harddrive, crash, gear[/tags]

Just an ordinary day… and then all of a sudden you read the news and realize that Benazair Bhutto was assassinated.

One lesson I keep learning is get out as soon as you can if you’re in a sub-optimal situation.

So I’m out a large chunk of change, spent endless (un-billed) hours going back and forth with my client and I have very little to show for and I have a client who’s disappointed with my work. Boo.

Well I learned quite a few lessons in consulting in all of this and being a subcontractor.

Get out early

If a project isn’t going the way you think it should, or you foresee something not being a good relationship. Get out early. Get out before you start.

For me I felt like I was leaving a client hanging - even though I felt like I was getting a raw deal, even though I knew their expectations weren’t being met. I figured we both put effort into this and I might as well see it through.

I persisted with this, even after there were situations where it no longer made sense to continue. I persisted. I stuck to it, even during a conversion of our part of our house into a rental and managing a daunting move across country and negotiations for full time employment at Yahoo! I decided to put my nose to the grind and stick through it.

While life changes alone weren’t a reason to abandon a project, it was clear from other goings on that I should have not persisted. The client could have subcontracted quite easily to a number of other firms, and we could have just cut our losses. In the end we both had losses and nobody wins.

Meanwhile I got out or rejected a lot of projects simply because I saw similar patterns emerging, or that it wasn’t going to be a good communicative fit. I am glad to not have that extra baggage on my shoulder.

Don’t sell yourself short

I had a negotiated rate with this client that was less than what I normally charge. I never raised my rates even when many of my clients were paying a significant amount more.

I had… for whatever reason had worse relationships with people who paid a lower hourly rate. I know their is a psychology of value that people perceive with higher rates. You’ll treat a $20 pair of jeans like crap, and complain about them wearing out, but a $80 pair of jeans that you wear on special occasions you’ll treat like gold.

After raising my rates, I realize now that I do better work when I’m compensated for it. I feel better about the work I do. The clients don’t waste my time (paid or otherwise). The communication is also dead-clear. Nobody risks miscommunication when the stakes are high.

It’s hard to do because you want to be able to help people and be accessible, but in the long run this works for the best. The clients I do have now really appreciate me, and really respect my expertise.

Work on interesting projects or short projects or both

I decided a lot of development is tedious. Build this module, make this crud, create this form, etc. Some development is fun and interesting and engaging.

Engaging work is hard to come by, generally people who approach me about large projects have some grandiose vision which I don’t necessarily share, or think will pan out.

It’s a bad idea to get involved with those projects, because money alone can’t motivate you.

If the project spans more than a few months and its not engaging… it will be a drag. You might out of guilt pass up better opportunities and be stuck in a bad situation. Let someone who is motivated by a project work on it, and go move on to better things.

Estimate well and get it down in writing

I can trace the beginnings of failure with this project from before I started it. I was asked to give an estimate on the project and I ball-parked it. The estimate wasn’t supposed to be committal, but it ended up being construed as such.

Estimates define expectations and even if they are ballpark figures they aren’t always flexible.

Large projects are hard to estimate. It helps to have a detailed specification, sketches, etc, but really the onus is on you to make sure you can create a detailed estimate. There’s two schools of thought on estimates. One is that they can never be accurate. The other is that they can be done and take a lot of work more than the actual development in some cases.

I believed in the former, but everyone wants the latter. Strive for the latter and pad numbers if you have to. If you over-estimate you get free money. If you under-estimate… someone ends up paying more than they expected or working more than they expected.

A detailed outline of every step and every check off point should be made. This is where large projects get broken down. You may want to just agree to work on one module at a time, rather than the whole thing.

If you’re not willing to do the estimate, or if it’s not coming out right, you can ask your client to come up with the check points and you can use that as a starting point. Either way, the school of “estimates don’t work” isn’t going to cut it.

Follow the money

I was being subcontracted. For how much, I did not know. But I had this feeling that it wasn’t for enough money. I used to resent working for companies, or being subcontracted, because I felt they were making a mint off me. But I now no if the margins are too tight, you run into a lot of other problems. Large margins can afford yo to go over an estimate. They can also allow you to increase your rate over time.

It also removes guilt. There is a lot of guilt that is to be had for charging clients for work. I myself wouldn’t pay a developer to develop my own hair-brained idea, unless I had some source of funding. Make sure you know that one exists, and then you won’t feel bad charging a decent price.

Don’t count your chickens before they hatch

I ended up bringing in a contractor to help me finish up the site. I thought it would work, but my margins were nil. I ended up not getting paid my last invoice, and I had to pay my contractor out of pocket. It wasn’t really pocket change either. I was so sure that we were going to see the project through and that my client who had a reputation of paying me on time fell through. It will take me months to recover from it.

Closure

I paid up my contractor, and had to write this all off to a life-lesson. Even before this ended I learned to take smaller or at least more interesting projects. I learned to not compromise as much on my rates. I also keep better tabs on the money. I want to help people develop web sites, not deal with headaches, long nights, chasing down clients for money.

I decided I want to learn python, if only to learn Django and to “get” what all the python hub-bub is about.

Python’s named arguments in function calls is pure genius. Let me explain.

In PHP, and many other languages you can define a function as such:

function foo($a = 2, $b = 2)
{
	return pow($a,$b);
}

If you follow, foo() will give you 4. foo(3) is 9 and foo(99,0) is 1. In python we can do the same thing, but it’ll pay to use some better variable names:

def foo(base=2, exponent=2):
	return base**exponent

Similarly foo() will give you 4. foo(3) is 9 and foo(99,0) is 1. But what if we forgot what the order was? Did base come first or was it exponent? We can do this:

foo(exponent=99, base=2)

Since base and exponent both have default values, we can even omit base and let it use the default:

foo(exponent=10)

This means rather than passing an $options array to my functions and checking whether an option was set or not, I can just specify which options I want in my function call. Or instead of remembering the order of the arguments, I can use whatever order suits me. Or instead of calling a function like bar(null, null, null, 2) I can just skip those first three arguments all together.

A side effect of this, is now there’s a real use, even for simple functions, to give your variables easy to remember names.

After talking to people about the benefits and disadvantages of various ORMs… and reading up a little on non RDMBSs like Amazon SimpleDB I came to the realization that ORM is really a hack to get RDBMSs to work as a storage for objects.

I’m being liberal with the term hack. It really does work for a lot of situations, but it’s not very elegant. The workflow is more or less this:

• You create a database.
• You create some objects
• You define tables to store attributes of objects
• You establish a mapping

There’s a lot that goes into database definition. It would be nice to breakout from this line of thinking and do things a bit differently:

• Create database
• Save named (e.g. Person, Place, Log, Restaurant, Rating, Review) serialized objects to the database.

Let the database learn from the saving of the object how to define the type. In fact, it should be flexible and let us have mixmatched types, etc.

Let the database index everything, and keep the indexes up to date, but prioritize it based on usage. In other words if we usually query a database of Persons in order by a field called lastname, then make sure that index on lastname is always at hand. We should be able to query this data back out of storage based on how we stored it.

We should also be able to reach other objects in the database in a similar manner.

The key here is letting the database layer do the heavy-thinking about what to do with serialized data, versus having some middle layer take care of it.

…

so I might just be naive about data and databases. But if this idea is worthwhile and some database people can validate me, I’d be willing to work on it.