Dev Chats: VM (Vicky) Brasseur

Introduce yourself! Who are you? Where do you work?

Ohai! I’m VM Brasseur, but because we’re all friends here you can call me Vicky. Beyond that, answering the question, “who are you?” is surprisingly difficult. My external identity is a free and open source/software development leader with twenty years of experience in this field. I’ve led software engineering departments and held positions up to the VP/CTO level, but free and open source is where my heart lives. I travel the world teaching and presenting on open source, community, failure, and management (sometimes all at once).

My internal identity is someone who’s still surprised to wake up and discover she’s an adult now and who is really disappointed there’s no real money in sitting at home playing with my cats, watching goofy scifi, and eating cheese.

Currently, I work wherever I happen to be. This isn’t only because I’ve telecommuted for the majority of the past ten years, or because I travel so much for conferences, but because I’m a freelancer. If you or your company need help understanding or implementing any aspect of free and open source software (complying with licenses, contributing to, or releasing your own), I’m your gal. I also provide corporate training for public speaking and contributing to open source.

 

Who or what got you into programming?

Ah, see, there’s an assumption in this question: I’ve never really been “into” programming, but I love technology. We had a Commodore 64 when I was growing up. I peeked and poked at it a bit, but without a problem for it to solve for me, it wasn’t really worth my time to mess with it. I was interested in programming in university, but the condescending treatment I received from others taking the courses convinced me it wasn’t worth my time. That didn’t stop me from spending countless hours in the computer lab learning how to use UNIX (this was pre-Linux) and exploring Usenet, Archie, Gopher, and BBSs.

Near the end of my time at the university I was on staff at the circulation desk of the main library. The library was migrating to a new software system. This one featured a cutting edge (for the time) graphical user interface that our library was beta testing. I took over the library side of the beta test, coordinating testing and bug reports with my counterpart at the software company in California.

When my second degree was complete, that software company offered me a job running beta tests from their side of the equation. Naturally, I accepted. That job required a lot of repetitive and manual software installation across dozens of *NIX systems. Finally, I had what I’d lacked back in those Commodore 64 days: A problem to solve with programming. I taught myself shell scripting to automate my tasks, then moved on to learning Perl for more advanced work. I also added MySQL to my bag of tricks and very nearly pursued a career as a DBA. Instead, I left that company for one that needed a Perl programmer with MySQL skills. That lasted about a year before I transitioned (still at the same company) first to product manager and then to Director of Product Development.

This was my first management position and I was hooked. I love technology, but I don’t want to program it. I love empowering the people who build software, getting obstacles out of their way and coaching them toward their goals. One day of leading technologists is more satisfying to me than all my years of programming combined.

 

What makes open source important for you?

Last year the US Food & Drug Administration approved a genetic cancer treatment. That treatment was the result of a study that built upon a study that built upon a study… Would this breakthrough have been possible without the hundreds of researchers involved with those earlier studies? Or if their methods and results had not been available for today’s scientists to reference and learn from? Do I really need to answer that question?

Is software development analogous to cancer research? In many ways, yes, it is. To create the most stable, most secure, and most innovative software requires building upon the work of those who came before us. With software infiltrating the everyday items of our lives, it’s more vital than ever that we work together to ensure that safety and security of the end user, AKA the people whom we serve.

Free and open source software, methods, and collaboration are the key not only to serving our end users well, but also to creating the innovations that will ensure the value, the jobs, and the magic of the future. If you’re free to take a thing I create for one purpose and improve it to serve a different group of people, then the chain of value of my software is lengthened and strengthened. For proprietary software, there is no chain of value. It’s a single round link, providing value to a small group of people. That’s fine for some purposes, but locking innovations out of sight will not help anyone advance technology.

Beyond the methods and the innovation, free and open source software communities are leading the way for the distributed and collaborative workforce required for our ever more globalised society. These communities have been at this for nearly forty years, putting them decades ahead of the curve for developing the tools and practices required for efficient software development by a dispersed team with a fluid membership. Businesses that study and learn from these tools and practices are those that will thrive in the decades to come.

And, yeah, I also believe in sharing. But my personal beliefs aren’t nearly as important as those other benefits I listed above. This isn’t about me, it’s about us.

 

How has speaking at (many!) conferences helped your career? Any surprising outcomes?

I couldn’t do my job without presenting at all of these conferences. Conferences are where I meet with free and open source maintainers, contributors, and users from all over the world. This is where I learn new things, get to know new people, provide and receive counsel on all sorts of strategic, technologic, and community concerns.

Unlike many in free and open source software, I don’t identify as a member of any one community (Apache, Node.js, or Debian for instance). I collaborate with and contribute my expertise to all that need it. This gives me a broad view of the issues affecting free and open source software, but it also enables me to introduce people who may not have met otherwise so they can share their approaches to similar challenges being faced in different projects and communities. This would not be possible without attending so many conferences.

Many of the people I meet at conferences have become close friends, many more have become colleagues, and even more than that have joined my personal network. When I have a question, a concern, or a need, I have no lack of people to whom I can turn for assistance and advice.

And, of course, as a freelancer it’s very important for me to gain exposure and a reputation for providing knowledgeable and quality advice. Presenting at conferences not only does that, it’s also the best way I’ve found to locate clients.

The most surprising outcome of presenting at so many conferences was learning that not only am I good at it, but I also really enjoy it. I never saw that coming and wouldn’t have known if I hadn’t tried.

 

What has been your toughest lesson to learn in your software career so far?

Skipping vacations, working long hours, prioritising work over life? That’s not dedication; it’s pure stupidity. Cut it the hell out and live, dammit.

I’m still working on this one.

 

What would be your number one piece of advice for a successful software career?

You are in a service industry. You’re not being paid to program; you’re being paid to create a tool to make someone’s life better.

It’s not about the tech. It’s not about you. It’s about what you can use the tech to do for others.

 

Have you got any hobbies outside of your job? Do you think they help your tech career in any way?

I don’t give myself enough hobby time right now (again, I’m working on this), but when I do it’s spent on cooking, knitting, and sewing. Upper management isn’t a role that generates a lot of things you can see and use. While you’re serving your team and your users, you’re enabling your team to create things rather than creating them yourself. My hobbies fill that creative void for me.

As for whether they help me in my tech career…? I could probably fabricate some faux profound (profauxnd?) statement about how the slow creation of an end product allows me to consider the goals more fully, or how the difficulty in un-doing a thing has taught me to measure twice cut once for all projects in my life, but…yeah, we’d all know that’s mental masturbation thought leadery bullshit.

I don’t know whether these things help me in my career because I don’t think about them that way and don’t want to. They’re a welcome pause in an otherwise probably-too-fast work life. I enjoy them and that’s all I need from these pursuits. I’m not going to burden them with also influencing my professional life.

Plus, handknit socks are more amazing than your paltry mass-market-hosiery-wearing dreams could imagine. You’re missing out. Learn to knit.

 

What resources for open source and public speaking would you recommend?

Way to stack the question deck, Sam!

There’s only one public speaking resource to recommend, but it’s a collection of all the other public speaking resources: the Public Speaking repository on GitHub. It’s your one-stop shop for public speaking assistance. We also have a community of people ready to help you with your conference proposals, presentations, and performances. That’s on the #public_speaking channel on Freenode IRC. (that link goes to a webchat UI, so you won’t need to mess with setting up an IRC client to get help) Please join us and let us help you teach others!

As for resources for open source…well, that’s a very large ask. Resources about contributing? Using? Releasing? There’s just so much ground to cover there. So instead of covering it myself, I’ll just direct you to opensource.com. Search there and you’ll find articles on what you need. And if you don’t find an article, contact me and I’ll help you contribute the article yourself.

 

I hear you have a book coming out? Tell us about that!

I’m still coming to grips with the fact that OMGIWROTEABOOK, so you’ll pardon me if I’m a little scattered right now. Writing at all? Hard. Writing a book? Hard++. Thankfully I have a brilliant editor to help keep me motivated and inspired. None of this would have happened without his help.

So, have you ever gone to contribute to an open source project and found that the experience was…let’s just say sub-optimal? And that everyone expected you to know a lot of stuff that you didn’t realise you were supposed to know, and that expected stuff is poorly documented, and that documentation is strewn across a dozen different blog posts? Yeah, that.

On behalf of the entire free and open source software community (for whom I am not authorised to speak): I apologise. We’ve let you, the new contributor, down and we can do better.

This book does better. If you’re even vaguely interested in contributing to open source projects, you should check it out. And if you’re not a programmer? You should still check it out, since the book is written to be inclusive of all the skills required to deliver good software. Programmers, writers, designers, testers, marketers, more. Open source needs your skills. This book helps you contribute them, no coding required.

The book isn’t complete yet, but it’s now available in beta early release. This means if you buy the book now you not only get more than enough to get you started contributing to and participating in free and open source software communities, it also means you get frequent updates, the entire book when it’s done (est. June after copy editing, typesetting), and the opportunity to provide feedback while writing is still in progress.

This is my first book, so I’m both excited and terrified to release it to y’all. I hope you give it a try and that it’s helpful for you.

 

And finally, when you mime programming to somebody, do you use T-rex arms, or wiggly fingers?

This question vexed me more than I should probably admit. Does thinking about a typical action result in the typical action or only the action you wish were typical? Do I actually do what I think I do or do I just think it? Have I just lost The Game by thinking about The Game, and also now made all of you lose it, as well? Who did put the bomp in the in the bomp bah bomp bah bomp? So many questions!

After far too much thought, the answer is: Neither or, more specifically, both. I do T-rex with wiggly fingers.