In retrospect, after reviewing this document, I came out surprised at how much I’ve written, even when trying to be synthetic and mostly to the point. Of course I’m sharing a personal view, purposely including a few memories I found relevant (and maybe interesting?), letting in a dose of emotional perspective. I guess that’s what you get if you do many things for a long enough period of time (or maybe that’s just me, then, which is perfectly fine, too). Welcome!
These words have been created as a prose, describing my journey. They are better read like so, from start to finish, maybe along with a nice cup of coffee or other beverage of choice. Readers are free to do as they will, naturally, skimming through, or going directly to any particular section: I’ve written about my early days, learning “properly”, my professional journey, and the present — I even took a stab at the future, even though, many would agree, it is yet to be written.
Kids can be mean
Back on the 11th grade, along with a buddy, I created a simple MS-DOS TSR program that would randomly print a harmless, but threatening message:
This is a computer virus: all your files will be destroyed!
Created with Borland’s Turbo Pascal, we managed to install it in every system’s
autoexec.bat or some such.
It did nothing else, but it disturbed and scared both our colleagues and our computer lab teacher. Quite a lot!
After a couple of weeks the computer virus gossip was all over the school, up to and including the school director. With a growing sense of guilt, and seeing that “no one would ever fix” the computers, we turned ourselves in, “fixed” the computers and were punished, justly, with two out-of-school suspension days. Then, life went on.
Having been born in Lisbon, Portugal, and living in its whereabouts ever since, I would say it all started one day, in the early eighties when, as a kid, I received my first personal computer: a Sinclair ZX Spectrum. By that time, very few of my friends had a computer like me, almost no software was available for purchase — let alone, properly licensed original copies! — and, most importantly, I did not have a cassette player to load software from. All that was left, after the proper “Can I use the TV for the computer?” parent approval, of course, would be starring at a blank screen; that, or going through the ZX Spectrum’s Basic Programming guide, which is precisely how I spent the first computing hours of my life. Being in the 5th or 6th grade by then, I’m not sure whether learning BASIC helped me learning English or if it was the other way around.
Later, in high-school, after programming the ZX Spectrum to death (and playing lots of games, too) I traded it for an Atari 800 XL. It had a real keyboard and a pro-looking 5.25” floppy disk drive: floppies were fast! I remember punching a hole through double-sided ones so that they could be flipped over and used on the single-sided Atari drive, for twice the storage capacity. Exploring the 800 XL felt a lot like my ZX Spectrum beginnings: none of my friends had one, there was very little software, documentation, magazine articles or any other learning materials. I loved every bit of that challenge, mostly playing around with the extended graphics and sound capabilities of the system.
A couple of years later, eager for more, I traded my computer again. I went for a powerful Atari 520 STFM. It had a 16 bit Motorola 68000 CPU, a whopping 512 KB of RAM, even better graphics and sound, built in 5-pin DIN MIDI ports and more: an operating system — if you could call it that — with a graphical shell known as GEM, in its Spanish incarnation (if the ZX Spectrum may have helped my English, the ST certainly forced me to improve my Spanish: “Ventanas” for “Windows”, “Carpetas” for “Folders” and off I went!). The ST was the first system I had that did not include a BASIC ROM; this was strange and, at first sight, the computer felt pretty useless: who would ever want a non-programmable computer?! I remember getting hold of a copy of GFA Basic — a powerful, non-standard, BASIC variation, that didn’t require line numbers! — and writing my first “networking code” then, with MIDI, to interact with a synthesizer and a drum machine I had at the time, a Kawai K1 and an Alesis HR-16: that felt mind-blowing! Those were also the days I started delving into music playing and production, especially after I found Steinberg’s Pro24 amazing MIDI sequencer.
Learning my way through those simple computers of the time, with barely no OS and direct access to the underlying hardware, helped me grasping the fundamentals of modern-day computers: there was an incredible sense of satisfaction in powering them up, poking around, and getting immediate, distraction free, results.
How do kids learn, today?
Sometimes I wonder how kids go about learning computers today… The world is so much bigger and complex and powerful: probably the first computer they get to explore is some variation of a smartphone or tablet — incredible internet-connected devices. But how can they program them and make those devices do what they want? Do they even know it’s possible?!
Maybe they’ll have access to a “real” computer, running Windows, macOS, or even Linux — again, incredibly powerful systems, but also infinitely complex and certainly not distraction free. Where’s the “programming prompt” in computers today? Does it even make sense to ask for that?
While the barrier to entry seems much higher than it was before and, at the same time, expectations and ambitions have gone through the roof — kids want (rightly so!) to play video, build internet-enabled games, interactive web pages, etc. — the sheer amount of freely available learning materials and tools on the internet is invaluable. Maybe things even out, I suppose. They’ll just take a different path and, in the end, learn as much, if not more, than the ones that came before them.
[ As if there ever was a “proper” way to learn, that is. I’m calling it “proper” in the sense of formal, structured, systematic: there’s lots of value in that; even more so, when we can do it while having fun along the way. ]
I went through the 5 year long Computer Science and Engineering Degree at Instituto Superior Técnico and I had a blast!
There were tough times, of course, learning advanced maths and physics, later brought together in robotics where algebra, trigonometry, mechanics and AI were key in building and programming a fully working 6 DoF robot arm. Abstract computer science was also hard but, again, later valuable in creating working compilers. Learning and re-learning different programming paradigms and languages, and Artificial Intelligence — which I always looked at with suspicion, then — was eye-opening.
If there’s one thing that dazzled me, at some point, was that I finally understood modern computers in their full extent: I learned about computer architecture and all its underlying details and abstractions — I could design simple computers with discrete logic circuits, I could build logic circuits out of logic gates, I knew how to create logic gates from transistors and I even knew how TTL and CMOS transistors operated, having created quite a few — in simulated environments, of course! In the other direction, I learned about pre-emptive, non-preemptive, real-time, single- and multi-user operating systems, compilers, networking, parallel and distributed computing, and more!
Those were the days I started working with Linux. I remember downloading tons of floppy disk images (could it be Slackware, by then?) and installing it on a friend’s PC, fighting hard to get the X Window System working. Once we did, we started doing most of our projects at home: particularly those that involved computer graphics, since we no longer had to wait for an available X Terminal at the school’s lab.
Going through university was an incredible learning experience: not only on computers and technology, but also in making friends, meeting people from different backgrounds and, of course, in music: I played all throughout those years, in different bands and groups, learning a lot, and being a proud founding member of TUIST — a male student group playing traditional Portuguese music, with a strong focus on serenades.
Even though HP did provide for lots of formal training and associated materials, this was the time I found out about O’Reilly and their now famous animal books: I remember learning a lot from older editions of Sendmail and DNS and BIND, for example, and using Perl to automate lots of HP-UX tasks, thanks to the Camel Book.
I started my professional activity at Hewlett-Packard, in the late nineties, acting as a Response Center Engineer. The job was simple yet full of challenges and learning opportunities: responding to qualified support requests from paying customers, over the phone. I tackled software-related topics, working in close cooperation with the Field Engineering team, that dealt with hardware diagnostics and on-site activity. Learning HP-UX, and its transition from a BSD-like to a System-V-like system, dealing with customer expectations and anxieties, reproducing failures, escalating requests to Worldwide Technology Expert Centers, coordinating with the field colleagues and driving the diagnostic and fixing process (and instructions!) over the phone was quite an experience.
I quickly grew into roles with more responsibility: working on-site setting up shared-storage highly available cluster solutions, planning and later leading big infrastructure projects like datacenter moves, storage consolidations, complex backup and disaster recovery solutions, and more. I also integrated the mission critical support team, sharing the burden (joy?) of being on-call 24x7 every four to six weeks, assuring “4h commitment to repair” contracts were upheld (and they certainly were, thanks to the incredible team we had). In retrospect, I find myself with fond memories from those early days: working throughout the Y2K craziness, including being in the office, ready to fix anything, on the actual réveillon; fighting off a huge, dual V-Class system, cluster setup for endless hours only to find out that two (out of the twelve!) NICs had duplicate MAC addresses; being invited by the management team to Madrid, to meet the then new CEO, Carly Fiorina, which I took more as a recognition for a job well done than anything else (I did meet her indeed, and we shook hands and talked for brief moments — little did I, or any of us know, then, about the changes she would propel HP into).
There are two things I find myself doing instinctively since those days: one is planning first, doing later; the other is accounting for possible failures, eliminating the ones I can, mitigating others, and consciously accepting the risks on the remaining ones, known and unknown.
At some point, with local management approval, after finding no usable in-house solutions all across Europe, I created a web-based tool (modern, in those days!) to help my team streamline its non-standard service orders, keeping track of associated processes and sharing useful, actionable information with the Sales and Accounting teams.
Built with Apache, PHP and PostgreSQL, it was still in use by mid 2017, last I heard. Wow!
Later I assumed a team leading role which then evolved into technical service delivery management. After an initial period of adaptation, in the realms of do less, delegate more, coordinate even more, plan, involve, communicate, account for unexpected changes, deal with hard constraints, be constructive, find solutions, etc., I found myself in what I considered a challenging and continuous engineering problem: now focused on people and organizations and much less on systems and machines. Processes and communication methods were key in improving our results and everybody’s satisfaction: and that’s what I did more and more.
One fine day I learned that HP and Compaq were to be merged. After the initial shock — was anyone expecting that? — I had to put myself to work. Those were tough days for everybody: my team felt insecure, not knowing what the future would bring, the “others” were often deemed (wrongly!) as the “bad guys” and, invariably, two things needed to happen: normal, day to day customer service activities had to go on — held up to the usual high standards — and I needed to come up with effective plans and decisions for the merge itself, while under not necessarily easy to satisfy top management established constraints. Cutting a long story short, yes, there were losses; yes, bringing everyone and everything together — teams, processes, tools, skills, clients, etc. — took more time than what I or anyone would have liked; and yes, for those that went through it, it was an incredible, if somewhat painful, learning experience.
A key lesson I took from those days is that people are the same everywhere: they have aspirations and fears, strengths and weaknesses, and varying skill sets. Bringing them together, in the right combinations, can lead to incredible results.
Is the name of an album I arranged, co-produced, and also played in, along with a few friends, published by EMI Records in 2005. It was my first foray into pro-level music production, blending traditional Portuguese Fado with a variety of music genres.
Some people liked it a lot — including some traditionalists — others did not (isn’t that always the case?). Once in a blue moon it gets air time on the Radio. Going back to it, I still feel pretty happy about the music we created, back then.
After almost 10 years of service at HP, when the merger dust finally settled, I decided it was time to move on. I sought other kinds of challenges, greater independence, a different lifestyle. HP had been a great experience — thank you — but I was done with huge, slow-moving, multi-national organizations.
My next professional endeavour had me joining two friends that had just created their own company, Colours Concept. Sharing ideas and convictions on better ways of doing business, and having a solid and diverse professional background in sales, marketing, information systems, design, and more, we started off with a bang — from the early days, Colours promoted three autonomous business units: Cardinal Telephony, Lime Media and Purple Design. While the former was created from the ground up, the latter two were originally two companies we brought together under a common umbrella (ah, more mergers in my life!).
For the first years, my role was divided between driving Cardinal Telephony’s business, on one hand, and bringing the three organization’s networks and systems together, on the other. Those were the days where, out of necessity, I ended up doing a lot of everything: finding better technical solutions for Lime Media’s music and video distribution network and player provisioning, automating software updates on Purple Design’s Macs, bringing it all together into a common, manageable network, automating backup procedures, you name it. Most of my work was, however, focused on Cardinal Telephony’s activity: we offered tailor-made software-driven telephony solutions with very advanced capabilities. From cross-region/-country IP based voice networks and browser based click-to-call and click-to-talk solutions — with a product we called webtalk — to redundant, automated IVR and ACD solutions, including device provisioning, call accounting and reporting and, most importantly, integration with existing services — like Microsoft’s Active Directory — and business applications — such as SAP and other ERPs/CRMs — with advanced screen-pops and task automation, we did it all.
Those were the days I started using Python professionally: and it certainly showed its power for the many tasks we threw at it, from low-level networking tools to full-scale business process integration solutions.
One day I was invited by a friend to join him in lecturing a Practical Networking Course on a local University. After meeting the coordinator we agreed that I would lead the lectures and my friend would handle the labs. The course covered a lot of material, from physical and link-level ethernet/wifi up the stack, delivering solid knowledge on IP, TCP, UDP, detailing protocols like ARP, DHCP, DNS, static and dynamic routing, LDAP, HTTP, SMTP, Kerberos and more. We did that for two consecutive years, having had a wonderful teaching — and learning — experience, getting great feedback from both the school and from the majority of our students.
A few years later, we imposed a few major changes at Colours: the Lime Media and Purple Design business units were spun-off, back to their original company forms, and a new business unit was created, Saffron Marketing Intelligence; we also moved offices to a location better suited to the refreshed and then re-branded COLOURS ‘ COMPANY. Kicking off Saffron Marketing Intelligence, that offered data analytics and predictive behavior modeling services (what the industry calls AI and machine learning, nowadays) involved two big changes: creating a new suitably skilled team, bringing in new people into the organization, and building a computing infrastructure to support its activity. By that time, I was formally holding two job roles: leading the Cardinal Telephony business and managing all IT/IS operations. Under the latter, I worked with the newly created Saffron team in planning, architecting, building, and maintaining multiple computing solutions: easy to use and secure data transfer and collaboration tools, automated and scalable ETL and data processing pipelines, secure and easy to manage development and production data marts, powerful data visualization and navigation tools integrated into a highly scalable and secure live dashboard web platform for end clients to use, and more.
The combined experience we had with Saffron — which had been taking up a lot of my time and resources, being a growing success and attracting international customers to our business — and Cardinal — with its highly appreciated tailor-made solutions, often with variations on the same challenges, but with long sales cycles and difficult to export — brought us to one fundamental business decision: the time came to productize Cardinal Telephony’s business. What followed were two long and even harder working years: from identifying the key value propositions of the existing offer and how to turn them into products, to deciding on a product structure and what capabilities first iterations should include (and which should be left out!), including evaluating competitors, creating a new brand, designing and testing user interfaces, creating specifications, documentation and, obviously, bringing it all together in code into a self-contained marketable software product, we had the ride of our lifetimes — that’s when Promptar was born.
In the following years we worked on Promptar quite a lot, making partnerships around the world, training partners and customers, addressing their challenges and feature requests, creating new connectors, marketing materials, and, overall, improving it. Acting as the Promptar Product Manager and Lead Developer I had to constantly balance product positioning and capabilities against development efforts and risks, while keeping the team in full sync about where we were going next.
At some point we realized we had been growing into two very different companies within COLOURS itself, each with their own challenges and distinctive culture; and I felt that quite directly, since I was still acting as IT/IS manager all throughout. We had more and more resource conflicts and starvation between the Promptar business — product oriented, sold via a partner network — and the Saffron one — service oriented, with strong relationships with client management teams; our ideas about how to address them often diverged, but we agreed that we needed to hire for two key positions: we needed a Service Delivery Manager and a full-time IT/IS Lead, both with strong focus and enough bandwidth to address the operational needs of Saffron, relieving the Promptar team from the often-required operational inclusion in Saffron’s activity.
Nearly 10 years into the COLOURS venture, we decided it was time to part ways: some of my partners wanted to seize an opportunity of merging with a larger consulting group, others, including myself, saw it differently. In the end, we figured out it would be better to go our separate ways and the COLOURS Saffron business was indeed integrated into a bigger company while Promptar was spun-off into its own independent organization, which I continued leading.
Terços de Fado
In early 2016 I ventured into my second professional music production project. This time around I detached myself from actual music playing, assuming the Art Direction and Production roles.
As a producer, my biggest challenge was ensuring the conditions, often mostly emotional, for capturing Tânia’s and the musicians’ best possible studio performances, as each track was to be live recorded — working with three distinct sets of musicians, each with their own characters, only made it more demanding.
Since its launch the album has been widely appraised — credits to the artists! — and I feel very happy and proud about my contribution.
The COLOURS journey has been one of the most enlightening professional experiences of my life. In my thoughts I sometimes find myself saying everybody should go through a similar experience, at least once, if only for a short period — deciding on your own fate, fighting two-way uphill battles in a highly competitive open market, being legally and financially accountable for an organization’s activities, fulfilling all your obligations, including 10 years of monthly payrolls without skipping a beat, is not for the faint of heart, agreed — but it does teach you a lot, and you’ll come out of it a stronger, better professional, and a much more mature, well rounded person.
These days I continue working as the Product Manager and Lead Developer for Promptar while, at the same time, doing independent Python Training and Coaching. I find these two activities — somewhat conflicting, at first sight — are a great match for each other and for myself. Admittedly, they do tend to keep me very busy, and there are periods when everything seems to be calling for action at the same time, but most often the workloads combine very well and I end up with a very manageable and flexible work schedule.
The Promptar product management work has me focusing on two major tasks: on one hand I manage partner and key client relationships, driving business opportunities, addressing complex support requests, collecting product feedback, etc., mostly promoting Promptar and learning from it; on the other, picking up from that experience, I observe industry trends and competitors and, with a dose of hopefully well guided insight and creativity, take the lead in establishing where Promptar should go next, short- and long-term, product-wise, in its features and capabilities, and market-wise, in its competitive positioning, pricing model, and more.
As a Lead Developer I find myself doing one of three things at any given time: fixing Promptar, improving Promptar, or finding ways of simplifying the Promptar development process; and, of course, coordinating it all. As any seasoned programmer will certainly agree, there is no such thing as code without bugs (at least when sufficiently large) — Promptar is no different in this regard and, even though it is very well tested, the odd bug still shows up in a client environment, from time to time; fortunately, most tend to be easy to tackle, resulting in fast customer responses. The ones I find most challenging are commonly in the phone system integration domain, for a few good reasons — as much as any developer would like, there’s no practical way to have all possible combinations of supported phone systems and devices in the lab; this, in turn, makes reproducing certain types of behaviors approach the realm of impossibility, slowing down the diagnostic process and requiring more developer/client iterations that anyone would like; lastly, everybody’s favorite, I dare say [sarcasm!], is the fact that some manufacturers just don’t comply with a given standard, when their marketing and technical materials clearly state so; going through and understanding the documented vs. actual behavior, commonly sprinkled with nuances, and finding ways to conflate them in clean, elegant and maintainable code, while avoiding regressions, is often not simple.
Improving Promptar, adding new capabilities and supporting new integrations, can be very fulfilling and satisfying, as a creative process. More so when the new code fits cleanly and naturally into the existing design, and even more so when it matches a given market demand or customer request. Creating prototypes, implementing protocols, materializing new concepts and interactions, and finding effective ways of guaranteeing correctness are among common tasks that Python, the language Promptar is created in, makes not only fast, but also a joy. Using Python to create Promptar has proved to be a very good choice, to date: it’s very expressive, including powerful meta-programming abilities, it easily integrates with other libraries, components and systems, and, with the proper design and its async capabilities, is plenty performant, scaling to pretty much any workload we throw at it.
Python Training is something that I evolved into somewhat naturally. After having trained so many people in multiple technical subjects across my professional life, having a need to keep myself constantly up to date on Python in the context of Promptar development, having had a great experience as a volunteer trainer in recent EuroPython editions, and, importantly, feeling right at home as trainer and coach, I could say it all started one day, over a phone call with a friend, where we were discussing a few technical challenges and, at some point, I said “you could solve that quickly and easily with Python”, driving his interest — one thing lead to another and, a few months later, I was kicking off the first iteration of what currently is This is Python: I trialled it in a friends-only, invite-basis, zero-cost training course I decided to call Python Among Friends, then, and, after a few tweaks, have since been delivering it in corporate settings with great results.
Wide open and mostly unknown, I’ve come to appreciate it the way it is. Having said that, I’m very keen on keeping my work in Promptar and as a Python Trainer for the foreseeable time to come, holding up to professional commitments and pushing them forward, seeing where they take me next. Somehow I feel my work will always be related to technology, building products and services, creating or leading teams that create things, most probably keeping Python around as a reliable tool, among many others in my tool-belt, one way or another.
I’m both an Engineer and a Manager, a Creator and an Observer, a Trainer and a Student.
I fathom I’ll always be these and more, who knows: as a professional and as a human being.
Feel like affecting my future? Go ahead and start by reaching out to me.