Me too. My view of it has changed immensely. Scattered thoughts:
- I don't think of myself as a {language} programmer. People will ask what language you code in, and I will throw out a few current ones. But I don't think of them as some particular skill that's hard to acquire. If I need a new language, I'll read the tutorials, and then I'm able to find my way. Only exception is c++, that one I still regard as a bit of a skill, where if you haven't tried it you have a lot of concepts to learn.
- A lot of the skill isn't coding, it's domain knowledge. Not knowing what you are building is the greatest impediment to building it.
- Another huge barrier to becoming a good coder is not respecting the craft of coding. Typically if you come from domain expertise, you are prone to this problem. "I know how trading works, I just need this coded up". This attitude will get you crappy code. In fact just needing something coded is code for not actually knowing what you want.
- Satisfying things can often be closer to the code than the domain. Things like finally figuring out how to get the most out of a lock free ring. Nothing to do with the domain, but oddly satisfying. Another one is being able to reduce the size of the code.
- There's a bunch of ancillary skills that you don't think of as programming, but you need to know them. Version control, devops-type stuff like how to provision a server. Feel tedious but again you can't really do the job without doing all of the job.
- I don't think of myself as a {language} programmer. People will ask what language you code in, and I will throw out a few current ones. But I don't think of them as some particular skill that's hard to acquire. If I need a new language, I'll read the tutorials, and then I'm able to find my way. Only exception is c++, that one I still regard as a bit of a skill, where if you haven't tried it you have a lot of concepts to learn.
- A lot of the skill isn't coding, it's domain knowledge. Not knowing what you are building is the greatest impediment to building it.
- Another huge barrier to becoming a good coder is not respecting the craft of coding. Typically if you come from domain expertise, you are prone to this problem. "I know how trading works, I just need this coded up". This attitude will get you crappy code. In fact just needing something coded is code for not actually knowing what you want.
- Satisfying things can often be closer to the code than the domain. Things like finally figuring out how to get the most out of a lock free ring. Nothing to do with the domain, but oddly satisfying. Another one is being able to reduce the size of the code.
- There's a bunch of ancillary skills that you don't think of as programming, but you need to know them. Version control, devops-type stuff like how to provision a server. Feel tedious but again you can't really do the job without doing all of the job.