How I Avoided Management for 25 Years

A recent post that showed up in reddit’s /r/programming, What Happens To Developers Who Never Go Into Management?, got my mind buzzing on all the ways I had to re-invent myself to avoid going into management in the security industry. Being in my 50s, I do technical level work with people who are often half my age, and I am often older than my manager and sometimes my manager’s manager and even higher levels. I have continued to dodge the bullet of going into management, but only in the past couple years have I considered that maybe I should give management a try.

This is a blog about what to expect if you want to avoid management. It’s largely about my personal experiences. For the last decade I have been in AppSec, but prior to that I was involved with embedded security and cryptography. If there is one takeaway from this blog, it is that you have to keep on re-inventing yourself while learning new technologies and industry directions. Maybe it’s obvious when you see it written out, but it may not be so obvious when you are early in your career.

What Happens as you Become Older and Avoid Management?

The short answer is that the technologies and expertise that we have mastered often become less and less relevant, as new technologies come to take their place and new skills are needed. Many skills we learned at University become obsolete. The new, young developers learn the latest technologies and skills, and we have to find the time to learn those ourselves in order to remain relevant.

But it’s not all doom and gloom for the old fart. We have had many years of experience to see how industry changes. We understand that that change will continue to happen, and if we position ourselves right, we can help direct the change. We can become thought leaders (even without being a manager), which requires not only insights, but excellent communication skills. We’ve learned the value of team work, and understand the necessity for practical solutions that meet the needs of various teams within an organisation. We also tend to have a sense of when something is just not working the way it should work, which gives us the opportunity to take the lead for change. The catch for this paragraph is that it doesn’t happen all by itself: we need to grab the bull by the horns to make those changes happen.

Personal Example of the Above Points

Here’s a breakdown of my own career and how I had to constantly re-invent myself:

25 years ago: After grabbing Masters degrees in Computer Science and second one in Mathematics, I started my career in industry. I was an expert at C programming, algorithms, parallel programming and making code fast. I knew C programming pitfalls (such as buffer overflow) and how to exploit them. I was good at various assembly languages and cryptography. I had the niche skill of being able to break cryptosystems. I also knew embedded programming. I had the skills that many Silicon Valley companies wanted, yet the compensation was not much more than beans. I got to do what I loved to do all day at my job and was rarely interrupted. I was happy. Back then we did waterfall development methodology, which seemed right at the time.

We developers who worked back then had the very frustrating experience of working on early versions Microsoft Windows, which was awful beyond belief. Cygwin was a partial escape from this horror. Eventually Linux became more common, but back then we had to set up our computers to use dual boot, and it was painful to switch between the two.

15 years ago: Object oriented programming became the cool thing. My beloved C language was being pushed out due to C++, which I learned to read but I hated it. Embedded programming jobs were hard to come by where I was living, but I found one. The catch was that I spent the whole 4 years at the job doing security code review. Unfortunately there was no concept of “shift left” back then, and I was stuck at the tail end of a broken attempt at bringing security into a product. I was still able to use my cryptographic expertise for some cool stuff. I started to learn Python and Java.

A nice development was the availability of Virtual Machines that let us run Linux within Windows. I still preferred Linux, but Windows XP was getting close to acceptable from a usability point-of-view (not from a security viewpoint).

10 years ago: I had trouble finding jobs in embedded security where I Iived and I could not find a programming position that would pay the bills largely due to my increasingly obsolete languages of expertise. I decided to switch to web security. I started learning about OWASP, shifting left, Secure Development Life Cycle (SDLC), iOS programming, test pyramid, very basic web penetration testing, Oauth 2, and introduction to AWS and cloud computing. I continued to learn more Java and Python but never became fluent. I started to learn about SAST tooling. I also gained a strong appreciation for Agile development methodology.

An interesting point here is that I warned about web security supply chain attacks before it was the cool thing to talk about (Remark: vulnerable 3rd party libraries was just making the OWASP Top 10 when I made that StackOverflow post, but that was for accidental vulnerabilities — there was hardly any mention of intentional backdoors being put in 3rd party software back then). This is because in embedded security, we are very paranoid about the 3rd party software that we use. It was a bit of culture shock to see that web security had little concern for it at the time, but it certainly is hitting the headlines frequently in recent years.

5 years ago: I went into consulting. The cool phrase of the day was DevSecOps. I got lots of hands on experience with security tooling, mainly SAST and DAST, and how to automate the testing. I became better at penetration testing. I also learned many new languages, frameworks, and technologies: JavaScript, C#, .Net Core, Android, Nodejs, Docker, Kubernetes, CVSS, etc…. I got fairly strong knowledge of the OWASP Top 10 and how to prevent these problems. I also learned about Microservices.

There were some really big surprises to me at this time. For example, JavaScript was a language to be taken seriously, something I never believed before. I learned to program in it, both front end and back end. I became okay at it, except the async await stuff. I learned about the Document Object Model and jQuery. Another surprise to me was that Microsoft, in my view, was turning into a respectable company (yep, I said it!). I had previously considered them to be evil due to suffering through the pains of their monopoly. But Microsoft made some major changes that were required for them to survive in a cloud computing world against giants like Google and Amazon. Suddenly I no longer hated them. They were actually very mature in the SDLC. They had good documentation, and their C# and .Net Core seemed very cool, especially with the efforts to bake in security by default. The more I compared C# to Java, the less I liked Java.

Recent years / now:

My appreciation for communication skills started during my consulting time, but I continued to develop it beyond then. I was seeing so-called “experts” and “researchers” getting publicity, and too many times they were getting credit for things that were not particularly innovative.

My blog was created to communicate my thoughts on security, and to make certain obscure but useful research results more known (example: Fighting Bots with the Client-Puzzle Protocol). I spent a lot of time reading research and staying abreast of industry developments. I became increasingly focused on user-friendly security, which others are beginning to grab onto, but I believe I was there among the earliest (in fact, this was something I had been talking about for approximately 10 years). I was able to bring some of these ideas to real products for great change at previous employment. Also, with some colleagues, I started AppSec Australia meetup to help increase sharing of AppSec knowledge in Australia.

I’ve always believed in security education, but the more I improve my communication skills, the more impact I see it having. At my previous job, we had a lot of success with security education. There was not much whining coming from the AppSec group at that company: I truly believe we were doing things very effectively for such a small team.

Then Versus Now

What skills did I have 25 years ago that I still use today? Cryptography, shell scripting, and not much more. I still use vim as my primary editor, but I am trying to push myself to VS Code. I had to re-invent myself several times to stay relevant. I love learning, so that’s okay with me. But it can be frustrating to learn a new language that someone half your age has mastered right out of University! I’ll get good at that async await stuff eventually!

Truthfully, I had so many expertise back then that were matched by very few people, yet I’m not sure I can say that about anything now. What I can say is history has brought me breadth and depths of skills, vision for how things change, and the confidence to step up and take the lead for change.

One thing to keep in mind if you want to avoid management is that University does not “train” you, instead it “educates” you. Training IMHO means learning a skill, whereas educating involves learning a skill and learning to think and solve problems. If you did your education right, you can adapt to change. The big problem we have as we get older is having less time to do so. This is due to having families and weakening bodies that prevent us from doing the long, crazy hours that the younger people can. It is my belief that experience is the key to using our time wiser.

Leave a comment