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 hosted by the marvelous podcaster Dave Rael (@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 Dave interviewed Adam Barr (@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.

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 and Adam 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 referring to the a 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, alternatively we could have decided to use Dancer. 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 by Olaf Alders (@olafalders).

Our tool chain in addition consist of: carton, cpanm, perlbrew, the first being a variation of Ruby's Bundler 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 for database integration, some of my colleagues prefer the Object-Relational Mapper (ORM) DBIx::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 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 and the whole family of test modules ranging Test::More and on... in addition to Postman and Selenium. We do static analysis using 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" 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 with daily stand-ups, backlog refinements, sprint refinements and retrospectives
• Design Sprints
• User Stories

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 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 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.