Discover “Pro D3.js”, a new book to improve your JavaScript data visualizations

D3.js is the de facto standard JavaScript library for building interactive data visualizations on the Web. When beginning a new D3.js project, developers usually start by taking one of the community’s many examples and using it to jumpstart new work. This is a convenient way to get something working fast so that they can iterate over it. However, by working this way, you soon struggle to maintain, extend, or modify your charts. D3.js examples are made to demonstrate implementations and techniques, not to ship them to production.

Discover “Pro D3.js”, the new book that walks you through the creation of maintainable, modular, and testable charts. You will also learn how to package and document your visualizations, producing open-source libraries. Read on to learn more about the book and its contents. Continue reading “Discover “Pro D3.js”, a new book to improve your JavaScript data visualizations”

Simple and Easy Mentorship with a Mentoring Agreement

Two girls talking

Mentoring is hard. Mentors and mentees usually have many things on their respective tables between work, personal projects, and their training paths. Learning opportunities are infinite, but the time available is not. How can we foster productive mentoring relationships without consuming our time communicating and aligning our expectations?

Read on to learn how a mentoring agreement can help you streamline the mentor-mentee relationship, making communications more efficient, and setting the – sometimes hidden – expectations on both sides of the deal.

My struggles navigating the mentorship program

At Eventbrite, we run an engineer mentorship program. During six months, developers and leaders both mentor and receive mentorship from their peers. A committee matches participants depending on the skills they want to learn or teach.

The program has happened a couple of times already, and I have always had hardworking mentees and great mentors. However, during the initial cycle, I struggled with several aspects of the relationship. The first issue was accountability and commitment: How could I motivate my mentees to get things done and make the most of our time? Also, how do I continue to motivate without coming off as pushy or too demanding? Other challenges I faced were inefficient communications or lack of clarity in terms of goals and expectations. As a mentee myself, I assumed my mentors might be experiencing similar challenges.

With these issues in mind and craving to improve, I did some research and looked for solutions. Inspired by 6 Things Every Mentor Should Do and Kim Clayton’s talk Overcoming the Challenges of Mentoring, I arrived at a process that includes a mentoring kickoff meeting, where mentor and mentee discuss a mentoring agreement.

The mentoring kickoff meeting

The mentoring kickoff meeting is a quick gathering where mentor and mentee set goals and talk about how they will measure their achievement. In that meeting, you could also:

  • Set hourly commitments and cadence of meetings and communications.
  • Draft a plan of action for the whole mentorship period.
  • Arrange a review meeting later on, where you and your mentor/mentee can sit down to evaluate the relationship.

However, the most critical part of the kickoff meeting is to read, understand and clarify the points of the mentoring agreement.

What is a mentoring agreement?

A mentoring agreement is a reference document where mentor and mentee agree what are their commitments during the period they work together.

A mentoring agreement can enrich the mentor-mentee relationship with the following qualities:

  • Clear expectations. The agreement highlights what mentor and mentee are going to do, establishing a two-way relationship. The shared expectations also make accountability an official part of the mentorship experience and also help with identifying areas where either mentor or mentee need extra support.
  • Honest communication. The agreement specifies how communication should happen between the two participants, establishing the channels you are going to use and striving for open and transparent communication.
  • Goals and deadline setting. Discussing what the mentee will do and agreeing to a timeline is an essential component of this document, especially in terms of keeping both parties on track and the overall experience productive. You need to know what success looks like to achieve it.

I like to keep the mentoring agreement short, with five to eight bullet points per role. Some points are intentionally vague, leaving room for interpretation and ongoing discussion.

My agreement

Here is the mentoring agreement that I propose to my mentors and mentees for a healthy and productive relationship:

A Mentor

  • Is there to offer support as a guide
  • Will push the mentee to produce their best work
  • Acknowledges the work put forward by the mentee
  • Prepares the mentee to become a mentor

A Mentee

  • Must finish homework on time and with a quality
  • Will graduate after <agreed period>
  • Should let the mentor know if anything is not clear
  • Sets the meeting agenda and shares it with enough time for the mentor to prepare
  • Suggests activities and exercises to do together
  • Welcomes constructive criticism
  • Should keep the relationship going

Both Mentor and Mentee

  • Should be responsive and communicative
  • Should get to know each other

The value of a process

Subscribing to a mentoring agreement sets the expectations of the mentor-mentee relationship, streamlines communication and highlights the goals and deadlines of the interaction.

Although you could say this is all common sense, there is value in making the shared terms explicit. It is more efficient, as you compress several conversations into one. Moreover, you demonstrate the value you bring to the mentorship experience by running it like a pro.

In my first try, this agreement has worked well: it reduced communication overhead, and my relationships have been more productive. I will admit that from time to time I have let a deadline slide for fear of affecting the relationship. I know! I should stick to the agreement, but I guess that’s material for another blog post.

Would you add anything else to this agreement? Is there something you think is helpful to mention? Drop me some lines below or ping me on Twitter @golodhros.

Photo by Mimi Thian on Unsplash

Introducing Britecharts: Eventbrite’s Reusable Charting Library Based on D3

The usual workflow when developing interactive data visualizations with D3.js is based on the significant number of examples that the D3 community provides. They are broad and useful, but they are still not ideal. Most of the time, they require a lot of effort to integrate into your code and to make them production-ready.

In a previous series of posts about Leveling Up D3, I talked about a different way of building D3.js charts, using the Reusable API, building our components via TDD and improving them with events and refactorings. Following those ideas, and with the help of Eventbrite’s design team, we have been working on our chart library, and now we want to share it with you. It’s called Britecharts.

Continue reading “Introducing Britecharts: Eventbrite’s Reusable Charting Library Based on D3”

Leveling Up D3: Events and Refactorings

This is the third and final post in the Leveling Up D3 series. In the first post, we talked about the Reusable Chart API and its advantages. And in the second article, we test-drove a basic bar char. In this post, we will carry out some refactoring and optimizations made possible by our new, shiny, and high-quality code.

Personal Note

I love refactoring and evolving my code, as I greatly value being proud of the code I produce. In general terms, in the Software Development field, it is pretty common to introduce bugs when new features are added to a product. This obviously isn’t ideal, but people have gotten used to it.

However, when we talk about improving a piece of code that is already on production, organizations do not like adding bugs when pushing those changes. And that’s why the previous steps were so important. Without the tests generated in the last post, we wouldn’t have the necessary confidence to refactor our charts code once it had been shipped.

Continue reading “Leveling Up D3: Events and Refactorings”

Commenting JavaScript code with JSDoc

Software developers do not document their code very often, that’s especially true for JavaScript. That’s a problem when they jump into parts of the code they are not familiar with (or they forgot about) and there are no docs or comments.
How can we avoid this? In this post, I will talk about how you can use JSDoc comments to clarify your JavaScript code and generate documentation for it.

My Experience

Some months ago, I spent some time reading a bit about JSDoc. I found it really interesting, so I decided to use JSDoc comments in the next projects I tackled at Eventbrite.

Over the last few months, I had the chance to use JSDoc comments in three ‘types’ of codebases that I think represent three different archetypes of code. Let me introduce you to them: I’m breaking it down into The Good, The Bad & The Ugly.

Continue reading “Commenting JavaScript code with JSDoc”

Leveling Up D3: Test Driven Development

In the previous post, I introduced the Reusable Chart API and its multiple benefits when compared to the standard example-based approach of building D3 charts. This time, I will go into deeper detail about how you can further advance your workflow. By using Test-Driven Development when building your D3 charts, you will be able to embrace change, mercilessly refactor your code and at the same time, get executable documentation for your components.

tdd-d3-rgr

I’ll walk you through the creation of a simple bar chart using Test-Driven Development (TDD). But first, let’s compare this with a common approach to writing d3 code.

Continue reading “Leveling Up D3: Test Driven Development”

Leveling up D3: The Reusable Chart API

This is the first post in a series where I’ll show you how to improve D3 charts. My goal is to help you build D3 charts in a less painful way  by using the Reusable API, a Test Driven approach and good quality code.

Britecharts line chart example

In this first post, I’ll demonstrate why the Reusable API pattern is so amazing. In the next post in this series, I’ll cover how to craft a bar chart test-by-test, following a TDD approach. A third post will deal with more advanced refactoring facilitated by our new high quality code, like improved accessors and event handling.

Continue reading “Leveling up D3: The Reusable Chart API”

What I’m Reading: 15 of My Favorite Web Development Newsletters

Updated on September 16, 2017

Added Versioning, Frontend Focus, Web Animation Weekly and removed those that are not being released anymore.

Keeping up to date with the ever-changing world of web development is tricky. You can either get overwhelmed by the amount of JavaScript frameworks and new shiny projects that promise you 10x productivity or you can just say, to hell with it and pray not to be left behind in the web development world.

Don’t desperate; we have you covered! In this post, I will walk you through the benefits of newsletters as a source of web development related news, and I will also recommend some of my personal favorites.

Continue reading “What I’m Reading: 15 of My Favorite Web Development Newsletters”

Readable JavaScript Tests with Object Builders

Building objects purely for testing purposes is often tedious. Let’s walk through the wondrous world of using design patterns to improve your JavaScript tests.

Over the past weeks we’ve been porting features to our new Event pages. Events are complicated, and the front end of the event page that supports them is feature-rich and has to deal with all sorts of different states an event can be in, in addition to all the types of ticket an event can have. As you can imagine, writing tests to cater for all these different scenarios can get tricky fast.

Continue reading “Readable JavaScript Tests with Object Builders”