I wrote my first paid code when I was about 14. A freelance job, PHP, something small that someone needed done. I didn't know what I was doing. But I figured it out, delivered it, got paid, and kept going. Twenty-eight now, still shipping code, still figuring things out. The languages changed. The lessons didn't.
Key Lessons
- Code that ships beats code that's clever, every time
- Maintenance is the real job - building is the easy part
- Working across cultures and time zones teaches more than any framework
- Breadth isn't a lack of focus - it's a different kind of expertise
The Early Years
I did my BS in Software Engineering at the University of Lahore. 3.71 GPA, which I mention only because people assume self-taught developers skip the fundamentals. I didn't. Data structures, algorithms, operating systems, compiler design - all of it. The degree gave me a foundation. Everything after that gave me opinions.
My internship at Demixsoft was PHP, JavaScript, and C# desktop applications. Three languages in one role. That set the pattern for everything that followed.
After that I freelanced. A lot. Laravel backends, Vue frontends, Unity game development, Arduino prototyping. Whatever clients needed, I learned enough to deliver. Breadth turned out to be its own specialisation. Some of those projects were small. Some were messy. All of them taught me something.
The Unity work was interesting because game development forces you to think about performance in a way that web development doesn't. Every frame matters. Every allocation matters. When I went back to web work after a Unity project, my code was leaner.
Arduino was different again. Hardware constraints make you respect resources. You can't throw more RAM at a microcontroller. You learn to be efficient or the thing literally doesn't work.
The Scraper Years
I built over 30 web scrapers in C# for Teoalida. Property data, real estate listings, structured extraction from sites that didn't want to be scraped. This sounds unglamorous. It was some of the most useful training I've had.
Scrapers break constantly. Sites change their HTML. Rate limits kick in. CAPTCHAs appear. Network connections drop. You learn to write code that expects failure and handles it gracefully. Retry logic, exponential backoff, checkpoint systems so you don't lose hours of work when something crashes at 3am.
Every enterprise integration I've built since then uses the same patterns. APIs are just scrapers with better documentation.
Working Across the World
I've worked with teams in the US (STSBrands), Slovakia (smartsourcepartners), and New Zealand (PB Tech, RIVER). Remote, across time zones, different working cultures.
The biggest thing I learned: clear written communication matters more than any technical skill. When you're eight hours ahead of your team, you can't tap someone on the shoulder and ask a question. You write things down. You document your decisions. You make your pull requests self-explanatory because nobody's going to be awake to walk through them with you.
This made me a better engineer. When you have to explain your code in writing, you write better code. Simpler functions. Clearer names. Less cleverness.
PB Tech and commercebuild
Six years at PB Tech, New Zealand's biggest tech retailer. PHP, SQL, Apache Solr for product search, REST APIs for internal systems. This was the most sustained enterprise work I'd done, and it changed how I think about software.
At scale, everything is a data problem. Product catalogues with thousands of SKUs. Search indexing that needs to be fast and relevant. Inventory that has to sync across systems without losing orders. The code isn't hard. Keeping the data consistent is hard.
At commercebuild, I worked on their eCommerce platform - payment gateway integrations, Elasticsearch, Laravel. That eCommerce experience turned out to be directly transferable to enterprise AI. Payment integrations taught me that third-party APIs are never as reliable as their documentation claims. You build for the failure case first.
What Actually Stuck
Code that ships beats code that's clever. I've written clever code. Elegant abstractions. Beautiful patterns. Most of it got rewritten within a year by someone who couldn't understand it. The code that survived was boring. Simple functions, obvious names, straightforward logic. I stopped trying to be clever around year eight.
Maintenance is the real job. Building something new takes a few weeks. Maintaining it takes years. The decisions you make in those first few weeks determine whether maintenance is straightforward or painful. I now spend more time thinking about how code will be maintained than how it will be built.
Breadth is its own skill. I've built in PHP, C#, JavaScript, Python, and more. Each language taught me patterns that transferred to the next. Unity taught me state management. Scrapers taught me error handling. Arduino taught me resource constraints. None of that happens if you stay in one stack.
Working across cultures teaches you to communicate. My best documentation habits came from working with teams I couldn't talk to in real time. When your code has to speak for itself, you write differently.
RIVER and Now
Hassan's the person you put on the problem nobody else can figure out. Not because he knows every technology, but because he'll learn whatever the problem requires and start producing useful output within days. That's rare.
Isaac Rolfe
Managing Director
I joined RIVER in 2022. The work here is enterprise AI integration - connecting AI capabilities to existing business systems. It uses everything I've learned: the Laravel and PHP from PB Tech, the API integration patterns from commercebuild, the error handling from the scraper years, the cross-timezone communication from remote work.
I also built ByteRemix, my own startup. Different context, same lessons. Ship fast, get feedback, iterate. Don't build what you think people want. Build the smallest thing that works and find out.
Fourteen years in, the thing I'm most confident about is that the fundamentals don't change. Languages come and go. Frameworks rise and fall. But writing clear code, handling errors properly, communicating well, and shipping reliably - those are permanent skills.
If you want that kind of engineering on your next project, get in touch.