How an email group brought me my first PHP project
I learned PHP by chance in 2002.
Before that, I was mostly working in FoxPro and Visual C++. I did a little bit of JavaScript here and there, but not much.
Those days, there were many email forums, or what they called email groups. Most of these groups were hosted on Yahoo.
You would send an email to a group’s subscription address and become a member. After that, whenever someone posted a message, it would go to everyone in the group. You could also receive the messages as a digest, with multiple messages and discussion threads compiled into a single email.
This was before LinkedIn and other social networking websites became common. If you wanted to connect with business owners, programmers, web designers or people looking for their services, these email groups were among the best places to be.
I had joined many business networking groups where people would post requirements for programmers, web designers or whatever services they needed.
In one such group, I came across a message from someone in the US. He was looking for a PHP programmer who could build a quotation engine for him. The engine would collect lots of information from the user and calculate insurance prices from multiple companies.
I did not know PHP at the time.
Lots of niche portals were being built in those days, and I knew a PHP programmer who had worked on a popular portal. I wrote to her and asked if she would like to work on a PHP project. After confirming with her, I responded to the client’s message and told him that I could get the work done.
This may sound strange today, but such arrangements were common at the time. You found someone with the required skill, handled the client and managed the project. At least, that was how I thought it would work.
When the PHP programmer stopped responding
The client sent me the detailed logic of what needed to be done. I charged an advance, paid it to the programmer and, from my side, set the ball rolling.
She said she would give me an update in a week.
There was no update.
When I sent her a message, she said she would need another week. Another week passed… and there was still no update.
The logic of the quotation engine was difficult. The user had to provide a large amount of information, and the engine had to process it according to the rules of different insurance companies. If the programmer needed more time, it was understandable.
But the problem was that she wasn’t giving me any updates. She wasn’t telling me what she had completed, where she was stuck or whether she would be able to finish the work at all.
A delayed project can be managed if people communicate. Silence is harder to manage. When you don’t know what is happening, you cannot make a new plan and you cannot give the client an honest update.
Eventually, I wrote to the client and told him that the PHP programmer wasn’t responding. Since she had already taken the advance, I was prepared to return the client’s money out of my own pocket.
I gave him two options: either I could return the advance and we could go our separate ways, or he could give me two weeks to learn PHP and build a working version of the quotation engine myself.
This was a wild card because the project was already delayed. There was only a slim chance that he would ask me to continue, especially after knowing that I didn’t know PHP.
To my pleasant surprise, he said yes.
Much later, he told me why he had taken that chance. I had been giving him regular updates and had never tried to hide anything from him. He had also been looking for a trustworthy PHP programmer for a long time without much success.
At that point, perhaps my honesty mattered more to him than my lack of experience in PHP.
Learning PHP with a delayed project waiting
I was not starting from zero. I was already comfortable with C++ and had developed applications in dBase, FoxPro and Visual C++. I had also installed several of these applications for different businesses.
PHP syntax was similar to C++ and JavaScript in many ways, although it had its own commands and its own way of handling data. I purchased a few PHP books that were popular at the time and also sought help from websites.
There was a real project waiting to be completed, so I could not spend months reading everything about the language before writing the first line of code. I had to learn what I needed, use it immediately and then move to the next problem.
My learning process was quite direct:
- Read enough to understand the immediate problem
- Write the required code
- Run it and see what broke
- Return to the books or websites
- Correct the code and move to the next part
Every topic had an immediate purpose. I needed to receive information from a form, work with that information, apply the rules of different insurance companies and show the correct prices to the user.
When you are learning without a project, it is easy to keep reading while avoiding the difficult part: writing working code. I couldn’t do that. A client was waiting, money had already changed hands and I had made a promise.
Within two weeks, I had built a working version of the quotation engine.
The client was happy with the work and hired me on a monthly retainer for ongoing updates.
That was how I became a PHP programmer. It wasn’t planned. It began with a failed arrangement and a promise that I wasn’t completely sure I could keep.
What began as one project became a 24-year relationship
It is 2026, and I am still working for the same client.
The quotation engine has changed a great deal over the years. Its basic purpose remains the same, but the logic has become much more complex. More insurance plans have been added, and every plan comes with its own rules and calculations.
The companies represented by my client also keep changing their data. Sometimes they change the way a price is calculated. Sometimes they add a plan, revise an existing one or change the information required from the user. Every such change must be added carefully because one wrong condition can produce an incorrect quotation.
This is the part of programming that people often don’t see. Building the first version is only the beginning. A useful business application must continue to change with the business. Code that worked correctly last year may need to be revised because the company, product or calculation behind it has changed.
Over these 24 years, I have rewritten parts of the engine, added new plans and changed its logic many times. I have also learned that long-term programming work depends on more than knowing a language. You must understand the business rules, ask questions when the instructions are unclear and be available when something changes.
Learning PHP also paid me well. Over the years, I took on many other web development projects and built numerous websites. What began as an attempt to rescue one delayed project became an important source of work for me.
The first version of that quotation engine taught me PHP, but maintaining it for 24 years taught me something more important. A programmer needs technical knowledge, but clients also need someone who communicates, accepts responsibility and doesn’t disappear when the work becomes difficult.
I became a PHP programmer because another programmer stopped communicating. Perhaps that is why communication has remained such an important part of my work.
One unanswered email shaped the next 24 years of my life.