So, I am at a cross-roads in my career. Due to some recent circumstances, I will be looking for a new employer effective February 1st, 2014 (my last day with my current employer will be Jan 31). So I will be available for hire in the near future!

This is the fourth post in my “Beyond” series. The previous three posts focused on re-imagining OOP and questioning some of the core beliefs that we have come to take for granted. This one is going to be slightly different, in that I want to talk about another angle of writing code: the process itself. We always talk about how code should be clean, but how do you write clean code?

In the last post Beyond Inheritance, we talked about looking past “types” and reasoning about objects differently. The conclusion was that inheritance wasn’t necessary for OOP, and often results in more problems than it solves. Well, let’s go beyond that and explore more of what will come from treating objects as containers of behavior. Let’s look at what this means for various kinds of classes:

In my last post, I talked about revisiting the concept of Design Patterns and questioned how useful it is to “learn” them. The conclusion that I came to was that you are better served by focusing on how objects communicate rather than traditional patterns. Well, that’s not the only “traditional concept” that I think we should move beyond. So, let’s talk about inheritance…

Many people teach design patterns as a fundamental step to Object Oriented Programming. They are so universally seen as important that almost every single conference that I have been to has had at least one talk about them. They are quite often used as interview questions to test a candidate’s OOP knowledge. However, just like inheritance, they are not needed for OOP. And just like inheritance, they are a distraction rather than a foundation. Instead of focusing on patterns, I suggest focusing on learning about abstraction and communication. Why? Let’s talk it out…

This is a post that I didn’t want to write. Actually, it’s a post that I still don’t want to write. But I find myself in a situation where I feel that I have to say something. So I’m going to just open up here. I’m going to put it all out on the table, and see what happens from there.

Yesterday I was asked a rather interesting question about presenting technical presentations. While I don’t think my method will work for everyone, I feel it’s a good thing to talk about. So here’s my method, and some advice that I would give first time presenters:

I will be speaking several times in the coming months at several conferences in the US and Europe. I hope to see you at one of these events!

Last week at the BlackHat security conference, a new attack on SSL secured content was unveiled. This attack is called BREACH, and has been generating a lot of buz on the internet. Tech blogs have been plastering their sites with articles about how there’s no fix, and how you can try to defend against BREACH. Well respected security people have been writing about it.

And I’m here to say don’t worry about it.

For the past several months I have been struggling to figure out what I want the next step in my career to be. I am still trying to figure the details out, but I had an important revelation last night. I want to share that revelation with you.