… his passing has made me think about what it means to actually be who you say you want to be and have your life’s work reflect that. I hope I’ll be a little more honest in my work because of him.
Beautiful articulation of Aaron’s work and what we can all take away from his life’s work.
The hour’s approaching, just give it your best,
You’ve got to reach your prime.
That’s when you need to put yourself to the test,
And show us a passage of time.
We’re gonna need a montageCodeMontage improves your coding skills with real projects that matter. You’ll get real challenges that…
They say when you find the right person you just know.
Why do we embrace this notion for love and friend relationships, but create our most pivotal career relationships from job titles or at best, text-based inventories of skills? Mentoring is about so much more than a discrete transfer of skills - it’s about sharing the real failures and successes we inevitably encounter in our professional lives.
I’m grateful to have mentored as a technical lead, founder, and girl scout. I’ve had excellent short and long-term mentors and I’ve also connected with “mentors” who I wasn’t sure what to talk about with next. I’ve seen mentoring relationships between people of all ages and from casual to corporate environments and noticed a few common factors of success.
Chemistry
- You have to straight up like each other. Mentors must genuinely care about their mentees as individuals so they will share time and experiences openly, without resentment. Mentees must feel a strong enough connection to overcome the discomfort of asking tough questions and to internalize the mentor’s advice.
- Corporate mentoring programs tend to match purely based on divisions or job ranks, and their programs are valuable for networking, but rarely as effective as matches with an emotional bond.
Shared Values
- Sharing similar life values makes it more likely you’ll be comfortable with similar tactics for dealing with problems, and that you’ll both listen to each other.
For example - I believe strongly in the free culture movement. It would be hard for me to take the advice of a technical mentor who believed in technology that strongly limits use in order to protect copyright holders, such as DRM. Without a strong basis of shared values, the depth of our relationship and ability to explore solutions together would be limited. I also might snarl at them, which could compromise our chemistry. - Communities (vs. corporations) often spawn excellent mentoring relationships, even if they don’t deliberately facilitate, because of the strength of shared values among members.
Transparent Goals
- Both mentors and mentees must articulate and share their goals. Otherwise, you’re just hanging out.
- At the end of a session, and routinely during the active mentoring relationship, both sides should be able to ask “did you get what you hoped for out of this?”.
Once you’ve developed a relationship with someone you can learn from or share your knowledge with, the details of when, how, and how often suddenly don’t seem like such a chore. You’ll be free to focus on sharing and improving through mentorship.
Ready to mentor? Reach out to your communities and join the mentoring topic on Ohours*, which has additional tips for mentoring.
*Note: I’m an advisor and obsessive avid user of Ohours.
Debate is way too linear, and that problem grows with number of people and issue complexity. For example, 3 people sitting at a table would have no trouble reaching perfect, mutual understanding about whether or not orange is the new pink. On the other hand, 10,000 people in a stadium, even if…
First and foremost, Congratulations to Yoko Harada, one of this year’s Ruby Heroes! She’s made substantial contributions to the Ruby community, specifically for her work on open source projects JRuby and Nokogiri. Yoko inspired me to share an example of one of many projects that were possible thanks to free and open source software, and specifically Nokogiri.
In July 2011, Girl Develop It hosted a Hackathon for Humanity (in the Hamptons thanks to Deborah Jackson & JumpThru!), Nathan Hurst and I used Nokogiri to parse data from Backpage.com and flag potential evidence of human trafficking. We used wget to pull the posts and Nokogiri to parse the data into a Rails application and Postgres database, which I then queried to identify potential child prostitution advertisements. We were able to flag hundreds to be investigated and removed by Backpage.com.
The project readme file expands a bit on our methodology- basically, we’d read that many human trafficking rings tend to diversify their crime businesses by engaging in many types of trafficking and other illegal activity, so we cross-referenced some of the phone numbers across different subject areas on the site. We found dozens of posts that once examined by the human eye were clearly not legal, and hardly any false positives. This method proved quite accurate and a lot more manageable than manually sorting through all of the posts.
We definitely wouldn’t have pulled that off, especially not in a weekend hackathon, without Nokogiri being free, open source, and delightfully easy to use.
The project is on Github at https://github.com/girldevelopit/traffic-report. Note that this is the code from a one-time weekend project, but if you’re interested in forking or just learning from it and building a service to continue this work, please do! We’re happy to share any undocumented lessons or answer questions, just reach out by email (nathan@ohours.org or vanessa@developersforgood.org).
Last night I watched Soledad O’Brien’s CNN Black in America: The New Promised Land - Silicon Valley special that offered a lesser known perspective on an industry I know well. The special followed black entrepreneurs who participated in the first annual NewMe startup accelerator. After the special aired, I watched Mario Armstrong’s Town Hall and heard plenty of great advice from accomplished panelists of different races and backgrounds. In just an hour and a half they covered a range of cultural problems and shared opinions on solutions.
The best thing about pieces like this is that they focus on a problem and hopefully, get us all riled up to fix it - but do we? One of the audience members stood up and reminded the room that the change wasn’t going to come down from the panelists, but come up from them - that they had to make the change for themselves.
Right here and right now, I’d like to do something to address this problem. We heard over and over again the importance of networks and of having the right conversation with the right people. Entrepreneurs were advised to “insert” themselves into social circles of Silicon Valley. I agree with panelist/engineer/founder Hank Williams that taking baby steps is the key to both programming and life, so here’s my step for today:
I’ll be hosting open video chats specifically to mentor people who aren’t already in my established social circles.
Here’s My Open Mentoring Availability, starting with
- Thursday, November 17 at 1:00pm, 1:15pm, and 1:30pm ET
- Wednesday, November 23 at 2:00pm, 2:15pm, and 2:30pm ET
My goal is to make it less uncomfortable for new people to get involved in tech and startup communities.
I hope to see other leaders of these communities offer their time and guidance as well. I’ve written some and talked a whole lot about personal scheduling and efficiency, so I want to be clear that this is a relatively small, effective commitment - I plan to give 45 minutes to conversations with up to three new people and to spend the remaining 15 minutes of my alotted hour following up or laying the groundwork to help those people. This will amount to roughly one hour a week. If you’d like to help, too, consider joining the Ohours mentoring topic.
If you or anyone you know aspires to be an entrepreneur, engineer, teacher, computer scientist, wielder of data, or perhaps is now a girl scout, military brat, data lover, amateur organizational psychologist, blonde - or maybe none of the above, but would like to talk with someone who is - please send them my way. My door is wide open.
Laziness: The quality that makes you go to great effort to reduce overall energy expenditure.
Paperless Post Database Engineer and Girl Develop IT co-founder Vanessa Hurst recently sat down with GIRLS WHO ROCK for our Tech Thursday: Women in Tech Series.
Last Friday morning I woke up completely exhausted. Each previous day that week felt as if it shoud have been Friday, but disappointingly turned out to be just some anonymous middle-of-the-week day. I’m sure I don’t need to explain the intense psychological role the day Friday plays in our lives - we have internet sensations for that. But this Friday, instead of strolling into work late, taking extra long coffee breaks, catching up on blogs for hours, and mentally checking out right about lunchtime per the usual Friday routine in Corporate America - I did something different.
I got in the zone. I layed out the design for a project I’d been interested in but slightly intimidated by. Though aware I probably didn’t have enough time to get through it, I dove in. I had one meeting and two phone conferences scheduled that encroached on my maker’s schedule potential for the day, but I let my brain roam into the project anyway. I started with a brief work breakdown structure, gradually adding more detail as I reviewed the intermediate pieces all the way until I wrote the code as easily as I’d written the notes. Two meetings were postponed. By the time the third came around, I was in too deep.
I didn’t eat lunch, I barely noticed the office puppy, and I didn’t even refill my water glass for several hours. I just created. I wrote code, I tested, I rewrote, I tested, I simplified. I kept the entire project - a horizontal data slice of our entire application - in my head and just executed, piece by piece, until I had something I could push together and deploy so that anyone could perform this magic with just one command. Every step of the way presented new obstacles - merge conflicts, unfamiliar deploy tools, arbitrary configs to update - but they didn’t phase me. I was in the zone. I eventually grabbed a few goldfish and a new water glass while waiting on a test data import, but the buzz from powering through this intimidating project stayed with me.
I spend a lot of time dicussing the future of technology and especially diversity in technology for a variety of reasons - innovation, equality, national security, product quality to name a few. But it’s days like Friday, especially because it was Friday, that represent a more indulgent but also meaningful reason I hope people give technical careers a shot: passion.
I have extreme passion for what I do. I can work as if my sore eyes and empty stomach and dry throat don’t even exist because I absolutely love what I’m doing. I can get wholly absorbed in something that helps other people (my team, our customers), that I get paid for, and that makes me a better and more capable problem solver. I have complete intellectual freedom, and I’ve been able to experiment enough to find challenges that both frustrate and satisfy me. Beyond the essentials of food and shelter, I wish nothing more for other humans than that they might find their own zone. That they might know what it feels like to immerse themselves in something so deeply and so fully that time flies. Perhaps coding isn’t that for many people. I certainly never would have guessed it would be for me. And yet, programming took me from a potentially miserable, rainy day to an enthusiastic, high-on-life adrenaline-infused night.
This week, March 22-25, the PostgreSQL community (with guest appearances by MongoDB advocates & users) came to NYC for PG East 2011. At the beginning of the week I wasn’t sure how to manage my jealousy of those headed to GigaOm’s Structure Big Data (which, by the way, is at the same time and 5x more expensive), but I didn’t think twice about it while meeting and learning from members of the PG community. The days were a mix of talks and sharing war stories in the hallways, and the evenings included happy hours with the NY Postgres Users Group (if you’re in NYC, join!) and Paperless Post.
I gave a talk that briefly addresses what an ORM (Object-Relational Mapper) is and how they are great for application development, but can be a headache for DBAs. Most of the talk focuses on key factors to consider in evaluating an ORM and in maintaining and scaling systems that use ORMs. The intended audience for the talk is:
- DBAs curious if ORMs might actually be the devil
- Startups or development shops without a data expert on hand
- Lone DBAs or small DBA teams that are seriously outnumbered by developers using ORMs
- Developers who want to understand more about ensuring applications create usable data
- Developers using ORMs who think the database might be a performance bottleneck
Obviously the slides are never quite the same as a live talk, but I tried to make them somewhat independently valuable:
