I’m a Consulting Software Engineer at 18F, who also helps lead a part of the engineering chapter as a supervisor and am involved in hiring, staffing, and business development for the chapter. I read and write code in JavaScript and Ruby mainly, but have also done work in Python, C#, and PHP. I also have a knack for Terraform and CircleCI configuration.

I consider myself a generalist when it comes to technical skills, but my focus is mainly around the web, including both the front-end and back-end of HTTP/S communications, caching and security, and WebSockets.

I live in Washington, DC, fondly in the U St/Cardozo neighborhood (previously in Trinidad and the H Street Corridor). I was born and raised in the western suburbs of Chicago (Woodridge), and lived in Kansas City, MO for a few years (Blue Hills, Crossroads, Columbus Park).

• I love to bike, walk, subway, bus, and generally not use cars to get around.

• Helping others learn programming concepts is important to me, and run an event called DC Code and Coffee every other Sunday to help folks network and learn from each other. I’m also a community builder and moderator on DC Tech Slack, a community of 10,000 technology workers around the DC area.

• I have a perpetual cross-stitching project which is based on one of Mary Daisy Arnold’s watercolor portraits of an avocado.

• I like experimenting with cocktails, and at the time of writing am into a mezcal/coconut cream/nutmeg drink.

• I like all sorts of music, but have a special spot in my heart for electronic dance music (Trance, among other sub-genres) and enjoy live events whenever possible at a few of DC’s venues, including U Street Music Hall, Soundcheck, and Echostage.

• I work in a bay window which is full of light and plants, including a grapefruit tree, succulents and aloe, an orchid, and a few others. Less glamorously, also a litter box.

Specifically, I’m working on learning additional conflict resolution styles. I typically trend towards avoiding/accommodating conflict and resolving through compromising or collaborating, and I’m especially focused on learning more assertive conflict resolution in a way that still leaves everyone feeling heard and understood.

More generally, before 18F at two previous positions I witnessed major leadership shifts which resulted in engineers quitting, being fired, or in the most extreme, a company splitting. I recognized these happening at the time — in the first instance, I quit and moved on before the company split. In the second, I was part of the casualties.

At 18F, I’ve been working to understand how different organizations function and focusing on my transparency and communication skills to help position myself into a role where I can help steer organizations away from (or through) the kinds of large-scale problems I’ve seen in the past.

• Be a cheerful presence in meetings and keep the work in perspective.

• Help with finding analogies!

• Put on a variety of different hats including leadership, project management, and note-taking when they are needed.

• Create clarity, documenting what I learn in a transparent way.

• As much as possible, I like to be able to plan out my day including when I’ll be away from my desk to take breaks. My work schedule shifts a bit as the winds of my life and seasons change — I’m generally available, but occasionally not. I feel bad for missing meetings if I am out on a break, so I find planning a bit in advance (2 - 3 hours of working time ahead) works best.

• If something I’m doing is troubling you, please let me know! I hope that we can work well together, and I probably don’t realize that I’m troubling you. I’d love for the opportunity to improve — please help me!

• I don’t always do a good job of avoiding internalizing the stress I feel at work, although I try (both to reduce that stress, and to avoid internalizing what can’t be reduced — making positive change is hard!). If you notice me acting frantically or unusual, I might be losing perspective and internalizing too much. A quick note to remember to take a day off or a step back would be appreciated!

• Keeping track of the work to be done, it’s relative priority, and where I can go for the “next task” when I’ve completed the current one helps me feel like the project is on track. I prefer a Trello Board or GitHub Projects to track this work, but I’m flexible.

• When it comes to accomplishing difficult tasks, I think it‘s sometimes easiest to work on them together. This includes pair programming, but also I really enjoy pair drafting for written communications — where we take turns brainstorming what we’d like to say while the other person takes notes. I find it’s easier to say what you want to say out-loud in some cases, and writing it down elegantly can block forward progress. We can sift through the notes as we go and create an outline, and then we’re unblocked!

• For code documentation, I find that Google Docs is great for collaborating but it’s really easy to lose them over time. I like collaborating on documents using Google Docs, but then deprecating them and moving the content to markdown in a GitHub repository. A win for transparency, too!

• I prefer to have consensus on a path forward on projects, but I prefer to have disagreement and discussion along the way to that consensus. If we don’t experience any disagreement or discussion, then I worry we’re not fully engaged or that one voice is dominating a conversation.

• It can be valuable to present a united front, specifically if we are being relied upon for guidance. It can also be valuable to bring others into the consensus-building process and present our individual ideas, if we’re being relied upon for information to assist in decision-making.

Thank you for giving me the opportunity to grow. Much like you, I only know I’m doing well or poorly based on the information I’m getting from those I work with, and without feedback, I can continue to stumble without knowing there is another way.

I generally prefer to receive positive feedback publicly and growth feedback privately. Sometimes it takes a walk or a break to process growth feedback, and if that’s the case, I’ll let you know and loop back with you after I’ve been able to internalize it well — I’d hate to disrespect the work you’ve put into helping me improve because of a knee-jerk emotion I wasn’t expecting!

Written feedback is okay, but I might ask to speak to you about it so I can make sure I’m understanding you correctly — reading tone in written words is sometimes difficult!

If you ever hear me using non-inclusive language by mistake, please feel free to call me in on the spot and let me know about it, whether we’re in a one-on-one meeting or in a large group. You can also find time to talk with me later one-on-one. I welcome correction and accountability, and always want to be learning and growing.