Stage Delight: Thoughts on My First Tech Talk

White lady with pink hair speaking in front of a slide that reads "This is the story of..."

In October, I celebrated my first anniversary of becoming a software engineer. In December, I gave my first talk at a tech conference. It was thrilling and terrifying and the best kind of difficult, and part of my pep talk leading up to it was promising myself that, if I didn’t ultimately feel that all the panicking preceding it was worth it, I never had to do it again.

Instead, I came off the stage, waited for my heart rate to return to normal, and thought, That was fabulous. I came home that night and started a doc to collect future talk ideas I might come up with.

In the way of any process nerd who loves a post-mortem, I’ve been thinking about what worked and what didn’t. Here’s what I learned from my first foray into speaking in this particular professional world and what I wish I’d known back in November.

Start with something you already half know.

It’s a pretty common trick to pitch a talk based on something you want to learn, as the impending obligation will make damn sure you do the thing you committed to doing. However, if you’re just starting out, take it easy on yourself – pick a subject you’re already at least fairly familiar with.

My topic originally came from one of my bosses, who knew I’d been reading a man page most workdays in an effort to get more adept at the command line and Linux in general. (Which, in turn, was a great idea suggested by a wise coworker. Highly recommended, and I’ll be writing more about it later.) Said boss tipped me off to the surprising history of the formatting tool behind man pages, mentioned that this exceedingly appropriate conference was coming up, and gave me the nudge I needed to submit a proposal.

If I’d needed to start by figuring out just what the hell a man page was, the challenge would have been too daunting to feel attainable. Instead, I had already read several dozen man pages and had a sense of their structure and tone, plus some opinions about what parts were most effective for helping me with my work. With that basic learning out of the way, I got to focus on the fun part of learning the background and making it as interesting to other people as it was to me.

Write a blog version of your talk. Seriously.

When it comes to things like writing and online promotion, I have skills that give me some useful advantages. In my past professional life, I was a writer, editor, and content strategist, and I spent more time than I liked using social media in a professional context. Because of this, writing an accompanying blog post while I was finishing my talk took relatively little additional effort, since the research and structure were already there. With that part finished, writing a fairly lengthy prose version of my presentation was a no-brainer for me, since a lot of the work that would usually go into an original blog post was already done.

This isn’t true for a lot of people, I realize, because most people didn’t spend more than a decade dashing out thousands upon thousands of words about hotels and waterparks and white noise machines and content marketing practices and travel destinations and many, many other subjects. I’m uncommon that way, and I recognize that.

However, even if writing is difficult for you, writing something to accompany your talk can give you a remarkable return on the energy invested. Even just enough paragraphs to hold all the links in your bibliography is a worthwhile resource for someone looking to learn more about your subject.

In my slides, I provided the short URL for my company’s blog and pinned a tweet with the post link on Twitter. On top of that, my talk title and my name were on every slide, and I started and ended the presentation with my Twitter handle.

The day of the talk, I’d intended to put my phone in my backpack when I went onto the stage. Instead, in the sweep of adrenaline after I got miced up and ready to go, I left my phone tucked in the bodice of my pocketless dress. About a minute into my talk, my phone began buzzing, and it rarely stopped for the entire 19-odd minutes of my talk. It was only after I was finished that I got to peek and see what was up. I had been quietly hoping, as I talked, that there hadn’t been a death in the family, or a disaster in San Francisco, or any of the other darker events that usually make a phone blow up at 9:45 am on a weekday.

But no: it was TWITTER. Follows and tweets and retweets and likes, my talking points spread far and wide, my tidbits turned hashtags, and that pinned tweet with my link in it racing steadily from conference-goer to conference-goer and beyond.

It was so much more than I’d even dared to imagine. I’d written the post because I dislike when a really interesting talk proves ephemeral – a hashtag and a hastily photographed bibliography slide, and then all that might be left is a title listed on a conference website. It’s a bummer when someone put the effort in and made a really memorable, effective talk, and all I have to show anyone else is a blurry slide photo and maybe some quick notes.

So I wrote it for people like me, who like to be able to revisit what was discussed and to click links rather than transcribing, to command-F instead of clicking around a video. I also wanted some artifact of my work on my company’s blog, as my bosses had very kindly allowed me to do a lot of talk prep on company time.

And it was worth it. My company’s site got more hits that day than we had in the twelve months prior. (We’re wonderful, but niche for sure.) A few weeks later, I had my own work recommended to me on Twitter by someone who didn’t remember my name as a speaker but did remember my talk.* Recently, I looked up “man page history” to learn about the -c flag for the history command, and I found that, even in an incognito window, my talk was the sixth result for that search. WHAT.

So, if it’s at all within your powers to do so, write up your talk. Publish the day of or the day before, and have tweets ready for yourself and your employer, if you work somewhere that does Twitter. Make it available on your slides and on your social media. Make it accessible. And if you can’t write it? Consider doing a skill trade with someone or even hiring someone to write it for you. Don’t know any writers for hire? Contact me, and I can put you in touch with someone who will make your work shine. The cost of the work of a good writer, correctly used, is very often a bargain.

Get advice from an accomplished speaker.

Maybe this is my other cheat: one of my bosses is an especially experienced, very skilled speaker and has a lot of clear, tested advice around how to approach it.** I got to sit down with him for an hour early in my talk creation process and get his suggestions on how to prepare, how to work with the conference staff, and how to make the day of go as smoothly as possible. A few things I wouldn’t have known otherwise:

  • Do a brown M&M test: ask your contact if there’s a prep room, how their AV will work, if they have a provided deck template to work from, what kind of microphone they’ll be providing, and when you need to arrive – among other logistical questions. You need to know these things, but it’s also good to know if they don’t know them yet. This lets you better prepare both yourself and your expectations. If the people running the conference are inexperienced, your questions could provide some structure for their plans. Win/win.
  • Do a little cardio (a quick jog down the conference hall, jumping jacks) just before so that your body has a good reason for your heart to be racing a little. And lay off the coffee until you’re done.
  • Make sure you have some kind of timing advice available – and bring one even if the venue promises to have one.
  • Put time markers in your slide notes so you can tell that you’re keeping the right pace in the time allotted.
  • Try to get a friend/plant in the audience so that you have a friendly visual focus, feedback, and prompts if needed.

I’d done one talk before but in a pretty different context, so I had no way of knowing these things ahead of time. A little expert advice spared me a lot of uncertainty.

Do multiple test runs. For humans.

I practiced my talk for two solid weeks leading up to the conference. In order, here were my test audiences and what I learned from each.

  • My cats: I could string the sentences together well enough, and my jokes felt ok to say. (This was me running through my slides in my apartment over and over until I felt a rhythm begin to come together.)
  • One coworker: the Keynote theme I’d chosen included slides with grey text on a black background. This was very hard to read (and just in time to fix). Doing a test run earlier on also lets you test out storylines and interest in your material before you’re fully committed.
  • My entire company: I needed more confidence in my jokes and to give them time to land – my usual deadpan understatement was not working for this talk. Also, I needed to stop putting my hands in my pockets.

It’s hard to hear criticism, but it’s a delight to get feedback at a time when you can still do something about it. Find your critical audience and have at least a couple tries when you still have enough time to course correct.

Not everything is riding on this one time.

I am very pleased with how this all turned out. It was a lot of work, but it was enormously rewarding, and I got to feel a sense of professional community I hadn’t experienced at that point. I still get to have surprise conversations with online strangers about man pages. That said, there are still things I’ll be aiming for in my next talk, such as:

  • Better memorization and the ability to speak more freely without glancing at my notes. Memorization is really hard for me, but I admire the fluidity I see in other speakers who have clearly done the work. I want to be able to give that to people who might hear me in the future.
  • A little more lightness. While my delivery did what I needed it to do, I found out later that I came across a little more grave than I intended. This is understandable, considering, but I’m a pretty animated and cheery talker in regular life. I’d like to bring some more of that to the way I speak to groups.
  • More practice and ease. I want to find a local Toastmaster group for some more regular experience with lower stakes, so I can continue teaching my body that I am not going to die of public speaking. Leading up to the talk, when friends asked how it was going and how I felt about it, I told them, “So long as I don’t die, it’ll be a success.” Now I know; I just need to get my body to trust that this really is true.

And the great thing is that I work at a company that encourages speaking in a field that’s hungry for people willing to talk out loud and teach. I’ll get more opportunities – and be better equipped to iterate, improve, and get closer to the skill level I’m aiming for.

If you’re tempted, do the thing.

As I mentioned, I have a background in content marketing, so blogging has always been a part of professionally establishing myself, and it was a particular goal as I got my bearings as an engineer. I figured that I wanted to try to speak too, since it’s a pretty natural extension of presenting ideas in writing. But I thought I’d get a steady clip going on this blog, start getting comfortable exploring and explaining ideas here, and then begin to play with the idea of talking – you know, in time. We do internal talks at my company specifically for that kind of experience, so I figured I’d start there and maybe branch out to local meetups. Go from there. Right?

Then a bigger opportunity came up faster than I expected. But if that hadn’t come together, I would have targeted local meetups. I would have talked internally. I would have organized or participated in a talk night with my school’s alumni group. I would have done it somewhere, and I would’ve been nervous then. And it would have been ok.

If you’re inclined to talk, just do it. There are enough groups, particularly in tech-oriented cities, that someone wants to hear your explanation of whatever it is you find interesting. You’ll also probably meet some rad people while you’re doing it.

A few helpful things for you.

This post from Heidi Waterhouse about how to dress as a speaker is useful in all the ways I usually find “how to dress” articles aren’t. (Most “how to dress” articles are not written by people with hair of a hue similar to my own, for a start.) Pragmatic and with an aim toward natural comfort, this article had enough information that I referred to it several times throughout my talk prep, particularly for advice on dressing around different types of microphones. Read it and avoid unnecessary surprises.

Technically Speaking provides a weekly dose of speaking encouragement and opportunities. The women who run it are smart and opinionated, and if you’re interested in this, it’s a wonderful addition to your inbox. And if you’re considering speaking? (And I hope you do.) Meetup can probably connect you to a group that would be interested in your subject.

And with that, I hope I leave you better off than I was at the start of this odyssey. If you’re interested in something, you probably have something to say about it. I, at least, would love to hear it. :)

*Incidentally, this was not mansplaining - it was communing about a mutually interesting subject and a pretty rad compliment. 

**Actually, that's true for a few people I work with and for, but Everett just does MORE of it. Truss has a rad speaking culture, and I dig it.

11 Lessons from My First Year in Software Engineering

Paper garlands against a twilit sky

I hit my one-year anniversary as a software engineer in October. It has been, professionally, one of the harder, stranger years of my life, but the challenges generally were exactly what I hoped they would be: complicated, but with clear questions, and answers that were a pleasure to seek. That said, there are a few things I wish I could whisper to my past self, either right when I was starting this job, just as I was starting Hackbright, or a couple of years ago when I wrote my first lines of Python. Here’s a bit of advice to my past self, to anyone who’s considering this journey, and to anyone who’s still fairly new and would like a little reassurance.

1. Everything I heard about learning this is true (or: no, really, just pick a project).

If you want to learn programming, you do need to just pick a project and proceed. I really disliked this advice when I first heard it, because I am all about context, and I couldn’t imagine picking an appropriate challenge without knowing the limits and possibilities out there. And that’s a legitimate concern – it’s crucial to pick the right-sized problem, so far as complexity and the number of tools it will require, if you’re going to learn without getting so frustrated that you quit prematurely. Even so, it’s those raw edges, that unpredictable stuff, that gives you the real learning, that can be the most educational (and most satisfying) to wrap your brain around.

My real, substantial learning on this job began when I was put on a project, which didn’t happen immediately after I was hired. I had learned things before then, self-studying along in the office, but it lived strictly within the realm of the hypothetical (something I consider likelier a limitation of my own beginner state than anything else). Learning within the context of a project can be kind of like memorizing a poem by hearing every fifth word, and out of order and occasionally in a different language to boot. However, what you do learn will be practical and actionable, and – perhaps most valuable of all – will provide the context around what happened and what you need to do. And eventually, you’ll know a lot of it – and be able to intuit or sleuth out the rest.

My suggestion to you: it’s annoying how much it’s true, but I’d suggest just giving in (and finding a good advisor for picking and shaping your project, if you can). Find a practical problem in your own life and decide a way to start addressing it. If you get stuck, it’s a big, generous internet out there, and some of the people in it will even have right answers. 

Bonus suggestion: consider making a command line utility. It has a delightfully low barrier to entry and gives you a great chance to make something useful to you without worrying about deploying or front-end work. If you’re a Python kid like me, start by looking at argparse and then let your imagination run away with you. 

Bonus bonus suggestion: many programming communities now have Slack networks that are open to the public, if you request access. If you know you’re interested in a particular language and want someone to ask questions to, see if there’s an active Slack channel for your area of interest. The availability of DMs and the more regulated, curated nature of most Slack communities can make them friendlier to beginners.

2. Learning is a skill. Learning this is a different skill.

Computer science’s history is relatively short, but it’s some dense archeology, if you’re trying to wrap your head around even the most essential central stuff. Some people get to be immersed in it for four years before they’re thrust into the workplace; the rest of us get to pick up on useful commonality when we start playing with our third programming language. (Though people like Gayle Laakmann MacDowell have said that this is far from an insurmountable hindrance.) The good thing is that each new skill you learn will require slightly less origination and effort and will build slightly more on things you’ve already learned.

However, this growing knowledge will never reach one hundred percent, regardless of your background. If you plan on staying in this field, you have to learn to love at least a little constant disorientation. If you aren’t confused on the regular in your first couple of years in this field, you’re not trying hard enough.

My suggestion to you: learn to love feeling like your feet aren’t quite firmly planted beneath you, because it means you’re in the learning space. Disorientation means you’re surrounded entirely by new things to learn. Eat it up.

3. Any dregs of self-consciousness and admitting ignorance will either go out the window fast – or you will remain bad at this.

My company is largely remote four days a week, and I was, for a time, the only engineer in our central office. This meant that, if I had a problem and my manager wasn’t available, I had to go into a public Slack channel to seek help. This eased in time, mostly as I got to know my coworkers better. But until I got to that point, every question I asked felt like broadcasting my ignorance to the company, who only knew me as the inquisitive little Slack avatar. HEY LOOK AT ME HERE’S THE THING I DON’T KNOW OF THE HOUR.

That is, until I stopped caring because I understood that no one else cares. And beyond that, it’s as true here as in any other field that the best time to ask basic-ass questions is toward the beginning, when they naturally occur, before you start eroding the foundation you’re trying to build. 

My suggestion to you: breathe deep and get over it – or pretend to until it’s true. Admitting you don’t know something is a vital part of being good at this job, because there’s no room to bullshit. Any fudging you do will be revealed later, and most likely at a really annoying (and embarrassing) time.  

4. Useful experience is less about exhaustive knowledge and more about navigating new situations and tech.

Expertise can sometimes be demonstrated by knowing who wrote what language, what the most vital book is about a subject, or the history of the specific design decisions and needs that went into a framework. But this is surface trivia, and what’s most important (to me, so far) is context and the experience that provides it. It’s still the thing I crave most often, when I find myself in those disorienting moments where I don’t know the answer and am not even entirely certain of the right question.

It can be extra frustrating because I don’t just want to know how something works. I also want to know the situations where considering that thing as a solution on a project is appropriate, what would inform that recommendation, and what you heard about its past releases and future plans that might make everything terrible in six months.

I felt this basically constantly at the beginning and now, fourteen months in, I still feel this way pretty often. I choose to view it as still finding this field incredibly interesting. I can’t imagine what being bored or plateauing would look like in this job because there is always, always more stuff. And, after a while, you’ll have experienced enough of it that you’ll know better how to navigate the next big thing. 

My suggestion to you: hang in there, mostly. And just be willing to try things, volunteer for new projects, and get all of the experience you can – within reason.

5. My sense of curiosity is a valuable job qualification.

I have, in the past, annoyed lesser bosses by asking why. When I asked, I wasn’t questioning their judgment – or not usually, anyway. What I needed was to understand what went into a given decision, so that I could make my own decisions to support it appropriately. (Yes, it does make sense that I have user research in my background too.)

This quality is really useful in this job – in fact, in a well-functioning environment, I’d call it essential. It’s particularly so when you do consulting for clients, as my company does. Sometimes we serve them better not by doing exactly as they request but by asking why enough (and politely enough) to find out what it is they really want. From there, good work actually gets done.

My suggestion to you: your beginner enthusiasm and curiosity are valuable tools. When you don’t take anything for granted, you can notice things more seasoned engineers don’t. If something isn’t clear, ask about it (even if only privately to your boss) until it becomes clear.

6. Sometimes the tool is broken. Not you.

Early last year, I was doing some experimenting with AWS on my own at work, going between the command line and the web UI to launch instances, tailor and tweak them, and get used to the interaction between different aspects of the tool. But for a few weeks at the very beginning, things just didn’t work right. I’d follow a tutorial, enter a command, and – what even the hell? Trying to spin up an instance would fail. Security groups wouldn’t work right. And, worse still, I was so new and the failures were inconsistent enough that I couldn’t deduce any logic from what was happening. I was failing and didn’t feel like I was learning from it, one of the worst feelings. I rarely have reason to wonder if maybe I’ve been secretly stupid all along, but in that handful of weeks, I’d stop sometimes and wonder if engineering was finding some sad new quality of mine that had been hiding throughout my career.

Then another senior engineer got hired and had a little time before being put on a client. He found that our AWS account was old enough that it worked differently than more recently created ones do. He made a new account. Suddenly, tutorials made sense, and my results were predictable – including my errors. I was so relieved I had to stop and stare into space for a few minutes to absorb it all. AWS and I are friends now, despite our rocky start, but I would never have figured this out on my own.

My suggestion to you: sometimes the problem is between keyboard and chair, sure. But sometimes it is not. Ask questions, pair with someone, and make sure that someone who knows more than you witnesses your sticky moments sometimes. It’s ego-deflating, but it’s better than spending days or weeks flailing in some swamp that isn’t of your own making.

7. Timing is everything.

If you have even a semi-active sense of curiosity, you can spend endless amounts of time reading docs, essays, StackOverflow speculation, comments, comics, reviews by the competition, helpful blog posts, amusingly bitchy blog posts, and so many other things that may be very useful, completely useless, or – worst of all – approximately 29 percent useful. It’s that last one that can eat your afternoon. If you aren’t aware of this particular hazard, you can lose an hour or four much more easily than you might have ever suspected.

My suggestion to you: timebox that shit. And if you have access to someone more experienced than you, work out a relationship where you can come to them pretty regularly for reality checks and course corrections before you sail yourself deep into the ocean of chatty, chatty internet people. It’s ok to ask a more senior person to rule out some obvious stuff before you dig into researching your problem.

8. Unless the docs are shit, trust the docs.

(And if the docs are shit, should you really be using the thing it’s documenting at all?)

I realized recently (thanks to talking with one of my bosses; see the previous section), that I’d developed a habit I’ve nicknamed narrative research. I’d come to believe that the most efficient way to work through problems was to try to match my problem to someone else’s phrasing, find their solution on this or that third-party site, try to get that solution working to fix my problem, and then work backward to find out why what I had done worked, to learn a larger lesson from there.

Perhaps you’re already seeing the problem here.

If the tool you’re using requires the backassward methodology of someone in a completely different context than you to get it to work, it may be time to examine if you’re using the right tool – or, perhaps more likely, if you’re doing it right at all. You can stir your coffee with a screwdriver if you really want to, but there are better ways to use it. If you have a problem to solve, research just enough to find what library or whatever it is you need to use – and then use its own documentation. Don’t work off-label unless you really need to. Probably check with someone more experienced, if you really think this is a good idea.

My suggestion to you: there be dragons in Stack Overflow sometimes. Stay with primary resources as much as you can.

9. If you’re a person who does the caffeine thing, get your coffee game down.

I most often need one between three and four pm, just to perk my brain up to get through the rest of my day. A single Americano is a great way for me to address this. Recently, I messed up and overcaffeinated myself via the rookie mistake of using a bigger glass than usual for my cold brew. I spent the afternoon sweaty, with racing thoughts. Not a good look.

This is general life advice too, but I’ve found it more critical in this job than any other. It may seem surface, and maybe it is surface, but having your biological needs in check will let you do better at this.

My suggestion to you: know thyself.

10. Don’t be a hero when you’re sick.

This is especially important for me and my consulting colleagues who have a vested interest in quality billable hours, but: if you’re sick, be sick. Don’t soldier through. (And not just because of the obvious part about not being a disease vector. Seriously, stay off my BART if you’re ailing and have sick time to use.) If you feel like shit, you’re not going to be able to brain, and this work requires a functional brain more than any other job I’ve had. The others could be difficult too (especially the UX consulting gig I had just before I went to engineering school), but it’s just… different. Pack a snack, sleep enough, and pay attention when you’re sick.

My suggestion to you: be an adult and be honest with yourself. Sleep enough, eat enough, and stay home with pho from Seamless if you’re under the weather. Treat yourself like you’re parenting a toddler – you know, honest assessments. Sometimes you just need a snack; sometimes you need to stay the hell in bed.

11. And, finally: decency counts.

This is an industry riddled with social fuckery, and even people who found it worthwhile to stick it out usually have at least a couple really vile stories of colleagues and managers acting like total assholes. I work in a magical unicorner of the industry that’s largely free of that, but – get this – I still get points just for being housebroken and friendly enough that it’s pleasant to share space with me. It still seems to be considered remarkable in this industry (though it’s a requirement to work at my company). Can you treat a troublesome team with human decency? Can you be polite and keep it together even when you’re having a bad feeling and not getting your way? Do you have a regular life, and can you make nice chit-chat about it without it being a big thing? Congratulations: you have an important skill.

Beyond that, social stuff in tech is just different than it is in other industries. I’ve always been lucky enough to have coworkers I wanted to be friends with too, but there’s a certain all-banding-together kind of feeling in tech that I haven’t seen anywhere else. In some companies, it’s a natural side effect of putting a bunch of 22-to-29-year-olds with a shared predilection for alcohol in the same space for 60-plus hours a week. But even then, it has a function – when stuff gets hard, that empathy and caring and shared knowledge comes together, and everything functions better.

My suggestion to you: be cool, honey bunny. And, even if you have limited social energy (I certainly do), try to conserve some of it to spend time with your coworkers once every week or two. A lot of people are lovely, and the stuff about being a good member of a team is easier if you’ve taken a real interest in the people around you.

There you go, new engineer. There you go, Breanne of a year or two ago. And here are a few more resources that I’ve found really useful in the last year. I didn’t even write all of them myself.

  • How to edit your PATH variable (and what PATH is): I had the hardest time getting an answer to this, which was tough when I was already learning a lot about how a computer works when you’re not just using it to dick around on the internet. So I pestered my coworkers for answers until it felt coherent and wrote it down. I hope it helps you too.
  • 7 Things I Wish I Knew Before Starting at a Developer Bootcamp: my friend and coworker Emily Chen wrote this, and I really wish I could teleport it back to myself in spring 2015. Why this isn’t a prereq for every immersive programming school, I do not understand.
  • The rad illustrations of Julia Evans: always thorough and yet always approaching subjects from a unique angle, her illustrations are such a nice companion for whatever you’re learning.
  • And, just, you know what? Wikipedia is the shit for computer science stuff. Surprise! There’s a lot of legit documentation out there (ahem, man pages, ahem), but Wikipedia is so often a great place to start, and seeing unfamiliar stuff laid out in a familiar format can be really helpful if you’re stumped.

Restoring Github Repo Access in the Terminal after Adding 2FA

Molding, windows, and walls of central room of Oakland's 16th Street Station

This is the second time I’ve had to look this up, and the instructions are spread across a couple of pages. So for the sake of my future self, I’m compiling the steps here. Maybe it’ll help someone else too. That’d be cool.

So you added 2FA to your Github account. (Very smart; nice job.) Problem: your terminal no longer accepts your (still valid) password when you’re trying to push to a repo. Here’s how to fix that.*

1. Create a new personal access token.

Go to Github and ensure you’re logged in. (An aside: you’ve saved your access codes in a password manager or some other secure place in case the device you designated for 2FA authentication codes catches on fire, right? Excellent, carry on.)

Go to the upper-right corner of the page, click your profile image, and click Settings. In the sidebar of the next page, scroll to the bottom and click Personal access tokens. Click Generate new token. Give it a name that will make your future self grateful for today’s clarity. Select what permissions you want this token to give. Then: Generate token. The token that appears will only be visible right now, so make sure you save it or do what you need to do with it. (Or save it to 1Password and then proceed to the next step.)

2. Save it to your OSX keychain credentials

Here’s the choose your own adventure part: do you have Github credentials saved for more than one Github account on this machine?

2a. Nah, just one. Let’s nuke it and replace it.

Cool, let’s get rid of the old credential first. Go into your terminal and type this:

git credential-osxkeychain erase

There’ll be a pause and then nothing. That means success. (I still find this convention strange, but I like a verbose interface, so that’s my own struggle to deal with.)

Now, do that push that you were probably trying to do when you realized you’d cut off access on a machine you perhaps don’t code from so often. It’ll ask you for your username and password. Give it your username as usual, but instead of your password, paste that Personal access token that we created in the last step into the terminal. Hit enter. Wait. Enjoy your success (which will be confirmed by a message this time).

2b. I’m super cool and access SO MANY accounts. Let’s just replace one, please.

Alright, fancy. For this one, we’ll start with the Keychain Access app instead of the terminal. (Don’t worry, we’ll finish in the terminal for this step too, if you prefer.) Open Keychain Access and then type in “Github” to narrow down the options listed. You’re looking for an entry for github.com. To confirm you’re looking at the right one, ^click and select “Get info” from the menu that appears. Confirm that the username you’re looking for is the one listed under account, then select Access Control and confirm that the option listed is git-credential-osxkeychain. If those two things look right, we’ve found the right credential.

Now you can edit it there, replacing the existing password with your new token, or you can delete it and provide the new credential via the terminal when prompted after you try to push again, as described in 2a.

There you go! Such security, what authentication.

Want to double-check my work? Here’s what I used to put together these steps (both times, because sometimes that’s what it takes):

And if you haven’t set up 2FA for Github yet, my god get on that ok wow with the instructions here.

*On a Mac. That’s the context here. Mac Mac Mac.

Header image is from my recent visit to Oakland’s 16th Street Station, which is usually closed up. In this case, my access was granted by paying to be part of a photo tour. Authentication comes in many forms. 

 

New Post on PATH for My Company Blog

A path in Skogskyrkogården cemetery in StockholmAnd surprise surprise, I ended up at a company that’s as almost as excited about me blogging about software engineering as I am. I published a post for them a few days ago about working with your PATH, what the PATH system variable is, and how to access and change it.

This was a bit of an enduring mystery for me at Hackbright – this vital thing that comes up in so many tutorials but which so many smart, willing people had a surprisingly hard time explaining. I started thinking of it as everything and nothing, the alpha and the omega. 

Late last fall, gainfully employed and feeling sillier by the day for not having mastered this important concept, I began a campaign of badgering my coworkers on Slack until I cobbled together a working explanation of what PATH is and what you might need to do with it. One coworker noted, after publishing, that this is a bash-specific explanation (given the system files I mention), and he is of course completely correct.

So do check out my bash-specific PATH tutorial, with the expectation that you people who use zsh and other fancy-pants shells will have to do a little adapting in your head. I’m sure you’re used to that anyway.

The photo is one from my recent trip to Sweden. I like to visit cemeteries when I travel; this is a photo from Skogskyrkogården, which was beautiful and worth a long-ish metro ride.

Python with Flask and PostgreSQL: “Is the server running on host “localhost” (127.0.0.1) and accepting TCP/IP connections on port 5432?”

My beautiful errors when I encountered a certain server error with PostgreSQL and Flask

This one goes out to the new people who are, as I described myself a few minutes ago, “still building context.”

This error is not this. This error is not that.  This is error is that you, perhaps like me, restarted your system recently and didn’t restart Postgres.app.

“I can’t reach the server,” it says. Maybe you, like me, will get stuck on the port thing, thinking that server.py is having some new and terribly exotic error. Server.py is running. What is its problem? It’s RIGHT THERE.

No.

Restart your database server. (Or, y’know, start it.)

Then change your preferences so PostgreSQL starts after login for the duration of your project.

You’re welcome.

This blog post is brought to you by me wishing that I’d found the perfect, straightforward answer to this simple-ass question. Port 5432: not a part of server.py. No, it is Postgres. Just Postgres.

Now you know. Get it.

For Google fu, here’s the relevant text of the screencap above:

OperationalError: (psycopg2.OperationalError) could not connect to server: Connection refused Is the server running on host “localhost” (::1) and accepting TCP/IP connections on port 5432? could not connect to server: Connection refused Is the server running on host “localhost” (fe80::1) and accepting TCP/IP connections on port 5432? could not connect to server: Connection refused Is the server running on host “localhost” (127.0.0.1) and accepting TCP/IP connections on port 5432?

git status-add-commit, git status-add-commit, git status…

We had a field trip to learn about Firebase at the Google office last week. The presentation was great, but then... this view, this view. Mmph.
We had a field trip to learn about Firebase at the Google office last week. The presentation was great, but then… this view, this view. Mmph.

Consider this picture your moment of zen. We’re about to dive into nightmare territory.

In the first week of class, I was pair programming, and we’d reached the point (one of fairly dozens that day) of editing and troubleshooting. We use Sublime Text 2, something I’m fairly used to at this point; what I wasn’t used to was Ubuntu. I hit an F key without meaning to; suddenly, our window maximized, and neither double-clicking nor dragging the top bar of the window down made it shrink. The maximized Sublime stared at us from two mirrored monitors, waiting.

So I began tapping the F keys again, one by one, thinking it would ultimately undo what I’d done, and I might learn a couple shortcuts too. This is a practice that has served me fairly well for the last 20-odd years, with not a casualty to speak of.

Til that day, anyway.

Somewhere around F-8 or F-9, all of our lines of code rearranged themselves. Instead of our 40-plus lines of tidily indented work, they had formed a perverse pyramid, blank rows at the top, and the rest below in order of descending indentation, alphabetized within those length blocks. Under the edit menu, undo was greyed out.

I think – I think – that I managed not to actually say “What even the fuck?” in front of my pair. (We were all still using people manners then; now there’s a post-it in one of the bathrooms telling you to drink more water, lest you get constipated, a problematic situation the post-it writer knows very well, ok?)

I called over my advisor, explained the situation, and watched as she tried a few of my steps again. No undo. No solution. Nothing.

She frowned and said words that were not meant to be an indictment but were nonetheless: when was the last time you committed?

It was about 5:50 pm. We’d last committed after we’d finished our last exercise. You know, at 1 pm.

“Well,” she said finally, rising from the keyboard. “You learned something.”

“I did,” I told her. “And I’m not – well, I’m not proud. But it’s not often that a person really manages to break something beyond repair with computers. It’s… notable.”

She shrugged and went to help less hapless people. I apologized profusely to my pair, who was altogether lovely about it.

I thought for a moment and closed Sublime. I counted to three and reopened it.

Our properly ordered, fully functional Python file was restored.

I’m not sure I took a whole breath in before I completed a commit on it. And now I, like all of us in our time, am a committing zealot. Early, often, excessively.

I don’t recommend being an anxious person. But for certain qualities? I totally recommend hiring them.

UX-Centered Development: Making a Pre-Planning Survey

Here in week five, I have firmly established myself at Hackbright as the person with a UX background. (I have probably also established myself as the person who would like to tell you again that she has a UX background.) To give myself an exercise in applying my older skills to my newer ones and to approach this project in the way that I know best, I’m planning out a Very UX-y Hackbright Final Project.

Step one is a survey. Because of the limits of my time and budget (as in, I’m not paying anyone for this, and I do believe UX participant work should be compensated – at least if someone is making money from the product using the results), I knew I wouldn’t get anything resembling a scientific sample. Even so, I knew I’d feel better prioritizing my semi-planned product features with even a general sense of how people who are not me would use a web app like the one I’ll be producing through August.

In this post, I’ll explain how I came up with the idea, why I find it interesting, how I decided to use a survey to verify and prioritize my feelings as the unavoidable first user, and the principles I used to craft my short, very to-the-point survey. Read on.

Fish Waffles and Inspiration

My plan from the beginning, from before Hackbright was a possibility in my mind at all, has been to create a food truck tracking app. I came up with this idea in Seattle last year, sitting on a grassy slope with my boyfriend, eating a fish-shaped waffle. I’d never seen a fish-shaped waffle before, let alone knew they were something I could buy from a van within the city I’d occupied for nearly a decade. This bothered me, because I like to think I know most of the awesome things the places I live have to offer. Why wasn’t there an app for this? Why wasn’t this information more accessible, considering the ways I do research?

I originally thought of a mobile app, and I still have some interest in eventually going that direction with my work. We shall see. But when I was accepted to Hackbright and learned more about how their curriculum works, I never doubted what I would do. I would build the food truck web app that I wanted to see in the world.

Before we get into the actual coding part (oh, next week), I’m going to do as much research as I reasonably can. I’ll soon be reviewing the existing apps out there, web and mobile, to see what features are considered typical and expected, what information’s out there, and what seems to be working. But first: my survey. I kept it simple so that I wouldn’t be asking too much of people’s goodwill. This is a fairly central tenet of UX research done without participant compensation: make it fast, make it easy, and thank profusely. (Or maybe just a fairly central tenet of being a polite, respectful person asking people for favors.)

The Survey and My Strategy

I used a Google Forms survey to do this, passing the link via social media and hoping my friends would both take it and share it. (Many of them did. Thanks, friends.) I explained the scope of my project (that it’s for school; what the school is) and said some more grateful things because I was and am grateful.

The Survey Itself

1. How often do you eat at a food truck?

-Once a week

-Once a month

-Once every six months

-Once a year

-I’ve never eaten at a food truck

2. How do you find food trucks to visit?

The truck’s Facebook page

A mobile app

A website

Friends

Find them on the street

At a gathering or festival

Other

3. What do you need to know about food trucks to plan a visit?

Type of food

Prices

Location that day

Schedule for future

Method of payment

Other

4. What features would you like a food truck tracking app to have?

Text listings with search

Search by food type

Search by price

Links to truck social media or websites

Other

These were all required. The following were open-text fields and were not required.

  • What is your favorite truck, and what city is it in?
  • What is your favorite food truck-finding resource?
  • What is your favorite app or resource for finding places to eat? 
  • What’s the best food truck pun name you’ve ever heard?

I got 127 responses. Not bad! I’d decided I’d be pretty thrilled at 100.

How I Made My Choices

Here are a few things I considered when putting this together:

  • I wanted to be as brief as possible to avoid having people open the survey, think, “Oh hell no,” and close it without completing it. I’m pretty generous with my time on student surveys (UCD school will do that to you), but I have definitely said nope to too-long ones.
  • I wanted a clear picture of feature/information priorities, hence the “choose all that interest you” and “choose the most important one” questions.
  • I wanted to be able to correlate feature/information priorities to frequency of food truck habits – a person who has been to a food truck once will probably not have as clear a view of the relevant information as someone who seeks them out regularly.
  • I included other fields to ensure that respondent options were not limited to my own possibly incomplete view of the relevant information and features.
  • I wanted to expand my list of sites, apps, and other resources to look at as I get deeper into planning my project.
  • I like puns and like including an open opportunity for survey respondents to have a little fun.

What’s Next

I’m currently working on a Python program that will tally my responses. It would probably be easier to just use Excel or certain other existing tools, but I want the practice, and I get to have some fun with classes and objects while I do it. So: CSV and my own Python efforts it is. Coming up, I’ll post about my conclusions and observations and how it effects my features list and how I set my priorities.*

*Aside from the simple question of, “Can this fit in five weeks?” and “Is this strictly relevant to what I want to learn and demonstrate that I have learned?”

P.S. The image is from the book that gave me the first exposure I ever had to food trucks. As I recall, totally worth the time.

I Hate Pair Programming; I Must Pair Program

Cartons of cold brew coffee from Blue Bottle
Pair programming at 5 pm? Better grab a couple of these.

I knew before coming to school that the Hackbright day leaned heavily on pair programming. During the first five weeks, days unfurl like this:

  • Lecture
  • Pair programming
  • Lunch
  • Lecture
  • Pair programming
  • Break
  • More pair programming
  • Profit? Or collapse onto BART. One of those.

I am told that it’s not a super common practice for tech companies, or at least not outside of training or special projects. But I know that people learn better if they have to learn, discuss, and then teach. I know that the general level of knowledge in the room rises if we have to work through problems together, combining what we know to make a greater, more effective whole. One of the reasons I decided to go to a school like this is that I have a well-documented tendency to read about how to make this loop or that data structure, nod to myself with some satisfaction, consider it learned, and move on.

That is a great way to learn some vocabulary terms; it is a piss-poor way to learn programming.

And it’s part of why I decided to go to school rather than going my usual autodidact way. I knew that, with the structure of school and the requirements of a major final project, I would have to read, digest, and then practice. I wouldn’t really learn anything otherwise. And that meant pair programming, with its constant verbalizing, sharing of knowledge, and immediate application of what we’d learned in lecture. Sounded great to me. Sign me up and tell me where to send the deposit.

I was right about every bit of it. Pair programming is a stellar communication tool, and, when paired with available expert help, it’s like having your own half-a-tutor. You learn things from them; you have to explain things to them. You really learn.

That said, I’m pretty excited to get to the second half of my program, because it means less pair programming and more time slogging through my project by myself. And it is absolutely not because of the people I’ve been paired with, who have all had good manners and and the good grace to teach me things.

I hate pair programming because I am a hard introvert with only so much social energy in a given day. The first week at Hackbright, I met about 40 new people, found myself in a new city where I have only two friends, and also had to talk through assignments with a near-stranger for close to four hours a day.

I’m surprised I didn’t actually melt into an Odo-like puddle in a bucket.

I’ve kvetched about this to my advisor. To friends. To fellow exhausted Hackbright students. And yet I’d never advise them to change this part of the curriculum, because I really can’t think of a different, better approach.

Instead, I’ve just dialed back how social I am. I have more lunches alone; I take quiet texting breaks. I don’t go out very much. And it’s a bummer, because I have access to 34 other aspiring software engineers, and so many of them are so very interesting.

But I can hear their life stories while I eat my reheated pizza, or I can have brain to solve programming problems. I can’t have both. So I retreat and read, and I use my social energy very carefully.

And I hate pair programming.

But I’m grateful for what it’s going to give me.

P.S. If you want some legitimately useful pair programming tips, cohort friend Noelle has some for you.

To Be a Gold-Plated Unicorn: From UX to Programming

A stuffed balloonicorn and cups of champagne
Part of week one’s social

Five days a week, I go to class with scientists and electrical engineers and nurses and artists and people from fields in between and beyond. People at Hackbright take a lot of different paths to get there, which is one of my favorite things about the people you meet at continuing ed programs: the people are always so varied and so dedicated. The common ground at Hackbright is the thematic stuff, and it usually goes as follows:

  1. The Hackbrighter wants to get paid.
  2. They want to be sought after by employers who want to pay them.
  3. They want to work on something that matters rather than feeling perpetually on the periphery.
  4. They’ve always had some kind of technical ability or affinity and would like to see where it could take them.

I’m no different. I came to Hackbright from a background of online content and, later, UX and usability; my last job, which I adored, was UX content strategist. I realized, though, that there was a force at work on my career, which I named the Inexorable Drift Toward Marketing. It’s inevitable: you can use words? You are good at explaining things? On the internet? Then the related jobs usually see you explaining things made by one third party so that someone from another third party can buy them. Unsurprisingly, the money is where the people that might buy things are.

Sometimes, buying things is helpful and necessary; sometimes, guiding people to buying the thing they need feels like a useful service to provide the world. But even though those moments exist, content is forever undervalued, the first thing cut from a budget, the element of a project brought in at the last minute, so easy to neglect (even though it is, genuinely, a crucial part of your website, your company’s brand and voice, or your system).

Separate of that, I’d come to realize that I might have an ability, an important one, that had never really been used: technology doesn’t scare me. Programming, with a reasonable amount of effort on my part, makes sense to me. And I’m a dogged troubleshooter who will pursue the thing until it works and works well, refining and redoing until it’s as it needs to be or slightly better.

It’s a quality that’s served me well as a writer, but it’s one that could take me further in a different field. And so, early this year, exhausted by a then-fruitless year-long job search, I applied to Hackbright. I took an intro to computer science class at Code Fellows back in Seattle, which was the last thing I needed to convince myself that I really-no-seriously was interested in this thing. Had I not made it into Hackbright (did you know about their acceptance rate? It is low), I would’ve pursued Python or iOS development there.

My former boss (and current friend) asked me how much more of a unicorn I needed to be. I said I wanted to be an eminently employable one. I can create a content strategy, write and interpret a survey, do interviews, create user journeys, make smart and effective editorial recommendations for companies large and small, originate and grow a company’s social media presence, rewrite a company’s entire website, create genuinely useful company documentation, establish a vocabulary for a niche industry, and host an industry meet-up. But I also want to be able to make the things that make the world run. I want to materialize my own awesome ideas. I want to fully participate in the world I’ve grown up in. And so I am here.

What’s next? I’ll write about why I chose single-gender education, something I never considered for high school or college. I’ll tell you about learning something like this in a ten-week program (which is, fortunately, not a boot camp). I’ll write about introvert overload and how programming somehow completely changes your metabolism. I’ll show you progress on my project, which I’ll be starting in earnest in a couple of weeks.

And I’ll write about my week-by-week experience, starting in week four, which I am just starting as I write this. I wanted to write sooner, but honestly, I was way too tired to start before now.

And, in the meantime, if you want a hyperarticulate, overly literate, UX-practicing junior Python dev for your team? Let’s talk; I’ll be available in September.