Zoomers, do you want to hear a tale from the last century, before the world lost its mind? I was born in 1980 — I don’t know or care exactly what “generation” that makes me — and I was lucky enough to get my first programming job in 1999, working at a small (20 person) private company in the southern USA.
Interview Process
I interviewed with a couple of managers who were no longer actively coding, but still knew some technical questions to ask me, such as “In Windows, what is the difference between SendMessage and PostMessage?”
Self-deprecating humor worked well, for example “I guess I’m just another programmer who needs a personality transplant” was how I described myself.
The only “portfolio” I could show was an MP3 Tag Manager I had written in C++, both in MFC and in QT (Yes, QT really is that old).
But the most memorable part of the interview was sitting alone in a room for 20 minutes, completing a written test. It was like an IQ test which only targeted logical reasoning and pattern recognition. Everyone at the company took this test, so they had a baseline. (By the way, such a direct test has never been illegal, as long as it is directly related to what an employee needs to do.)
Meetings
Every Monday, we had a 1 hour meeting to go over:
1) Issues our customers were raising with support, and which ones had priority to fix. Customers paid for our software, so keeping them happy was job #1.
2) New features our salespeople wanted to promise to drive new revenue.
3) Concerns raised by developers, for example if a requirement was too vague, and needed to be documented more formally so other parties like QA could sign off on a test plan.
It was taken for granted that you could remember what you were supposed to be working on for the rest of the week. There was no such thing as daily standing meetings.
When we gave estimates for how long our tasks would take, we would use hours or days, and give a range if it was uncertain, or say we needed some time for analysis.
There was no such thing as “sprints”, “story points”, “velocity”, or “t-shirt sizes”. Our salespeople, managers, and our customers would have found those terms preposterous.
Breaking The Build
Our C++ code was built once a day. If you broke this daily build (i.e. you merged a code change that didn’t compile), you had to bring in donuts for the entire company. This was a fun but also serious way to make sure you weren’t wasting others time.
System Test Day
The entire company helped test a major release. We’d try to click every button, exercise every feature, and check every tooltip and help page (if a feature wasn’t documented in the manual, it wasn’t complete). There would be awards for who found the most bugs.
Company Events
Ever year, the president of the company and the VP of development would recognize employees who went above and beyond their expectations. There was also a Superbowl party every year with cash prizes, although as an introvert I never went. (After reading Peopleware, I realize I should have tried to go to these events.)
The company knew that people who were talented and motivated were what made them successful. It wasn’t about following a “process” or treating people like replaceable cogs on an assembly line. A few talented people can easily outperform a large number of less talented, and this company definitely had people smarter than me.
3rd Party Libraries
All our libraries were paid for, for example we used one to help with sockets and asynchronous DNS on Windows. The expectation that unpaid volunteers on the internet would maintain code for us was unheard of.
User Interface
We used a commercial GUI product called Objective Toolkit, that was more professional and functional than the gray, flat, dumbed-down mobile style of today. It had dockable toolbars and a nice icon set, and we also made our own icons. We paid consultants a lot of money to give us a color scheme that would make our product stand out. We didn’t want to look exactly like everyone else… that would have been ridiculous.
There was no grotesque Allegria or Corporate Memphis “art” stinking up our products, either. (I’ve seen better cave-man drawings.)
Windows
Windows 2000 had some severe performance regressions with its C++ runtime and MFC libraries, due to forcing existing APIs to become Unicode-aware. We rewrote some code and recompiled a library ourselves as workarounds, because it would take years for Microsoft to ship all the fixes. The lesson for me was that neither a “low level” runtime library, nor a “high level” developer productivity library, could be trusted. Avoiding them and implementing as much as possible yourself would save time and headaches in the long run.
At least Windows 2000 had a cohesive UI that was designed for professionals, compared to today’s standard. That was the peak of Windows UI for me, it’s been downhill ever since.
Office Space
We all worked in the same office, in the same city, and could talk to someone to get unblocked whenever we needed to. If required, a support ticket could be escalated to a developer and we would be on the phone with the customer (and viewing their desktop remotely, which was a new technology we had to pay for).
Managers didn’t trust us to work from home, thinking we wouldn’t be responsive to an escalated support ticket. The company later moved its office and the commute became a nightmare for me, although others benefited.
Lessons from Peopleware
The book “Peopleware” was written in 1987 and I believe it inspired the culture at this company, which was also founded in the 1980’s. The book’s main point is that most IT projects fail not due to technology, but to human and organizational issues. You can avoid these problems by giving people ownership and autonomy, and focusing on the customer instead of internal politics, processes, and interruptions.
I don’t think the book says anything controversial, much of it seems like common sense, and it provides studies and surveys to back up its claims. Basically, in the 1980s, it was already known what makes a productive engineering team. (The Mythical Man Month was written even earlier.)
Things Fall Down
I worked at this company for over a decade, the longest stint of my career. It is not a coincidence that this company who never heard of the word Agile, treated its employees the best and was the most responsive to its customers.
Unfortunately, the common sense that many people knew in the previous century can’t be monetized by consultants and coaches who sell Agile/Scrum. And I’m not talking about the Agile manifesto as written in 2001, I’m talking about what it has become in practice.
Obviously, the too-big-to fail, federal-government-subsidized, monopoly megacorps love it. It’s more administrative headcount, more boxes to mindlessly tick, and adds to their core competency which is doing as little productive work as possible, while promoting those who like politics.
But I’ve also seen a private, 10 person company drink the Agile/Scrum Kool-Aid, because their greed to make short-term money was just what the paid Agile “consultants” took advantage of. Oh, your low-budget offshore team can’t code a moderately complex application, or fix their inefficient database schema? Just hire a certified scrum master — in a different country — to do daily standups with them, and make more tiny Jira subtasks. (All this will do is drive away the people who would spend the long-term effort to fix the source of the problems.)
I have to admit, it’s one amazing grift that can sell to both of those camps.
When Truth Dies
Over the last 15 years, I have seen many people in the USA become untethered to reality, and buying into the cult of Agile is just one of many disconcerting symptoms of this lack-of-truth disorder.
People seem happy today to believe any nonsense, as long as they think it puts them in the majority, or it promises them a paycheck.
But I will never let this, my own experience, be forgotten: Productive programming was not, and never will be, about following Agile/Scrum charlatans (grifters), or believing any hype without skepticism. It’s about hiring, and trying to keep — which isn’t necessarily about pay — the people who are productive, both technically and interpersonally.
