Three years ago, I wrote this essay about my ongoing struggle with binge eating. In it, I detailed my longstanding struggle with my seemingly endless appetite and predilection to stuffing huge amounts of food in my face. I had no solutions as of yet, but I was now out of the closet about this behavior that haunted me.

Since writing that essay, I’ve received dozens of emails from readers asking about my journey of recovery — where am I at now with it? Do I have any wisdom I could impart?

In these three years since, I’ve learned so much about this demon that used to haunt me. I used to feel lost and powerless when it came to what I saw as one of my most shameful behaviors … but I’ve since found the keys to recovery, unlocked my own cage, and walked out. Today, I still occasionally emotionally eat, but it’s rare, and it’s almost never a binge. I want the same for you.

How did I crack the code?

Well, first, I stopped endlessly berating myself for my seeming inability to stop eating. I stopped looking outside of myself for solutions, in online articles and advice from friends. Instead, I decided to compassionately look inward and get curious.

I started observing myself to understand why I was engaging in this behavior. After watching myself and my emotional eating habits closely, I found that without exception, I binge-eat in response to three different situations:

1. when I’ve been “restricting”
2. when I’m avoiding an emotion
3. when I’m neglecting my own pleasure

By eliminating these three triggers, I’ve been able to completely eliminate binge eating from my life. I’ll explore each of them in detail.

1. Restriction is the *problem*, not the answer

For me, this was the really really really huge key.

When I was in the thick of my battle with my disordered eating, I was convinced that the key to “solving” it was discipline and restriction. I felt sure that the answer was to cut off food after a certain time at night, or not keep certain foods in the house, or watch my caloric intake like a hawk. I just needed to make a resolution not to eat when I wasn’t hungry, and then stick to it, darn it.

But what I wasn’t taking into account was: For twelve years, this was exactly what I’d been trying to do. And it wasn’t working.

It wasn’t until I found the writing of Isabel Foxen Duke that I realized something revolutionary: Restriction isn’t the answer. It’s the problem.

It’s a cycle, really: I judge the way my body looks, so in order to avoid the emotional pain of gaining weight, I restrict myself. The pressure of that restriction and quest for thinness wears me out and leaves me feeling deprived, which leads me to binge. Then, in response to the binge, I feel shame and judge myself, so I restrict myself again. The cycle goes on relentlessly.

The key to understanding this inner landscape is that I am both the policeman and the detainee (inner child). The policeman’s goal is to protect me from gaining weight, which we’re conditioned to believe is the equivalent of death. The policeman cracks her whip on the inner child, who’s threatening to ruin the whole operation by desiring foods the policeman has designated “dangerous” or “bad”. But when the policeman’s not looking, the inner child — who’s feeling deprived and spiteful — eats everything in sight. Then, when the policeman’s back on duty, the whip comes down even harder with more restriction, perpetuating the cycle.

But if I can just open the jail cell — if I can face my fear of weight gain and let go of the need to restrict — the whole tension ends. There’s no longer any pressure, any emotional charge, any self-loathing involved.

Of course, giving up the need to restrict isn’t easy. Our culture incessantly tells us that we’re unlovable at a larger weight, which means staying thin feels like a survival mechanism in order to gain love. But I’m slowly learning to trust my body’s fluctuations, knowing deep down that I’d rather have a larger-sized body and face my own internalized fatphobia, than be participating in my own oppression and constantly suffering like this.

My first step to ending my own inner cycle of deprivation and binging was to start “allowing all foods again”. I started buying the foods I had for so long labeled “bad” — for me, this meant baked goods, pop tarts, ice cream, butter on bread. I’m not going to lie — it was really, really scary. I felt terrified that I was going to gain weight and feel unlovable. And I did gain a little bit of weight at first.

But eventually, my urge to eat tons of the stuff I’d spent the last 13 years depriving myself of went away. Now, I’m able to tap into what my body really wants in any given moment, which sometimes means vegetable soup, and other times means chocolate brownies. But before I could feel that intuitive connection, I had to let my inner child know that every food was okay — that there was no guilt and no wrong choices. Now, food feels pleasurable, and I never eat the whole cake at once, because I no longer feel rushed to eat it all before I start feeling guilty and restricting again. I can have it whenever I like, knowing I won’t feel bad about it. This lack of pressure destroys the whole cycle, leaving me feeling balanced and healthy in my approach to food.

If you’re looking for more resources on this journey to end the oppressive cycle of restriction, google “intuitive eating”. An entire movement has begun surrounding this idea of giving up the inner war so many of us fight. I joined a bunch of these groups on Facebook, and the communities there have helped me immensely on my journey to a healthier, more easeful relationship with food.

2. Turn towards uncomfortable emotions instead of away from them

It’s interesting — for most of my life, I’ve considered myself a highly emotional person. I am no stranger to melancholy, awe, or sentimentality. I’ve cried at touching commercials for as long as I can remember.

But what I didn’t realize was that I had unconsciously been avoiding certain other emotions: rejection, loneliness, emptiness, shame, unworthiness, fear of the void.

To avoid these feelings, I ate. Simple as that. I didn’t realize that this was what I was doing, but it was. I would feel a pang of discomfort in my belly, and I would take that as a signal to run to the fridge. Then, afterwards, I would be uncomfortably full, and the emotion would be nowhere to be found, drowned out by food.

What I’ve found, however, is that when that pang of discomfort arises, if I can sit with the sensations of that feeling, even just for a few minutes, often the urge to eat will completely go away. And the sensation isn’t really so scary after all, if I just face it.

Slowly over time, I have built this capacity to sit with my emotions, through modalities like Vipassana meditation, Focusing, EFT/tapping, and a type of therapy called “Parts Work” (or Internal Family Systems/IFS). I highly recommend looking into these methods if you are curious about how, in practice, to truly feel your feelings.

3. Fill your pleasure deficit

Food is a kind of pleasure, perhaps the first kind we ever know.

Growing up, pleasure wasn’t emphasized to me as a value. In fact, we live in a highly pleasure-negative culture — from the suppression of sexuality, to the emphasis on working long hours as a sign of moral superiority, to the sense that intuition & “what feels good” is a childish whim not to be trusted … our culture teaches us an extraordinarily unhealthy relationship to pleasure.

But as my teacher Regena Thomashauer says, “Pleasure is a nutrient.” And if we don’t get enough of it, we start to wither and die.

When I would feel the urge to binge-eat, it was often because my body was desperately yearning for pleasure. And because my sexuality was totally shut down — and I’d never dedicated much time to discovering what else brought me pleasure in life — food was my default (and perhaps only) source of that pleasure.

I was substituting food for all forms of pleasure and self-love that might be nourishing to my body — like some loving touch, or sleep, or dance, or just some words of affirmation from myself to myself.

To amend this, I didn’t stop using food for pleasure — there’s nothing wrong with that! Instead, I just started adding more forms of pleasure, big and small, to my life: self-touch, long baths, candles, plants, massages, masturbation, anointing my body after showers, prioritizing the hobbies I love.

And I started really enjoying the tiny pleasures that I already had in my life by bringing more presence to them. A helpful exercise for me was to run through all my senses and ask myself what kind of pleasure I could give to that sense in this moment:

sight: what kind of beautiful things could I feast my eyes on today? could i look at some art? go watch the sunset?
hearing: what kind of music or sounds would bring me deep pleasure right now? could i go listen to the birds? or moan and enjoy the sound of my own moans?
smell: what would smell great right now? essential oils? a flower? a particular meal my mother used to make?
taste: what delicious food might i be able to have a taste of right now, and *really* savor it, like i never have before?
touch: how would my body love to be touched right now? what would my skin love to feel? can i give that to myself?

As I found and added these little pleasures to my everyday life, suddenly life felt fuller and more nourishing, and I found myself feeling the craving to binge-eat much less often.

And, it’s worth noting: I still sometimes choose to respond to these pleasure-cravings by eating. And that is perfectly okay.

If I had to summarize some small (but huge!) steps that might be helpful if you find yourself deep in the struggle of binge eating, they would be these:

• End the internal war by forgiving yourself when you binge eat. Do not add any more shame.
• Make a list of small things in your life that bring you pleasure. Aim to insert a certain number of these into your life each day.
• Allow all foods. Intentionally buy the foods you’ve said you “can’t have in your house”. When in the kitchen, try asking yourself: “What is my body truly wanting to eat right now?” and follow it, whether it’s salad or chocolate cake.
• Learn to feel your emotions. I recommend Vipassana meditation for this. When you feel a discomfort arising in your body, practice sitting with it, even just for ten seconds.
• Decondition yourself from fatphobia by following body-positive bloggers and Instagram accounts. The less you’re afraid of gaining weight, the more sane your relationship with food will get. A few I recommend include @bodyposipanda, @bodyimagemovement, and @thebodylovesociety.
• Read Isabel Foxen Duke and/or Geneen Roth. These two writers helped me immensely to understand the underlying causes of my disordered relationship with food.
• Practice self-compassion above all. In any given moment, ask yourself, “What would feel nurturing to myself right now?” and do that.

Good luck, everyone! I genuinely wish you the absolute best as you untangle yourself from a confusing, painful, maladaptive relationship with food and your body. I can say personally that it’s one of the best things for myself that I’ve ever done. 🌟

— — 
If you enjoyed this piece, I’d love it if you hit the clap button 👏 so others might stumble upon it. You can find more of my thoughts and projects at http://www.sophiaciocca.com.

The key to curing binge eating isn’t what you think was originally published in Be Yourself on Medium, where people are continuing the conversation by highlighting and responding to this story.

I’ve been thinking a lot about self-love lately.

It started when two months ago, after a long stretching period of existential depression, I was visited by a lover from overseas. The two weeks that he was here were nothing short of magic — I was temporarily living life in technicolor as I “played house” with this wonderful human.

Then he left, because that’s what people do when they’re visiting from another country. And suddenly, everything about my life felt unbearably empty. I woke up every morning with an excruciating, dull, lonely ache in my chest. Did I really live my whole life like this until he and I met a few months ago? I wondered.

As the weeks passed, I began to notice that ever since his departure, I’d been abjectly avoiding being alone without something to do. In fact, I’d been doing this for most of my life. I’d been packing my schedule each day with friend-dates, real dates, and fun events … and filling in every remaining minute with personal tasks, like running errands and cooking dinner.

I’d also begun compulsively adding “white noise” to my life — always listening to a podcast or music while I did anything. In the moments when I truly had nothing to occupy me, I was scrolling through my phone and diligently completing crossword puzzles. Basically, I was actively ensuring every day that there was no moment in which I had to just sit with myself.

Because to be honest, sitting with myself felt dangerous.

A part of me knew that if I sat by myself in the quiet, I would come face to face with the giant void that was my relationship to myself.

version 0: the sensitive critic

Growing up, I didn’t have much of a concept of self-love. It wasn’t a value stressed to me — never once did I hear the words “you should love yourself” from anyone in my life, nor did I learn any practices through which to do so.

My one sense of self-love was tied to my ability to deeply feel my emotions as a highly sensitive person (HSP). While I sometimes felt embarrassment about my sensitivity, I also loved it, believing it made me “special” and gave me a deeper experience of life than other people had.

But while I loved that one part of myself, I unconsciously criticized every other part. For most of my life (read: until I started meditating), I wasn’t even aware that I had an inner monologue or that it was constantly attacking me. Even if I had noticed, though, I wouldn’t have considered this a problem — I was just “holding myself to a high standard.” I carried a quintessential perfectionist’s mentality, and it brought me great success in life: straight As, an Ivy league degree, a top-tier corporate job. I was subtly and unconsciously destroying myself, but no one would ever guess it by looking at my life.

…and then two years ago, without warning, my body went on strike.

version 1: self-love = a mission

In 2016, I woke up dizzy and tired one morning and ultimately spent seven months mind-numbingly sick. When allopathic doctor after allopathic doctor threw up their arms unable to tell me anything about the ailment that shook my bones, all I could intuit from my body was that I am emotionally at war with myself.

This was confusing — as a “feeler” I had always vigorously embraced my emotions, relishing the waves of joy, melancholy, inspiration, and self-pity. But what I didn’t realize was that I had unconsciously been avoiding certain emotions: rejection, loneliness, unworthiness, fear of the void. To avoid the feelings I didn’t want to feel, I had spent my life clinging to perfectionism, people-pleasing, emotional eating, excessive exercise, and self-criticism in an effort to numb myself or make myself “good enough” to never experience the scary feelings of loneliness or rejection.

But these habits that I was unconsciously using to avoid bad feelings were making me sick.

Armed with this revelation, I set out to cure my illness by “loving myself” and “feeling my feelings”, bringing to this mission the determination and ruthlessness that had taken me so far in life. I recited affirmations to myself in the mirror every morning like a soldier. I meditated daily. I filled my Instagram feed with cliché self-love quotes on picturesque backgrounds. I diligently journaled about my childhood wounds. I used EFT to force myself to cry out my feelings at least once a day. I created a checklist of healing modalities and tried them all. And eventually, the illness receded. It seemed that with my forceful approach, I had figured this self-love thing out. I had approached it like a battle, and I had won.

version 2: self-love = radical friendship

But now, two years later, I’ve been feeling unwell again, and this illness — combined with my longstanding pattern of unhealthy attachment to the men I date — is calling me to audit my self-love. It’s clear something’s missing: I’m not giving myself enough love, so I keep attracting men who are also not able to give me the love I crave.

At first, this realization felt bewildering. “I do love myself!” I thought. “I’ve been on a self-love journey for three full years now. I do affirmations in the mirror and meditate and practice yoga. Damn well I love myself!”

…And yet here it was, this inarguably empty feeling inside when I contemplated being alone. Myself felt like … nothing. A terrifying nothing. Love has to have an object, doesn’t it? What could it even mean to love this empty space that is me?

Last week, I finally found a piece of what it might mean. After work on Tuesday, I arrived home at my apartment with that familiar uneasy feeling, thinking, “uh oh, you’re about to be alone … here it comes …” But this time, instead of immediately busying myself with a task or distracting myself with my phone, I walked straight to the couch and sat down in silence. I took a deep breath and focused on the physical sensation of uneasiness in my body.

All of a sudden a guttural cry erupted from somewhere deep inside me, and soon I was sobbing. I instinctively caressed my arms and legs to soothe myself, and then I heard my body tell me to lay on my side on the floor. This direct message startled me, and so I started talking to my body out loud. I asked her to tell me about what she was feeling. This felt foreign and confusing at first — who was talking to whom in this situation? How was I holding up both parts of the conversation?

But it soon became clear that the part of me that is awareness itself was soothing and listening to the part of me that is this human character, Sophia, with messy needs and emotions. I guess when people say “self-love”, maybe that’s what they mean — the enlightened part of you giving compassion to the childlike part of you that’s actually physically struggling through this lifetime.

I talked my way through my storm of emotions, sobbing all the way, naming each emotion as it came up and hugging myself through the process of feeling them all — grief, frustration, existential fear. The dialogue sounded something like this:

Higher self: It’s ok, it’s ok (rubbing shoulders). Tell me about what you’re feeling.
Body (through tears): Fear. Fear. Fear. Fear. Fear. Fear. I’m so scared. Fear. Fear. Fear.
Higher self: (Nods vigorously and compassionately) It’s so valid to feel that. I get you. Life’s really scary sometimes. What specifically do you feel afraid of?
Body: — long teary pause — I’m scared that nothing matters. That life is a void. That *sniffle* I’ll never feel full and whole by myself. That everything is out to criticize and hate me. That I’ll never feel truly “at home”.
Higher self: (hugs self, rubbing arms) Yeah. That fear is so valid. I don’t know what the answer is, but I’m here. I’m feeling this with you.

It had felt new and weird, but after 15 minutes of loving touch and dialogue with my poor body, the fear subsided. And know what’s wild? At the end, without forcing anything, self-love just poured out of me. I found myself saying to myself, “I love you so much. I love you so much.” Over and over again it came out, in waves of compassion for myself. “We’ve been through some shit. I know. I know, it hurts. It really hurts. It’s okay to be scared, it’s scary. It’s so valid. It’s okay, just feel it. Feel it all, I’m here.”

And every time I’d talk to myself like that, something amazing happened: Every cell of my body lit up like a Christmas tree, energy releasing with resonance, my body saying thank you for understanding, finally. Thank you for validating me and giving me permission to just be where I’m at. For the first time in my life, it felt like every part of me was on the same page.

As I’m building this deeper friendship with myself, I chuckle remembering my old interpretation of “self-love”, back when I was curing my illness. Self-love then was a project — it was “fixing the problem”. I’d feel a difficult emotion in my body, and I’d sit there pressuring it to come out, practically yelling at it. I treated my body like a crying baby, desperately shoving things at it to force the feeling out and have it be over. The monologue would usually go something like this:

“UH OH, WHY ARE YOU SO ANXIOUS? DO YOU NEED FOOD? HERE’S A BANANA. NO? IS IT THAT YOU’RE THIRSTY? HERE GULP DOWN THIS WATER. NO? ARE YOU TIRED? JESUS CHRIST PLEASE JUST BE CLEARER.”

While that forceful approach ultimately didn’t lead me to true self-love, it did yield something valuable: the tools I found for feeling my feelings in the first place. Methods like EFT (tapping), Vipassana-style meditation, Focusing, and conscious movement continue to be precious resources to me. The difference is that now, I’m using them as a way to be with myself, instead of as a way to fix myself.

And maybe that’s what self-love really is, at the end of the day —not bath bombs and chocolate, nor counting all the external things I’m good at, nor “fixing” anything at all … but rather, just giving myself permission to be exactly where I’m at. Holding all of my states, all of my traits, and all of my feelings in the loving eye of pure awareness and compassion.

I’m realizing that loving yourself doesn’t require feeling overjoyed about every part of you (though if you can find a way to do that, more power to you.) No, it’s just about being able to look at every one of those parts, and say, “I accept you. You are a part of me.” And to the less savory ones, say, “You are hurting. It’s okay to be in this hurting state: to be human and imperfect and messy. it’s grand, this life thing, and I’m here with you.”

So what now? I sense that the road of self-love only gets more scenic from here. In addition to a steady diet of “I love you”s dozens of times a day, I’m telling myself the things I’ve been waiting for friends or romantic partners to tell me for my entire life. These likely vary from person to person, but mine are:

Your sensitivity is breathtakingly beautiful. You are so wise. Your desire for deep connection is so valid. Your life journey is so inspiring. I see you, I see your depth and it is so gorgeous, like nothing I’ve ever seen before. I will never leave you.

And it’s crazy: My brain doesn’t know the difference between someone else telling me these things, and me telling them to myself. My body glows just as brightly as it would if it got these compliments from someone else. It’s drinking these words up like it’s been thirsty in the desert for decades. I tear up often, like my heart is saying, “Oh. There you are. I have been waiting for this kind of love for my whole life.”

Thanks to this work, my base level of self-esteem is rapidly upgrading. I am slowly but surely healing the roots of so many of my issues, rather than the branches. Instead of working to “fix my people-pleasing”, or “love people more”, or “speak more confidently”, those things just come naturally out of a firm base of self-love. This is revolutionary. I’m just getting started, and it’ll be a while until this is all firmly rooted, but I trust that the seeds are planted and the shift is happening, oh it’s happening.

For now, I’m taking the time to do nothing. I’m going slower. I’m no longer filling my life with white noise or compulsively doing crossword puzzles. Sitting with myself feels bearable now — in fact, it’s starting to feel like home.

— — 
If you enjoyed this piece, I’d love it if you hit the clap button 👏 so others might stumble upon it. You can find more of my thoughts and projects at http://www.sophiaciocca.com.

“Real self-love”: On finally cultivating an intimate relationship with my heart was originally published in Personal Growth on Medium, where people are continuing the conversation by highlighting and responding to this story.

If you’re like most people in America, you use a text editor nearly every day. Whether it’s your basic Apple Notes, or something more advanced like Google Docs, Microsoft Word or Medium, our text editors allow us to record and render our important thoughts and information, enabling us to tell stories in the most engaging ways.

But you might not have ever thought about how those text editors work under the hood. Every time you press a key, hundreds of lines of code may be executing to render your desired character on the page. Actions that seem small — such as dragging a selection over a few words of text or turning text into a heading — actually trigger lots of changes in the system underlying the program.

While you may not think about the code powering these complicated text-editing maneuvers, my team here at The New York Times thinks about it constantly. Our primary task is to create an ultra-customized story editor for the newsroom. Beyond the basics of being able to type and render content, this new story editor needs to combine the advanced features of Google Docs with the intuitive design focus of Medium, then add lots of features unique to the newsroom’s workflow.

For a number of years, The Times’s newsroom has used a legacy homegrown text editor that hasn’t quite served its many needs. While our older editor is intensely tailored to the newsroom’s production workflow, its UI leaves much to be desired: It heavily compartmentalizes that workflow, separating different parts of a story (e.g. text, photos, social media and copy-editing) into completely different parts of the app. Producing an article in this older editor therefore requires navigating through a lengthy series of unintuitive and visually unappealing tabs.

In addition to promoting a fragmented workflow for users, the legacy editor also causes a lot of pain on the engineering side. It relies on direct DOM manipulation to render everything in the editor, adding various HTML tags to signify the difference between deleted text, new text and comments. This means engineers on other teams then have to put the article through heavy tag cleanup before it can be published and rendered to the website, a process that is time-consuming and prone to mistakes.

As the newsroom evolves, we envisioned a new story editor that would visually bring the different components of stories inline, so that reporters and editors alike could see exactly what a story would look like before it publishes. Additionally, the new approach would ideally be more intuitive and flexible in its code implementation, avoiding many of the problems caused by the older editor.

With these two goals in mind, my team set out to build this new text editor, which we named Oak. After much research and months of prototyping, we opted to build it on the foundation of ProseMirror, a robust open-source JavaScript toolkit for building rich-text editors. ProseMirror takes a completely different approach than our old text editor did, representing the document using its own non-HTML tree-shaped data structure that describes the structure of the text in terms of paragraphs, headings, lists, links and more.

Unlike the output of our old editor, the output of a text editor built on ProseMirror can ultimately be rendered as a DOM tree, Markdown text or any other number of other formats that can express the concepts it encodes, making it very versatile and solving many of the problems we run into with our legacy text editor.

So how does ProseMirror work, exactly? Let’s jump into the technology behind it.

Everything is a Node

ProseMirror structures its main elements — paragraphs, headings, lists, images, etc. — as nodes. Many nodes can have child nodes — e.g., a heading_basic node can have child nodes including a heading1 node, a byline node, a timestamp node and image nodes. This leads to the tree-like structure I mentioned above.

The interesting exception to this tree-like structure lies in the way paragraph nodes codify their text. Consider a paragraph consisting of the sentence, “This is strong text with emphasis”.

The DOM would codify that sentence as a tree, like this:

In ProseMirror, however, the content of a paragraph is represented as a flat sequence of inline elements, each with its own set of styles:

There’s an advantage to this flat paragraph structure: ProseMirror keeps track of every node in terms of its numerical position. Because ProseMirror recognizes the italicized and bolded word “emphasis” in the example above as its own standalone node, it can represent the node’s position as simple character offsets rather than thinking about it as a location in a tree. The text editor can know, for example, that the word “emphasis” begins at position 63 in the document, which makes it easy to select, find and work with.

All of these nodes — paragraph nodes, heading nodes, image nodes, etc. — have certain features associated with them, including sizes, placeholders and draggability. In the case of some specific nodes like images or videos, they also must contain an ID so that media files can be found in the larger CMS environment. How does Oak know about all of these node features?

To tell Oak what a particular node is like, we create it with a “node spec,” a class that defines those custom behaviors or methods that the text editor needs to understand and properly work with the node. We then define a schema of all the nodes that exist in our editor and where each node is allowed to be placed in the overall document. (We wouldn’t, for example, want users placing embedded tweets inside of the header, so we disallow it in the schema.) In the schema, we list all the nodes that exist in the Oak environment and how they relate to each other.

export function nytBodySchemaSpec() {
  const schemaSpec = {
    nodes: {
      doc: new DocSpec({ content: 'block+', marks: '_' }),
      paragraph: new ParagraphSpec({ content: 'inline*', group:  'block', marks: '_' }),
      heading1: new Heading1Spec({ content: 'inline*', group: 'block', marks: 'comment' }),
      blockquote: new BlockquoteSpec({ content: 'inline*', group: 'block', marks: '_' }),
      summary: new SummarySpec({ content: 'inline*', group: 'block', marks: 'comment' }),
      header_timestamp: new HeaderTimestampSpec({ group: 'header-child-block', marks: 'comment' }),
      ...
    },
    marks: 
      link: new LinkSpec(),
      em: new EmSpec(),
      strong: new StrongSpec(),
      comment: new CommentMarkSpec(),
    },
  };
}

Using this list of all the nodes that exist in the Oak environment and how they relate to each other, ProseMirror creates a model of the document at any given time. This model is an object, very similar to the JSON shown next to the example Oak article in the topmost illustration. As the user edits the article, this object is constantly being replaced with a new object that includes the edits, which ensures ProseMirror always knows what the document includes and therefore what to render on the page.

Speaking of which: Once ProseMirror knows how nodes fit together in a document tree, how does it know what those nodes look like or how to actually display them on the page? To map the ProseMirror state to the DOM, every node has a simple toDOM() method out of the box that converts the node to a basic DOM tag — for example, a Paragraph node’s toDOM() method would convert it to a <p> tag, while an Image node’s toDOM() method would convert it to an <img> tag. But because Oak needs customized nodes that do very specific things, our team leverages ProseMirror’s NodeView function to design a custom React component that renders the nodes in specific ways.

(Note: ProseMirror is framework-agnostic, and NodeViews can be created using any front-end framework or none at all; our team has just chosen to use React.)

Keeping track of text styling

If a node is created with a specific visual appearance that ProseMirror gets from its NodeView, how do additional user-added stylings like bold or italics work? That’s what marks are for. You might have noticed them up in the schema code block above.

Following the block where we declare all the nodes in the schema, we declare the types of marks each node is allowed to have. In Oak, we support certain marks for some nodes, and not for others — for instance, we allow italics and hyperlinks in small heading nodes, but neither in large heading nodes. Marks for a given node are then kept in that node’s object in ProseMirror’s state of the current document. We also use marks for our custom comment feature, which I’ll get to a little later in this post.

How do edits work under the hood?

In order to render an accurate version of the document at any given time and also track a version history, it’s critically important that we record virtually everything the user does to change the document — for example, pressing the letter “s” or the enter key, or inserting an image. ProseMirror calls each of these micro-changes a step.

To ensure that all parts of the app are in sync and showing the most recent data, the state of the document is immutable, meaning that updates to the state don’t happen by simply editing the existing data object. Instead, ProseMirror takes the old object, combines it with this new step object and arrives at a brand new state. (For those of you familiar with Flux concepts, this probably feels familiar.)

This flow both encourages cleaner code and also leaves a trail of updates, enabling some of the editor’s most important features, including version comparison. We track these steps and their order in our Redux store, making it easy for the user to roll back or roll forward changes to switch between versions and see the edits that different users have made:

Some of the Cool Features We’ve Built

The ProseMirror library is intentionally modular and extensible, which means it requires heavy customization to do anything at all. This was perfect for us because our goal was to build a text editor to fit the newsroom’s specific requirements. Some of the most interesting features our team has built include:

Track Changes

Our “track changes” feature, shown above, is arguably Oak’s most advanced and important. With newsroom articles involving a complex flow between reporters and their various editors, it’s important to be able to track what changes different users have made to the document and when. This feature relies heavily on the careful tracking of each transaction, storing each one in a database and then rendering them in the document as green text for additions and red strikeout text for deletions.

Custom Headers

Part of Oak’s purpose is to be a design-focused text editor, giving reporters and editors the ability to present visual journalism in the way that best fits any given story. To this aim, we’ve created custom header nodes including horizontal and vertical full-bleed images. These headers in Oak are each nodes with their own unique NodeViews and schemas that allow them to include bylines, timestamps, images and other nested nodes. For users, they mirror the headers that published articles can have on the reader-facing site, giving reporters and editors as close as possible a representation to what the article will look like when it’s published for the public on the actual New York Times website.

Comments

Comments are an important part of the newsroom workflow — editors need to converse with reporters, asking questions and giving suggestions. In our legacy editor, users were forced to put their comments directly into the document alongside the article text, which often made the article look busy and were easy to miss. For Oak, our team created an intricate ProseMirror plugin that renders comments off to the right. Believe it or not, comments are actually a type of mark under the hood. It’s an annotation on text, like bold, italics or hyperlinks; the difference is just the display style.

Oak has come a long way since its conception, and we’re excited to continue building new features for the many newsroom desks that are beginning to make the switch from our legacy editor. We’re planning to begin work soon on a collaborative editing feature that would allow more than one user to edit an article at the same time, which will radically improve the way reporters and editors work together.

Text editors are much more complex than many know. I consider it a privilege to be part of the Oak team, building a tool that, as a writer, I find fascinating and also so important for the functioning of one of the world’s largest and most influential newsrooms. Thank you to my managers, Tessa Ann Taylor and Joe Hart, and my team that’s been working on Oak since well before I arrived: Thomas Rhiel, Jeff Sisson, Will Dunning, Matthew Stake, Matthew Berkowitz, Dylan Nelson, Shilpa Kumar, Shayni Sood and Robinson Deckert. I am lucky to have such amazing teammates in making the Oak magic happen. Thank you.

Building a Text Editor for a Digital-First Newsroom was originally published in NYT Open on Medium, where people are continuing the conversation by highlighting and responding to this story.

I’ve always felt deeply drawn to New Years Resolutions. I’m a sucker for that “clean slate” feeling, and with my birthday kicking off the year on January 1, it feels like a further amplified opportunity for a new beginning.

But everyone knows that traditional resolutions — vague and ungrounded statements like “go to the gym more” — rarely last or produce any meaningful change. As someone who relishes structure and organization, I prefer to treat resolutions with a bit more thought and care.

As I considered possible resolutions for this year, I thought about what 2017 was missing for me, and the answer was clear:

I don’t feel like I’m adequately living out my values.

I’m a very values-centric person (INFJ, hollaaa), and I’ve thought extensively about what my strongest values are. I value authenticity. I value expression. I value empathy. I value adventure.

But most of all, as cliché as it sounds, I value love. In all its forms. Love for self, love for others, romantic love, family love, agapé brotherly love.

Some of you may recall that I spent 2015 doing a series of month-long experiments, in which I’d try out a lifestyle change with strict guidelines for a month, in an effort to decide whether I’d like to incorporate it more fluidly and permanently into my life. The projects spanned lots of random ideas I wanted to explore, from trying out veganism, to taking cold showers, to being “radically honest” every day in every interaction.

Those 2015 projects felt awesome. It felt so good to spend a full year guided by a structure intended to foster my own growth; by the end of the year, I had done so much, and it made the year feel so full, so well-spent.

So this time, I’m conducting another year of projects, but this year I’m focusing it a bit more around a central theme. This year, my monthly projects will all support the theme of love, in an effort to train myself to live more directly aligned with my own primary value.

I’ve decided to alternate my 2018 projects between three sub-themes:

1. Love for self

Why “love for self”? If there’s anything I’ve realized this past year, it’s that self-love is the basis for all other love. I can only share what I’ve already cultivated. Self-love builds a sense of self-worth, which is the foundation for fulfilling all of my desires. Learning to love myself is an endlessly important endeavor, and it deserves at least four months of my year.

2. Love for others

Why “love for others”? Because we’re all mirrors for each other. The more I learn to see strangers as brothers and sisters and extend grace and love to them, the more I can extend it to myself and to the specific people I care about in my life. New York City is the perfect playground for this, “Others” refers to anyone and anything outside of myself.

3. Miscellaneous

There are several projects I want to experiment with this year, more along the lines of the random projects I did in 2015, and I want to make space for those as well. After all, making those kinds of lifestyle changes are conducive to health and happiness, which better allow me to love wholeheartedly.

2018 Project Love Schedule*

January: [[self]] — Seeing my attention as a gift

• Treat each and every interaction I have as an experiment in recognizing my own worthiness, the gift of my presence
• Flirt with at least one stranger every day

February: [[others]] — Love notes to the city

• Leave a short encouraging note or love letter every day around the city — in library books, on subway seats, given directly to particular strangers that strike my fancy, etc.

March: [[misc]] — Cutting out dairy

• Cut dairy entirely out of my life (including in baked goods)
• Track how I feel every morning, afternoon, and evening, to see whether I feel better.

April: [[self]] — Body Love

• Apply coconut oil to my entire body every evening in front of my mirror
• Ensure I feel “embodied” every day, most often by dancing when I wake up
• Post something lovingly body-centric to social media each day (including dancing videos)
• Work through my own sexual trauma and train my body to feel safe again through loving touch

May: [[others]] — Fostering love for individual strangers and friends

• Voice authentic compliments to strangers and friends every single time I think of one (even if it seems awkward)
• Practice seeing every human I pass as their mother sees them

June: [[misc]] — Wim Hof Method

• Research the methods
• Take freezing cold showers every day, following my original 2015 schedule (increasing the length of the showers each week)
• Practice Wim Hof’s breathing techniques
• Track how I feel every day, both directly after the shower and breathing techniques, and later in the evening

July: [[self]] — Bragging & Affirmations

• Create a new affirmation for each week; speak it first thing in the morning to myself in the mirror, strive to live all day with that affirmation in mind
• Make a weekly piece of art with the affirmation; post it on social media, and hang it in my cubicle
• Brag freely about the things I’m proud of about myself, any time such a thought arises

August: [[others]] — Extreme Gratitude

• Upon waking up, list five things I’m immediately grateful for
• Keep a gratitude journal all month, and every day add at least five new things
• Write a gratitude-centered poem and perform it
• Practice trust that my life is perfect the way it is, that everything is happening in divine timing for the advancement of my soul

September: [[misc]] — Kicking the Sugar Dependence

• Cut out *all* non-natural sugars (no candy, baked goods, etc.)
• Limit honey and dried fruit intake
• (Possibly follow someone else’s established regimen for this)

October: [[self]] —The Art of Asking

• List my desires & intentions for the day every morning immediately upon waking up
• Focus this month exclusively on meditations centered around visualizing my desires
• Ask for everything I want, to anyone I want things from, and feel through the rejection when it occurs. Accustom myself to it, so it’s no longer scary

November: [[others]] — Radical Generosity

• Give money (or food) to every single homeless person I encounter in the city (on the street, on trains, etc.)
• Give money to every single street performer I encounter in the city
• Have conversations with these people when possible

December: [[misc]] — Creative Writing Month

• Complete a creative writing prompt every single day (more details to come)

*subject to change based on my whims and desires from month to month.

Wish me luck! I’ll be blogging publicly about the takeaways from some of these experiments, but not all of them. If any of you are thinking of doing a similar year of projects, or want to join me for any of my months, comment, and I’d love to follow your journey as well!

All the best to all of you in the sparkling new year! I can already feel it — it’s going to be a year chock-full of change and growth.

— — 
If you enjoyed this piece, I’d love it if you hit the clap button 👏 so others might stumble upon it. You can find more of my thoughts and projects at http://www.sophiaciocca.com.

2018: My year of monthly love projects was originally published in Personal Growth on Medium, where people are continuing the conversation by highlighting and responding to this story.

How deeply-rooted feelings of unworthiness have kept me eternally single

I’ve barely dated anyone in my life.

In fact, despite being 24 in New York City, I haven’t been in any sort of romantic relationship in over three years, even for just a week or two. My longest relationship ever lasted two months — eight months if you count the lead-up to it — and on average, I’m physically intimate with someone maybe a few times a year.

I generally don’t mind being single, but my unusual pattern begs the question: Why don’t I date more? When people ask me that question, I always say, “it just doesn’t happen to me” … but why doesn’t it? I look around at my friends, some of whom are what I call “serial monogamists”, always dating someone new … and I often wonder what I’m doing wrong.

It’s not that I’m not meeting enough people. I have hoards of attractive male friends, and because I’m part of several dance communities, I intimately interact with these men on the reg. In fact, I actually have a habit of dancing with an unusually high number of men on any given night out. Earlier this year at a dance party, my friend Joe pointed it out, joking, “When did this begin, all these men throwing themselves at you?” I looked away, bemused — were some of the men I was dancing with actually interested in me and I just never realized it? That was a terrifying but exciting thought.

When I recounted this story to another male friend of mine, he agreed with Joe, saying, “Sophia, you’re a catch. I would bet that a solid percentage of your male ‘friends’ would be down to date you, but don’t think you’re interested.”

It makes me wonder: am I putting out the wrong energy? With a default assumption that men only want to be friends with me, am I creating a self-fulfilling prophecy? And why is it that my own attractiveness feels so hard to believe, leading me to make that assumption in the first place?

Let me tell you more about my current dating situation, but first, a flashback to how I ended up here.

Wound origins

I have a wound. This wound initially formed in middle school, when all my classmates started dating each other but I was always overlooked, never chosen by the boys in my class. When we moved to high school, I was never once asked to a school dance —in fact, I was one of the few people who even went to prom solo (for the record, this was not a thing that people did.) This still feels like an embarrassing thing to admit.

In hindsight, there were probably justifiable reasons for my lack of suitors: I had other priorities, and I didn’t conform to the social norms of high school. I wore no makeup and slapped my hair in a ponytail every day; I carried a giant three-inch binder in the crook of my arm everywhere I went; and I never hung out with anyone outside of school because my first love was homework. But instead of ascribing the lack of male attention I received to my lifestyle choices, I internalized it and assumed something was inherently wrong with me.

After a while, I concluded I was by definition “not desirable”, and learned to occupy a platonic space in everyone’s lives, outside of the dating pool. The way I saw it, everyone had an internal switch labeled “Potential Romantic Interest:”, and mine must have been switched to ‘No’ from birth.

I learned to never express my own desire, out of fear I would be laughed at for thinking I could even be considered. This became a scab for the wound, protecting myself from others’ judgment — if I never asked for anything or expressed desire for anyone, I would never have to be rejected. I wouldn’t have to confront the fact that I deeply wanted to be loved, but felt afraid others deemed me unworthy of it.

As I grew older, I started wearing my hair down and expanded my horizons beyond academics, which inadvertently earned me more male attention. In college, I had several romantic sparks with men, but because I still believed I wasn’t worthy of being desired, the connections never materialized into anything.

I distinctly remember one such connection with a guy named Carson during my junior year. I met him at a salsa dancing event, and we immediately clicked. We lived in the same dorm building, so we started hanging out regularly, me climbing the stairs to his room every weekend and sitting on his bed talking until morning about philosophy, music, existentialism, and our childhoods. I had a huge crush on him, but he never made any clear moves, so I was left constantly wondering where we stood and how he felt. No matter how crazy it drove me, though, I wouldn’t dare ask — I feared I would seem stupid or silly for imagining he could possibly be attracted to me, particularly for a relationship or any kind of commitment.

One night, he finally brought it up. We were mid-conversation about Proust, when he said,

“Sophia, I need to ask you something. What do you want from me?”

I froze. “I, I don’t know...” I stuttered, but it was a lie. I wanted to date him. I wanted him to kiss me. I wanted lots of things, most of all to feel wanted. But I couldn’t voice any of that, because my inner critic had commandeered my brain with its constant chanting: “You aren’t dateable. You aren’t worth commitment. You aren’t even attractive. Simply put, you aren’t good enough. Why would you ever tell him you want to date him when you know there’s no way he could possibly want that? How embarrassing for you, and what an awkward position to put him in!”

To you, the reader, this mindset might seem silly, nonsensical, baseless. “Get some self-worth…” you might be saying to yourself. But this belief I have is deep-set, stubborn and difficult to unlearn. It’s hard to convey how solidly my brain is routed this way — how scary it feels to even be writing this, to be saying, “Yes, I actually am worthy of relationships with people I desire, and I’m telling this story about the faulty voice in my head,” when the voice itself is screaming at me, “You know this article is just going to be super awkward, right? You’re not dateable, and now you sound like a fool for talking as if you actually are, as if you’re ‘overcoming this’, when really it’s just the truth.”

I’ve been thinking a lot lately about where this voice in my head came from — why I inexplicably feel this way, even when evidence to the contrary presents itself in the form of a romantic interest that does briefly get past the gates of my mindset. As shame and vulnerability researcher Brené Brown says,

Shame used to be a two-person game, but now I’ve learned to do it all by myself.

While I might trace the voice’s origins to my experiences during high school, now it doesn’t matter what experiences I have — no matter what happens, my mind will somehow use the experience to support the story that I’m not good enough. It will invent infinite reasons why I’m probably not worthy, ranging from body size, being too opinionated, being not-spiritually-evolved-enough, facial asymmetry, the acne scars on my forehead, and that ridiculous internal not-a-romantic-option defect I mentioned earlier.

This cycle connects closely with my deeply-rooted perfectionism: My mind believes “If you are not perfect, no one will love you,” and since perfection is unachievable no matter how hard I work, my mind always wins — I’m never good enough to be loved. And so I never even ask for anything I desire, or tell the people I love that I’m in love with them — because I preemptively assume that I’m not worthy of getting what I want, and that the answer is no.

So that brings me to these last few months. I’ve been feeling stuck, repeating the same pattern over and over again. The pattern goes like this: I meet a guy, and we hang out. I become attracted to him, but I receive mixed signals from him, which leaves me wondering: Is he into me? Or are we just friends hanging out one on one?

And at that point, I feel frozen in a kind of no-man’s-land. I don’t voice how I’m feeling, and the connection goes nowhere. Like with Carson that night in college, my feelings catch in my throat, and I can’t speak my desire. That primordial fear comes creeping back, that I am not worthy of what I want, so how can I possibly speak it out loud? Plus, there’s my patriarchal conditioning monologuing in my head:

Isn’t this a game, where I’m supposed to be coy and aloof and he’s supposed to chase me? If I say I’m into him, even if he’s sort-of into me, won’t my saying something ruin it? Anyway, if he was into me, wouldn’t he be saying something? My job here as a woman is to play small and wait.

But none of that bullshit is real, and even if it is, it doesn’t matter. My feelings are valid, and voicing my desire to someone I’m dating is a good filter. If he is less interested in me because of my desire for him and my honesty about it, then I was never going to be truly known and loved by him anyway. After all, I’m not interested in a relationship that rests on a game of Who can care less?. I lose that game every time, and playing it feels inauthentic to who I am. I want and need to be able to express my whole self freely to someone I consider a partner.

More importantly, speaking my desire is a way of honoring myself and my own feelings — desire being a perfectly legitimate feeling. By speaking my desire, I am honoring what’s true for me and refusing to participate in my own oppression. I am refusing to shrink myself for someone else’s comfort. I am allowing myself to take up space, and empowering myself to ask for what I want and deserve.

Don’t get me wrong — I’m still afraid. The voice in my head is still loud and constant, yelling statements about my unworthiness and defectiveness. But I am learning to ignore it and say the hard things anyway. To squeeze my eyes shut and hold my breath through the pause after I tell someone “Hey, I’m into you” and allow that pause to take up space. Because regardless of outcome, my speaking out is evidence of embodied courage and vulnerability, two qualities I intrinsically value.

Something tells me Brené would be proud.

— — 
If you enjoyed this piece, I’d love it if you hit the clap button 👏 so others might stumble upon it. You can find more of my thoughts and projects at http://www.sophiaciocca.com.

Am I undateable? and other fears was originally published in Be Yourself on Medium, where people are continuing the conversation by highlighting and responding to this story.

After graduating from the Grace Hopper Program (an all-women’s coding bootcamp) this summer, I spent the following three months on a Teaching Fellowship, mentoring the next cohort of GH students, and began my post-bootcamp job search in the second week of September.

During my seven weeks on the search, I connected with 45 companies and received four offers. It’s now the end of October and I just signed on with The New York Times! I definitely caught some lucky breaks, and my own privilege certainly played a part in my success. But I also worked really hard to make this happen, and I’d love to share with you how I approached the job search.

My approach

People often think a job search entails sending out hundreds — or even thousands — of applications in order to snag a job. But personally, I connected with fewer than 50 companies, and sent out only three actual applications. (and one of those was after the interview, just so that I was officially on file.) It doesn’t have to be a numbers game. There is a way to succeed in the job search with a “quality over quantity” philosophy. How, you ask?

The way I see it, there are two very different approaches people take to the job search: the “quality” route (networking) and the “quantity” route (submitting cold applications). My intuition told me the “quality” route would yield more benefits for the time spent, so I threw myself into it full-force.

My strategy was simple: Get through to “a real person” and ask to buy them coffee or chat on the phone. The beginning of the job application process for me was always talking to a person, regardless of whether that was a person I already knew, a person I found cold on LinkedIn, a person I followed on Twitter, a person whose email address I guessed at until I got it right, a fellow alumna on Slack. How did these different sources of people compare?

My main sources of company leads:

My leads came from lots of different places, but I’ll break them down into categories:

• Friends, who would connect me to their own companies or to their connections at others. This was definitely one of the easiest ways to get connected to a company — a friend would simply introduce me to a hiring manager or engineering manager on their team, or a friend at another company that interested me. If a friend was the source of the lead, the next step was usually a coffee chat.
• Companies I targeted and reached out to cold, finding engineers on LinkedIn who worked there and messaging them. People are surprisingly willing to help out eager and friendly people who express interest in them. I’d say my response rate for this was 50%. Again, I would always ask for a coffee chat or a phone call.
• Meetups and networking events, especially ones geared towards recruiting. I especially had success at women-in-tech-focused recruiting events, one of which is where I met my future manager and initially heard about the position I later took!
• Recruiters and engineers who reached out to me, either through LinkedIn or email. Some of these passive leads came to me simply because I had a fully fleshed-out LinkedIn profile with my skills prominently listed, making me easily searchable. Others came because people found my technical writing here on Medium and then reached out. One of my offers came from one of these passive leads.
• My bootcamp’s Hiring Day, a mini-interview event from which I got lots of leads, but which came too late in my process. (Because I was a teaching fellow, I had started my job search five weeks prior to Hiring Day, and so I received the offer I took before I could go onsite with most of the Hiring Day companies.)
• Cold applications, which, as I mentioned, comprised only a negligible portion of my leads, and ultimately got me nowhere.

Tracking Tool:

To track my job search, my bootcamp’s Career Success department suggested I use Asana, and boy, was it helpful.

As you can see, I gave each company a “task” listing, in which I would list the job listing and my connections there, as well as comments with each action I’d taken with that company so far, whether it was reaching out to someone, getting coffee, completing a phone interview, etc., and notes about how it went.

Whenever I reached a new phase of the recruitment process with a company, I would physically drag the company’s listing up to the next category (e.g. Phone Screen, Coding Challenge, On-Site, etc.)

This system allowed me to keep track of where I stood with every company at any given time. It also enabled me to find all the details for my relationship with a specific company in one place, as well as set a deadline to remind myself when to follow up. If I hadn’t done this, I would have gotten very mixed up with so many companies!

The Recruiting Pipeline:

Each company’s hiring process differs in its components — some companies had recruiter phone screens then immediately brought me onsite, others gave me technical phone screens, or take-home coding challenges (some timed, some untimed). Some on-site interviews involved white-boarding and others didn’t. Some involved architecture components, and others didn’t.

In general, the smaller the company, the more relaxed I found their interview process to be. Heck, at one tiny company, I never once had to code for them — I just showed them my Github and that was enough. The tech giants, on the other hand, often have several rounds of grueling interviews.

In any case, here’s how my pipeline went:

As you can see, the “coffee chat” approach led to a much wider funnel than what you usually see— over half of my coffee chats resulted in a phone screen or referral, as opposed to many job-searchers’ pipelines, in which 300+ applications yields a dozen phone screens. In fact, two of my four offers originated in a coffee chat or informational call, and one of the others was from meeting someone in person at a networking event.

For the coffee chats that didn’t lead anywhere, it was generally because either (a) the company wasn’t hiring, or (b) I was already about to take an offer, so it was just too late in my process. Moral of the story: Coffee chats are great.

In general, once I snagged a phone screen, I found that my chances were pretty good from there. 66% of my phone screens resulted in a next step, and half of the ones that didn’t were companies I turned down. Only two companies turned me down after the phone screen. (I attribute this success, very simply, to lots of practice answering basic technical questions, and smiling and sounding pleasant and excited while on the phone.)

Also, I found that referrals in big company systems often are not particularly helpful; the three that I graciously received sat in large HR systems and nothing ever became of them.

What I Learned:

All right, here’s the part where I share my hard-earned wisdom — lessons I learned both the easy way (from doing them and succeeding) and the hard way (from not doing them and failing):

1. Figure out what part of the job search you’re weakest at, and prioritize your time accordingly.

The way I saw it, there were three main ways to spend time during my job search:

• Networking / generating leads
• Building out my portfolio
• Studying algorithms / practicing whiteboarding

Between those three, I felt weakest in the networking department, so I spent the vast majority of my job-search time just reaching out and making connections. I had already finished a few portfolio pieces, and I had been practicing whiteboarding in bootcamp, so connecting with companies was definitely the most valuable way to spend my time.

That said, if you don’t feel you have any portfolio pieces to talk about in your interviews, or if you’ve never stood in front of a whiteboard, your priorities might look different.

2. Fully fill out your LinkedIn profile to gain the attention of recruiters.

My bootcamp’s Career Success Department required us all to update our LinkedIn with a professional photo and a pitch/summary, as well as list every one of the technologies we knew as a skill. By listing these skills, you will show up in recruiters’ searches, so make sure you have them on your profile!

My cohort also all endorsed each other for those skills and wrote recommendations for our closest teammates, which gave our profiles a stronger sense of legitimacy. This sometimes felt silly, but I feel confident now that my robust LinkedIn was one of the reasons so many recruiters and engineers reached out to me.

3. Take interviews first from companies that interest you less, but also don’t wait too long to reach out to your dream companies.

Timing was one of the most difficult parts of my job search. My general strategy was to initially take interviews with small companies that I was less excited about. This was both good and bad — it was great practice, but also meant I got offers before I had even gotten into the process with the companies I really wanted to work for.

The approach I suggest:

1. Start your search by taking whatever you can find through easy leads — alumni posting on the alumni slack channel about openings at their companies, for example. Tell everyone you’re interested, and take any interview you are given. The more interviews you’ve done, the better you will perform in future interviews, both behaviorally and technically. (And hey, you might even find that once you’re on-site at a company you had never heard of, you actually love the company!)
2. After you’ve done ~5 “practice runs”, reach out to your dream companies, especially if they’re tech giants. The hiring process at large companies can take longer than you anticipate, and you don’t want to start too late and feel pressure to take a smaller company’s offer before you even finish the process with the larger companies that excite you more.

4. Make a list of questions to which you actually want the answers, and bring it to coffee chats and interviews.

My friend and cohort-mate Rachel Berkowitz gave me this advice, and it was absolutely invaluable. She recommended I make a list of 5–10 “factors I care most about in a workplace”, which for me included factors like:

• a modern technology stack
• clear expectations and feedback
• a culture of openness, collaboration, and vulnerability when one “doesn’t know” something
• work-life balance
• structured onboarding

Then, I turned those factors into 5–10 questions that I could ask at coffee chats or at the ends of interviews, like:

1. What is the feedback mechanism on your team? How do engineers know how they’re doing?
2. How do people learn on the team? Collaboratively or independently?
3. What kinds of personalities tend to thrive at X company/X team? (This one often resulted in revealing answers that made me certain I didn’t want to work at certain places!)

These questions not only made me look curious and interested to my interviewers and connections, but also gave me a better idea of whether or not the company fit what I was looking for. Remember, you’re interviewing the company just as much as they’re interviewing you!

5. Always google “common [insert language here] interview questions” before the interview.

Even if you’ve done this before, it’s amazing what a refresher can do. I looked up “common JavaScript interview questions” before each interview, and it was amazing how many of those questions actually came up in my interviews. Because I’d seen them and prepared them, I had intelligent answers at the ready.

Also, Glassdoor interview summaries often included the specific questions companies had asked applicants in the past. I highly recommend looking at those before the interview as well.

6. Send a LinkedIn request with a note after meeting ANYONE.

After any coffee chat, networking event, or interview, I would immediately log onto LinkedIn and send a connection request to each of the people I met. I always included a note, so that the person remembered who I was and what we talked about. In the note, I would thank the person for their time and ask about next steps or how to best keep in touch about opportunities at their company.

This was one of the most valuable things I did, both for immediate gains during my job search and for future value. I built out my network, and now, even at the companies that I didn’t accept offers with this time, I can build relationships with the people I met and easily reach out in the future. It’s all about building new bridges!

7. To get in the door at big companies, find a way to connect to an engineering manager or hiring manager.

Initially, I thought referrals were going to be my golden ticket into the large companies I dreamed of working at. If I could just get someone — anyone — at the company to internally “put me in the system”, I would have an in. Right?

Wrong. While a random employee referral might be enough at a smaller company, I found that even with a red referral flag next to my name, at big companies, my applications still just sat forgotten about in giant HR systems. My three official employee referrals at big companies went absolutely nowhere.

A better approach is to find a direct connection to an engineering or hiring manager. I usually did this by asking people at the end of coffee chats if they could “connect me with an engineering manager or hiring manager on their team”, but reaching out cold might work, too. The point is, the manager is looking for a real person to fit their real needs. If you can speak with them, establish face and name recognition, and make a case for why you are the person who can solve their problems and fit well on their team, your chances at a phone screen go up exponentially.

8. Always follow up, even when your message is ignored.

Initially, following up was something I never did — if someone didn’t respond to my email, or if I never heard back after they had passed on my resume, I assumed that meant I was rejected, I was bothering them, or they didn’t have time for me or want to talk to me.

But the Career Success team quickly set me straight — if someone doesn’t reply, it might just be that your email got lost among the week’s flurry of emails. The people you’re messaging are generally not sitting at home and watching their inbox. Wait five business days, and then follow up. I can’t tell you how many times my own follow-up reignited a lead.

9. Create a brand for yourself and/or write technical blog posts.

Besides networking, the two best things I did for my job search were to (1) write about tech on Medium, and (2) create a personal portfolio site, where people could contact me after reading my articles.

I’ve always loved to write, so when someone recommended to me that I write about tech as I’m learning it, I jumped at the opportunity, never realizing how much it would help my job search. But it did — I received emails, LinkedIn requests, and Twitter follows from developers who had read my articles and were interested in interviewing me for their companies. Writing also just feels like a great way to give back to the tech community.

For more detail about how to build a personal brand as a new software developer, this post breaks it down well. TL;DR: Have a tech-focused social presence on Medium, Twitter, Github, and LinkedIn. Cross-post original content between the different channels. Be an active participant in the developer community, and show some personality and passion in your work and online presence.

If you’re job-searching, I hope this was helpful, and I wish you the best of luck! It’s only going to get easier from here, as we gain experience in the software world and become highly-desired in a market with a supply shortage. For now, go dazzle some hiring managers and get that first tech job!

— — 
If you enjoyed this piece, I’d love it if you hit the clap button 👏 so others might stumble upon it. You can find my code on GitHub, musings on Twitter, and more of my writing and projects at http://www.sophiaciocca.com.

How I landed my post-bootcamp software developer job in just seven weeks was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

A simple step-by-step guide to go from idea to deployed app

My three months of coding bootcamp at the Grace Hopper Program have come to a close, and the title of this article is actually not quite true — I’ve now built three full-stack apps: an e-commerce store from scratch, a personal hackathon project of my choice, and finally, a three-week capstone project. That capstone project was by far the most intensive— a three week journey with two teammates — and it is my proudest achievement from bootcamp. It is the first robust, complex app I have ever fully built and designed.

As most developers know, even when you “know how to code”, it can be really overwhelming to embark on the creation of your first full-stack app. The JavaScript ecosystem is incredibly vast: with package managers, modules, build tools, transpilers, databases, libraries, and decisions to be made about all of them, it’s no wonder that so many budding coders never build anything beyond Codecademy tutorials. That’s why I want to walk you through a step-by-step guide of the decisions and steps my team took to create our live app, Align.

First, some context. Align is a web app that uses an intuitive timeline interface to help users set long-term goals and manage them over time. Our stack includes Firebase for back-end services and React on the front end. My teammates and I explain more in this short video:

So how did we go from Day 1, when we were assigned our teams, to the final live app? Here’s a rundown of the steps we took:

Step 1: Ideate

The first step was to figure out what exactly we wanted to build. In my past life as a consultant at IBM, I led ideation workshops with corporate leaders. Pulling from that, I suggested to my group the classic post-it brainstorming strategy, in which we all scribble out as many ideas as we can — even ‘stupid ones’ — so that people’s brains keep moving and no one avoids voicing ideas out of fear.

After generating a few dozen app ideas, we sorted them into categories to gain a better understanding of what themes we were collectively excited about. In our group, we saw a clear trend towards ideas surrounding self-improvement, goal-setting, nostalgia, and personal development. From that, we eventually honed in on a specific idea: a personal dashboard for setting and managing long-term goals, with elements of memory-keeping and data visualization over time.

From there, we created a set of user stories — descriptions of features we wanted to have, from an end-user perspective — to elucidate what exactly we wanted our app to do.

Step 2: Wireframe UX/UI

Next, on a white board, we drew out the basic views we envisioned in our app. We incorporated our set of user stories to understand how these views would work in a skeletal app framework.

These sketches ensured we were all on the same page, and provided a visual blueprint going forward of what exactly we were all working towards.

Step 3: Choose a data structure and type of database

It was now time to design our data structure. Based on our wireframes and user stories, we created a list in a Google doc of the models we would need and what attributes each should include. We knew we needed a ‘goal’ model, a ‘user’ model, a ‘milestone’ model, and a ‘checkin’ model, as well as eventually a ‘resource’ model, and an ‘upload’ model.

After informally sketching the models out, we needed to choose a type of database: ‘relational’ vs. ‘non-relational’ (a.k.a. ‘SQL’ vs. ‘NoSQL’). Whereas SQL databases are table-based and need predefined schema, NoSQL databases are document-based and have dynamic schema for unstructured data.

For our use case, it didn’t matter much whether we used a SQL or a No-SQL database, so we ultimately chose Google’s cloud NoSQL database Firebase for other reasons:

1. It could hold user image uploads in its cloud storage
2. It included WebSocket integration for real-time updating
3. It could handle our user authentication and offer easy OAuth integration

Once we chose a database, it was time to understand the relations between our data models. Since Firebase is NoSQL, we couldn’t create join tables or set up formal relations like “Checkins belongTo Goals”. Instead, we needed to figure out what the JSON tree would look like, and how the objects would be nested (or not). Ultimately, we structured our model like this:

(Note: Firebase prefers shallow, normalized data structures for efficiency, but for our use case, it made most sense to nest it, since we would never be pulling a Goal from the database without its child Milestones and Checkins.)

Step 4: Set up Github and an agile workflow

We knew from the start that staying organized and practicing agile development would serve us well. We set up a Github repo, on which we prevented merging to master to force ourselves to review each other’s code.

We also created an agile board on Waffle.io, which is free and has easy integration with Github. On the Waffle board, we listed our user stories as well as bugs we knew we needed to fix. Later, when we started coding, we would each create git branches for the user story we were currently working on, moving it from swim lane to swim lane as we made progress.

We also began holding “stand-up” meetings each morning to discuss the previous day’s progress and any blockers each of us were encountering. This meeting often decided the day’s flow — who would be pair programming, and who would work on an issue solo.

I highly recommend some sort of structured workflow like this, as it allowed us to clearly define our priorities and make efficient progress without any interpersonal conflict.

Step 5: Choose & download a boilerplate

Because the JavaScript ecosystem is so complicated, we opted not to build our app from absolute ground zero. It felt unnecessary to spend valuable time wiring up our Webpack build scripts and loaders, and our symlink that pointed to our project directory. My team chose the Firebones skeleton because it fit our use case, but there are many open-source skeleton options available to choose from.

Step 6: Write back-end API routes (or Firebase listeners)

If we weren’t using a cloud-based database, this would have been the time to start writing our back-end Express routes to make requests to our database. But since we were using Firebase, which is already in the cloud and has a different way of communicating with code, we just worked to set up our first successful database listener.

To ensure our listener was working, we coded out a basic user form for creating a Goal, and saw that, indeed, when we filled out the form, our database was live-updating. We were connected!

Step 7: Build a “Proof Of Concept”

Our next step was to create a “proof of concept” for our app, or a prototype of the most difficult fundamental features to implement, demonstrating that our app could eventually exist. For us, this meant finding a front-end library to satisfactorily render timelines, and connecting it to Firebase successfully to display some seed data in our database.

We found Victory.JS, a React library built on D3, and spent a day reading the documentation and putting together a very basic example of a VictoryLine component and a VictoryScatter component to visually display data from the database. Indeed, it worked! We were ready to build.

Step 8: Code out the features

Finally, it was time to build out all the exciting functionality of our app. This is a giant step that will obviously vary widely depending on the app you’re personally building. We looked at our wireframes and started coding out the individual user stories in our Waffle. This often included touching both front-end and back-end code (for example, creating a front-end form and also connecting it to the database). Our features ranged from major to minor, and included things like:

• ability to create new goals, milestones, and checkins
• ability to delete goals, milestones, and checkins
• ability to change a timeline’s name, color, and details
• ability to zoom in on timelines
• ability to add links to resources
• ability to upload media
• ability to bubble up resources and media from milestones and checkins to their associated goals
• rich text editor integration
• user signup / authentication / OAuth
• popover to view timeline options
• loading screens

For obvious reasons, this step took up the bulk of our time — this phase is where most of the meaty code happened, and each time we finished a feature, there were always more to build out!

Step 9: Choose and code the design scheme

Once we had an MVP of the functionality we desired in our app, it was time to clean it up and make it pretty. My team used Material-UI for components like form fields, menus, and login tabs, which ensured everything looked sleek, polished, and coherent without much in-depth design knowledge.

We spent a while choosing a color scheme and editing the CSS, which provided us a nice break from in-the-trenches coding. We also designed a logo and uploaded a favicon.

Step 10: Find and squash bugs

While we should have been using test-driven development from the beginning, time constraints left us with precious little time for anything but features. This meant that we spent the final two days simulating every user flow we could think of and hunting our app for bugs.

This process was not the most systematic, but we found plenty of bugs to keep us busy, including a bug in which the loading screen would last indefinitely in certain situations, and one in which the resource component had stopped working entirely. Fixing bugs can be annoying, but when it finally works, it’s extremely satisfying.

Step 11: Deploy the live app

The final step was to deploy our app so it would be available live! Because we were using Firebase to store our data, we deployed to Firebase Hosting, which was intuitive and simple. If your back end uses a different database, you can use Heroku or DigitalOcean. Generally, deployment directions are readily available on the hosting site.

We also bought a cheap domain name on Namecheap.com to make our app more polished and easy to find.

And that was it — we were suddenly the co-creators of a real live full-stack app that someone could use! If we had a longer runway, Step 12 would have been to run A/B testing on users, so we could better understand how actual users interact with our app and what they’d like to see in a V2.

For now, however, we’re happy with the final product, and with the immeasurable knowledge and understanding we gained throughout this process. Check out Align here!

— — 
If you enjoyed this piece, I’d love it if you hit the green heart 💚 so others might stumble upon it. Feel free to check out the source code for Align, and follow me on Github, as well as my badass team members, Sara Kladky and Melanie Mohn.

How we built our first full-stack JavaScript web app in three weeks was originally published in Ladies Storm Hackathons on Medium, where people are continuing the conversation by highlighting and responding to this story.

What I Learned in Coding Bootcamp, Part 1

I’m currently a student at one of New York’s top coding bootcamps — Fullstack’s Grace Hopper Program. I just completed the first six weeks, otherwise known as “Junior Phase”. This is the “straight-up learning portion”, full of lectures and workshops, in which students learn all of the concepts that we’ll go on to apply in longer projects in Senior Phase.

I can already hear senior developers screaming at me through my screen: “You can’t possibly learn full-stack JavaScript in six weeks! Don’t get me wrong, I’m nowhere near an expert, and I’ve spent a LOT of hours at my bootcamp every week to learn these concepts. But the curriculum has been top-notch, and after six weeks following it, I feel like I have a solid grasp of the different parts of the stack and how they fit together.

Because my bootcamp has been highly successful in placing grads into jobs all around the stack, I figured it might be helpful to outline exactly what we learned in this first phase — the concepts our founders and hiring partners deem necessary to be a successful full-stack developer. Basically, if you’re trying to go the “self-taught” route, this is a curriculum that’s been success-tested.

Note: There will obviously be disagreement about what concepts, frameworks, and libraries are most important to learn, and everyone has an opinion. This is just one bootcamp’s take on a curriculum. That said, Fullstack has a reputation for constantly reworking its curriculum to stay up to date with best practices and skills most in-demand from employers, so I think it’s a pretty good starting point!

What We Learned

1. Foundations: Programming Fundamentals

First thing’s first: Before we even arrived on campus, we all were required to complete four weeks of part-time work online, covering basic JavaScript concepts that had to be second-nature by the time we started digging into the more complex stuff. This included:

• basic object-oriented JavaScript; constructor and factory functions, and prototypal inheritance
• basic functional JavaScript; higher-order functions, closure, recursion
• how to read Jasmine test specs
• the bare basics of HTML, CSS, and jQuery

2. Git & Terminal Fluency

Git is definitely a necessity for software developers today, as is comfort using the terminal, so we learned to use these tools early. Basic skills included: creating and moving files around in directories, initializing and committing updates to git, and setting up remote directories on Github.

3. CS Basics: Data structures & algorithms

Our first full week of bootcamp was dedicated to understanding the history and fundamental concepts of computer science. We learned to implement basic data structures — linked lists, queues, stacks, binary search trees, and hash tables — and implemented several different types of sorting algorithms. We also talked in depth about Big O notation, and its implications for the efficiency of different code implementations.

4. Node.js

Ten years ago, JavaScript was used strictly for front-end scripting. Now, however, thanks to Node.js, it can be used for the full-stack (which is one of the reasons it’s such an appealing choice to learn as a first programming language!) Node is simply a run-time environment for JavaScript on the server side, so learning to use Node didn’t require much additional syntax. We learned to import and export files and modularize our code, installed and used npm libraries, and acclimated ourselves to using the terminal as a console, all the while building our own clone of the bash Unix shell to practice these concepts.

5. Servers, HTTP, and Express.js

After learning to use Node, the next step to understanding back-end development is to understand servers and routing. We began with an introduction to ports and protocols, with a focus on HTTP — its “verbs”, its filepath, its headers, its payload, its response statuses. We then learned to use Express, a Node library for request handling. We practiced modular RESTful routing, learning to handle GET, POST, PUT, and DELETE requests.

6. Asynchronous JavaScript

Asynchronicity is one of the hallmark qualities of JavaScript, creating division among developers everywhere — some love it, some hate it. But as budding JavaScript developers, one thing’s certain: We must understand it inside and out. We initially focused on understanding the call stack and Event Loop and tracing callback functions; then, we took a deep dive into Promises, understanding their purpose and how to use them, and even building our own Promise library to understand how they work. Promises and asynchronicity in general were some of the toughest concepts in the curriculum to get an intellectual grasp on, but they’re also some of the most important.

7. Databases, Schemas, Models, & ORMs

Databases are a crucial component of web apps — If you have data to load or want your app to be able to persist beyond refreshing the page, you’re going to need to connect to a database. We first began by talking about different types of databases (relational vs. non-relational), and discussing possible associations between data (one-to-many, many-to-many, etc.) and the ramifications of those associations (foreign ids, join tables). We learned to use SQL to access and manipulate databases, but then replaced those long SQL commands with the Sequelize ORM, which converts data from JavaScript object models to formats used by SQL database managers. We used Postgres to run our database, though there are many other options as well. Finally, we integrated our Sequelize code with our Express routes to create a (very basic) persistent full-stack web application.

8. HTML5, CSS3, & Sass

It’s crucial for any developer to have a handle on the basic language of the DOM — HTML — and to be able to style it with CSS. This was definitely the weakest part of the curriculum, which is ok — it isn’t a design bootcamp, it’s a coding bootcamp — but we did learn the basics. We also learned Sass — “Syntactically Awesome Style Sheets” — which allowed us to use loops and other time-savers to organize our CSS and make it a little more “code-like”. To practice, we recreated a basic version of the Bootstrap library and styled a single-page web app.

9. jQuery & DOM manipulation

After building out front-ends in HTML and CSS, we learned to use event emitters and jQuery to manipulate the DOM. We worked on selecting, updating, deleting, and restyling DOM events, and learned about the concept of “event delegation”. Many argue that jQuery is dying, as front-end frameworks like Angular and React replace much of its functionality, but because so many current applications make use of jQuery, it’s important to know at least the basics. And, anyway, I would argue it’s not always necessary to use a large hammer like React for smaller apps; sometimes, a little lightweight jQuery is all you need.

10. Chrome Dev Tools

I would be remiss if I didn’t mention that we also learned to use Chrome Dev Tools for all of our front-end work. This included using the Inspect tool to examine the styling of DOM components, as well as the console, of course, to debug. Chrome Dev Tools also includes more nifty tabs, like the Network tab, which was extremely useful for testing our backend routes. In general, Dev Tools is just profoundly useful for novice web developers and experts alike.

11. AJAX

If you ever want to create an app that doesn’t refresh the page every time it sends or receives information to/from the database, you’ll need to understand AJAX, or “asynchronous JavaScript and XML”. Basically, AJAX sends background asynchronous HTTP requests, whose responses trigger only a partial re-rendering of the view. There are a few different implementations of AJAX requests across browsers; we used jQuery’s “.ajax” method, which takes care of a lot of cross-browser considerations under the hood, and later transitioned to the Axios client when we began using React.

12. Test-Driven Development

We paused for a couple of days to focus on the important concept of Test-driven Development, a.k.a. the idea that a developer should first write an initially-failing test, then write the minimum amount of code to pass it, then refactor to acceptable standards, then reiterate to cover all of the functionality desired of the app.

We had worked with Jasmine and Mocha/Chai before, simply passing tests written for us by our instructors. But now, we became the drivers and wrote our own tests. Most of us found this dull and rather unpleasant, but it’s important in order to cover as many edge cases as possible and ultimately produce less buggy code.

13. WebSockets

We only got a high-level look at web sockets, but they are highly useful, so I recommend looking into them. We learned about the WebSocket protocol, which provides back-and-forth communication channel over a TCP connection (as compared to HTTP, which is one-to-one and requires that a request be made from a client before a singular response is sent from the server.) This makes apps like realtime chatrooms possible without both computers sitting there constantly sending GET requests for new data.

We used the Socket.IO library to actually implement this protocol, though there are other options as well.

14. ES6, Babel, & Webpack

JavaScript is a rapidly changing language, and ES6 (a.k.a. ES2015) changed the game quite a bit, syntactically and functionally. Heck, apparently proposals for ES2017 are in the works, and the language will soon be changing even more! To be an up-to-date and employable JS developer, it’s important to know and be able to use these new features.

But with a changing language comes a problem: cross-browser compatibility issues. What’s a JS developer to do?

Enter Babel, a JavaScript compiler that allows you to write in ES6 (and, soon, beyond) without worrying about compatibility, because it compiles it all to ES5. Babel can even compile JSX/React components for you, making it an essential part of the modern developer workflow.

It was at this point that we were also introduced to Webpack, a build tool that puts all of your assets, including Javascript, images, fonts, and CSS, in a dependency graph. Webpack isn’t always necessary for small applications, but as we head into React-land, building large apps with many components and non-code static assets, it’s a critically useful tool.

15. React

At the beginning of week 5, we finally arrived at a topic many of us were eager to tackle — React! To understand how it worked, we built a clone of Spotify piece by piece, covering the virtual DOM and the component lifecycle; stateful and stateless components, and when to use each; passing props from component to component; creating forms in React; and front-end routing with React Router. Throughout the workshops, we slowly gained a solid grasp on not only how to work with React, but why working with React is useful, and when to use it.

16. Redux

After learning React, we quickly refactored our Spotify clone to use predictable state container Redux — and then the react-redux library to make it all a little cleaner. We learned about action types (definitions and labels for a type of action, which we defined in a ‘constants’ file); action creators, functions that can take information and return objects formatted to be sent to the Redux state; reducers, which usually a switch statement that describes a different update depending on the action's type; and the store, where the object representing the Redux state is kept.

Because the pretend app we were building wasn’t large enough to actually warrant the use of Redux, it was difficult to see the point of all the extra upfront code, but I do imagine that having a singular organized state and modularized code proves useful for very large apps, or apps that rely on real-time updating of the state from multiple users, like multiplayer games.

17. Authentication, sessions, & cookies

Our second-to-last curriculum topic covered a topic I’ve been curious about for a long time: how does an app accommodate users, who log in and out and have certain privileges depending on who they are?

We started by learning about sessions and cookies, small text files created by a server handling an HTTP request, and passed on to the browser to keep track of a user’s identity. Then, we ensured that those sessions persisted using the express-session library, and used it to connect login and logout pages to user models in the database, setting authorization privileges based on user identity.

18. Web security

Finally, we touched on a topic that’s becoming a critically important consideration for anyone looking to develop an app: security. We took a high-level look at different types of web security threats, alternating between “attacking” (i.e. understanding the vulnerability from the attacker’s point of view, and how a hacker might inflict damage) and then “defending” (fixing and protecting our code to prevent the attack. In particular, we covered the topics of uncovering API secrets, improper route access, data injection, XSS, and data theft.

Beyond the curriculum and stellar lectures, what truly made Junior Phase so effective was the workshops, in which we actually practiced each of the concepts, cumulatively adding them together and ultimately creating clones of actual apps, like Twitter (to learn Express.js), Wikipedia (to learn databases and Sequelize), a trip planning app (to learn Sass, jQuery, and AJAX requests), and Spotify (to learn React).

Starting this week, I’ll be in Senior Phase, in which we’ll be building bigger projects from scratch, including an eCommerce site, a personal hackathon project, and a 21-day Capstone project. We’ll also practice whiteboard interview questions daily, give a “tech talk” about a topic of our choice, learn about deployment and build systems, and attend a Hiring Day with employers.

I personally can’t wait to put all of these skills into practice in the coming weeks and in the career that awaits me. Best of luck to you on this journey we’re on!

— — — — — — — — — — —
If you enjoyed this piece, I’d love it if you hit the green heart 💚 so others might stumble upon it. You can find my code on GitHub and my other projects at http://www.sophiaciocca.me.

Full-Stack JavaScript in Six Weeks: A Curriculum Guide was originally published in Ladies Storm Hackathons on Medium, where people are continuing the conversation by highlighting and responding to this story.

I’m really doing it: Starting next week, I will be a student at the Grace Hopper Program, an all-women’s branch of Fullstack Academy, one of the top coding bootcamps in NYC. If all goes well, by the end of 2017 I will be a full-time software developer.

My friends are shocked, but to be honest, this has been a long time coming.

My affinity for coding began when I was 11 years old, spending hours each day after school on the computer coding layouts for Xanga, Myspace, and Neopets user profiles and offering them free online to people around the world. I taught myself graphic design using early-Photoshop-alternatives Paint Shop Pro and Animation Shop 3, and my graphic tinkering quickly became an important creative outlet. What I loved most, however, was working with HTML and CSS, editing templates, figuring out the logic, and bringing my own ideas to life on the internet.

As I entered high school, I quickly found myself busy with a large workload from my honors and AP classes, and I promptly forgot about my early forays into computer science and design … but when I sat down to choose classes for my senior year, I discovered an unadvertised Computer Science class and took it as an elective. It wasn’t an honors-level course, and most of my classmates were uninterested kids who were only taking it to to cover their math credit and avoid dropping out, but no matter — I quickly fell in love with the subject. We learned C++, creating basic functions and programs, and I frequently annoyed my teacher, as I asked dozens of questions each class, always trying to go beyond the instructions, create something bigger and better. There was no doubt that I loved programming — how logical it was, how black-and-white, and how it required one to be so detail-oriented, a state of mind I already inhabited.

But despite what, in hindsight, was clearly a strong aptitude for computer science, I inexplicably didn’t feel “good enough” to pursue it. As I headed off to college, despite excelling in my CS class, I didn’t feel like I had “enough skills and knowledge” to apply for university-level engineering or computer science programs. What, exactly, constituted “enough skills and knowledge”? I had no idea, but I felt certain it must be more than what I possessed.

After high school, I gained admission to Penn, at which I majored in economics. Economics was a safe major — a major that would lead to jobs, and a major that I felt didn’t have any major prerequisites, like I felt tech had. When I applied for housing my first year, despite my non-technical major, I was randomly (and ironically) placed in a residential program called the “Science & Technology Wing”, full of the nerdiest and most enthusiastic engineering students on campus.

Living on “STWing”, as they affectionately called it, I felt acutely like Penny on the set of The Big Bang Theory — so alienated from my nerdy neighbors, but also secretly jealous of them. Most of them had been taking apart computers since they were twelve, and it was like they spoke another language. While I never admitted it, I wished more than anything that I could join their club. I wished I had the knowledge, the background, the je-ne-sais-quois that makes someone eligible to be a techie. But my mindset about it was inexplicably fixed, as if I could never learn. It was already too late. At the ripe old age of 18, the boat had already left, and I had missed it, forever doomed to the world of non-tech.

My final year at Penn, I had extra space in my schedule, so I took my school’s famous CIS-110 introductory Computer Science course as an elective. It was quite a difficult intro course in Java, but I loved spending countless hours completing the assignments. During lectures, however, my self-doubt would creep back in. I looked around at all the people in my class, most of whom were male, and many of whom I assumed were like my STWing peers, coding since they were wee tots. I occasionally thought back to my HTML/CSS background — I guess I had been coding for a long time, too … but this seemed different. These were kids who had built robots, who understood how to make apps …they were “real coders”. My mind had created an impenetrable block that forever deemed myself “not a real coder”, and so no matter how many men I outperformed on the test curve or project scores, I always felt inferior.

This isn’t meant to be a sob story about my own inferiority complex. The truth is, my experience reflects a widespread trend in the way women and minorities feel in the world of tech. The way I felt in that class mirrors the way many women (and men of color) feel even when they do make it through that initial self-doubt and enter the tech industry. And this impostor syndrome that plagues women in tech has a source — it is culturally instilled in us from a young age, seen in the gender-typing of childhood toys (robots for boys, art sets for girls) and in constant suggestions from media that women should be focusing their efforts on more superficial pursuits, like looking good (since that’s all we’re worth anyway, right?) These ideas, while obviously false, inevitably seep into our sense of self.

The cultural treatment of women also seeps into the way that men in tech think about us. For proof, one need only look at the never-ending stream of stories from women about the rampant misogyny they encounter in Silicon Valley (I’m looking at you, #Uber), and the sad statistics on female representation in tech.

This is a problem with wide-reaching implications if something doesn’t give. Women comprise the majority of the world’s population, and yet are dangerously underrepresented in an industry that is soon going to completely reframe the power structure in the labor economy. While this underrepresentation is likely a combination of both pipeline shortages and company bias in hiring decisions, I firmly believe both of these effects stem back to the cultural messaging about women that pervades and alters our sense of our aptitudes and abilities.

Of course, solving such deeply-rooted gender issues isn’t easy, and I certainly don’t believe it is the fault or sole responsibility of women to solve it. The idea of “impostor syndrome” can often be used as a way to gaslight women and minorities, to make us feel like it’s our own fault and we just need to overcome our own self-confidence issues. As Cate Huston writes,

“What we call imposter syndrome often reflects the reality of an environment that tells marginalized groups that we shouldn’t be confident, that our skills aren’t enough, that we won’t succeed — and when we do, our accomplishments won’t even be attributed to us. Yet imposter syndrome is treated as a personal problem to be overcome, a distortion in processing rather than a realistic reflection of the hostility, discrimination, and stereotyping that pervades tech culture.”

That said, while gender bias in tech is indeed a problem much larger than a single woman’s psyche, I do believe we women can do something profound to lessen it — we can start individually standing up, despite all of the culturally-induced doubt, and say: I am smart enough. I can do this. If we fight through the messaging and believe in ourselves in large enough numbers, I feel confident that we can begin to erode some of these barriers, and men will have no choice but to believe in us, too.

So this is me, after three unhappy post-collegiate years in non-technical professions, finally standing up to be counted. I’ve felt left out of the tech world (and secretly wanting in) for too damn long, and I hope that by combating my self-doubt and pursuing what I authentically want to pursue, I can be part of the solution. Maybe I can even inspire another girl like myself, wanting to do tech but feeling unqualified, to apply to that engineering program. And if you’re reading this and are long-past college, please don’t think it’s too late. It is never too late. Just open a Codecademy account already.

Since making the decision in December to get into tech, I’ve spent the last four months teaching myself JavaScript and gaining admission to the bootcamp I’m about to begin. As I’ve completed this prep-work, I’ve fallen absolutely in love with it. Some days, I can’t believe I ever thought that coding “wasn’t for me” …. and yet, most days, those doubts still hit me. I still harbor lingering fears that I’m not smart enough, not experienced enough, not “really coding”. I know that these doubts come from what our culture tells women about ourselves — about what we are, what we can do, what we can accomplish. Our unique power, however, comes from our ability to realize that the psychological cage we’re standing in has an open door. We can simply step out and do the things they always said we couldn’t.

Am I proud of myself for working hard enough to gain admission? Absolutely. Am I excited to be on a track to making significantly more money and having a job in which I get to challenge my brain and create cool things? Abso-freaking-lutely. But more than anything, I’m proud of myself for confronting my own fixed mindset — for deciding that I am good enough, and I do have the intelligence and potential to be a successful software developer.

Wish me luck at bootcamp! See you on the other side, in the world I’ve wanted to be part of for so long.

— — — — — — — — — — —
If you enjoyed this piece, I’d love it if you hit the green heart 💚 (or ‘clap’ for it) so others might stumble upon it. You can find my code on GitHub or my other projects at http://www.sophiaciocca.com.

F*ck impostor syndrome — I’m finally learning to code. was originally published in Personal Growth on Medium, where people are continuing the conversation by highlighting and responding to this story.