Be a paradigm-agnostic developer
Software engineering > coding
Sunday 11 February 2024
Programming paradigms dictate the way programs are implemented - conceptually, they give them a specific structure, style, and characteristics. I use ‘paradigm-agnostic’ to mean someone who doesn’t constantly advocate specifically in favour of one programming paradigm.
Do you need to be paradigm-agnostic?
No.
Plenty of developers make a great living having learnt one language, and perhaps a relevant framework, as well.
So should you?
That depends on the kind of work you want to do, how far you’re taking your career, and, by extension, the kind of developer you want to be. I’d answer ‘yes’ for any of the following:
- Architecting systems
- Detecting anti-patterns
- Becoming a highly-experienced ‘senior developer’
- Reaching the mythological mythological unicorn developer of legend
- In rarer instances, when your favourite not-favourite language decides to migrate or include features from another (guess who had it easier when JS and React started leaning into the functional paradigm, ahem 👀)
Admittedly, these things are all related; I’d file them under ‘being a great software engineer’.
During an interview for which I was approached once upon a time, the interviewers (both tech people - the founder and CTO) specified that while solid React developers were aplenty and easy to come by (ouch), they wanted someone with strong programming skills: someone who could spot anti-patterns and be responsible for the health of their codebase. ‘Someone who can actually program’. That stuck with me.
If you’re going to be doing actual software engineering, and not simply coding, that suggests you’re moving across numerous projects with different languages, tooling, and architecture. To navigate them well - or, further to that - pick and use the right languages and tools for the project, being able to understand their applicability is important. Being able to use a variety makes you more employable as well as benefiting projects, too; a business may be less inclined to feel limited by their developers’ language knowledge.
Truly experienced developers will often have a personal preference, and that’s fine - but they won’t use this as a reason to pick something for a project, like children over Pokémon vs Digimon (did you just pick one internally? 😆). I know the line height isn’t especially large, but you should be able to read between them and hide that sort of paradismal behaviour if you ever feel inclined towards it.
How to get there
Learn different languages with different paradigms, if that wasn’t obvious. I’m sure it was. But do so with intention:
- One of the best things you can do is reinvent the wheel in different paradigms, across multiple languages (e.g. manipulating arrays) and understand how they work under the hood. This will help build the mental model for each paradigm. The more you work with them the easier it’ll get.
- Understand how algorithms and data structures are implemented within different paradigms.
- Learn best practices for various languages and tooling. You don’t have to memorise them all; it’s more about doing things well. Patterns will reveal themselves and those will stick.
- Actual understanding is important. Doing a course quickly with a couple of cookie-cutter projects isn’t necessarily going to consolidate that understanding internally. Be thorough.
I only realised how useful this was after I had done this for years, courtesy of my degree, and it’s something I recommend others to look for in their education. This was out of sheer luck; it’s difficult to be intentional about picking a degree as a noob.
If that’s something you decide to do, good luck - and don’t forget to make learning enjoyable!