Speaking at Eurucamp was an eye-opening experience. I feel very much like a stereotypical American college student who visits Europe & returns to the U.S. “enlightened”. So, forgive me if I gush too much. Eurucamp this year was a single track conference with a good mix of non-technical and semi-technical talks. This was very nice because I was able to see all of the presentations. I could tell the organizers were extremely thoughtful in curating the selections and the order in which they were presented.
The conference was held at the University of Potsdam, located just outside of Berlin on the Griebnitzee. We stayed in the Avendi am Griebnitzsee and enjoyed beautiful views of the river from the hotel.
The Talks
As I mentioned before, all of the talks were truly great. There were a few that especially spoke to me though.
I, at least, hear all the time from product managers, project managers, sales engineers and the like claim to be “not very technical” then reveal that they have a CS degree or explain to me a complex technical system. Just because you’re not writing code every day doesn’t mean that you aren’t a “technical” person. You probably are, and you should embrace it and give yourself the credit you deserve!
Davy Stephenson spoke about orders of magnitude and how our inability as humans to understand very large or very small values hinders our ability to mitigate risk.
Here was one of my favorite slides from this talk:
Rebecca Poulson presented “The Junior Jump” and gave us all ideas for what we can do to help jr. developers be successful. This was a very refreshing perspective for me because I hav always felt that organizational change must be supported by actions of those at the top or those with authority. Many people (myself included) often provide all the advice to jr. developers and none to those who manage and mentor them. I think that if you’re really interesting in fostering talented people you really need to hear this talk.
Katherine Wu (you can call her kwu) presented on Ask vs. Guess culture. Chances are, if there is someone you have trouble communicating with, they are probably using the opposite communication style as you. Highlighting and understanding these differences can help very different people understand each other.
The best advice I believe I have ever been given about public speaking is this: “Believe that your audience has no knowledge about your subject but all of the capacity in the world to learn.”
When I presented this talk previously at RailsConf in Atlanta and at the Athens Developer User Group I was able to rely on the assumption that many of the audience knew who Amelia Bedelia is. At Eurucamp I found that she wasn’t as widely known and further, that I couldn’t expect everyone to know exactly what I meant when I said “idiom”. I did the thing I was afraid of, and swore I’d never do, I rewrote the introduction to my talk while at the conference! Too close for comfort for me, but if I wanted to get my point across I had to do it. Once I was presenting, I was really glad I decided to do this. Explaining a bit more at the beginning meant I didn’t have to worry if my audience had read enough Amelia Bedelia to find the talk engaging. They didn’t have experience with this particular book but given a little bit of information they had the ability to comprehend how the story worked and why I wrote it.
like all my best work, this talk re-write is being haphazardly thrown together the night before in a hotel bar
While I didn’t enjoy rewriting my talk the night before, I did enjoy the opportunity to get to know the audience better and create an experience that would be both enjoyable and instructional for them. This is a personal belief, but I feel that’s what I owe each audience I am presenting to, an enjoyable and instructional experience.
Here are the slides I used to accompany “Amelia Bedelia Learns to Code” at Eurucamp:
and here is the recording by ConFreaks (thanks to Eurucamp + sponsors for paying for this service!):
Speaking at a Technical Conference? That Sounds Like Fun
This was my first conference talk. I had spoken at a few user groups before which were decidedly smaller audiences. I even only spoke at the Atlanta Ruby User Group just the week before to practice. Until then, I’d been too scared to present in front of a group of what I consider Ruby experts.
I also figured, given I’m a novice speaker and that Rails Conf is fairly large they probably wouldn’t even accept my talk. So, what’s the risk right?
WRONG. My talk was accepted and now I would definitely be presenting it on a big (to me) stage in front of an audience (not my cat).
So What Does Kylie Do?
I was really nervous about speaking at a conference but I am really passionate about creating a culture of learning, so I did what I could to feel better about presenting.
I reminded myself that this talk was in the beginner track so the expectation was that it would be beneficial to beginners. As a sort of beginner-Ruby developer still I feel comfortable speaking to more beginner groups than advanced.
Why a Storybook? Why Not a Storybook?
I included in my application notes that I’d be presenting this as a storybook and I was worried that it wouldn’t go over well. Would adults tolerate being read to like children?
The selection committee picked my proposal, so I had to assume they didn’t think it was a terrible idea.
WAT
A lot of people (more than the 15 Atlanta developers at the conference) attended my talk, many of them seemed to enjoy it!
One guy laughed at every one of my jokes, and to him I’m eternally grateful (you can see in the video when we decide to be friends).
I was worried that people would just take this talk at its face value, a funny little story to break up the afternoon. I was pleasantly surprised with the reception it received though. The video doesn’t include this, but after the talk I asked people to talk about their mistakes. I was doubly surprised when so many of them (and not just beginners) volunteered their errors in front of the whole group. People came up to me after the talk and vowed to talk about their mistakes with their teams.
This Conference Talk Stuff is Fun
Preparing a conference talk was very stressful, but it seems like it has brought a lot of people joy. I think that in itself is worth the stress, so I might try to do another one in the future.
Here are some of the kind things people did in response to my talk:
Ernie Miller has unreasonably high expectations for me:
By the way folks, I want to say two things:
1. @KyFaSt is gonna tear up the conference circuit.
2. I knew her before she was famous.
❤️
There once was a web service who was not programmed with other developers in mind when he was originally written. To communicate any error, small or large, he took a great breath and sang out, “500! 500! The internal server has an error!”
The other developers came running to the error logs to help the web service drive the 500 error away. But when they arrived at the top of the logs, they found no 500. The web service laughed at the sight of their angry faces.
“Don’t cry ‘500’, web service,” said the developers, “when there’s no 500!” They went grumbling back out of the logs muttering “:q! and exit” under their breath.
Later, the web service sang out again, “500! 500! The internal server has an unspecified error!” To his naughty delight, he watched the developers ssh into the server and cd to logs to help him drive the 500 away.
When the developers saw no 500 they sternly said, “Save your frightened song for when there is really something wrong! Don’t cry ‘500’ when there is a more specific error!”
But the web service just grinned and watched them go grumbling back out of the logs once more.
Later, he had a REAL Internal Server Error, a power surge to the datacenter! Alarmed, he leaped to his feet and sang out as loudly as he could, “500! 500!”
But the developers thought he was trying to fool them again, and so they didn’t come.
At sunset, everyone wondered why the web service hadn’t hadn’t come back online. They went on to the server to find the web service. They found him wiped.
“There really was an internal server error! The data has scattered! I cried out, “500!” Why didn’t you come?”
A kindly developer tried to comfort the web service as they re-provisioned the servers.
“We’ll help you look for the lost data in the morning,” he said, putting his arm around the web service, “Nobody believes a liar…even when he is telling the truth!”
Full disclosure, I still consider myself a new-ish developer. I’ve only been in my current job for about a year (I was intern at the same company before hand but I kind of don’t count that). I’ve also been on the same project the entire time. That’s all to say, I haven’t been able to test these things out on a totally new project.
Read About the Dependencies
If you’re new to a Ruby project, read the whole Gemfile & find out what each of the gems do. Each of the gems (should) correspond to features or developer tools on the project. If it’s not a Ruby project, look up each of the non-standard libraries your project is dependent on. If your project doesn’t have a lot of non-standard libraries, there’s probably a reason for that. Maybe it’s an older project with no support for newer libraries. Maybe your product requires extremely strict auditing of outside tools so it makes more sense to roll your own. If you research the dependencies really well, you might even notice that a dependency is unused and can be removed (hello, first pull request).
Read and Write Tests
Your new project hopefully has some tests in place. Even if someone says “Oh our test suite needs work,” Read those tests! I have a lot of thoughts on tests, but the one that’s relevant here is the idea that a good test suite can be your app’s documentation. I definitely hear and understand the argument that good code should be it’s own documentation but in the real world I don’t think it’s always possible. Complicated logic might be a code smell, but if that’s the nature of the application then the true behavior might be easier for a newbie to parse from tests rather than the code itself.
More likely than not though, there are probably a few places in your new test suite that need coverage. You can use code climate (if your project has it set up) or ask someone on your team for units or features that need testing. You’ll learn a lot about the project & it’s a great way to add value for everyone on your team. A strong, trustworthy test suite inspires confidence in merges and deployments to production.
Pair Program
Pair program with everyone on your team. I wouldn’t try too hard to pick up a lot of new tools (unless you need them) right now, just try to get more knowledge of the domain. Unfortunately, many teams rely on tribal knowledge and the only way you’ll learn some of the quirks of your new is by hearing about them from someone else. More importantly though, you’ll get to know your new teammates. It’s much easier to interpret out-of-sync communications (emails, slack messages, comments on code review) charitably when you already have a good relationship with those on your team.
###Learning How to Join a Team
So what would I tell 1.5 years younger Kylie? You’re not having a hard time of this because you’re a newbie developer, you’re having a hard time of this because joining a new team is hard.
Don’t try to drink from the firehose on day 1. It’s tempting, you feel like because you’ve been hired as a developer that you’re expected to write great code from the start. You might be able to, but if you’re not don’t feel terrible. You don’t have the context of the whole project yet, and that’s okay as long as you have a plan.
Here’s a good plan until you start to get a hang of the project:
Read the Gemfile, figure out what this project depends on and why.
Read and write tests, tests can contain knowledge of user features and interesting edge cases that might be difficult to otherwise divine.
Pair program. Don’t schedule to pair once and then never do it again out of shyness. If someone tells you to pair with them whenever they’re available, take them up on this. Schedule to pair with each person on your new team at least 1x a week.
Letters to a Young Developer
This was part two of a series called “Letters to a Young Developer” where I’ll share the great advice I got, or the advice I wish I’d gotten when I first started learning Ruby. This post was written as a pre-cursor to a post I’ll write soon about moving from feeling like an individual contributor to feeling like a full team member. I was inspired by Kate Heddleston’s talk from GoGaRuCo on Technical OnBoarding, Training and Mentoring.
When I first started my current project, I had a lot of good internal resources from my company but I pretty quickly got muddled with all the new information. The stuff I wrote about here are the things I wish I’d kept in mind when I first onboarded.
Not everything on this blog will be about programming. I really enjoy my work, but only if I need a job. If I didn’t need a job, instead of writing terrible, terrible code I would write terrible, terrible comedy. Here are two very bad jokes I wrote for a very bad standup set for people who only want to hear jokes about animals:
Cats
Cats hate the smell of citrus because it reminds them of the time that they got way too drunk on El Presidente margaritas and got banned from Chilis.
Dogs
Dogs can’t have chocolate because they’re dieting.
