IN/Clojure 2020

India's annual Clojure and ClojureScript conference. 14th-15th Feb, 2020. Pune, MH, IN.

Growing a Clojure Company from small to mid-sized (and hopefully beyond): tips, tricks, habits, practices

Submitted by Vedang Manerikar (@vedang) on Dec 31, 2019

🌓 Submission Type: Crisp (20 minutes) Status: Confirmed & scheduled

Abstract

This is a crisp talk targeting engineers in leadership roles in Clojure companies. I will cover our experience at Helpshift, growing from 5 Clojure engineers to 30+ today. I will talk about:
1. Clojure as a force-multiplier in a small company
2. Clojure as a way to attract a certain kind of talent
3. Problems as the company grows. Specific things around Clojure that have worked for us over time.
- Hiring senior vs junior talent. Problems and solutions around both sets of people.
- How Clojure can get in the way, and how to deal with this.
4. Comparison of using Clojure and language patterns at a small company vs a mid-sized company.
- Prerequisites for growing a Clojure company successfully.
- Challenges specific to mid-sized companies
- Why I’m hopeful about a large-sized company that has grown this way.

While this talk and my experience is specific to Clojure, I believe that the underlying principles apply to growing a company successfully using any other niche language. I’ll go so far as to say that many of the problems are universal and plague “standard” companies using “standard” languages as well.

Outline

Clojure as a force multiplier in small companies.

Startups are fast, and Clojure startups are even faster

  • REPL: the best tool for iterative changes in dev and production
    • Fast turn-around on bug fixes makes for impressed customers.
  • The testing story of Clojure is incredible.
    • The ability to redefine functions means that writing complex tests is simpler than in popular languages like C, Java, Python.
  • The compatibility story of Clojure is incredible.
    • Upgrading Clojure is often just changing the version number to the latest version number

Clojure as a language choice

  • Lisp, imposes great constraints, like immutability. Dynamic typing is great for rapid iteration.
  • “I bet there’s a Java library for this.” > JVM + interop is a super power.
    • Packaging as a Jar means deployment is an understood and solved problem.
  • Clojure attracts a certain kind of programmer: opinionated, passionate, experienced.
  • It is an easy language to learn for a new comer. Blank slate can absorb and get started incredibly fast.

The Clojure mess: Going from small to medium - people

  • Going from < 10 Clojure engineers to > 10 Clojure engineers.

Onboarding and training

  • For a Clojure company, focusing on onboarding and training is a full-time job.
  • How we went from 6 months to 2 months needed for making a new engineer productive.
    • Our mentoring program, what we do in the first month
  • Personal opinion: Why being forced to do this is a good thing.

Senior vs Junior talent

  • With a good onboarding program in place, hiring and growing junior talent is easy and rewarding.
    • Junior devs are the best folk to improve your onboarding programs.
    • Optimize for self-driven individuals and listen to their feedback.
  • Hiring senior talent is hard.
    • Why? Challenges and dealing with self-doubt, unlearning.
    • Improving onboarding for senior engineers.

The Clojure mess: Going from small to medium - language

As a small company, build any way you want, just ship fast.

  • Hello macros and DSLs for everything. Sections of code become personal fiefdoms - understandable only to the authors.
    • This works fine for small code-bases and small teams, but starts to be a problem as the team grows.
  • Clojure is an expressive language, so people have built libraries for everything.
    • core.async, core.spec, core.typed, core.logic
    • And this is just the core.

The medium company brings the reality of the common denominator.

  • Understanding the code can become a challenge. How to deal with this.

What can you do to make this better?

  • Process around committing code.
  • Dealing with and abstracting common patterns. Each person should do these in the same way, via the same libraries.
  • Using templates of code in projects
    • A new project should have a predictable layout, with necessary libraries imported and base code written in.
    • Reviewers should know exactly what they need to review, and should be able to safely ignore the rest.
  • Exploring new / complex features of the core language in a deliberate manner

A large Clojure company: an amazing vision

  • What we can do when we have bandwidth to dedicate senior Clojure devs to projects which don’t immediately focus on customers / features.

Closing thoughts: Mid-sized companies, Clojure, perspective building

Speaker bio

Hi! I’m Vedang. I live in Pune, India and work at Helpshift. Now-a-days, I head the Helpshift Core backend team and work on improving processes and workflows within the team with the help of my team mates. Previously, I was an individual contributor and helped design and write some of the code that runs Helpshift.

I’m passionate about programming, and some of my work can be found on GitHub. I use Emacs as my editor-for-everything, and blog about it from time to time.

Links

Comments

{{ gettext('Login to leave a comment') }}

{{ gettext('You need to be a participant to comment.') }}

{{ formTitle }}
{{ gettext('Post a comment...') }}
{{ gettext('New comment') }}

{{ errorMsg }}