I’ve been programming since 1996, when I taught myself Perl 2 from a 600+ page book and 3.5″ floppy disk. Yes, disk, not disc. K, as in kuadralateral, not C as in sircle. I have since written code in:
- over a dozen high-level languages: Perl, JavaScript (ECMAScripts1-6, ActionScript, Google Apps Script), Pascal, Turbo Pascal, Java, , PHP, Visual Basic, C++, C, QBasic, Ruby, Python, C#
- low level assemblers: x86, 68k
- transpiling/syntactical superset languages: Typescript, Dart, CoffeeScript
- over a half dozen markup languages and styling tools: HTML2/3/4/5, xHTML, XML, SGML, CSS, SASS, Less
- and a smattering of really useful though sometimes frustrating macro/command languages: VBA, LaTeX, BASH, Batch, Awk, Sed
That’s around 40 different languages, and all to say that none of it really matters because simply programming with these tools is not writing software.
Software should be a useable, viable product – not only for the user, but for the authors. Their process is as important as the result. Hacking code together, no matter the complexity, isn’t writing software until the authors apply methodology. Methodology means myriad decisions and justifications for each, and collaborative or otherwise, that methodology should include things like:
- defining user stories or capturing (business) goals, even if not in an agile environment
- writing/running unit tests to those specifications
- defining an architectural approach and establishing design patterns to be used
- choosing a package manager and module installation process
- configuring build tools that automate various processes, and documenting those settings and their justifications
- code review – which ideally is an objective external observer who is an expert in the given context
- Quality Assurance – manual review of user stories/use cases
- writing documentation and user guides/manuals/video/etc.
This is all to say that writing software is hard.
It isn’t enough to simply know the fundamentals of a language. In fact, the fundamentals are often what matter least if you already know the rote mechanics of programming.
The approach that has worked best for me recently – as I reacquaint myself with modern development practices – is to get a sense of the meta, so to speak. Understanding the contemporary context of any specific language will reveal much of the above. Lately I’ve been referencing the 12 Factor App (12FA) as a starting point to supplement the above list. That said, I think 12FA approach doesn’t address a lot of important psychological considerations implicit with working collaboratively, so it’s critical to examine your own process, especially if you work collaboratively.