Decks for both talks came from SlidesGo. They’re beautifully designed, kitted out with all sorts of assets, and I will never go back to slumming it with default Google Slides templates.
If you’re here, it might be because we talked and I gave you one of my shiny business cards. Here are some useful resources for knowing more about what I’m doing.
The posts on this blog are typically about my work as an SRE and then as a security engineer. Read on if you want, but there’s no fiction here (except the one about computers being a good idea; I assure you they are not).
I mostly write novels these days, which are in various phases of revision. I’m planning to query later this year. I write what I consider regular fiction (meaning no magic or spaceships) but also a fair amount of fantasy (yes magic) and sci-fi (yes spaceships).
I’ve written zines for a lot of years too. You can get glimpses of them here.
I’m on Twitter more than is ideal for, well, anyone, but there it is.
I ate my first cheesesteak this week, which represents more meat than I’ve probably eaten in the previous seven or eight years. Out of character for me, but it felt stupid to come all the way here and not eat the food of the people. I paired it with a Yuengling and a friend’s good company and felt fairly content.
Anyway, hi! I probably enjoyed talking to you. You know how to reach me. I hope AWP is treating you well (and me too, for that matter).
I’ve had an ambition to become a security engineer for some time. I realized I found security really interesting early on in my career as an engineer in late 2015; it was a nice complement to infrastructure and networking, the other interests I quickly picked up. However, security roles are notoriously hard to fill but also notoriously hard to get. I assumed it would be something I’d pursue once I felt more secure in my skills as a site reliability engineer – meaning I might have waited forever.
Instead, early last fall, a friend reached out to me about an opening on her team. They wanted someone with an SRE background and security aspirations. Was I interested in pursuing it as a job, she asked, or was it just a professionally adjacent hobby?
I had to sit and think about that.
For about five seconds.
I typed back a quick I VOLUNTEER AS TRIBUTE extremely casual and professional confirmation that I was indeed interested in security as a career, and then the process began in earnest.
But before we get to where I am now, let’s back up to how I got here – and what I brought to the interview that (in my opinion, at least) got me the job.
The earnest scribbler
I’ve taken to describing the last couple of months as the Slumdog Millionaire portion of my career: it’s the part where everything I’ve done suddenly falls into place in a new and rather wonderful way.
I began my career as a writer and editor. It’s what I went to college for; rather shockingly, it’s how I supported myself for more than a decade. I’ve been a proofreader, a freelance writer, a mediocre book reviewer, a contract content editor, a lead editor in charge of style guides and training groups of other contractors, a mediocre marketing writer, and a content strategist. Toward the end of that time, I got a certificate in user-centered design from the University of Washington. I loved the work and loved content strategy, but it had become increasingly apparent over the previous couple of years that most writing that paid was meant to sell something, which wasn’t what I wanted to spend forty-plus hours a week doing. I could get by, but I knew I needed to change something, so I began paying closer attention to what I was actually really good at and what wasn’t a total slog within my jobs.
I learned to understand things and to be able to teach those same things to other people in language they could understand and refer to over and over. I became a prolific and effective documentation writer. I learned to navigate people and teams, most especially to get buy-in, because as a writer, sometimes half the job is convincing people that writing is worth paying for.
Toward the end of that period of struggle, I hung out with some software engineers for the first time. I discovered – and I say this with infinite gentleness – that they weren’t any smarter than I am. Between that and the rising resources for people looking to get into programming without a computer science degree, I decided it was now or never, and I needed to make the leap. If all else failed, I could go back to being a frustrated writer – just one who at least tried to do something else.
Engineering part one: consulting
I landed in San Francisco in 2015 to go to code school, and I stayed when I got my first job. I worked at a consultancy for three years, doing a lot of work in healthcare and govtech. I was thrown in the deep end as an infrastructure engineer and essentially a sysadmin, which was incredibly difficult and also incredibly formative to the kind of engineer I’d become. I also spent six months as a full-stack engineer.
Code school taught me how to code, to connect different layers of the stack to each other, and how to begin researching complex problems. At my first job, I added networking and AWS, Terraform, Bash, my love of writing CLI tools, and automation. I learned more about navigating bureaucratic nightmares, how to run teams effectively, and how to facilitate good meetings and retros. I also learned that I don’t like writing Javascript very much. Between that and realizing how much I enjoyed working with AWS, I decided my next role would be as a site reliability engineer or something like it.
Interlude one: in which security becomes very interesting
I began to think I might have something to offer the security world at the predecessor to Day of Shecurity in 2017. I was interested enough in the subject to sign up, but thinking I might have relevant skills was a different matter. Generally, I explained my interest in security as a complement to my regular job. “Ops is about building things,” I’d say. “Security tells me how you can break them, so I can learn to build them better.”
One session that day was a CTF of sorts, with three flags to find in the vulnerable test network we were exploring. Navigating to them required using command line tools, the ability to grep, and feeling comfortable with flags and documentation. I won two of the three and won two Amazon gift cards. I bought the official Golang book, cat litter, and the sparkly boots I still wear at least a couple of times a week, which I saw on a cool woman in the Lookout office that day. I’ve thought of them as my security boots ever since and have stomped through DEF CON, DoS, and job interviews in them. I use them as a reminder of that feeling: oh, wait, I might actually have something to offer in this field.
Engineering part two: SRE life
I spent 13 months as an SRE, a job I was thrilled to get (and still thrilled I landed). I got to dig deeper into the skills I’d gotten at the last job, as well as spending long days with Elasticsearch, becoming friends with Ansible, and learning another flavor of Linux. My company outsourced their security work to an outside firm, and I made a point of studying what they did: reading the emails they sent back to bug bounty seekers, responding to the small incidents that popped up here and there, and carrying out mitigations of issues in the infrastructure reviews they made for us.
I also grabbed the security-adjacent opportunities that came up, doing a lot of work on our AWS IAM policies and co-creating the company educational material on phishing avoidance. I learned about secret storage and rotation, artful construction of security groups for our servers, and how to best communicate policies like password manager use to people with lots of different technical backgrounds.
Engineering part three: present day
Early last fall, a friend reached out saying that her team at Salesforce wanted someone with an SRE background and an interest in learning security. We’d gone to the same coding school, though not at the same time. We actually met at a WISP event. She placed first in the handcuff escape competition; I placed second. We stayed in touch. She invited me over to a certain very tall San Francisco building to talk to her and her manager about the role, and so the process began.
My team does software reviews, which can involve black box pen testing (where we don’t see the code), code reviews, consulting on responsible data use for possible software options and the expansion of existing tools we use, and being a resource for other teams. We’re a friendlier face of security, which is the only kind of security I’m really interested in being a part of. We also work directly with outside software companies to improve their security practices if they don’t pass our initial review, so I’ll get the chance to help other engineers be better, which is one of my favorite things.
As of this writing, I still spend most of my days on training: learning to write and read Apex, doing secure code reviews of increasing complexity, and figuring out who does what in a security org with more than a thousand people. Coming into a very large company requires a ton of building context, and fortunately, I get the space to figure it all out.
Skills, revisited
So now you have an idea of what I learned and brought to the process of applying to this job. I recognized fairly quickly before that ops and security have a lot of things in common – that is, beyond a reputation for being risk-averse and more than a little curmudgeonly.
There are skills that are essential for both, including:
Networking, AWS, and port hygiene
Coding, especially scripting; Bash and Python are great choices
Command line abilities
Looking up running processes and changing their state
Reading and manipulating logs
The skills that less explicitly in demand but that I’ve found to be really useful include:
Communication, both written and verbal
Documentation creation and maintenance
Teaching
A UX-centered approach
Let me explain what I mean by that last one. As I said before, I have some education in UX principles in practices, and I’ve done official UX exercises as part of jobs. I’m still able to, if needed. The part of it I use most often, though, is what I’ve come to think of as a UX approach to the everyday.
What I mean by that is the ability to come into a situation with someone and assume that you don’t understand their motivations, previous actions, or context, and then to work deliberately to build those by asking questions. The key part is remembering that, even if someone is doing something you don’t think makes sense, they most likely have reasons for it, and you can only discover those by asking them.
This is at the center of how I approach all of my work, and it seems to be distinctive – when I left my last job, a senior engineer pulled me aside and gave me the nicest compliment about how he’d learned from me by watching me do exactly that approach for the year we’d worked together. He told me how different it was from how he worked and that he’d learned from me. It was a very nice sendoff.
Interlude two: my accidental security education
Here’s something I only realized afterward, which I alluded to earlier: I’ve done a LOT of security learning since becoming an engineer. I just didn’t fully realize what I’d been doing because I thought I was just having fun.
So I did none of these things with interview preparation in mind. The closest I came was thinking, “Oh, I see how this might be useful for the kinds of jobs I might want later, but I’m definitely not pursuing that job right now.” Well! Maybe you can be more deliberate and aware than I was.
These are the things I did that ended up being really helpful, when it came to prepare officially for a security interview, over the last four years:
Every one of these things gave me something that either helped me feel more adept while interviewing or something I mentioned specifically when discussing things and answering questions. Four years is a lot of time to pursue something casually, especially since I usually went to an event every month or two.
I’ve also benefited a lot from different industry newsletters, especially these:
Many of these are ops-centric, but all of them have provided something as I was working toward shifting jobs. Very few issues and problems exist in only a single discipline, and these digests have been really useful for seeing the regular intersections between things I knew and things I wanted to know more about.
Interview preparation, done deliberately
I officially applied for the job a month or so after that fateful informational coffee. I applied while I was out of town for three weeks being a maid of honor in my best friend’s wedding, meaning I didn’t get to do much until I was home and had slept for a couple of days.
Once my brain worked again, I made a wishlist of everything I wanted to be able to talk confidently about. Then I prioritized it. Then I began working through everything I could. I touched on about half of it.
I studied for about a week and a half, a couple hours at a time. I focused on three main things:
Blog posts that crossed my current discipline and the one I aspired to
The Exercism work was because I never feel like I code as much as I’d like in my jobs, and I feel more confident in technical settings when I feel more fluent in code. The OWASP reading was a mix of official resources, their cheat sheets, and other people’s writing about them; reading different perspectives is part of how I wrap my head around things like this. And the blog posts were for broader context and also to get more conversant about the intersection between my existing skills and the role I was aspiring to. The Capital One breach was really useful for this, because it happened due to misconfigured AWS IAM permissions.
This is the list I made, ordered by priority. The ones in italics are the ones I addressed to my satisfaction.
Sean is my boyfriend. One of the kindest things he does for me is that he lets me explain technical things to him until I’m able to explain them to non-engineers again. I do this pretty regularly, because it’s really important to me to be able to teach people without a lengthy engineering background, and I did it during interview preparation because I know how easy it is to obscure a lack of understanding with jargon, and I didn’t want to do that. Having someone who lets me do this is perhaps the other thing I didn’t realize would be as helpful as it has been; we started doing it because he wanted to know what I did at work, and I realized that it helped make me a better communicator and engineer. May you all have someone as patient as he is to help you translate engineerspeak to human language on the regular.
So that was how I spent my preparation time. Next: the interview.
A series of conversations, across from the tallest tower
For reasons I’m sure you can guess, I can’t give you the most specific play-by-play of the interview process. However, I got permission to give you a higher-level view of it that I hope will still be illuminating.
My interview was a bit bespoke, because they were more accustomed to hiring people who had already been pen testers or security researchers. Because of that, in addition to proving that I knew a few things about spotting insecure code and thinking through vulnerabilities, I also talked to their DevOps architect about ops things, including opinions on infrastructure as code and the creation and socialization of development environments. (We also found that we take a similarly dim view of senior engineers who bully junior engineers.) I talked about securing a server when several different types of users would need to reach it in different ways. And yes, I talked some about the OWASP top ten.
My bar for a “good interview” is whether the things we talked about or did were directly relevant to the needs and responsibilities of the job, and that was absolutely the case here. The only whiteboarding I did was when I volunteered to do so, drawing out network diagrams when I realized my hand gestures were not up to conveying the complexity of what we were discussing. Everything else felt collaborative, casual, and built to help me explain the things I knew about without feeling all the uncertainty that badly designed interviews can evoke.
Getting ready for your own security path
My goal in writing this post (based on a talk I did for Secure Diversity on 28 January 2020, which I will link to when the video is up) was to give the extremely specific information about how I got the job that I’ve always been thirsty for but often found lacking in “how I got here” talks for these kinds of roles. I hope I managed that; when I proposed the talk, I was very grateful to my past self for keeping such fastidious notes. However, I also want to leave you with some more general ideas of how to shape your current career to more effectively get to the security role I presume you’re seeking.
Find a couple security-essential skills you already know something about and dive deeply into them. I have a lot to say about IAM stuff, in AWS and Jenkins and general principle of least privilege stuff, so that’s been something I’ve really focused on when trying to convey my skills to other people. Find what you’re doing that already applies to the role you want, and get conversational. Keep up on news stories relevant to those skills. This part shouldn’t be that hard, because these skills should be interesting to you. If they aren’t, choose different skills to focus on.
While you’re doing this learning, make sure the people in your professional life know what you’re doing. This can be your manager, but it can also be online communities, coworkers you keep in touch with as you all move companies, and anyone else you can speak computer or security with. Don’t labor in obscurity; share links, mention things you’ve learned, and throw bait out to find other people interested in the same things.
Build that community further by going to meetups and workshops. When I think about living outside the Bay Area (which of course I do, because it’s a beloved hobby of just about everyone who lives around here), one of the things that would be hardest to give up is all the free education that’s available almost every night of the week. Day of Shecurity, Secure Diversity, OWASP in SF and the south bay, NCC meetups, and there are so many more. Go to the thing, learn the thing, and read about the thing after.
Finally, remember that security needs you. Like all of tech, security is better when there are a lot of different kinds of people working out how to make things and fix things. Please hang in there and keep trying.
The question of how to install things still trips me up sometimes. There are a bunch of possible ways it could be done in any given situation, and fairly often, the preferred method isn’t detailed overly meticulously in the README or other docs. Sometimes you have to clone repos and run a certain command in that directory; sometimes it means adding something to /usr/bin and opening a new terminal window; sometimes you summon a UI with a texty terminal command, which feels oddly like sorcery to me.
It’s a good deal easier now, but when I was just starting it could be a real trial. I spent a lot of an afternoon at Hackbright struggling with Postgres because I did a brew install instead of Postgres.app, which… did not get me what I needed and introduced a host of other problems. (It did get me a really interesting philosophical kind of conversation about the pros and cons of installing things from too high a level, courtesy of a teacher who became my friend – who still semifondly recalls that time she had to unpick what fuckery I’d wrought in such good faith.)
Today, trying to figure out how to get the command ldapsearch available to me, I learned one thing and was reminded of another.
I learned yum whatprovides */$WhatYouSeek. (Thanks, Server Fault.) In my case, ldapsearch was one of several commands inside a differently named package: openldap. Oho. (It’s actually in a couple different families of packages, but I do not need to get Perl up in my business today.)
I was reminded that – less commonly for the kind of work that I do – sometimes the needed command is not the name of the package. Some packages aren’t all about one command doing one thing well, despite the best urgings of the Unix philosophy. So – ldapsearch is snuggled into openldap. Got it.
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.
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?
