Thoughts I wrote down

Incoming Perspectives

Get context on prior decisions before offering new solutions.

I am just starting the first proper job search I have conducted in a decade, and I’ll most likely end up joining an established team with an established product. And that brings with it an established code base, with established cruft, mistakes, poor decisions, etc. I know, because I’ve written that cruft and made those mistakes and poor decisions.

People have joined teams I have been on for years prior to their start, and you know what inevitably happens? They come in and shit on your prior work. They don’t to it with malice (probably), but they do it, and it can hurt. Because I’ve had that experience, being on the receiving side of the insults and accusations, I plan to be particularly aware of whether I fall into the same trap. I plan to be mindful of my attitude and tone as I discover code, architecture, database designs that are, in my view, wrong. And when I do come upon those, I hope I will remember to pause, ask questions to gain context, and offer constructive suggestions for change.

Probably the most egregious example I can recall involved an ornery operations guy. He joined and immediately declared our logging system a pile of shit, claiming that the log4j format was inscrutable and it all needed to be replaced. As it turns out, the format was inscrutable because he hadn’t taken any time to look at it, learn it, and make sense of it. It just wasn’t familiar to him, so he called it crap. It is particularly hard to work with someone who brings that attitude to a job, and I never worked well with him.

Another more sane interaction started with a question I received from a new product manager while I was tending bar at one of our happy hours (yes, a couple times a year, a colleague and I would make cocktails for the office, mostly so that we could get to know the new people joining during the fastest growth of the company). This PM was hired to work on a brand new mobile app, and as I handed her a cocktail and introduced myself, she asked me, “Why didn’t you build services from the start?” First, let’s think about her perspective: she is going to be responsible for a mobile app that integrates with the data and features we have built into our web app, which is a monolith. Services would be incredibly helpful to her team so they can just make the API calls they need and ship product fast. I get that. She wants services. At this point in the company’s trajectory, so do I. But let’s look at my perspective: four years prior, when I first started building the application, we weren’t even building a web app – just a big batch processing system – and we were focused on building what we needed to solve client needs. Designing services before we knew what we were building, and handling the complexity of running those services, would have prevented us from getting the company off the ground. While she was not rude or insulting, she hadn’t considered that at all in her question. I explained it to her, and we carried on enjoying cocktails.

So, my lesson is to take these experiences and remember them when I join a new team and my gut reaction is to hurl insults either at technology or at people. Nope – pause, get context, offer constructive suggestions, and help make the changes needed for success.

Engineering’s Second Bottom Line

We are building a sustainable system for a sustainable business.

Opower has a set of company values, the first of which is “We are double bottom line.” Our two bottom lines are the environment (we want to improve that) and money (we want to make that). Everyone in the company is fully bought in to the first bottom line. Given our enterprisey business model, the engineering team cannot contribute directly to the company making money (accounting lingo deems us a liability, as does HR sometimes), so we have a slightly different second bottom line.

Continue Reading...

Opower Engineering Principles

We are engineers, and these are the principles we follow.

We are engineers. Not programmers, developers, or coders; and certainly not hackers. The distinction is important, because we are building a system for the long haul, not just a class or script or even an application. It is our responsibility to keep the entire operating environment in mind as we think about what we build, because we must consider all components of the system in order to build it to sustain the life of the business. Hackers do not do this type of work. Engineers do. We are engineers.

Continue Reading...

Jeffrey steals my “blahg”

Zeldman takes one from Kolesky

Looks like great Jeffrey’s think alike: Blahg.

I’ll forgive him – I’ve done my fair share of stealing as well.


A graphic advertising a text link advertising network? Huh?

Text link ads?

Startup School Remix

Some thoughts on a day of listening about startup success stories.

I’m always somewhat disappointed in these technology conference/summit things. I go in with the expectation that someone much smarter and much more successful than I will have at least one piece of fantastic wisdom that will enlighten me. Invariably I am disappointed, and it is not because the speakers are not much smarter than me (they are) or much more successful (they are). It is because they have learned the same things in their experiences as I have, and honestly, most of it is all common sense.

Continue Reading...

Broken Blog

My blog broke today, but so did a whole lot of other people’s.

I noticed today (all of a sudden and four days after I resumed blogging) that my blog was broken – none of my content was showing up. I suspected it had something to do with one of the plugins, as I had had a similar issue when I was first setting up the blog. So I played around with the plugins and found that one was outputting this error message:

Warning: preg\_replace\_callback(): Unknown modifier '|'

Knowing very little about PHP and trusting the good net citizens out in the world (well, those on the web at least), I did a quick Google search for the error string and found some interesting results in Google’s cache. Expecting to quickly find that an upgrade to PHP caused an issue with the Markdown plugin in WordPress (which was the issue and had been fixed in a newer version of Markdown), I instead found that a lot of people were having the same problem I had, but no one wanted to discuss it.

Clerk encounter

It really is true what they say about indie record store clerks.

I had my “holier-than-thou indie record store clerk” cherry popped this afternoon when I went to Rasputin to purchase the Wolf Parade album. I know what you’re thinking: “After that diatribe on how different Jeff is, how come he is just now getting around to buying the Wolf Parade album when all his indie friends already have it?” Well, fear not, Wolf Parade is still filed under “indie” at Rasputin, so as far as I’m concerned, I am still ahead of the curve.

So I went to the register with the album in hand, and upon seeing my selection the clerk said, “Finally someone is buying a good record.” I joked with him, “Who?” (which he didn’t really get). He told me he hadn’t been able to catch their shows when they were in town a few months ago, but his girlfriend saw both. Then he went on to tell me about the ol’ Canadian sound and how there is another Canadian band with a similar sound that apparently shared studio space with Wolf Parade. I promptly forgot the new band’s name as the clerk told me how they new band has what you’d consider a “Brooklyn sound” with Casio keyboards and a drum machine, even though they have a drummer too. More experimental.

If only I could remember the name, I’d be totally ahead of the curve this time around.