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.