💾 Archived View for degrowther.smol.pub › 20240316_linters captured on 2024-03-21 at 15:00:07. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

Ambivalent about code linters

I’ve been reflecting on this piece, which describes a particular ontology of people who work in technical and creative fields:

The craftsperson and the scientist: Two ways of working we've identified through our collaborative practice

‘Craftspeople’ are skilled individuals who are often used to working on their own. They’ll be looking to apply their experience gained from creating dozens of similar things and to build solutions based predominantly on their own best judgement, rather than looking for external data to back up every decision.

‘Scientists’, on the other hand, look for data to back up every decision they make. They’ll want to work with external parties (such as users, clients and other organisations) to conduct fieldwork and testing to make sure the right decisions have been made and that what’s been decided is still working.

It’s interesting to me that I am trained as a scientist, and am still employed doing largely “scientific” work, but my approach is much closer to that of a craftsperson described above. I’m not unique in this: in my own experience, many scientific fields (within academia, at least) are full of craftspeople; the master/apprentice relationship is so common that it’s hard to forget that academic culture is rooted in Medieval Europe (the robes help with that, too).

I’m not just a craftsperson when I’m designing a study or analyzing data though; I am perhaps the most “craftspersonlike” when writing code. I’m constantly challenging myself to stretch into new techniques and paradigms, but I’m also the most effective when I’m using the well-honed tools I’ve worked with for years.

All of this probably explains why I’m ambivalent about linters.

I actually worked with a version of LINT(1) in my first bona fide programming job (writing C code for scientific computing). I was also one of only two full-time programmers on this particular project, and it felt very much like an apprenticeship. I think I was learning my manager’s style as much as anything else. In the years since then, I haven’t much used the linting tools available for other languages (my C skills have long atrophied); I never felt like I needed them because I always thought my code had “good style”. But also, whenever I do consider incorporating linting tools into my workflow, I experience friction and give up: the very notion of a program telling me what my code should look like feels too top-down, corporate, and authoritarian for my crafty spirit.

Yet on the other hand, I appreciate the social aspects of coding, and I always celebrate the moments where I feel like I am part of any coding “community”. I understand (intellectually) that a stricter adherence to a widely-adopted style makes my code more inviting for collaborators, and that’s something I want to encourage. Especially in my professional life — as I become more “senior”, and find myself working on code with folks with less experience and formal education in programming that I have, I want my programs to be instructional and inviting. Linters can help with that, especially for people in the “pattern recognition” stage of learning to program.

Anyway, that’s where things stand at the moment. I think I’ve talked myself into trying out linters for things that I know will be shared with colleagues, and I’ll see if this becomes another tool in my toolbox or if I stick with what I like.

Home