The longest week I ever worked was 117 hours. This was during the dot com boom when arbitrary and unrealistic deadlines were even more normal than they may be today. My schedule during some of those weeks would make the Chinese 996 schedule look like a vacation. On top of this, I was going to college full time.
During that period I neglected my classes and my grades suffered, and I eventually had to reorient myself. I could have used someone at the time to tell me that work schedule wasn’t sustainable or even expected. Eventually I struck a balance to succeed at both work and school.
Moving on to work with adults
My first long term job could not have been better suited to my life. It coincided with my junior and senior years of college, and was literally a bike ride away from campus. I worked with adults, professionals who worked around my class schedule. It was an entirely different environment than the two dot coms I worked at, in the best possible way.
I stayed at this job for nearly ten years, working on Java apps initially and then .NET framework applications later. I saw many trends come and go during this time such as Java EJB and SOAP services collapsing under their own weight. Struts gained steam, felt like handcuffs, and then went away. XML was tapped to take over everything before settling into its actually useful lane.
Can I quit on the first day?
My next job was at a student loan servicing company. I almost turned around and walked out on the first day. I was hired to be a business process management (BPM) developer, which I thought was already strange enough coming from the web world. It would however at least leverage skillsets I already had. On that first day I was told I’d be building an imaging system, something in which I had no skillset at all.
To this day I don’t know why those hiring me thought that was ok, but I ultimately stayed and decided it was an interesting test of my versatility. This was not a brief imaging project either. Over the course of two years my IBMi counterpart and I built a process that converted a paper-based process to digital ingestion of documents that underwent OCR, page recognition, human verification and correction, and an automated handoff to the IBMi.
That project gave me confidence that I wasn’t just good at my area of expertise, I was good at solving problems in front of me.
Following that I moved on to more familiar forms of software development, creating BPM workflows and supporting tools. For the final handful of years I stepped out of the implementation details and into the role of architect for the two BPM related teams.
What got me here won’t get me where I’m going
I left that job of nearly 15 years in order to go on a year-long international travel adventure with my family. At least that was the main reason. Truthfully I was also becoming complacent in a job that I was good at, and one that didn’t require much growth. The only way to get moving was to throw myself out of the nest.
Over the years I’ve watched a lot of technology arrive as inevitable and leave as a cautionary tale. This doesn’t make me skeptical, but it does make me interested in which parts of the current shift require caution.
So I’m exploring the changing landscape of software development first hand, by building products that people actually use, leaning hard on AI and modern tooling. Equal parts indie hacking and keeping myself current. Twenty-six years of writing software is the lens I’ll be applying to all of it.
The first is yesalittle.com, a tool I built for myself while traveling internationally which was invaluable for picking up conversational phrases in another language. More to come on it; the build so far, and where it goes next.