Don't Teach Yourself to Code by Writing a Library

It is a terrible idea to teach yourself how to use some unfamiliar feature of C++ by designing a library that heavily uses this feature.

I cannot think of an easily explained example, because libraries that come into existence in this way are very rarely easily explained. Even experienced C++ folks look at the thing and say, "Huh...WHAT?! Can you DO THAT?" Readers with more than a couple years of development experience are grimacing right now, because chances are good that the code they are paid to work in every day relies on a library that some genius thought would be cooler if it all used some tricks they'd been reading about.

It may be cool to the original author, but to anyone who hasn't read the same blogs as the author, it's just mysterious. Especially mysterious when the author has trouble doing what they originally imagined was possible, and ends up covering this lack of experience with a hack, that then lingers long after the author stops working on the library.

Writing libraries is a great time to slow down; to be conservative; to solicit the widest possible review; to ask your peers, "Is this good style?"

Reading Your Own Press Releases: A Management Antipattern

To customers, a new company is an unknown. A new company has no reputation. A new company must focus on providing innovative or cost-effective solutions to customer problems, because it's the only story they have to tell. Nothing wrong with that.

Well-established companies have more to say. In addition to presenting their latest product's features, they can tell customers about their previous products, their many years in business, their reputation for quality. Nothing wrong with that either. It's easy for a customer to choose an established company versus an upstart competitor, even without doing a bunch of homework, because the established company is a known quantity.

But sometimes, an established company loses its way. They begin to tell themselves about their reputation for quality, their years in business, and their leadership position. Their executives tell their product teams that they can charge a premium price because they are the "Cadillac brand", regardless of the strength of competitive products. If they say this often enough, it becomes received wisdom within the company. I call this behavior reading your own press releases.

A company that is reading its own press releases is already past its prime. When a company starts reading its own press releases, it stops worrying about solving customer problems, or being better, faster, and stronger than the competition. They may even get away with this for a few years if they really were market leaders. But eventually, they find themselves sidelined by their hungrier competitors, and their position of advantage evaporates.

I've worked for two companies who had this problem. One is now a division of a conglomerate, who fixed the problem by replacing complacent managers. The other annoyed its partners so much with slow product delivery that the partners made the company irrelevant. Last I checked, this second company was still in business, but they shed three quarters of their staff in a paroxysm of downsizing, and never recovered their former greatness.

I bet you can see some obvious examples in the news of large technology companies who have been reading their own press releases. Where are their new products? Missing in action or underwhelming critics and customers. When your division manager starts talking this way, tell them to wake up and smell the innovation.

Smartest Guy in the Room: An Organizational Anti-Pattern

Every software developer thinks they're smart. Heck, I think I'm very smart. But organizations seem to go badly wrong any time they anoint one person (or a few people) as the guy(s) to make all the smart decisions, and demote everyone else to code monkey.

I worked in a big organization where several senior developers convinced management to take them out of their business units, and put them in a special R&D cost center. They were going to do user interface research that would inform the next generation of products. Now, if this had been Bell Labs, and these guys had all been PhDs, they might have discovered the Cosmic Microwave Background or something. But these were just guys. When the team I was on asked these special devs to do some user interface research for our next product, they said, "Oh no, we can't be tied to a particular product." As far as I know this group never produced so much as a PowerPoint presentation. They were disbanded after a couple of years.

A company where I worked purchased a startup that found itself out of money and on the market for cheap. Their fast-talking CTO was a former employee of my company. He talked my company into putting him in charge of all development in our division, singing the following siren song. "You've been spending way too much time and money on carefully designing and architecting your products. At my company, what we did was just built 'things' and put them in a pile. Once a year or so, I would reach into the pile and pull out enough 'things' to make a shippable product." This strategy had worked so successfully for his last two companies that one had been folded into the other, and the survivor sold to us. It worked so well for us that he went through two years and six million dollars without producing a single product. Our division was shut down and everyone laid off, including the fast-talking smart guy, but not the two managers responsible for hiring him.

At another company, a smart team was created to write a big Windows editor to solve our very complicated configuration problem for a variety of products. They spent 18 months working (not too successfully) on a universal data input editor. But they never considered the complex problem of compiling the input data for each of several rather different products into usable files. They had in fact no idea how to solve this problem. So they never showed a single working version. They built a rather elaborate castle in the air, starting from the fancy gabled roof downward, hoping they would have an inspiration for how to build the foundation when they got to that point.

Moral: The smartest guy in the room needs to be managed just as much as the most ordinary. Otherwise they are liable to go off course and waste a bunch of time and talent, just like anyone else.

We're Special -- a Conversational Anti-Pattern

I've worked within organizations that told themselves that some best practice widely promoted throughout the industry cannot possibly be applied at this organization, because this organization's work is "special". Our code isn't like other code. Our customers aren't like other customers. Our problems aren't like other companies problems, so this commonsense rule does not apply to us (and therefore we need not change our practice).

When I had the evangelical furvor of the rookie, this behavior made me wild. It was clear to me that there was absolutely nothing special about our code, and that industry best practices got to be best practices exactly because they were widely applicable. I came to understand that the purpose of the word "special" in this conversation was to defeat any kind of reasoned argument, any comparison or evidence, and defend the status quo. 

When I became an old hand (and by that I mean, as I was typing this blog entry after facing this anti-pattern yet again), I realized something else. I realized that "special" was the antidote to the phrase "best practice", which itself is meant to defeat argument without presenting evidence.

When you find yourself in such a conversation, it means that both sides have staked out a position that they are too lazy to defend with any actual evidence. To make any progress you must change the conversation. Perhaps, "Best practice X will improve our results in thus-and-such a way.", or, "Practice P is being used successfully by our own competitors." This raises the level of the conversation so that the other stakeholders must argue specifically against your evidence. When they say "special", you can then say, "Yes, but in what way does our special-ness invalidate the evidence?"

It is tedious to argue from evidence, and easy to resort to words like "special" and "best practice". However, the comversation generally goes better if you come prepared with some actual data.

The Dream Team (a Management Anti-Pattern)

Senior developers are more productive than junior ones, or so I tell myself. Still, most employers like to hire devs 2-5 years out of college. Managers say, "These guys ae still fresh, with up-to-date skills, but they've learned how to work." But what managers think is, "These guys are cheap, and they do what they're told, because they don't have a lot of independent experience giving them ideas that conflict with my judgements."

But that's not what I would do. If I ran the world, I'd hire devs with 10+ years experience; devs who already knew what to do and could go do it without supervision. Some startups work like that. Yeah, an Old Hand costs more, maybe twice as much as raw rookies right out of school, but they are way more productive. They only have to be twice as productive (counting the managers you don't have to hire), to make them pay off.

I took a job at a company like that once. They bragged that they only hired senior folks. And indeed, the staff, taken as individuals, were bright and talented and very experienced. I was very excited, because this was just what I would do. I thought I was joining a dream team. Reality was quite a let-down.

The company founder was a guy who liked to code very fast. In fact, he'd hired this team to clean up after him. Over time the team became so outraged by the poor quality of the founder's work that they chased him away to "other opportunities". Problem was, people like to hire themselves, and the founder had hired a staff that liked to write code quickly, but didn't care to do that other stuff, like documentation, coordination, testing, etc.

One very senior C++ developer didn't trust objects. Their code looked like C, and had all the problems of C code. Another one had a very idiosyncratic coding style; they put all their method definitions in the header file. Partly this was a bad java habit. Partly they used a third-party tool for indexing the sources that worked better when the declarations and definitions were all in the same place (I think, sort of. I still don't understand). Another had a bunch of antiquated style habits they'd picked up in 1995, and couldn't imagine how their practice could possibly improve by changing their style to use modern features of C++. Naturally they each had their own indentation style, their own variable-naming conventions, and pretty much every other thing that they could do differently, they did.

They'd broken the code up into fiefdoms, so they weren't exposed to the silly habits of their peers. And they defended these fiefdoms fiercely. One of them checked in a change to my code because I'd started a one-line comment with "//", when they preferred "/* ... */".  Whatever, man.

Each fiefdom had their own include files, with duplicates of the same basic stuff, that had aged differently. The code base frequently produced compile warnings (on error level 3 in Visual Studio). They didn't lint the code, or use error level 4 because it produced too many error messages, and some devs would have to change their styles to make these go away. In fact, we had a critical bug delay a release, that turned out to have printed a compiler warning. Only there were so many warnings that nobody noticed this one, or bothered to follow it down into another dev's fiefdom and fix it.

They used a funky build tool written in python, rather than build inside Visual Studio or use make. Only two of the devs knew how to fiddle the build tool. They fought with each other endlessly, changing things back and forth.

They didn't really have any documentation for their creaky old code base. When I started doing docs, it started a war. One dev thought documentation should go into a wiki. Another thought it should be static HTML web pages. One thought Word was ok. Another thought we'd be more productive in FrameMaker (which is true, but FM is expensive). One wanted docs in the source code. Another argued that no documentation could be trusted because sometimes it might be out of date, so we shouldn't even comment the code.

We bickered about whether to put the docs in the source tree, or in one of two different styles of separate file tree. I tried to suggest that the first and only really important thing we should argue about was, what aspects of the project were most important to document, and worry about how to type it later. They thought that was crazy-talk. Each used the war as justification for not documenting their code.

An Old Hand reading this may have guessed by now that the problem was management. The lead was not doing anything to make the team work together as a team. By the time I got there, it was probably too late to change them anyway.

This company was a ten-year-old startup (which is an anti-pattern itself). Their product was pretty cool, but they were having trouble breaking out into the big time. The code had a million features, and a million little bugs. They knew they needed to work on improving their robustness because the next set of customers they had their sights on were big enough to demand really solid reliability. But the siren-song of each next customer was filling up the work queue with new feature requests.

I only made it six months at that company. They thought I should go, and I agreed. The feeling I had when I left must have been like viewing the Titanic from the perspective of the last lifeboat to pull away. Only the guys aboard the Titanic knew the ship was sinking.

Teams make the company. Not individual performers, no matter how experienced, talented, or bright they are. The Dream Team of individual performers is a management anti-pattern unless they are in fact managed as a team.