On the benefits of speaking

I enjoy speaking in front of an audience.  This doesn’t mean I don’t get nervous. Oh, I get nervous enough that I really do need that drink of water. I still love it – the challenge of reacting to the audience, the desire to impart what I know into something meaningful for them.

The greatest feeling I can get from a talk is someone coming up afterwards to thank me for saying what I said. For someone quoting me to me. Hell, for rephrasing what I said more eloquently. But really, it’s about connecting.

But beyond that joy, what real benefits does it give me as the speaker? And, at the same time, what benefits could it provide you?

I want to share my recent revelation with you, something I truly discovered after my most recent talk at Atlassian Summit 13. I had submitted the talk proposal four months earlier. I proposed to talk about a project I was currently on, and about the lessons we had learned in trying to do all that we would try to do. It was a lessons-learned talk, a retrospective. At the time, I had no clue as to what I would end up talking about. I just knew that between the time I proposed the talk and the time it came upon me, I would have learned a few things along the way.

Knowledge

It was because of accepting this talk that I forced myself to really explore what was going on in the project. What I mean is that while I knew there were problems, I couldn’t just point to the problems and say, “See! Don’t do that!” I had to understand why the problems existed, and more importantly, I had to offer up solutions.

I also started going around to certain individuals to try and understand their point of view. That means discussing matters with members of QA, and the other programmers on the team. From them, I not only gained better insight, but also uncovered wonderful metaphors I could use to describe the problems we were facing.

My initial slide deck was structured in the same what that a refactoring recipe is often presented: a smell, followed by why these are problems, followed by solutions. It seemed simple enough. But this was really just the first step. When I started practicing the talk, I came to the realization that while the presentation was factual, it was also fairly negative, and focused too much on the problems. I had very specific points I wanted to make, and most of these points were small bullet points in the third slide of each Smell/Problem/Solution set. I was burying my lead at every point!

The process of practicing my speech, of doing the research to put it together, of talking to individuals drove me to the point of understanding not only the problems, but also how I could properly present the solutions.

But that’s the point. By accepting my role as a speaker, by agreeing to get in front of people to speak on a topic, I need to make sure I know what I’m talking about. So that means I’m going to research the heck out of my topic of choice. That might seem backwards, but it’s not. You see, you’ll want to speak on a topic you’re already familiar with, but once you realize you need to speak on that topic, you’ll force yourself to work extra hard, understanding the additional nuts and bolts.

In the same way that teaching something requires you to learn about it, speaking on a topic means you’ll spend that extra time. And it’s also a great way to learn something. Normally, we are trying to learn something so we understand it. However, when you have to speak about a topic, you have to learn how to describe it easily. You have to impart that knowledge onto others. That means not only understanding it, but understanding it well enough that you can share that information with your audience.

Basically, giving a talk forces you to learn more than you normally would.

Confidence

Since as far back as I could remember, I’ve never had an issue being in front of people. That’s not to say I don’t get nervous, but rather that I overcome that nervousness. I’ve been in plays, I’ve given talks on topics at local events, I’ve stood alone in front of hundreds, I’ve been a member of a panel; but a talk at a national event is distinctly different. Unlike most other cases, a talk at a conference is one where you are very much aware money was involved (usually a significant amount) and people are choosing to use some of their limited time at that conference to listen to you. You are keenly aware that they did not pay to listen to you, but rather, paid the conference in the hopes that they chose correctly when allowing you to speak.

It wasn’t until I got to Atlassian Summit that I fully realized the gravity of my decision to speak. It was far larger than I’d anticipated, and the audiences in each of the tracks easily went beyond 200 people. And not only were there a lot of people, but the caliber of these people were intimidating. Lockheed Martin, NASA, Disney and LG just to name a few. I’m pretty sure I’m forgetting even larger ones. The point for me was learning this, and knowing that I had to give a talk in front of these people Thursday morning. It’s not that I didn’t think I could give the talk. Rather, it was worry that my talk might not be worth their time. Will my talk make them feel as if that hour had been a waste?

Basically, I wasn’t confident my talk was of any value to the audience I was presenting in front of. I shouldn’t have been worried. A large company is still made up of small teams, and those small teams still have the same problems other small teams have. It wasn’t until after the talk that I truly understood that. In the end, the confidence I gained from giving that talk would help me reach higher and farther than I would normally.

I’m talking about the confidence you get after a talk. That feeling you get when you finish, several people come up to you, thanking you personally and wanting to talk further about what you just spent thirty-minutes to an hour talking about already. The thrills of having someone come up and quote you to you. Reaching people.

That confidence can’t be found any other way. You can only earn that confidence after speaking. And that confidence will stay with you far longer than other kinds. And in the end, it will help you drive yourself farther along, to push yourself further.

Friends

The opportunities to speak can also help bring new friends. I’m not speaking about the act of speaking. But speaking in front of new people means you are meeting new people. You are visiting new places. And that brings you new opportunities to make new friends that you would not have made otherwise.

And beyond just making new friends, you can also learn from other people. I’ve been lucky enough to hear interesting stories from people sharing what they’ve done. Even when what they do has nothing to do with what I’m going to talk about, I’m still learning, and making new friends.

The desire to share my knowledge, the desire to speak, gave me the opportunity to make new friends. Meeting up at local user groups and offering to share my knowledge put me in the spotlight. When I moved back to the US, the first friends outside of work that I made were those I made at user groups. Being active in the user group with talks presented me with opportunities to work with them, and in the end, become friends.

You should speak

You really should. You won’t start out in front of a large crowd. You’ll do it first in front of people you know such as coworkers at your company. You’ll branch out into local meet up groups, speaking on carefully selected topics. And maybe that’s as far as you’ll ever want to go. That’s fine. But maybe you’ll want to go farther. And you’ll love it.

You really should try. It can be scary. It is a challenge. It does take work. But it can be worth it. And it can take you places you would have never gone otherwise.

MeetMe’s 90s Tech Flashback

One of the things about working in the tech industry is that we’ve collectively embraced our inner geeks to the point that our profession has become cool. We’ve always known it, but the outside world hasn’t always been as in touch, inadvertently portraying us as socially inept nerds. (To be fair, Bill Gates’s hair style probably set us back a few years on its own.) With software development as prevalent and dominant as it is, there is no longer as much of a negative connotation toward our industry. We wanted to revisit these times before the rest of the world started paying attention, when the tech world was still a little bit awkward.

This slideshow requires JavaScript.

If this interests you, consider applying to work at MeetMe.

How MeetMe Went International on Android

Our engineering team has been working hard to implement full internationalization (i18n), including localization (L10n) support. MeetMe sees international support as mutually beneficial for its members and the business. Through full i18n and L10n support, we provide a user experience that our current members want and some of our future members need. Internationalizing is great, and it makes the experience much better for native speakers, but it didn’t come without its own unique challenges in product, design, engineering, or quality assurance.

Preparing for internationalization

Stringification — ensuring text strings aren’t hard-coded — is one of the biggest pieces of prep-work for i18n in any project. Strings are used for user-facing text in UI components like buttons and labels. In Android, text strings are stored in a format known as string resources. Strings need to be extracted from any code and pushed into string resources. While we were working on i18n, we were fortunate enough to have the Android Lint tool which (among other things) identifies and reports hard-coded strings. If we did stringification early, that meant we could get the strings translated early (we used machine translation for development testing) and we could show our product and QA team just how badass we were. Our first pass was fairly simple: at least 90% of the application was already stringified. Supporting internationalization from the early stages saved us time in both testing and implementation. Having to refactor code is almost never a simple task, so having done it “the right way” from the beginning made it easy for us in the end.

As an example, in your application and within your layout code, let’s say you have an EditText view control with a hint. The hint may be a literal attribute value of the node. That value, android:hint="Email address" should be moved to a string resource to allow for different translations of that string. In your strings file (located in res/values/strings.xml, very likely) the node becomes <string name="email_hint">Email address</string> and your EditText’s hint attribute becomes android:hint="@string/email_hint" where @string/ denotes a string resource and email_hint is the value of the name attribute from your strings (strings.xml) file.

 

Translating all the strings

After we went through our initial stringification and machine translation, we needed to adopt a process for ingesting new and modified strings so they could be sent for translation without resending the already-translated strings. To do this, we endured a manual process for tracking strings changes. Each time a change was merged into our internal i18n branch, we reviewed the diff of our strings file, gathering new keys, and entering them into a file to be packaged for translation. Once translated, we had to import the new strings into localized strings files (under folders denoted with the appropriate qualifiers as per the “Configuration qualifier names” table. For Spanish (language code “es”), we placed our converted strings into /res/values-es/strings.xml. Once imported, code had to be committed, code reviewed, QA’d (to ensure different string lengths didn’t cause unexpected layout issues, which they sometimes did), and merged.

Using the aforementioned email_hint example, the original value in the strings file looks like
<string name="email_hint">Email address</string>
and then the Spanish strings (res/values-es/strings.xml) file has
<string name="email_hint">Dirección de correo electrónico</string>

Troubleshooting i18n layout issues

As previously mentioned, internationalized strings have different lengths and can sometimes cause unexpected issues related to the design and layout of an application. A Button or ListView item’s height or width may be adversely effected by a longer string, or a given layout may not implement fluidity to ensure proper layout display. Compensating for these issues typically works either through a fluid layout design or by rewording the string.

Fluid layout

The first way, introducing fluidity into a layout, can often help as it allows the view to expand or contract dependent upon the length of the string.

For example, a Button in English might be one line worth of text; in Spanish, the verbiage might be longer, creating the need to wrap the text to multiple lines. This type of layout is typically achieved by using non-static units for widths and heights, such as wrap_content (see Layout Params).

 

Rewording text

The second way, wording text for brevity, can be used to try to shorten the string to fit within the allotted space. Perhaps your layout has two buttons side-by-side with no additional vertical space to expand into. In that case, this technique is especially useful. For cases where we determined that this was the best solution, we marked our strings files with a custom attribute denoting that the length of the text should be as brief as possible and attempted to be fit into the existing character count of the English phrase.

Localizing

Users outside of the US/UK see kilometers instead of miles

Localization refers to the process of adapting or converting for use in another language, especially the support of regional local features like timezones, currency, distance units (imperial versus metric) and formatting of dates, times, numbers (decimals, percentages, currencies) and distances. Most of this functionality is afforded to the developer on Android through classes like Calendar, Date, DateUtils, and NumberFormat (as well as its children). Distances were a special case. If we wanted to show 13 ft, 18 mi, 24 km (in cases like Feed and Locals), we needed to implement it ourselves. Our implementation was as follows: if the user’s Locale country is US or UK, use imperial units; otherwise, use metric units. This doesn’t account for the UK’s switching of imperial/metric based on type of measurement (short distances are in metric, long distances in imperial), but we didn’t feel that needed to be implemented at this juncture since we only use the units for distances traveled (as the crow flies).

Strings from API responses

Success and Errors

One of our biggest problems with our English implementation was that a number of our UX responses depended on success and error strings from our API. This was an obvious downfall to our implementation and was already being revamped to localize strings to the device prior to the internationalization process being kicked off. That revamp didn’t really do much for our existing endpoints, as most of the errors that we were localizing were for new features. To localize errors, we used a straightforward structure: errorType & errorCode. Error types are unique (Exception class names from the API side) and error codes are unique to each error type they’re sent with. This mapping allowed us to easily gather all of the exceptions being thrown by our API, and map them on the device side to have them made into user-facing strings. Stringification of errors consumed a big chunk of development time as there are a lot of possible error cases — especially when it comes to validating, sanitizing, and approving user-generated content.

On one side of the coin, this couple of APIs is a nicety for our platforms. The API gets to define a strict set of error cases and limit the data throughput which is beneficial to both the device and the server architecture. Additionally, we don’t have to count on a minor change to an error string causing internationalization problems on the device due to string comparison issues. On the flip side, coupling these values puts a constraint on the API that it must maintain both that error type and code until such a time that the device may be able to update to a newer type or code. The reason that is an issue for us is due to the nature of our code file architecture. Code is shared throughout our services in order to attempt to avoid code duplication. While that’s good, what we don’t have is that code shared with the native platform. So a change reflecting constant value on the API doesn’t automatically get reflected within the device.

Ultimately, if an API error code can’t be mapped to a known code on the device, the user will be presented with the ubiquitous, default error string: “Something went awry.”

Region names

Another hurdle in the API-to-device transition was the internationalization of regional names (countries, states, regions, counties, cities, etc). For example, in English, the display name of the country for US (ISO 3166-1) is “United States” and is “Estados Unidos” in Español. On top of that, the abbreviation for the country varies by region. For US in US it is “US” but for US in ES it is “EE. UU.” To be honest, we didn’t truly conquer this challenge yet. For regions, we chose only to translate country names. Furthermore, that translation is done dynamically through a service we’re using called “Smartling.” Smartling acts as a proxy between the client and the origin; Smartling retrieves the request from the client, mimics the request to origin (our API), parses the response, replaces English strings with the translated strings for the requested language, and responds to the client with full translated content.

Our response originally comes out as ["AFGHANISTAN","ALBANIA","ALGERIA", ...] and is translated (based on the requested language, es-es in this example) to ["AFGANISTÁN","ALBANIA","ARGELIA", ...].

Conclusion

Internationalizing our Android application certainly wasn’t an easy task given some of the roadblocks and caveats we ran into, but we’re confident we finalized with a solid product and implementation that will continue to give our members a quality experience from end to end.

Check out the internationalized version of the MeetMe app for Android on Google Play.

If this type of challenge interests you, consider applying to work at MeetMe.