SeanKilleen
commented
5 years ago Hey! Thanks for writing in.
I think a lot of my answer would depend on what you mean by "proprietary languages for software development". So I'll have to make some assumptions here in order to answer. I'll assume for the sake of this response that by proprietary, you mean languages that are not open-source, or that are heavily tied to a specific vendor (Java has some restrictions coming up in some ways here I believe, and there are also various flavors of markdown and back-end domain languages for various products).
For me, I think that the trap for a lot of developers is building themselves a box and forgetting to step out of it every once in a while. Working with a proprietary or niche language seems like a fine idea, especially if you want to specialize in whatever value that language provides. However, I think it's important to recognize that you're doing so, and to ensure you keep perspective. Has the rest of the industry moved on? Where does your current choice diverge from the industry, and why? Do you feel like everything else looks like gibberish to you now? If you check yourself, I think you can use a proprietary language without losing your moorings.
Personally, I think that there are some great choices for languages that allow you to be as effective as possible for clients. C# & .NET are a big example of that for me these days. .NET; it's part of the .NET Foundation and .NET Core are open source; .NET Core runs on Linux/Mac/Windows; it has great tooling that's getting better all the time; it's fast as heck; and it's got some great abstractions to it. I've found that I've been able to specialize in the value I provide, using that stack (but being open to any others that are needed).
Regarding niche-based jobs, I think Erik Dietrich does some great writing on this. See his articles You should change the reason people pay you and Does Niching Make me Less Consultative?.
On the flip side, I think he captures the essence of my point in another great post, Tech Stack, Framework, Library, API: How not to specialize:
As you figure out how, take a lesson from my doctor analogy. Specialize in something where your patients, who are not medical experts, understand the value proposition but not the mechanics. “You might have cancer, and here’s what we’re going to do next. I can explain the technical details if you’d like.” That’s the conversation you want to be having with clients about their web apps, line of business installations and such. Find something where people look to you for diagnosis and prescription — not where they demand that you jump through hoops for the honor of performing labor. It’s a mental adjustment to be sure, and it’ll be a challenge at first. But practice. Time is on your side.
Hope this gives some food for thought! Feel free to respond / discuss / follow-up, especially because I had to make some assumptions.
Happy coding!
Via e-mail: