What I've been up to
Since my last post in 2011 (wow it's really been that long) I have done quite a lot. I was teaching at DigiPen while also working on getting my MS in Computer Science (thesis is still "in progress" after several years of work). I then stopped teaching and joined the game industry, working at ArenaNet (Guild Wars 2) for a while. That was fun, but I've since decided the game industry in general seems not to be the best fit for me (more about that later). While that may change in the future, for now I'm back to Enterprise LOB application development and currently working for IMS Health (we're now QuintilesIMS as of a couple weeks ago), which you've probably never heard of but I have a shitload of data about your medical history (yes you, the person reading this).
In addition, my supra still doesn't run, I've done a substantial remodel on my house including moving my electrical panel, and had virtually no time for anything else. My most significant change though was the birth of my son, Rowan, who just turned three as of the time that I'm writing this.
The future of this blog
While I have a lot of unfinished topics that I want to address, I've also learned so much over the last few years so you can definitely look forward to some new content. I have a few topics that are likely to become a series as well. Here are some highlights:
Putting the "Science" back in Computer Science
I have a few posts that I wrote a long time ago for this series so I still hope to complete those as well as write a lot more about some of the fundamentals that many of us have forgotten. There are of course the basic data structures and algorithms that are pretty much CS101 material and yet many people still seem to forget about these. There are also a lot of other data structures and algorithms that I have found most people have never heard of (or forgotten about completely) that I just think are useful to know about or just plain interesting in some way. Ever heard of a Brodal queue? That's going to be on the list at some point.
How to DevOps
DevOps has been something that I keep hearing in the software industry lately, especially when coupled with the question "how do I even DevOps?" or the more basic "what even is DevOps?" so I'm working on a series of posts that will take you through how to DevOps from the basics to the really cool and complicated shit. I've been doing a LOT with DevOps over the last few years so I have a lot to share in this area. I also have some great examples of what NOT to do, which I think is just as valuable. I find information on what doesn't work to be extremely useful; it doesn't (necessarily) help me solve the problem but at least it can save me a ton of time by eliminating solutions that may look promising but are provably incorrect.
Nifty tricks for productivity
My last main topic area is a bunch of random crap that I've figured out that other people might find useful and that I've used to somehow boost my productivity. This includes some various bash tricks, how to turn Vim into the greatest Python IDE ever, and something I call "The Curious Case of the 12GB Docker Container" (yes that's actually a thing, it's really useful, never do it in production, and more about that in a future blog post).
All Things Agile
I'm still very much into Agile and have seen it go both very well and very badly, with the latter case being more frequent in my experience. I'll start by being a bit controversial: I have come to hate what Scrum has turned into. There are far better ways to attempt to "manage" your software projects so I'll give some specifics on what I don't like about Scrum as well as some alternatives to consider.
The Technical Interview: you're doing it wrong
My last major topic that has come up most recently is my general hatred of how we tend to handle modern technical interviews. Most people want to see "how you think" so they ask a bunch of esoteric questions or programming problems that in reality teach almost nothing about a candidate. I find that I usually only need to ask an interviewee a single question (one of several) and I've had far better results. Asking someone "how would you derp derp derp problem description?" where the answer is "use Dijkstra's algorithm" and then somehow expecting them to remember that algorithm well enough to whiteboard it in 45 minutes after several years of not having implemented it is a really poor way to assess whether or not you want to work with that person and tells you little about their general level of skill. There are better and more open-ended technical questions, but ever those just don't tell you as much about a potential hire. I've learned things from being on both sides of the interview table that I'll share that just maybe might help finally un-fuck this thing we call "hiring" in the tech industry. I've got a post or two worth of ranting about how we recruit in the tech industry as well; I'd love to facilitate some change in that area if at all possible.
I hope to have time to write at least once per week but we'll see what life actually ends up doing to me this time around. I'm sure I've got some other topics rolling around in my brain as well, probably involving TDD, BDD, and various other ways to write better code. Hopefully at least some of this will prove helpful to someone out there.