Hello! I’m Petra. I’m a Staff Software Engineer (and most recently Engineering Manager) with 15 years of professional experience. My role at my last company was just cut, and I’m looking for my next thing. Maybe you’d find me useful on your team? Well, here’s a guide to that. Think of it as a giant personal ad. If you read this and you’re excited about the prospect of bringing me on, shoot me an email or a message on LinkedIn!
tl;dr: You might want to hire me if you value honest communication, fast iterative development, and continuous delivery to customers—and if you’d like your team to get better at those things.
Your Organization
I might be great for you if your organization is…
🎁 Product-led
The best products ultimately speak for themselves. I prefer to build products which customers fall in love with by using them, rather than products customers have to be taught to appreciate by a sales rep.
🪴 Early-to-growth stage
A lot of my value as an engineering leader is in setting direction early. I’m less effective fighting against existing momentum. If you have an established product that, say, doesn’t have any tests, I’m not the person to come in and turn that around (while some people are great at that). But if you have a small team you want to point in the right direction, or a larger team that needs an expertise boost, let’s talk.
👩🏻💻 Remote-friendly (even if not 100% remote)
I live in Western Massachusetts. Your company is probably not headquartered here, so I typically work remotely, and have done for the past 10 years. (I’m very open to travel, though—I love to see people in person!) I’d prefer not to be the only remote person on the team, though for a small team I’m open to being the first of many. I have experience advocating for remote workers, and I can help you become more remote-friendly.
Your Ideal Tech Stack
I might be great for you if you want your code to be…
🧩 Component-driven
It’s important to me that engineers, product managers, and stakeholders can all see real UI components as they discuss them. The best tool for this I know of is Storybook, but the tool is less important than how it improves the development process. I have experience building design systems and highly reusable components, and I love to make developing UIs easier.
🛤 Well typed
I believe the right type system is as valuable to software development as tracks are to a rollercoaster. My strongest skills are in TypeScript, but I’m open to other languages. I have experience with Lisps, MLs, and Ruby. But it’s hard for me to justify the friction of working without TypeScript’s interactivity and guardrails. Right now, few languages hit that bar. If you’re convinced static types just get in the way, I’m probably not for you. If you want help letting them serve you instead, I can do that.
🧮 Biased towards functional programming
I value immutability and functional operations over data mutation and imperative steps. If you dislike functional approaches, I’m not your hire. If you like the functional approach in theory but struggle to make it practical, I can help.
🚦 Well tested
You can’t improve code you’re scared to touch, and you can’t safely touch code that isn’t covered by great tests. My background is rich in automated testing, from the classic test-driven development I learned at Pivotal Labs, to the myriad test pyramids we supported at CircleCI. If you think writing tests is a waste of time, you don’t want me. If you want to write better tests, let’s pair on it.
My Values
I might be great for you if—like me—you value…
💡 Blameless accountability
Everyone seems to agree that “accountability” is important, but people wildly disagree about why, or even what it means. For me, the goal is not to point fingers and find a scapegoat. The goal of accountability is to acknowledge that something did not go the way we wanted, and then collaborate to improve next time.
🪟 Honesty
I’m not a fan of lying to people, and I’m not a fan of being lied to. So, mathematically, I’m doubly not a fan of lying to myself. Most of my job comes down to honesty: honestly describing the product, honestly discovering how users interact with it, honestly setting expectations for what we’ll build in the next week. I’ve found that neither optimism nor pessimism is as useful as clear communication and being honest with ourselves and with each other.
🤔 Curiosity
I ask a lot of questions, and I love when my teammates do too. “How will the customer use this?” “Are we sure this API works the way we think?” “What is the customer actually trying to accomplish?”
💚 Compassion
We’re all humans. We grow, we act irrationally, and we have more in our lives than our jobs. I remind myself to make space for my teammates to be people, and I expect my teammates to do the same for me—and when they forget to, I remind myself to make space for that too.
🔁 Real value in fast increments
Every moment between starting something and delivering it is a liability. What happens when someone spends two weeks on something and then discovers it won’t work? Or a customer sees it and we learn we should never have built it? That’s two weeks wasted. The smaller the delivery cycle, the lower our risk of work being wasted and the sooner we learn new things about our product. If you want to get something small in front of your customer fast and keep moving, I can help you slice up the work to make that happen smoothly.
The Product
I’m open to working on all sorts of products, as long as I can believe in the value of them. But there are some themes I’m particularly interested in. If your product is in this realm, I might be a particularly great fit:
- Knowledge Management, both “personal” and for teams. (Think Logseq, Notion, etc.)
- “Spreadsheets”, and whatever might replace them. (Think Google Sheets, Airtable, and even Observable.)
- “Issue trackers”, and whatever might replace them. (Think Jira, Trello, Pivotal Tracker—but the next generation.)
- Linked Data and the Semantic Web. (Think Solid, m-ld, Comunica, or anything enabled by them.)
I believe that information should be way more connectable than it is, that both spreadsheets and “agile” tools are way too cumbersome for beginners and experts alike, and that everything is clearer when we can see it in front of us—in our own lives, but even more so on a team.
Sound like you? Let’s chat! Find me on LinkedIn, or just send over an email. I’d love to chat.