Teaching: A Critical Skill for Engineers

Teaching is a critical skill for engineers – but it’s undervalued by most of us. Engineers rarely consider teaching to be part of their education or personal development. And it’s rarely taken into account in a company’s hiring criteria. Yet teaching comes up often in daily engineering tasks: training new people, writing documentation, reviewing code, etc. Most of us work on a project with multiple engineers – so we’ll need to teach others how to use a function, library, or other component that we’ve written. Every time your organization makes a hire, the new person will need, at very least, to learn your specific code, tools, and processes. You’ll need to teach.

Start early

Personally, I didn’t make much of an effort to develop my teaching skills during high school and college. I thought that being a teaching fellow (TF) for a course would take a lot of my time. While I’d develop a greater mastery of the course material, TFing would take up time that I could otherwise spend working on new projects or learning new material. . I failed to consider how the experience of being a TF would give me skills in lecturing, mentoring, reviewing work, and relating with students that could later prove invaluable – even if I didn’t pursue a career in academia. With the benefit of hindsight, I’d encourage any student is to seek out such opportunities .

Talk to Teach

There are many opportunities for engineers to give talks or presentations about their technical work. Often, people approach these talks as a way to demonstrate what they’ve done and how much they know. That’s understandable – we all want respect from our colleagues.

But I’d propose that you’ll gain more respect – and be more effective – if you view those talks as an opportunity to teach others rather than merely demonstrate your own expertise. Whether you’re giving the talk at a conference or internally to your company, you should use your talk to teach others something new. While it’s fine to impress upon the audience the rigor of your subject, I’d argue that it’s more impressive if you can make that topic accessible and understandable despite that complexity.

Evaluate Thoughtfully

In a good organization, an engineer has numerous times when he’s called upon to evaluate the work of others. At Tuenti, we practice 360-degree evaluations – and peer evaluations form a hugely valuable part of that picture. On a daily basis, we expect engineers to review each other’s code and provide timely feedback.

Recognize these as teaching opportunities; try to understand where the gaps are in the other person’s knowledge and determine how you can help them fill those gaps. Recognize that how you offer the feedback – tone, concision, frequency – matters.

Ultimately, as engineers, we must recognize that teaching is an inherent part of what we do. We build, but we also need to teach others how to use what we build – and how to become builders themselves.

Google Spreadsheet Locales for an International Company

Tuenti, where I work, is a Spanish company, based in Madrid, with an English-language working environment.  One particular problem this causes is how to format dates, numbers, currencies, and spreadsheet functions.   We use Google Apps for everything – and within Google Apps, formatting conventions pose the biggest challenge in spreadsheet.  If some people are creating spreadsheets with Locale=Spain, and others with Locale=United States you have some serious problems: dates are entered erroneously, you must constantly switch how you type numbers/functions, and copy-and-paste creates multiple layers of issues.

My solution to reach a sane standard:

1. set Google Spreadsheet locale to UK (see Google Spreadsheets Help on Locales). This gives the EU date format convention (dd/mm/yyyy), the decimal point (period) as the decimal mark, and the comma to separate function arguments. Unfortunately, it creates the problem of having the default currency as GBP; buries the option to format in EUR several levels down in the UX, and completely removes option to format in EUR rounded. Therefore, you must

2. use a Google App Script menu to format values in EUR (€). Google App Script is immature and a bit buggy, but it allows you to easily add a custom menu to a spreadsheet, from which you can invoke a function that will apply a format to the “active” (selected by the cursor) in the spreadsheet.  This is exactly analogous to the UI of the native formatting functions Google has in the toolbar by default.

To accomplish this, I wrote a simple App Script to format cells as rounded euro values, following English conventions (eg “€1,000” rather than the Spain default of “1.000€”). It is available in the App Script Gallery (or will be, once Google approves it). To add it to your spreadsheet, follow Google’s instructions on Installing a Script from the Gallery.

While you can look at the code yourself from the gallery, I’ve also included it below in appendix 1.

Appendix I: The Code

 

Here’s the code of the script; it is pretty simple, but it’s about as much coding as I get to do these days. I’ve structured it to be extensible to add a lot of custom formats, using the syntax/semantics defined in appendix II.  Feel free to adapt it however you wish.

/*
 * format active range as EURO round, comma separator on thousands
 *
 * why? bc if you're using English in the spreadsheet, but
 * want to use euros as units Goog lacks a direct way to format it
 *
 * placement of currency sign is language dependent, not currency
 * dependent; a spreadsheet in english should have EURO-sign before
 * the number, not after.
 * http://en.wikipedia.org/wiki/Linguistic_issues_concerning_the_euro
 */
function formatEuroRound() {
  applyNumberFormat("€,###");
}

/**
 * applies a numberFormat to the active range
 */
function applyNumberFormat(formatString) {
  var range = SpreadsheetApp.getActiveRange();

  var format = [];
  for (var i=0; i < range.getHeight(); i++) {
    format[i] = [];
    for (var j=0; j < range.getWidth(); j++) {
      format[i][j] = formatString;
    }
  }

  range.setNumberFormats(format);
}

Appendix II: Number Formats

The Google App Script documentation of the Spreadsheets Service describes the setNumberFormat  method, but doesn’t provide any guidance on what the syntax/semantics for the formatString parameter is.  It appears that number formats in Google Spreadsheets follow some historical conventions they’ve inherited from Excel – and I presume other places.  A decent forum post directed me to a spreadsheet giving numerous examples of formatting strings.  You can look at that, in combination with the applyNumberFormat() function I gave above to create arbitrary formatting functions.

Innovative Talent: Identify. Empower. Lead.

This is the English version of my recent post (in Spanish)  for Think Big,  Telefonica’s blog on technology and entrepreneurship. 

Talent is the key to Tuenti’s success. Continuing to build and renew our talented team will be the foundation of our future. We strive to hire people smarter than ourselves, to always raise the bar, to always demand more. But we must go beyond finding talented people; we must create a place where they are free to move quickly, take risks, and challenge convention.

Identify. One of our key initiatives to identify talent is the Tuenti Challenge.  Now in its third year, the Challenge attracts thousands of engineering students to match wits against a set of computer science problems.  The best participants are invited to a final event in Madrid, where they compete in more challenges as small teams.  The winners –  incredibly bright, self-motivated people who are passionate about coding – receive prizes and job offers.

Empower. It is not enough to identify and hire talent; we need to empower these individuals to get things done.  At Tuenti, we strive to provide the environment and processes to do so:

  • We build cross-functional teams, trying to free each team to execute within their product area without any external dependencies.

  • We try to keep processes light, to have reviews done primarily by peers and tightly time-boxed to avoid delays.

  • We automate testing and tools to streamline integrating each team’s projects into our applications and websites.

Lead. A set of teams working mostly independently brings its own challenges. To harness their efforts into a single product demands effective, focused leadership; all the more so when your teams are full of ambitious, intelligent people who feel great personal ownership in what they’re doing.  You must articulate an overall vision, ask teams to own pieces of that vision,  but ultimately cull what they produce into a single, great, coherent product.  This will require that a lot of features – the result of months of personal efforts in which people feel great personal ownership – must be cut.  Great leadership will be able to motivate people around the overall vision even in the face of such personal disappointments.

Centering Tuenti’s culture around talent has gotten us far.  We’ve built a great core social networking product; we’ve pivoted to integrating that with a mobile operator – to create an innovative, cross-platform social communications service.  It includes some great features: cross-platform messaging (web / Android / iOS / Windows Phone / BlackBerry), voicemail in the cloud, social call history, app and web-based account management – but we are just starting on the journey. We look to our focus on talent – finding the best people, empowering them, and rallying them around the vision – to bring us our future success.

Engineering Across Platforms

This is cross-posted from the Tuenti Engineering blog, where it originally appeared on May 6th, 2013.

In the last year or so, we’ve been dealing with a big problem that many web 2.0 companies have also faced: Going mobile.

I’ve benefited from reading others’ thoughts on the subject, but we’ve learned quite a bit through our own experiences.  I’ll describe where we’ve come from and the six big changes we’re making to be a more cross-platform company, from the perspective of engineering management.  Hopefully you’ll find some of these lessons helpful for your team.

Web was our DNA

We were born in AJAX; our desktop web client was our flagship, in which we sought to produce a fast and rich user experience.  It was built to leverage the most compelling techniques that Javascript, in the latest web browsers, could provide. Our JS experts were the rockstars in the company, prized by our recruiters.  While we also built a simple, mobile version of the site, our intent was merely to give users a way to stay connected when they couldn’t access a “real” browser.  I don’t believe we were alone in this approach..

In 2007-08, mobile was niche; it was utilitarian. Tablets were clumsy novelty toys.  iPhones couldn’t run apps. There was something called WAP.  Android didn’t exist.  We saw mobile use cases like “entertain yourself on the bus”, “pull up the details about the event while you’re on the way”, “get notified when you’re tagged in a photo (with option to untag)”.  It was basic – get stuff done, keep in touch – when no better alternative existed.

What we were wrong about was how quickly mobile app platforms would become “good enough”. Not just good enough for those basic utility cases – but for just about everything. Sure a full size screen might give you larger photos and a keyboard might help you write messages more quickly – but people were more willing to accept slightly smaller photos and slower typing than we anticipated.

Where this left us, in 2010, was with an organization of about 150 people in development-related roles (product, design, qa, engineering, etc) geared towards our flagship JavaScript-based client.  We had Android, iOS, J2ME, and Blackberry development ongoing – but these were not where the balance of our people or attention lay.  This neglect showed in the tools and processes we had to support development on these platforms.

What we had to change

I’ll go through each in detail, but let me summarize the changes that we’re making to transform our engineering organization for this challenge:

  1. architecture of clients and services

  2. interdisciplinary, product-oriented project teams

  3. “core” client/framework teams that build base components and support project teams with expert-level advising and code review

  4. cross-platform training program

  5. more code review

Architecture of Clients and Services

We started as a big monolithic web app. That legacy remains.  What you experience on tuenti.com and m.tuenti.com is, in many places, a presentation/client layer that is quite tightly coupled to the backend data access/management layer that powers it.  It probably will be for a long time.

These backend layers – and the communication between those layers and the html/javascript “client” – were built first and foremost for a web context. The assumption is that our client is running in a user’s modern browser, fully capable of making multiple, parallel AJAX calls to our servers over a network that is usually fast and reliable.  Data structures, abstraction, logic, etc are all designed accordingly.  Our mobile clients – where this assumption does not hold as well – were a special-case, communicating with our data layer via an API that is, in truth, something of a client itself.

To improve things, we’re moving towards a more a more service-oriented architecture (SOA). Each backend component is a service, exposing a well-defined API.  Those APIs are designed not just for “web” clients that happen to run in the same PHP process but also remote clients. To the extent we have any kind of mobile-client-specific “API” layer, it functions as an adapter, attempting to be agnostic of both the particular service and client between which it’s mediating.

As we live in the real world, and have a massive set of products and services already running, most of our stuff doesn’t comply with this vision. But that’s where we’re moving.

Team Structure

We learned long ago that the best way to scale a product dev org was to have inter-disciplinary teams. The idea is that for all the typical work that might come the team’s way, they have, internally, someone with the skills to get it done.  They probably don’t have “the best” person in the company to do a given task; that’s OK.  The point is that they are empowered to execute within their area of product responsibility, with minimal external dependencies.

For web, this mostly worked.  We had teams with frontend engineers, backend engineers, and usually a designer, QA, and PM.  We eventually even eliminated the frontend vs backend distinction to encourage people to be generalists.  While I acknowledge that in practice people tend to get tracked one way or the other, the principle is that everyone should have the knowledge to work up and down the stack.  For the extreme expert work, we had some core framework teams (next section) that built core bits and could offer guidance to help people working on a product team, if they encountered something particularly esoteric.

 

We’re extending this same structure across our mobile applications.  For each feature that a team owns, they own that feature in each of client applications. Therefore, to be empowered to execute independently, they must have someone with the capability to build for that client.  We staff accordingly, trying to spread people with not only php/js knowledge across our teams, but with android and iOS knowledge as well.  As we recognize that work for a specific platform will vary for a team overtime, we want our people to be generalists, with the knowledge to work across more than one platform and we have created a training program (described below) to try to expand this.

Core Framework Teams

For a number of years, we’ve had core framework and infrastructure teams for the web. As with our project team model, we generalized this for other platforms by creating, for each client platform we build for, a “core” team to own that platform within Tuenti.

These core teams aren’t the main people building features for the platform. Rather, they build the base architecture and shared components, maintain a standard developer tool set for the platform, and define best practices and code standards.  Operationally, they advise teams building for the platform, review their code, and manage the final stages of the integration cycle for clients on the platform.

For our service platform (based in PHP), we similarly have a “backend platform” team that owns this layer, and performs analogous functions for services as the other teams do for clients.

Training

We were mostly web guys (and girls).  While we firmly hold the belief that programming languages are mere tools – and a good engineer chooses the appropriate tool for the situation – we certainly recognize that building for web vs mobile is about more than syntax and language features.  There are differences in paradigms: concurrency, memory management, connectivity, etc.  While most of us touched on these things back in university, a lot of these issues were safely ignored in day-to-day web work.

To change, we’ve introduced a cross-platform training programming to step people through building their competency in a new platform.

  • level 0 “Exposed” – we start people with self-guided reading and “get to know you” talks, to familiarize people with the platform.  This stage is aimed at giving you a flavor of the platform and background on mobile concepts, in preparation for more formal training.

  • level 1 “Set-up” is to give you a full, working environment of all our tools for the platform, a repo clone, and a very basic knowledge of our specific architecture. The idea is that, in principle, if told to fix a typo on screen 3 of the registration flow in the app, you could, after digging around for no more than an hour or two, get this done and commit your change back. We offer workshops led by experienced engineers to walk people through this.

  • level 2 “Capable” means you have sufficient understanding of the frameworks, app architecture, and tests to code a small changeset (bugfix, feature tweak) that will pass review. Engineers are assigned a mentor to help them, should they need any support in this.

  • levels 3+ “Comfortable” – at this point, you can do day-to-day work independently.  From there, it’s just increasing knowledge/comfort/productivity with the platform – tracked only for the purpose of balancing skills across teams to match the features they’re building.

More Code Review

We’ve practiced code review for a long time.  However, I would say that it used to be more of an encouraged best practice than an institutionalized (required) step in our dev process.  That’s had to change for several reasons:

  • First, while we want to empower anybody to work on any client/service, we can’t have a free-for-all; a specific team still owns each component and needs awareness/approval over what’s being done (and how).

  • Second, it’s a natural, organic way to train people, share knowledge, and have ongoing feedback flow between peers. These first two points mattered on web, but they matter even more when you multiply the clients each team must now worry about and the platforms on which a given engineer must develop.

  • Third, compared to our web apps, our mobile integration process is heavier and we ship less often, which means  the cost of a bad change reaching either 1) integration, or 2) production is much higher (as we can’t discover and fix/revert it in hours or less).  I’ll describe the integration/release process for mobile a bit more below.

To become more rigorous and embed code review in our process, we’re becoming more disciplined in our use of JIRA to track work and Crucible to review code.

Conclusion

Like any organization, we’re still a work in progress.  Changing the expectations and culture of 150 people is hard.  While the target vision will undoubtedly change before we’re 100% there, I’ve tried to give you an idea of how we’re facing a more cross-platform world.

I might follow up with some more details on specific topics. If you have any specific questions that you’d like me to address, feel free to ask them via Twitter or Quora.