I have time availability for another client! Is it you?

Open sign by caveman92223 on Flickr; CC BY-NDSince I left the Helion OpenStack team, I’ve been helping companies–particularly startups and small/medium businesses–with Open Source, Technology, Community, Business, & the intersections between them. So far it’s been some of the most rewarding work of my professional life. I’ve worked with brilliant people helping them and their companies understand and contribute to free and open source software, as well as develop corporate open source policies.

I’ve been keeping it to one client at a time while I get my practice up to speed. Now I’m ready to ramp it up and add another.

Here’s a sample of what I could do for your company:

  • Counsel and collaborate with company leadership on corporate open source goals.
  • Define corporate open source usage and contribution methods.
  • Develop policies for open source compliance and risk management.
  • Train staff and leadership on meaning of and best practices for releasing and contributing to open source.
  • Analyse processes and provide change recommendations for using and contributing to open source, including community growth and engagement.
  • Develop staffing and hiring plans to support open source development, contributions, and healthy community engagement.

While my primary focus currently is consulting, I’m always open to hearing about full-time positions working in the open source space, be it leading open source software development as director or VP, managing open source program offices, or developing and growing developer advocacy and other community programs.

Contract or full time, I can help your company succeed with open source. Have ideas, leads, or just questions? Drop me a line. Let’s chat.

Changing the language

The other day I tweeted this:

Tweet by @vmbrasseur: "If you help to create software (design, prodman, QA, docs, code), you ARE a software developer. All roles are vital, not just programmers."
Tweet by @vmbrasseur: “If you help to create software (design, prodman, QA, docs, code), you ARE a software developer. All roles are vital, not just programmers.”

This tweet is a necessarily brief exclamation of something which has been on my mind a lot lately and warrants a larger post. In summary: The words we use matter.

It’s probably safe to assume that nearly everyone reading this is involved with creating software. Even if you’re not, you’re undoubtedly aware that software development is a complex process composed of many moving parts. While it’s possible to create software on your own, it usually works much better when we collaborate to build each of the parts.

Despite recent “full stack” trends, none of us can be specialists in every facet of the software development and creation process (nor should we try). Many different skills are required for the process to work smoothly:

  • Before writing a single line of code, product management, user experience, and user interface design are necessary to make sure you’re creating software which is valuable and useful to the end user.
  • The crafting of the deliverable software product involves front end coders, back end coders, security analysts, database administrators, and documentarians. It may also require more specialised roles such as mobile coder or data scientist.
  • Before the software can be delivered, quality assurance and product management must confirm that the software not only meets the needs of the end user but also that it works as expected (or at all).
  • The actual delivery of the software is the responsibility of system administrators, operations, and devops. They, along with DBAs and customer service representatives, also help to ensure the software remains available.
  • As the software progresses through its life cycle, customer service receives additional support and outreach assistance from marketing, sales, and community management.

This is the software development process. This is what it requires. A true “full stack” software developer would be skilled in all of these roles (which is why the very concept of “full stack” is laughable). Yet lately when we speak of software developer we mean only those who create the code. As we see above, programming is only a portion of the process, just one of those many moving parts. The term as currently used disregards the myriad other roles required to develop a successful piece of software.

It’s unclear what nudged our language to shift such that “software developer” has come to exclude the majority of roles responsible for successful software development. It’s not as though there is any shame in the title of “programmer.” It’s a descriptive title but more importantly it’s one with decades of rich history behind it. By using “software developer” instead we’re not only excluding people, we’re turning our back on this history and everything which it affords us.

Why is this important?

Words matter. How you talk about things affects how you think about them. To discuss “software development” as though it were a purely programmatic act excludes a large percentage of the people who participate in the process and encourages a “cult of the coder” mentality such that programmers are lifted up to near aristocratic levels.

This programming-centric view does software development no favours. By excluding other roles from the language we use, we also exclude them from how we think about the process. The piles of startup corpses strewn along the road to business success are a testiment to how ignoring things like user needs, market fit, and usability will scuttle even the best coded piece of software. Recent findings by GitHub show that excluding documentation from the process has negative effects on the adoption of and contributions to free and open source software projects, no matter how well architected their APIs.

The biggest loser in this “cult of the coder,” though, is the end user. The poor unfortunate souls who struggle to use a UI created by someone inexperienced in the skill, who growl in frustration as yet again a software service updates without a much requested feature, who are astounded by Internet of Things products with no concept of security, who puzzle out and reverse engineer undocumented installation steps. So much productivity, opportunity, and customer good will lost because software companies often focus more on programming than on the entire software development process.

Don’t get me wrong: I love programmers. I’ve spent most of the last ten years of my life leading programming teams and departments. Programming is a highly specialised and ever changing part of the industry. It’s populated by some of the most clever, most inspiring, and kindest people with whom I have ever had the honour to work. It is not the fault of programmers that the language shifted around them. It is the fault of our industry, our community, and our culture.

We can do better. We can do better for the end user, for programmers, and for everyone involved with or impacted by software development. It all starts with changing our perceptions through language.

Let’s start to shift the language back and reclaim the term “developer” for all who participate in this complex process rather than just the programmers. Let’s evolve the mindset back toward one where we recognise the contributions of all of the roles which contribute to delivering and supporting a successful software project. Let’s call a spade a spade and a programmer a programmer and just get back to work creating software which changes peoples’ lives in valuable ways.

Public Speaking Resources

Had you told me 10 years ago that not only would I be on the open source/tech conference speaking circuit but that I would love it, I would’ve looked at you like you had three heads but only two eyes between them all.

And yet, here we are. In 2016 I presented 18 talks at 15 events all over the world. So far in 2017 I’ve either presented or organised 9 talks or events. I advise people on their conference proposals, bios, and on the talks themselves. I provide training for those who wish to get started in conference speaking. This is not at all the life I envisioned for myself; it’s So Much Better and I’m grateful for the opportunities I’ve had so far. Thank you, all.

In 2016, in collaboration with Josh Berkus, I presented my first ever speaker training workshop. Since then both Josh & I have presented the material separately and each made it their own. We’re covering more ground this way, training far more people than we would if we had to coordinate between our very hectic schedules.

During the writing process of that workshop, we created a bibliography of public speaking links. In the year and a half which followed, I kept adding to that bibliography whenever I discovered a link which we hadn’t included the first time around. It was turning into a really great resource for those wanting to learn more about presenting at tech conferences, but it was impossible to find. Who drills down into the repo of a workshop which was presented only once? No one, that’s who. So the valuable bibliography was lying dormant. Well. It ain’t sleeping anymore…

🎉 Please welcome the Public Speaking Resources repo into the world! 🎉

Currently weighing in at 50 different public speaking and conference presenting links, this is one of the best resources you’ll find for improving your conference speaking experience.

One of the advantages of pulling the bibliography out into its own repository is that it’s now very easy for anyone to contribute a new link or resource for the benefit of everyone. We ❤️ contributions and contributors!

Even if you don’t have a link to contribute to the collection, the repo also serves as a focal point for a community which can answer your tech conference presenting questions and help support you on your path to becoming an amazing conference speaker. There are two ways to get this support:

  1. Open an issue with your question or suggestion and we’ll do our best to guide you.
  2. Join in the real-time conversation on the #public_speaking IRC channel on Freenode. Yeah, we know that Slack is the new hotness, but this project still kicks it old school. But fear not! The IRC channel is covered by the project code of conduct, so you needn’t worry about dealing with the less savory elements of the internet. You also don’t need to jump through a lot of hoops to join in the conversation. Just hop on the webchat, pick a nickname, and you’re good to go! If you’d like to learn more about how to use IRC, there’s an article for that.

There ya go! Please share this public speaking resource with everyone who might be interested and please contribute. Together, we’ll help a lot of people improve their public speaking, their self confidence, and their careers.

Organise your job hunt with Trello

Demo Job Hunt Trello Board Because I’ve moved on from previous job I have the legitimate pleasure to be speaking with a number of organisations about my next steps. At current count I’m speaking with a very-surprising-to-me 10 different companies, which usually might cause a bit of an organisational headache. Thankfully, years ago I came up with a system which keeps me sane during a job hunt.

We all know it: Job hunting sucks. One way to make it suck less is to keep good records so you always know where you stand and with which companies. Some people use their email for this, but no matter how good the search capabilities email is not a good project management system. Make no mistake, job hunting is a project just as much as developing a new version of your software. If you treat it as such you can reduce stress and improve your chances of success. Having good records allows you to be prepared and put together when you get that random recruiter calling and assuming you remember all of the details of their specific job. When job hunting you very much want to look prepared and put together. First impressions really do matter.

Record keeping

When I say “record keeping,” what do I mean? What sort of records should you keep? It’s a lot more than most people consider. You should track:

  • PDF of the job posting
  • Research on the company, position, & expected salary
  • Resume & cover letter used for application
  • URL/method for following up on the application
  • Every email & correspondence
  • Notes from every call and meeting

That sounds like a lot, and depending upon the activity of your hunt it really can be. Not only that, but all of these items must be available at your fingertips at any moment, just in case you do get that random recruiter call. So how do you keep track of so much information while still making it highly available? As you’ve already guessed from the title of this article, I use and recommend Trello for this purpose. Here’s how I do it…

Trello to the rescue

Trello is a kanban tool where tasks are represented by cards and each step of the process is represented by a column. Cards are moved between columns as they work their way through the process. The collection of columns and cards all live on a board. You can make good use of the tool with very basic To Do, Doing, Done columns, but you’ll get better results if the columns represent the actual steps of whatever process you are performing. The columns on my Job Hunt Trello board represent the typical steps in a hiring process in the software industry, plus a few extra for record keeping:

  • Gathering Info: I’ve heard about the position and am doing research to see whether I’d like to follow up on it in some way.
  • Applied: I’ve applied for the position and am waiting for more news.
  • Phone Screen: I’ve had some initial interested contact for the position, typically in the form of scheduling/having a phone screen, and am waiting for more news.
  • First Interview: I’ve either scheduled or had something which could qualify as a first interview for the position and am waiting for more news.
  • Second Interview: If necessary for the hiring process, I’ve either scheduled or had something which could qualify as a second interview for the position and am waiting for more news.
  • Offer: I’ve received an offer for the position and am considering/negotiating it.
  • Accept: I’ve accepted an offer for the position.
  • Declined: I’ve been declined for a position at any point in the process.
  • No Word; Assume Declined: I’ve heard absolutely nothing about the position after a long wait and have assumed that the organisation is not interested in my application. At the end of a job hunt, this column usually contains the most cards. Companies are utter rubbish at communication with applicants.
  • Withdrew: At some point in the process I decided that I was not interested in the position and I withdrew my application from consideration.
  • Defunct: The position no longer exists for some reason or other (usually budget cuts).
  • Meh: After gathering information but before applying, I decided I have no interest in pursuing the position. I could just archive the card, but there’s value to me in the perspective afforded by reviewing what positions I walked away from and why.

Gathering Info

Each position which catches my eye is captured in a separate card on the board. Typically the card starts in the Gathering Info column. If there is a job posting for it, I’ll save that off to a PDF then attach that to the card. Why? Because job postings have a tendency to disappear when you least expect it. For instance, if a company has decided it’s received enough applications it may unpublish the job posting. Should that happen and you’ve not saved a copy of it somewhere, you will no longer be able to reference it when a recruiter calls you out of the blue assuming you remember all of the salient details of the position. Attaching a posting PDF to the card ensures you’re never caught off guard.

At this point I’ll also research the position and the company, including reaching out to people I know who currently work there or have worked there in the past. All of this background information is added to notes in the card, collected in one spot for quick reference. If I like what I’ve learned, I’ll apply and move the card to the Applied column. If not, I add a note about why I don’t like the position then move the card to Meh.

Applied

Applying for a job is not a fire and forget process. There are artefacts which come out of it: the cover letter, the resume, and possibly some application-specific questions. Each cover letter and often each resume is customised for that specific application (why? read these). These, as you may expect, are also attached the the card. Some application processes include additional questions relating to the position. I copy those and my answers to them to a note in the card. Should those questions come up again during an interview process, I want to be able to answer consistently or otherwise refer back to my previous answers. Should the application process result in a URL for checking on the application status, I’ll also make sure that ends up in the card at this stage (normally in the Description field at the top so it’s easy to locate).

LOCKSS

While the posting PDF, cover letter, and resume are all attached to the card for the position, I’ve been in this industry too long to put all of my data eggs in one basket. These also get committed to a git repo which I maintain for this purpose. It contains every copy of my resume, every cover letter, and every job posting I’ve looked at for nearly a decade. Overkill? Perhaps. But unlike many people I will never have to rewrite my resume because I can’t locate a file I haven’t looked at for several years. It works for me and, as they say in the library and archiving world, LOCKSS.

“Ageing” cards

The movement across the board is fairly logical from here. As a particular position progresses through the process, its card moves to the appropriate column. Trello has a card-aging power up which will change the appearance of a card if it hasn’t been touched in a while, which really helps a lot. This allows me to see at a glance where things are in the process, which positions may need a follow-up from me, or which may be duds which need to move to the No Word; Assume Declined column.

Email is a poor filing system

Every piece of correspondence about a particular application is added as a note on its associated card. To do this, I make heavy use of Trello’s “email to note” feature. Each card has a unique email address. Mailing to it will add that email as a new note on the card. If the email has attachments, those will be attached to the card as well. I forward or BCC all email correspondence to its associated card, so I never have to go digging through my email archives to find an important message. The “email to note” feature is very handy in this way, but I do wish it would include the To:, From:, and Date: lines from the email message headers. This is valuable information but is stripped from the email when the note is created, so more than once I’ve still had to spelunk through my email archives to locate an address for someone who messaged me months back.

Aside from correspondence, I also tend to take a lot of notes during all job hunt-related conversations. To whom I spoke, when, and about what are all vital information as the process continues. I usually take these notes in Evernote (which until recently worked better for offline note taking than Trello) then transfer them to Trello after the conversation and/or interview is complete. Each piece of information slides into place to fill another hole in the puzzle, revealing more of the picture of the organisation. Keeping them all in one spot on the card allows me to review all notes and correspondence in advance of subsequent meetings or interviews. I’m always on top of the information and am able to be more prepared (and therefore more confident) during every interview. It really is like a superpower, that confidence boost of being prepared.

Closing the board

Once the entire process is done–a new job is located, negotiated, and accepted–the final step is to close the Trello board for that job hunt. It’s immensely satisfying to be able to put down your tools and walk away after a long and successful project, and closing the board is a great (if perhaps overly metaphorical) way to end one phase of your life as you start out on the next.

So that’s all there is to it. Create a board, create columns, a card for each position, attach all the things, note all the things, keep the cards moving down the board. Boom, you’re done.

Where to see more

If you’re interested in seeing more, I’ve created a public demo job hunt board. It doesn’t have attachments on the cards or many notes, but it can help you get a better sense of the workflow and how it might be useful for you.

Thinking Outside the Big Green Box

In October I had the dubious honor of laying off my entire team (they’ve all found excellent new positions). At the time I was to have joined them in a workforce reduction, but my position was retained and instead assigned to the group of people included in the SUSE acquisition of HPE Cloud. The acquisition is now complete and I once again find myself in a position to make a change.

I joined HPE in September of 2015 because I wanted to make a difference to a team of open source developers. To do so, I stepped down from a Director role into a Senior Manager one. The team was amazing, full of people whose capabilities and brilliance humbled me daily. I have no regrets and am grateful that I had the opportunity. I did not want to see it end.

The SUSE acquisition has put me into a different role, one which isn’t the direction I wish to take my career. Furthermore, it would do so at a Senior Manager level. I didn’t mind the step down when I was supporting a team devoted to open source, but upon reflection I find I do mind it when I’m working on a product rather than a passion. Therefore I’ve chosen to leave the team which has moved over to SUSE. They’ll do great, but they’ll do it without me.

While I am moving on, it’s not without sadness. I am leaving behind several inspiring people. Jim Meyer has proved the power of empathy and compassion in leadership and in product development, supporting and encouraging each member of the team to live life to the fullest and become the best person they can be, all while advancing the Helion OpenStack product. Allison Randal has been a sympathetic listening ear, always there with advice and an overflowing love for the team and for free and open source. Samuel de Medeiros Queiroz, I may miss you most of all. Your energy, enthusiasm, and passion continually remind me of the magic of open source, bringing people together and changing lives for the better. Thank you, to these three, Danielle, and to all the Parrots (you know who you are).

What’s next? Well, that’s a very good question. Running an open source program office would be fairly ideal. I’ve been working in the open source policy and strategy space for a while and would like to do that full time rather than on the side as I have been, but I don’t wish to limit myself. I’ve been leading software engineering departments and teams for most of the past 10 years. My teams tell me I’m a superb manager and leader. I know business. I know open source. I know community. How can I combine some or all of these? Let’s find out.

If you know or hear of anything in the open source space (strategy, policy, leading a team of people who work in open source, etc), I’d really appreciate it if you could send it my way. I currently have a contract helping a company open source an internal product. I’m looking forward to that project, but it’s temporary. I’m looking for the Forever Home I’d hoped HPE would be.

Drop me a line: anonymoushash at vmbrasseur dot com.

My resume: http://www.vmbrasseur.com/resume.pdf.

No, I will not “lighten up”

Here’s a conversation I was in recently. It’s paraphrased and anonymized because I’m not here to name-n-shame.

Person1: Oh hey, $less_popular_project I work on was found to be one of the most secure!

Me: Nice! Good for them. /me boosts signal

Person2: Too bad no one uses $less_popular_project, lol

Me: Not cool. Don’t bag on other projects.

Person2: Lighten up. It’s a joke, jeez.

Had Person2 known Person1 I could’ve let it go as banter between friends, but Person2 didn’t. Person1 was a stranger to them.

I’d intended to leave it at that. I said my piece and pointed out bad behavior, but after thinking about it a bit, no. I’m not done yet. I’m sick of this crap and I’m going to plant my flag in the sand.

Person1 was excited that their project was receiving well deserved recognition for all of their hard work. Person2 used this as an opportunity for a cheap shot and hurtful language.

No matter what the intention (“It’s a joke, jeez.), hurtful language is still just that: hurtful.

There is absolutely no benefit to being mean here. This sort of micro-aggression is masquerading as humor but is amusing only to the teller, not to most of the hearers and certainly not to the target.

Angry cat photo from Flickr user jing.dong, CC-BY-NCFor many years now I’ve been (usually gently) calling people out when they try this sort of thing, but right now I’m going to be more direct about it:

Shaming people’s open source project or community, programming language, platform, editor, framework… This is what bullies do. It’s not funny. It’s not useful. It’s just childish and mean. Knock it the fuck off.

OK, maybe that was more than a little direct. Whatever. I’m tired of third-rate bullies hiding their attacks behind “it’s a joke, jeez.”

I will be firm, polite, and respectful when I do it, but make no mistake that I will call you on your shit and at absolutely no point will I “lighten up.”

At this point someone will chime in with “Yes, see Aurynn’s post, too!” so let me just beat you to that: The very good Contempt Culture by Aurynn Shaw

3 ways to improve your hiring process

The new year often brings the end to a lot of finance- or holiday-imposed hiring freezes and a rush to get the hiring process wheels back into motion.

Aside from having done a ton of hiring myself over the years, I recently had the opportunity to help several people through the hiring process at many different companies. This reminded me of some of recommendations I made to my clients when I was a tech/biz management consultant.

What follows are three recommendations for improving hiring at your organization. There’s a lot to be said about each of these topics, so I’ll just hit the highlights. As with most things (including hiring), how much you get out of these recommendations will depend on how much you put into them. Which is to say: Your Mileage May Vary.

These recommendations are written for a tech company audience, but they apply to most every team and industry.

1. Write Better Job Postings.

The majority of the job postings don’t reflect the position being filled. They may share the same title, but the details are lacking or inaccurate. Often they’re copied from a posting written years ago, for a position on which the requirements have evolved but the posting text has not.

Ensuring the text of the job posting accurately reflects the position being filled not only makes it easier for candidates to self-select for interest and qualifications, it also confirms that everyone on the hiring team is on the same page.

The description for the position should be specific, reflecting the job to be done and the work necessary to perform it. Examples of projects on which the candidate may work can make it easier for them to gauge their interest in applying. Also helpful is the name of the position to which this one reports.

The requirements and qualifications listed for the position must be limited to those actually required to do the job. "What-ifs" and "Maybe we could use" qualifications are not requirements. What they are is a sign that the hiring team hasn’t defined what they’re looking for.

If the tasks performed by the role do not require a formal education, either in computer science or any other pursuit, do not list a degree as a requirement on the posting. Including a degree requirement is a lazy shortcut on considering the skills legitimately required by the role. It’s also elitist, typically unnecessary, and discourages highly qualified but un-degreed individuals from applying.

All job postings should be reviewed for gender and cultural biases. Studies show that certain language in postings cause women to avoid applying, which leads to perpetuating the gender imbalance in the tech industry. Tools like Textio and the Gender Decoder for Job Ads can help uncover unconscious and unintentional bias in your job posting text.

2. Ask Better Interview Questions.

For years companies like Microsoft and Google were known for their trick interview questions. Where the big dogs go the little dogs follow, so a lot of companies were soon using this approach to interviewing. It came as no surprise to many when both Microsoft and Google revealed that their studies showed that this type of question did not help them hire better people and that they were discontinuing their use. Your company should follow suit.

Only ask questions which are directly applicable to the job. Real world discussions are more effective hypothetical questions, every time.

These discussions should determine the candidate’s ability to learn, to perform the job, to problem solve, and to get along well with others. Trick questions, inquiries into their personal lives, or those which ask for information which can be found on their resumes are not good questions for an interview.

During the drafting of the job posting you already determined the concepts and qualities which are necessary to succeed in the role. Many of these skills, such as building or using an API endpoint, are not programming language specific. Languages are, relatively speaking, easy to pick up once you’ve mastered your first. Unless in-depth mastery of a language is necessary for the role, avoid language-based questions.

Avoid questions which imply or require a formal education in computer science. For instance: if the candidate is unlikely to write Big O Notation on the job, do not ask about it in the interview. By all means ask about algorithmic complexity and optimization…if it is required to perform the role.

If the role requires that a candidate regularly write pristine standard-library-free code on a whiteboard, include a question about it. But only in this case. In all others, try talking through a recent or current problem the team is solving to see how the candidate will approach it.

3. Standardize The Process.

Most interviews are a bit of an ad hoc process. You see who on the team is available, hand them a candidate resume, and allow them to use whatever questions come to mind. This is wrong.

An inconsistent approach to interviewing will lead to inconsistent results in hiring. You cannot compare candidates fairly if you do not treat them equally.

A better process:

  • Build a team of interviewers who will meet with every candidate. Some people may resist this as a large investment in time keeping them from their "real" work. Usually a reminder that interviewing is also an important part of their duties is enough to quell any objections. However, please make sure to balance their other duties so everything can still be accomplished in a standard number of working hours per week (read: no more than 40).
  • Meet w/interviewers in advance so they all know exactly what the position is and what to look for. To avoid duplication of questions, assign each interviewer qualifications to query and discuss which questions they will use. Please allow them the agency of writing their own questions and using their own voice.
  • Each interviewer must meet with each candidate. They also must ask the same questions of each candidate. Both of these can be difficult to schedule, but are worth the effort. In this way the interviewer has the best idea of how each candidate compares against the others on the qualifications.

Like I said, these recommendations typically apply to all situations. However if they don’t, or if you’d like to chat about how to apply these or other suggestions to your hiring process, drop me a line.

On the occasional unpleasantness of community

Dear well-dressed lady who walked by as I was clearing the sidewalk of snow and ice,

No, I am not doing this because, as you state, I am “ambitious.” There are myriad things I’d rather be doing right now, not the least of which is working on the article which is due tomorrow.

I am doing this because, however onerous, it’s the right thing to do. The ice I clear from my sidewalk may save one of my neighbors a very unpleasant fall. You, well-dressed lady walking by, must live in a city rather than a community. This is what we do when we live in a community: we help each other.

The same is true in open source communities. Do we want to write documentation? For many of us, the answer is “no.” Do we want to do code review? Hold design meetings? Take the time out to answer user questions? Triage bug reports? Again, the answer usually is “no.” But we do it because it’s the right thing. Because by taking a little bit of time to do something we may not enjoy, we make our little corner of the world a more pleasant and more welcoming place for others. We turn it from a project, from a city, into a community.

Enjoy the cleared sidewalk.

Love from a community member,

Me

How to record a presentation screencast video using Quicktime

I’m a frequent public speaker. The trend of late is for conferences to record presentations and then post them publicly later. This is a great trend, as it helps preserve and spread knowledge and expertise.

It often can take quite a while for a conference to get videos posted. I certainly don’t fault them for this; video post-processing is a time- and attention-intensive task, often made more difficult to schedule due to all-volunteer staff. For one reason or another (typically self-review for improving the presentation and my delivery) I usually need access to my talk videos more quickly than a conference can provide them.

This past August I presented speaker training at /dev/world/2016. While I was there Tony Gray, chair of the AUC, taught me how to take live screencasts of my presentations using Quicktime. This was, in its own small way, life changing for this public speaker. Thanks, Tony!

Now all y’all can benefit from Tony’s wisdom. What follows below are the steps to do this yourself. Some caveats:

  • That this is possible won’t be news to a lot of people, but I’ve been doing this speaking thing for years and had never heard of or seen it from any other speaker. When Tony told me about it I had a real head-smacking “Oh, duh!” moment.
  • This isn’t going to be the best or most professional quality recording, but it’s actually better than you’d think and so far it’s always been good enough for me to share the video.
  • These steps are very specifically targeted for recording a conference presentation. Modify as necessary for your specific needs.
  • This is for macOS and Quicktime. No, I don’t know how to do it on other platforms.

And now, those steps:

  1. Set up your slides for presenting. Whatever software you use for this (I currently use Deckset), however you usually prefer it presented (mirrored or not), do that.
  2. Fire up Quicktime Player. This comes standard on all Macs. Use your preferred method for locating/opening apps (mine’s Alfred) to start up the program.
Select 'New Screen Recording' 3. Select ‘New Screen Recording’. Select this from the File menu:
Select 'Internal Microphone' 4. Select ‘Internal Microphone’. There’s a little dropdown menu next to the ‘Record’ button. You can select audio input here. Select ‘Internal Microphone,’ unless you know you have an external one plugged into your Mac and working.
  5. Click ‘Record’. Assuming everything else is ready to go (slides are ready to roll), click ‘Record’. You’d think you’re recording now, but you’re not. There’s another step first:
Select which screen to record 6. Select which screen to record. If you mirror, either screen will do. I use a lot of speaker notes, so I don’t mirror when I display my slides. Therefore I need to get the pointer to the screen which is displaying the slides (usually behind me) and click anywhere on it. And now you’re recording.
  7. Click back on your screen. If you don’t do this your slides won’t have focus so your clicker or other slide-changing method won’t work. I’ve learned this the hard way. Twice (so far).
  8. Present. Do your presentation as usual. Please don’t forget to repeat the questions from the audience. Not only is it best practice, it also ensures that the questions end up on the recording, rather than just your out-of-context answers.
  9. End recording. When you’re done speaking, locate Quicktime and click that red button again to stop the recording. There may also be a red button in your menu bar. If there is, you can click it to stop the recording.
  10. Save recording. Do the usual File > Save… dance to save the file. THIS WILL TAKE A WHILE (depending on the length of the presentation), so don’t do it if you have to close your laptop and relocate soon (like when you’re packing up and making way for the next presenter). Wait until you can allow your Mac to sit undisturbed for a while. Don’t worry: as long as you don’t shut down your Mac or Quicktime that recording will sit there ready and waiting to be saved.

That’s it! You now have a lovely screencast recording of your presentation. It will have your slides with you speaking.

After this I usually do minimal editing (trimming any unnecessary slush from either end) and then upload the video to Internet Archive along with the slides+speaker notes.

I hope you find this helpful. If you do, please send some Twitter love to my friend Tony to thank him for showing these steps to me.

You don’t get to decide what you’re “worth”

Money from around the worldFolks frequently ask me for career advice, particularly when they’re starting a job hunt. In that situation, almost all of them ask the same general question: “How do I know what I’m worth?”

This, dear friends, is the wrong question. The reason it’s the wrong question is that you do not get to decide how much you are worth.

Setting aside the uncomfortable implication that a human being has an intrinsic monetary value (we are all priceless), the truth of the matter is that the word “worth” is incomplete without the context of “to whom/what.” Where a job hunt is concerned, the “to whom” is the prospective employer, not you.

There are certain numbers which you get to decide and/or control. You should take the time to figure out how much money you need, how much money you want, and how much money you will accept. These three numbers are rarely the same, if you’re being very honest with yourself, but they are the numbers over which you have some control.

The prospective employer, on the other hand, must determine the value it believes you will provide to the organization and how much it is willing to pay for that value. This is typically a range and is the “worth” in question here. While you may be able to influence this number, you have no control over it. Your power at this point lies solely in deciding whether or not you wish to accept the worth defined by the company, not in defining that worth itself.

This distinction of who gets to define worth is very important (as are your definitions of your personal need, want, accept numbers), but I acknowledge that the entire point is well-actuallying pedanticism. I used the question of “what am I worth?” as a springboard to discuss the above points rather than focusing on the real question being asked here: “What sort of pay should I expect for this role?” That’s a horse of a different color entirely.

While you cannot control what the company offers you, it is entirely possible to get some sense of what you might be able to expect as far as pay. Note: This is a sense of what to expect. It is not going to be an accurate number but it may be somewhere in the ballpark. The reason for that is that the same role will pay completely differently based upon variables such as industry, geography, size of company, whether it’s a non-profit, whether it’s a government agency… For instance, a project manager can probably expect to be offered more for a role at a large and successful startup in Silicon Valley than at a government research lab in Tennessee.

What follows are a list of resources you can use to research what a role may potentially pay, but treat the data as suggestions rather than gospel. It’s best to check all of the resources and compare the data you receive, as it often will differ between resources. Also, these resources are good for US-based positions. I currently do not have resources for jobs based outside the US. If you know of any, please leave them in the comments.