Yesterday afternoon I met and talked with a partner of mine about an
up-coming web project. Similar to the changes I made this morning, I
noticed that I knew what questions to ask and what details to watch
for.

I remember that when I first started I was constantly learning by
trial and pain. I remember scowering forum threads and looking
material up in books and wondering if I was somehow the first person
to ever have the questions I did. I remember making silent promises
that if I could have my answer, I would ensure that others would find
my solution by posting it.

It feels great to be beyond that.

Outside of the office, I also boulder regularly. Last week, I
overheard the owner telling one of the climbers that, “it wasn’t about
the numbers.” As a grappler I heard people saying, “it’s not about
the belt.” Numbers and belts both being skill level indicators.

These people are right, but in a sense, it is about the numbers and it
is about the belts. At their core they are just symbols, but they
make the activities more fun. For example, Pac Man is fun in itself,
but when you start trying to beat a high score, it gets much more
compelling.

You have to exercise caution however, mastering a skill is fun, but
it’s easy to turn that fun into work. You make plans, regimens,
drills, and etc. to deaden the fun and focus on what you percieve is
the quickest way to that high score which you have been enjoying
working towards. One day you wake up and there is no enjoying, just
working towards.

In addition, it’s no fun to reach too far beyond your skill level.
Nothing makes any sense and you utilize massive amounts of energy to
achieve only small parts of your goals. It’s not natural and
frusteration is ubiquitious. Similarly it’s no fun to wallow beneath
your skill level– boredom ensues.

There is a happy medium where you are regularly challenged and you
are up to the challenge. That’s where it’s really fun. For me, for
work, lately it has been writing extensions for other applications.
It’s an enormous step beyond coding websites.

It feels good to be at this stage of development and occasionally do
these easy jobs. If I had to do it all the time, I’d go nuts, but for
now it makes me smile and think, “I remember when this was difficult.”

From January until August I was working 60-70 hour weeks, getting up every morning and working into the evening seven days a week. Things leveled off a bit in September and then were depressingly slow into the end of the year. I started the year off poor and managed to end it poor.

This year wasn’t easy, but it’s been great.

I started 2009 with my general business strategy being that of marketing complete solutions to small businesses: design, development, and basic SEO. I planned to use content management as my niche, enabling businesses to exercise more control of their site than what other web professionals could offer. In support of this approach, I regularly attended a B2B group.

I no longer attend that group. Not only that, but I don’t market to small businesses, I don’t offer a complete solution, and I don’t sell content management (though I still specialize in it). In short, things are very different today than a year ago, and I’m in a much better position today to pursue my goals with Blue Bridge than then.

I’ve developed a strategy that I’ve found to work and work well. I now have a network of peers that I can collaborate with, receive work from, and give work to. I’ve angled my approach to provide me with the tasks that I most enjoy. And in the past 365 days, I’ve built my portfolio, my skills, and my business and technical knowledge.

Some of the things I’ve accomplished:

• I got certified as a Zend Engineer for PHP5
• I automated and improved my invoicing and client information systems.
• I did a challenging and portfolio worthy Wordpress site.
• I finally contributed to Joomla by writing and publishing a portfolio component.
• I increased my websites rank over 4,00,000 other sites.
• I developed a stand alone GTD application that is smart and useful.
• I did most of the work for a Wordpress tool that will be useful to many other developers.
• I arranged and implemented a site/brand re-design for BlueBridge that is far superior to my competitors’ sites.
• I documented my businesses systems and solved some of the core challenges of my approach.
• I managed to move BlueBridge’s niche from competing with small business web designers to providing professional development solutions.

I’m thankful for this year and what it’s provided me.  I’m grateful to my partners and to my family, friends, dog, and last, but not least, my wonderful girlfriend for being here with me.  It’s been wonderful: thank-you.

The Go-Giver is an allegory about a salesman named Joe who is trying to land a major contract in order to meet his quota for that quarter. He hatches a plan to try and convince a well known business figure, the Chairman, to help him pull the big contract. However, when he speaks with the Chairman, he finds himself going through a week long lesson on the subject of getting ahead.

Each day of the week is a theme about a law of Burg and John Mann’s approach. The five laws are:

1. The Law of Value
2. The Law of Compensation
3. The Law of Influence
4. The Law of Authenticity
5. The Law of Receptivity

My Take Away

I found the most important part of the giver were the first two laws:

The Law of Value

“Your true worth is determined by how much more you give in value than
take in payment.”

The Law of Compensation

“Your income is determined by how many people you serve and how well
you serve them.”

Why These Two

These two are the golden nuggets in the book because they most directly
reflect economic phenomena. I belive Burg would argue that these
aren’t intended to be viewed as tied solely bottom line, but rather
that they are meant to be life philosophies. However, I think they
pack the punch they do, because they are linked to economics.

Value and Price

Value isn’t fixed. When two parties engage in an exchange they both
percieve that they are trading something they value for something else
of greater value. I value a new 21″ flat screen display more than I value
$240. At the same time, I value $300 more than having a 23″ display.

There are a few implied corollaries with the first law:

• Know your target market and what they
• Know the difference between what they value and what you value.

I think that if you could get an accurate read on these two, you could
lower the value you provide to where it’s just above what they’re
willing to offer. I doubt Burg would endorse this approach and
neither do I. This has something to do with Burg and Mann’s second
law.

The Good of the Many

Like all businesses, I want to have happy clients. However, what
would make me very wealthy would be to have Apple’s clients. They
don’t have customers in the normal sense of the word, they have
missionaries that live the Apple lifestyle and continually seek to
convert those who don’t.

Apple doesn’t just try to provide an edge in value for what the
customer is willing to pay, they aim to provide an impressive user
experience that is more than worth the cost. They have seen their
influence and market explode because of this and in turn their income
has boomed.

What About the Other Laws

I don’t think the other laws are fluff, but to me, they seem to
represent sound personal values more than laws that will have have a
significant impact on a business. I would say that the attitude of
the allegory is karmic related and the final three laws act as a base
for good karma.

In Summary

I’m excited to work the Go-Giver ideas into my business’s systems. I
enjoy serving people and the story has ignited many ideas about how I
could improve my business’s services.

When I left the Marines, I had to attend a class on re-entering the civilian work force. Many of the speakers warned us that we may find that civilian life wasn’t all it was cracked up to be. I knew then that some people couldn’t stand the lack of structure and direction that exists in the civilian world, much like prisoners who have grown used to the walls that confine them.

A few years later, I was getting up every morning and having to go to work at an entry level position for a design firm in Vancouver. Going to work was easy, but I didn’t like the direction the firm was going and the direction I would be going within the organization.

Now I work for myself and I make my own structure and direction. I measure the environment, forecast changes, set goals, make plans, and execute them. It’s an opportunity and a blessing and I am grateful to be in this position.

The quote for virtues is a little tongue in cheek though, because it turns out that being lazy, impatient, and proud require copious amounts of diligence, patience, and care.

I’ve often seen a much more serious quality sought in programmers: attention to detail. Employers want this quality in the programmers they hire and most programmers probably find it to be an easy requirement. It requires a certain kind of myopic perception.

When I was in the Marines, attention to detail was also prized. During my four years I suffered several large errors that were caused by inattention to detail. They were whoppers for an infantry man, the kind that most grunts only made once. I made the errors from E1 all the way to E5. What they were was that I kept losing track of gear: bayonets, helmets, flak jackets, night vision goggles, and radios. I would be doing something and then realize, “Wait a sec, where the hell is my X?!!!”

These situations always caused me intense panic and were a major emotional drain.   They had zero impact on my ability to track details.

In the past two weeks I’ve probably sunk 14 hours into problem solving. I’d come to a point where I’d say, “I don’t understand this language as well as I thought I did– this phenomena doesn’t make any sense.” Then I’d find my detail.

The first six hours or so, I neglected to properly initialize a javascript variable with, “var.” It was causing semi-random behavior that makes perfect sense in retrospect. Yesterday and the day before I put eight hours into troubleshooting another seemingly random situation.

I was processing a WordPress database as text and whenever I tried to re-import it programatically, it would build the structure, but fail to populate the tables. If I took the *exact* same code and fed it to PHPMyAdmin, it would successfully re-import the database.

First, I was convinced that I was somehow using the wrong PDO function (query, exec, or statement execute). Then I decided that the str_ireplace function I was using could only handle a certain size of variable(other string functions had the same problem though). Then I figured maybe it was all the white space I had injected into the database export for readibilty, but this had no impact. Then I thought that maybe there was some encoding issue, and that by saving it to file, or at least “washing” it through an output buffer would solve the problem. None of this mumbo jumbo worked and finally I started using a diff tool to comb through the differences between the before
processing and after processing database imports. I found nothing that would cause a problem.

As my eyes glazed over after staring at two files side by side for an hour, I scrolled through them from top to bottom. I was considering taking a whole different tact to processing the database when my eye came to rest on my problem: an extra semi-colon among 753,043 other characters. One of the tables I was processing was empty and my code terminated each table import statement with a semi-colon. The statement before it got two semi-colons then, instead of one, which caused the rest of the imports to fail. PHPMyAdmin’s sql parser probably was smart enough to remove the extra semi-colon (good programming– hard to break).

I realized in the Marines that I couldn’t just be detail oriented. Faced with daily challenges though, I couldn’t afford to not be detail oriented either. What I learned was systems and principles. For my gear, it was something called, “Dummy Cord.” You tie everything to you, then no matter what happens, you don’t leave anything behind. New Marines are forced to dummy cord everything– I religiously dummy corded gear to me until the day I left the service, because every time I didn’t I lost something.

The system was dummy cord and the principle was, “If you don’t tie it to you, you’re going to lose it.”

For Javascript I have a new principle, “If the behavior of composite components is weird higher up the DOM, check for uninitialized variables in the lower components.”

For debugging in general, I have a new system/principle, “List your assumptions.” In this case, I assumed that the export data was correct, because I assumed that every table had data to dump. Also, “Go from more likely to more wild.” As in, it’s more likely that my import statement is messed up than there being a significant difference between executing a query with execute() or with exec().

So this afternoon I sat down and used a UML Modeling program to model up the validation interface.  It took me about an hour, and everything was done, but just for clarity, I decided to mark down the multiplicity of some of the relationships.  The second relationship I marked the program crashed; I hadn’t saved my diagram.  A rookie mistake!

I’m not going to rebuild the diagram.  Instead, I’m just going to describe the structure of the Validation package:

• The Validation Interface works like this:
  
...
$validator = new ValidationFacade;
$validator->addValidator(new GruntValidator(new emailSpec("email"), "That's not an email, please double check it.")));
$validator->addValidator(new GruntValidator(new alNumSpec("username"), "Your username can only be letters and numbers.")));
$validator->addValidator(new GruntValidator(new urlSpec("url"), "Please check your home page, that's not a valid url.")));
$validator->validate();
$clean =& $validator->getCleanRequest();
if(!$clean){
$this->_processErrors($validator->getErrors());
}
...

• The ValidationFacade class acts as a  facade to make the subset of interfaces and classes simple to use.  It’s composed of a ValidationCoordinator object and an array of GruntValidators.  It also depends on two classes that represent the HTTP Request: RawRequest and CleanRequest.
• In the code snippet above, you can see how the validators are added to the facade.  Behind the scenes, the facade creates a ValidationCoordinator with a RawRequest object and a CleanRequest object when you call the validate() method.
• The GruntValidator object is just a dumb worker.  You give it a tool, it performs a task with the tool, and it returns the result.  To make this possible, it depends upon an interface used to define how it can interact with it’s tool.  In this case, the tool is a test or rule. (emailSpec, alNumSpec, urlSpec)
• The rule follows a pattern called specification.  Specification tests whether something meets a given criteria(hence why I called it a rule a moment ago).   In the code files I’m going to attach, the interface is implied, but each specification object uses the same methods to apply different tests.  In the code above, those tests are an email test, an alpha-numeric test, and a url test.
• On validator->validate(), the ValidationFacade calls each GruntValidator and it passes them the same ValidationCoordinator object.  Each GruntValidator, calls the test method from the specification object it was given when created on the ValidationCoordinator. In this case, the intent isn’t to test the coordinator, just give it to its specification object.
• This is where the magic happens.  The specification object, asks the coordinator for the fieldname it needs.  The coordinator grabs the fieldname from the RawRequest object and gives it to the spec object.  The spec object tests the field and reports whether it passed the test or not to the GruntValidator.  If it passed, the GruntValidator tells the coordinator to add it to it’s CleanRequest object.  If it failed, the GruntValidator gives the coordinator its error message and tells it to add it to its errors list.
• When all of the validators have been validated, the facade checks the coordinator for errors.  If there are errors, it can’t get a CleanRequest object, if there aren’t errors it can.

This definitely isn’t the simplest way to validate a $_POST or $_GET array.  However, it does have it’s benefits.  It cleanly separates the processing from the view logic, it ensures that all values are validated and nothing can slip through (the RawRequest object destroys the globals when it is initialized), it’s easy to use and extend (OCP, SRP, and DIP), and it’s mobile and so I can benefit from it’s OOP nature instead of writing and re-writing validation when needed.

The authors of PHP in Action, leave a couple interesting ending points, that I may explore.  They suggest turning it into a fluid interface and also discuss possible methods to remove duplication between client and server side code (this would involve coming up with a set process, which is a-okay for me).

The classes:  Validation.tar.bz2

I’m going through an interesting phase with my business.  I did some navel gazing back in August and realized that client interaction takes up most of my time and doesn’t contribute nearly as much to my earnings.  I’m good at relationships, however just because you’re good at something doesn’t mean that you should devote more time to it than other activities (like billable work).

I figured out that to decrease my time working and increase my earnings I had to either try to focus on a few clients with larger budgets or get out of the client service business altogether and start writing software.  I decided to do both.

My first step was towards limiting support.  I stopped providing any type of services resembling it to my current clients– this was the bulk of my client interaction and generated lots of small transactions over the course of a month, but took up most of my time because each request generated communication overhead that was nearly equal to the work itself.

Here is what it looked like:

Small transactions

1 hour communicating/planning + 1 hour work = 1:1 ratio.

Communication is being billed, but three to four support requests at irregular times throughout the week slowed down and broke my focus on other projects.  In addition, these small support projects always occured as emergencies.  I considered charging an overnight rate, but realized that by adding another layer to my pricing I would incur upkeep in managing it, thereby adding to my time invested every time it occurred.

I decided what I wanted was the following:

Larger transactions

5 hours communicating/planning + 30 hours  = 1:6 ratio.

Under this system, I only need a project a week and my work flow is greatly improved.  These types of projects don’t occur as emergencies (like *all* small support tasks) and contribute greater hours to my bottom line.  In addition,  they’re easier to anticipate and don’t interrupt other projects, which increases efficiency and the quality of my work by allowing me to maintain  focus.

I think it’s clear that dropping support and trying to focus on larger projects is a benefit to me and the direction I would like to go with my business.  I think it also offers clear benefits to potential clients who want programming done or a complex site created.

However, I’m having to re-think this strategy.

The challenge I’m seeing is that some of the clients who are interested in the larger projects also want support.  They don’t just want someone to build it, they also want someone to take care of them once the project is done. I want a long term relationship also, just one that is project — not support — based.  What I’m trying to achieve is a lasting series of one night stands and what many clients are looking for is a marriage and babies.

Web agencies do that.  They have their veterans building and their apprentices supporting.  Generally speaking, support doesn’t require the smarts that building does and it’s a great way for growing developers to learn.  The vets earn their higher pay by taking on the more challenging jobs and everything occurs hidden under the agency’s banner.

Growing into an agency is not a part of my business plan and not an option.  An alternative that has come up frequently, is that it would behoove me and the people I partner with to form some sort of collective that could offer agency-like solutions.  That way, I could say, “I’ll build it and this partner will support it.”  The benefits to my clients of such an association would be best weighed in another post, but I know that several of the other web professionals I work with have brought up the same idea for differing reasons.

Another additional idea I have is to re-offer support, but on a package basis; it would be something semi-expensive like $400 per month, whether or not they use the hours their reserving for support.  The benefit of this would be that it would demonstrate the value of my time and change the perception to that I do offer support– just that it’s expensive.  As a bonus, this probably is comparable to many agency support packages.

A challenge that I’m currently interested in is input validation.  To date, I’ve been writing input validation as methods of classes that needed it.  Doing it that way doesn’t help me in the long term, because I can’t gain from code reuse.  It also doesn’t conform to good design practices because validation is, “the concept that varies.”  Fortunately, PHP in Action has an entire chapter dedicated to developing a logical framework for input validation.  As a bonus, it covers the Specification and Facade patterns.  Unfortunately, the authors don’t make any recommendations for the actual validation rules.  I will have to fill those in on my own.

My plan is to create the classes tomorrow and Thursday(Turkey Day) and post them here along with an explanation of how they interact this weekend.

This is my third time around the blogging bush. The first time I was
blogging about Linux and the second I was writing about small
businesses and web related technologies. I enjoy writing, so blogging
is a natural fit, but both times I was typing to an external pressure
(trying to tap into a growing user group and developing my “expert
status” for business reasons).

Fortunately, I’m putting all that behind me. I’ve read advice to the
effect that a developer should develop software to solve their own
problems. In a similar vein, I’ve decided to engage in purely
ego-centric writing. That doesn’t mean that I plan on writing about
whatever happens to interest me at the moment, just that I will write
more in the vein of journaling my experiences rather than trying to
create value for potential readers.

So if I’m not writing about the fuzz in my navel and what I had for
lunch today, what do I plan on journaling? This blog will serve to
chronicle my experiences and thoughts as a freelance web developer.

What has inspired me to do this has been a series of synchronicities
on blogging for personal development and the lack of information I’ve
found on freelancing as a web developer. The latter is a problem that
has vexed me for some time.

There are two sides to what I do professionally: craftsmanship and
business management. I formed Blue Bridge a year and a half ago and
since then I haven’t encountered any other individual who is doing the
same thing. I’ve met loads of freelance web designers (and a few of
them even dabbled some in development), but only two coders. Both of
the coders were semi-employed and made most of their income off of one
client. One of the developers actually works on site for his client
and still does some work on the side. So in a sense, neither
developer counts.

Most of the content I’ve found online caters to this skew of
demographics. It’s fairly straightforward to find information on
freelancing as a web designer and if you’re in another web related
trade, like a virtual assistant, much of the advice and information
will carry over.

Web development is different. It covers a broader range of
possibilities and skills. For example, with web design you focus on
developing your graphic design skills and your HTML and CSS. If you
have somewhat of a technological bent, you might invest in learning a
little Javascript or JQuery or figuring out how to theme designs for
Wordpress.

As a freelance developer you have to choose a set of languages to work
in that will directly impact what projects you can take on. They have
to be cohesive with each other, relevant to a market, and have a
future on the web. Finding that set is no easy task. When I started
out I almost chose Coldfusion over PHP as my server side focus. If I
had followed that path, freelancing as a developer probably wouldn’t
be an option because Coldfusion doesn’t have close to the ubiquity
that PHP does.

In addition to programming languages, you have to have a good
understanding of popular web platforms and how to work on and with
them (Wordpress, Joomla, Drupal, Magento, Zencart, and etc. and etc.)
You also have to have to know web servers, relational databases, and
security threats. Being that the web is so text-centric it doesn’t
hurt to have working knowledge of regular expressions either(a small
language in its own right).

Rapid application development through the use of a framework is
quickly getting to be an essential element of the developer toolbox:
which means a developer needs competence in CakePHP, CodeIgniter, the
Zend Framework or one of the others. They might as well match their
server side framework with a client side one: JQuery, Prototype,
Mootools, Dojo, and etc; because their clients are going to want Ajax
or animation at some point.

Finally, you also need to have competence in the tools you use to get
work done. That means an IDE or an editor, a version control system,
unit and web testing tools, and whatever else a project may demand
(automating builds, etc). These all come down to additional choices:
Eclipse, Net Beans, Notepad++, Aptana Studio, Subversion, Git, CVS,
Phing, and more.

As you can see, web development is complex in itself. If you’re lucky
you spend time in some sort of incubation where you develop a
specialized set of skills, a reputation, and a network to feed you
work. You find yourself moonlighting and then think, “Why don’t I
just quit and work for myself?”

That’s not how I did it– I did the opposite. I thought, “Why work
for someone else when I could be driving this thing?”

I think that the reason there are so few freelance developers to their
design counterparts is because of the common personality traits in
developers. I’ve no hard evidence to back this assertion up, but I
would generalize that developers commonly need organizations to
support them (and their development interests) and don’t like the risk
and uncertainty of freelancing. They may strike out on their own, but
they soon return to the fold of the same or another organization.

The lack of freelance developers out there leads to a lack of
information for and about those developers which leads us to my
predicament: I’m making this up as I go along.

Because I choose to continue as a freelancer and have no desire to
integrate into an organization, I have to make my own calls. I have
to balance my business’s needs along with the needs of the business
for me to grow as a developer. I’m continually faced with strategic
decisions and have no basis on which to make decisions expect my
limited previous experiences. I’m sure that there are others out
there in similar situations, just I’ve yet to encounter them or
benefit from their experience.

The information available on web design freelancing is of limited
help, because it doesn’t cover the complexity of development work.
For example, one of the questions I’m focusing on right now is how I
should structure my pricing.

To date, I’ve had a very designer-like approach. I submit bids based
upon an hourly projection. This has worked okay because much of the
work I’ve taken on has been neatly confined to a website package.
That is to say that the projects have revolved around a website’s
development from a designer or project manager’s concept to a live
site. However, where I want my business to go is primarily to
programming. For that type of work it is much less likely that a
project will be neatly wrapped in a familiar site-like package. Due
to this, it may not be appropriate to work based on a bid. The means
to program solutions may actually work against a bid based approach
and I might be limiting my profits and the benefit of my work to my
clients by working according to a price model that doesn’t fit.

Whether that’s the case or not, I have no idea. However, I plan on
exploring and answering this type of question through blogging. I
already drive my professional advancement through reading and
experimentation and now I will document take the time to document what
I’m learning.