Software Engineering and Storytelling

Software Engineering and Storytelling

This is a well known metaphor in the industry, but many coders are not all that familiar with it.

I would contend that coders should think of themselves as actual storytellers on a daily basis, rather than just occasionally being reminded of the amusing little comparisons between reading a story, say, and reviewing someone else's code.

The User Story Concept

Agile pushed this into its very vernacular with the user story (and epic) concept. But all too many coders dismiss it as such - i.e. just a concept; simply a non-techie spiel concocted by the business-analyst/scrum-master that attempts to describe yet another random little feature that needs to be added to the application.

Caution

In my opinion, to devalue this concept and to ignore the fundamental precepts of both good and bad, and ugly, storytelling while writing code is a critical mistake!

A Culture of Impatience & Fear

Many coders (mostly inexperienced ones, but also those who should know better) tend to dive in when tasked with a particular assignment. Once the basic solution (typically a familiar pattern, already used in various other places in the application) has been conceived, very often there is precious little additional upfront planning prior to actually writing the code.

The on-demand culture of today suggests that one should just jump in and make the best stab at churning out the code. Even if your solution is going to have to end up being a bit kludgy and/or if it's going to require a bunch of code duplication, no matter, there's no time to think about the future, nor if some restructuring (refactoring) should happen right now (maybe later - yep, let's just add a TODO comment for now)... After all, we have to demo this stuff to the powers-that-be next Wednesday at sprint reviews and we certainly don't want our team to look bad!!

There tends to be a fixation on the here-and-now functional requirements, with little real thought for the non-functional requirements which tend to only bubble up to the surface in the mid-to-longer term - i.e. later on, when the code is struggling in production, customer churn is overpouring, and the sh*t has truly hit the proverbial fan (please excuse the expletive)!

Be Articulate

💡
Disclaimer: the following section is something of a sweeping generalization to suggest that we have a serious problem brewing...

In the age of social media, the dumbing down of natural language is of genuine concern on a global scale. Education systems tend to promote learn-by-rote rather than creativity and critical thinking, and would appear to have a blatant disregard for the skill of being articulate. Thus, the scholar is bombarded with multiple-choice checkboxes as the primary gauge!

It seems the newer generations are rarely encouraged to tell a story anymore, whether it be in the form of a written composition or some form of speaking to an audience, nor indeed to read a good book and broaden their minds and their vocabulary!

Coders learn Computer Science fundamentals in school, and then go get a job by ticking all the boxes. But, very often, once they are ensconced in their well-paid position, they tend to forget to adapt that knowledge in their everyday coding habits. I see it all the time... they'll claim to be object-oriented aficionados, for example, but when it comes to reviewing that PR, the code is bleeding with anti-pattern guilt.

This is where the more experienced developers need to step up today. We need to lead by example and promote the emergence of a highly articulate workforce across the board in this industry!

Be Brave and Be Creative

To conclude, I would tell all software engineers (as I do so repeatedly to myself):

  • to ignore the fearmongering and the self-centeredness in our current society,

  • to ignore those worries about "not getting it absolutely correct the first time",

  • to own up to your mistakes (poor design choices, bugs, etc.) - we are human, we all make mistakes!...,

  • to be okay with saying: "I need a little assistance, else I'm going to continue to bang my head against that typewriter for another fruitless 4 hours",

  • to push back: "We underestimated the complexity of the task, we need a little more time to do the right thing", and

  • to do one's homework, whether it be on your own personal time or that of the company's. Always be looking to improve at what you do every day, in the hope "that you will keep on growing in knowledge and understanding".

Remember: showing a little vulnerability, now and again, is a strength... just so long as you don't get too fond of it ;-)