Blog post: Developer on Fire
Tags: perl, rage, opinion
Published: 2019-03-08 20:20:59

---
title: Blog post: Developer on Fire
published: true
description: a podcast incident and a description of a Perl environment
tags: perl, rage, opinion
---
I have been mulling over this blog post for a number of days, I even had the title "The Podcast Incident" lined up, but just today I decided to give it the title "Developer on Fire".

The term "Developer on Fire" was not coined by me, but it is the title of [the podcast](https://developeronfire.com/) hosted by the marvelous podcaster Dave Rael ([@raelyard](https://twitter.com/raelyard)). I decided to, under the banner of artistic liberty, to use the title here,

I really enjoy Dave's interviews and he always gets his guests to tell incredibly interesting and honest stories - I am actually a long time fan and I can only recommend the podcast for stories with human aspects, perspective and interesting stories involving software development and technology.

In [episode #410](https://developeronfire.com/podcast/episode-410-adam-barr-character) Dave interviewed Adam Barr ([@AdamDavidBarr](https://twitter.com/adamdavidbarr)).

During the interview Adam stated the following (I hope the quote is somewhat correct):

> When you write a small piece of software you can write it in anything, You can write it in Perl for example. Which a lot of people do and then they say "Oh my gosh Perl is a great language, look how efficient I am I saved 5 keystrokes that is so great", Then they go write a large piece of software in Perl and realize it is not a very good idea.

This particular example rubbed me _the wrong way_.

It is not often I interact in debating or exchange of opinions on the Internet, but this triggered something deep in me and I decided to [tweet](https://twitter.com/jonasbn/status/1100325616501563392).

I often tweet about podcast episodes or other things of interest, but mostly with a positive attitude - and this was not one those tweets.

Next morning [Dave](https://twitter.com/raelyard/status/1100407974386749446) and [Adam](https://twitter.com/AdamDavidBarr/status/1100438574258745344) had both replied to my tweet and I already felt regret. The tension had settled down, I was thinking more clearly and I decided to interact. I do not want to go into detail with the tweets, since it is not the narrative I want for this blog post. You can probably find the tweets pretty easily and as you can read, we came to an understanding - which personally makes be very happy.

Now lets get back to the topic of **Perl** and let me explain why Adam's comment triggered me.

I have been writing **Perl** for more than ten years and I love **Perl**. Through all the years I have been a part of a large an incredibly talented community, where I count many of the members as friends.

**Perl** is called [the Swiss Army Chainsaw](http://www.catb.org/jargon/html/S/Swiss-Army-chainsaw.html) referring to the  [a Swiss Army Knife](https://en.wikipedia.org/wiki/Swiss_Army_knife) tool, because you can do a lot of things with in, it is a very generic programming language, all of this is quite important to understand, since I am by no means a spokes person for **Perl** or it's community, but what I have observed over the years is a community with a shared love and appreciation for _geekery_, hacks, language, code, interaction and occasionally beer.

Where I work we have a large code base consisting of several web services, both internally and externally facing, we have decided to use the modern web framework [Mojolicious](https://mojolicious.org/), alternatively we could have decided to use [Dancer](http://perldancer.org/). We have a huge set of libraries/modules all are kept in a local repository (**DarkPAN**), which resembles the official **CPAN** and it supports the same tool-chain, so we use all the same tools you use for open source development for our development and deployment. If you want to read more about the different PANs do read [this piece](http://www.olafalders.com/2019/02/19/about-the-various-pans/) by Olaf Alders ([@olafalders](https://twitter.com/olafalders)).

Our tool chain in addition consist of: `carton`, `cpanm`, `perlbrew`, the first being a variation of **Ruby's** [Bundler](https://bundler.io/) for **Perl**. It lets us handle dependencies etc. quite easily. `cpanm` is the client to interact with our **Perl** library repository and finally `perlbrew` is our _virtual_ environment letting us work with different versions of **Perl** avoiding the varies system **Perls** on our different hosts, similar to **Ruby's** `[rbenv](https://github.com/rbenv/rbenv)` and **Python's** `[virtualenv](https://virtualenv.pypa.io/en/stable/)`

We ran into some issues with **OpenSSL**, when Apple decided to discontinue support, so we started using **Docker** for local development and we plan to extend this further to our test and quality assurance set up.

Our databases are **Oracle** and **PostgreSQL**, so we use the incredible library [DBI](https://dbi.perl.org/) for database integration, some of my colleagues prefer the [Object-Relational Mapper](https://en.wikipedia.org/wiki/Object-relational_mapping) (ORM) [DBIx::Schema](https://metacpan.org/pod/DBIx::Class::Schema), I am not much of a ORM fan myself, but some of our applications make use of this.

Our web services make use of the Job worker [Minion](https://metacpan.org/pod/Minion) another product from the Mojolicious front.

In addition we use **Jenkins** for CI. **Git** for version control. **Jira** from issue tracking and production planning, **Ansible** for configuration management.

Our CI system is integrated with [Devel::Cover](https://metacpan.org/pod/Devel::Cover) and the whole family of test modules ranging [Test::More](https://metacpan.org/pod/Test::More) and on... in addition to **Postman** and **Selenium**. We do static analysis using [Perl::Critic](https://metacpan.org/pod/Perl::Critic), something we just started investing more time in.

Developers are free to pick tools, so we have developers coding in **Vi**/**Vim**, **Visual Studio Code** and **Komodo Editor**. On **Linux**, **MacOS** and **Windows**. Once in a while we resort to debugging using `gdb` or the marvelous graphical debugger offered by ActiveState in **KomodoIDE**.

**Perl** had gone over many changes over the years, one of the more significant is this book: ["Modern Perl"](http://modernperlbooks.com/) by Chromatic, _freely_ available online.

Now my key point was the **Perl** use, some parts of our code base are however implemented in other languages, so we have components, libraries and integrations in:

- JavaScript (Vanilla and jQuery)
- Java
- C# (.NET)
- Various shells (primarily Bash)

In addition to all the technology we develop software in a way that attempts to balance the actual development process with our business.

- [SCRUM](https://en.wikipedia.org/wiki/Scrum_(software_development)) with daily stand-ups, backlog refinements, sprint refinements and retrospectives
- [Design Sprints](https://en.wikipedia.org/wiki/Design_sprint)
- [User Stories](https://en.wikipedia.org/wiki/User_story)

**Perl** shows sign of aging, the community does not seem to be as vibrant as it used to be, many of the members are working on other languages and technologies etc. But we have a pretty sane setup, toolchain and architecture, yes we have bugs, and issues, but we have the tools and will to fix, address and develop our platform.

Our largest challenge is recruiting.

Anyway dissing **Perl** does not make recruiting easier for us, who still rely on some _legacy_ and does not have the mandate or team size to change everything over night or run with the latests fads.

I proposed a talk on how to tackle this for the O´Reilly Software Architecture conference in London, but it did not get accepted, so I might turn this into a blog post or two simply because the process might be interesting to others in a similar situation.

When somebody trashes or diss **Perl** or it's merits - I react, often not publicly, when reacting publicly I mostly use [this quote](https://www.goodreads.com/author/quotes/64947.Bjarne_Stroustrup) by Bjarne Stroustrup:

> “There are only two kinds of languages: the ones people complain about and the ones nobody uses.”
> ― Bjarne Stroustrup, The C++ Programming Language

But I got rubbed _the wrong way_ - and I bolted out of my comfort zone.

As stated on Twitter I would give the episode another listen and I did. I am a huge fan of the "Developer on Fire" podcast and the funny thing is that I am actually quite interested in the topic Adam is talking and writing about and I ordered two of his books, since I am always working on learning to work with what I do and the software which is the product, even if it is written in **Perl**. I believe I can learn something from Adam, since we actually agree on several points and most important "any given language might not be right for all problems and Adam has more experience than me.

You see I am normally a very happy and positive person, but I can get too engaged and involved, _on fire_ so to speak, so I really did regret tweeting in the fashion I did. I wrote to Dave and referenced one of [his older episodes](https://developeronfire.com/podcast/episode-259-terence-mcghee-visible-leadership) and interview with a guy named Terence McGhee, which resonated with me, give it a listen if you have similar experiences or behavioral pattern as me - another _developer on fire_.