How did your technical skills fare in 2010?

Well, my first full year at SAIC is coming to an end and it is time to take stock of what I've learned, technically, over the past year. I hope to have another blog on management, project, and customer engagement skills, because, truth be told and like it or not, I've grown more in that area than technically in the past year.

Now your day job shouldn't be the only thing determining the level of your technical skills, but it is obviously a major factor. In the last quarter, I picked up leadership/management responsibilities so I will mindful in 2011 to ensure that I at least maintain the skills I've got and not become "soft" and hands-off. This point has been made crystal clear to me as I've been reviewing folks resumes (but have seldom interviewed them) that have let their skills go. A cautionary tale. And some that that I have managed to interview, I've heard the line "I could learn that again if I needed to" one too many times. Folks hold on to the skills they hold precious, even if you have to do it on your own time or change jobs. It is just too easy, especially if you are doing well and making an impact for your organization to let things go.

Coding
The last year has been no different that other periods. Historically, coding occurs in fits and stops. At the beginning of the year I was involved in a research project where I was doing a bunch of Python development with MongoDB, but that ended early on. Near the end of the year more light scripting mostly using dpkt, scapy, and nfqueue-bindings for some protocol testing testing that will hopefully end soon so I can stop the dreaded commute two times a week to Tysons Corner.

Networking & Security Products
I really enjoyed working with ScreenOS on the lower end Juniper SSGs. Most of my firewall experience was Cisco (or PF) so it was a refreshing change of pace. It was a bit frustrating at first, both the ScreenOS CLI and WebUI are preferable to anything from Cisco has ever developed. On the other hand, I did not enjoy working with Garretcom industrial switches, especially their screwed up way of configuring trunk ports and and VLANs. Not to mention their screwed up Flash UI. Working with one of the wireless clients/bridge/APs commonly used by some of the armed services was also a mixed bag, but I learned a little bit about RF surveys and the pros and cons of Mesh vs. Bridge vs. Client/AP wireless architectures. And then there is Air Defense, which I probably haven't learned as well as I could have but there wasn't enough time. In the lab, I kept up my skills up with IOS and ASA based SSLVPNs, but this was actually something I first learned in 2009.

Design/Build/Test/Deploy
A few of my projects have been true engineering (as opposed to assessment) projects that involved specific requirements (either that were provided to us or we had to develop ourselves for the client) where we were responsible for network/system design, configuring all these components and finally bringing them to deployment and handing the components over the customer. The "big enterprise" operational/IT skills I picked up at Hewitt definitely helped here. A couple of projects have required designing and implementing a new wired and wireless network infrastructure (as well as the appropriate C&A activities necessary to connect it) and this has been an interesting challenge, sort of like putting together a puzzle as you figure out to connect all the various L2/L3 infrastructure and security devices together.

Miscellaneous Stuff
Besides fooling around with MongoDB for about a month solid, I learned that some of the RAID controllers on Compaq hardware are lame and that backing up and restoring ESX filestores can be extremely slow and painful if you have SATA drives. Hands-on experience (mostly just getting it working and defining an appropriate security architecture vs. hard core device hacking) with several different smart meters, collectors, and headends, but nothing to write home about and certainly nothing I'd pose for a newspaper for in front of my hacking gear. Last, but not least, I've had the pleasure working with a great new client of taking a deep dive into a popular SCADA system and architecting a real time vulnerability management solution that will be deployed in the new year. Didn't learn any new products here but definitely a new experience of developing a solution from scratch.

It seems like I should have done more than this, but perhaps this is even better than 2010. I learned some new products, APIs, and wrote a bit of new code. I guess it could be worse as a senior engineer for a large government contractor I could be writing technical proposals and pricing non-stop. Fortunately I've been able to dip down and keep my hands dirty now and then, in addition to the normal QA (and tough questions) to keep engineers honest and on track.

So it's been a decent year, but in 2011 I need to do better, and this will be a challenge as there is no doubt that more of my time will be involved managing employees as opposed to just leading projects.Undoubtedly I will need to do work on my own time to keep it real. Stay tuned for some goals I will define for the new year.