Comment by ChrisRR

1 year ago

I feel like degrading the discipline of programming/development to "coding" is a bigger step backwards. Coding is used in programming, but if you're just churning out code then you're not developing well-architected, maintainable and safe software

It's like saying that accountant is just adding. I think come then of tax year you'd be avoiding an accountant who says they've got experience in adding.

I lean in the opposite direction. When someone random like a new neighbor initially asks me what I do, I say "I'm a coder at an insurance company". I teach fifth graders Python in an "Advanced Coding Club". When people ask me what I do for hobbies, one of them is "learning new languages to code with". I will only go into more detail if they are also technical and want more details about what it is I code.

I don't think of it as degrading the thing that I do. I think of it as boiling it down to the simplest description, and I find it more refreshing than "software developer" or "computer programmer" or f"{word} engineer".

  • I use what impact and benefit my work has to answer what I do.

    In your insurance case, I would say something like "I build tools to shield businesses from unexpected disasters like earthquakes or floods" or "I help people worry less about expenses during an emergency"

    If someone asks me more, then I might add on that I work on software to automate claim process or similar.

I think the field has long had an issue describing the differences between design and implementation, which has only grown worse as more levels of designing and implementing have appeared. It is a bit like explaining the difference, back in the day between the person who works out a formula and the person assigned to computing it. Neither is trivial work, and the outsider who doesn't like math will view both of them as doing math, but there is still a gap in the mathematical skill and insight involved.

You mention taxes, which makes me think of how many tax preparers are basically helping their customer input data into software and not providing any tax specific advice. That might still be a value add for someone who struggles computer UIs, but that isn't the same as the person helping move money between accounts to reduce tax liability.

I've seen similar when it comes to doing science in a lab.

How can any discipline protect the inner distinction against a much larger world which has a very simplified understanding and will mix the inner groups together?

I've never come across someone that was more enlightened by what I do when using the word "engineer" vs using the word "coder". If anything I would assume coder elicits a more accurate mental image than something a bit more overloaded like engineer.