I never thought of myself as a "niche programmer," but, as it turns out, I sort of, am.
I write native UIKit applications, using Swift. No PWAs, no hybrid systems (like React, Electron, or Ionic). I'm pretty good at it. I've been writing Swift, every day, since it was announced in 2014. It's no longer an "edge" language; it is now the baseline, mainstream, native development language for Apple systems, and I'm a fluent speaker.
It means that the apps I write are really small, really secure, really fast, accessible, highly usable, use very few system resources, leverage the latest Apple tech, have almost no external dependencies, work extremely well, and I write them very, very quickly. Also, because they are UIKit, I can get pretty ambitious, as UIKit is a very mature, ship-oriented system. I am looking forward to using SwiftUI, but am yet to be convinced that it is suitable for really ambitious projects.
It's really difficult to find other native Swift developers that work the way that I do. Part of that, I hate to admit, is probably because I'm 60, and I got really sick of sitting in meetups, with a circle of avoidance around me. I have come to understand that I have "cooties." I won't go where I'm not welcome.
But I have also come to realize that an awful lot of apps for Apple systems are written using hybrid systems, and that many folks are unaware that there are Apple app development languages, other than JavaScript.
> Part of that, I hate to admit, is probably because I'm 60, and I got really sick of sitting in meetups, with a circle of avoidance around me.
Man, this makes me sad. I come from a traditional engineering field; in meetup situations, the old guys were ALWAYS the most popular people around due to the sheer volume of problems they've solved and situations they'd seen. I got to talk to so many people whose names are synonymous with their (admittedly niche) fields (except for Ted Anderson[0], who's pretty well-known in the relevant industries) and learned a ton from all of them.
I've been enjoying Elm for a few years, because it keeps me away from most of the bloat and churn in web UI tech / frameworks, and it's enjoyable (for me) to work in. It really helps to keep my sanity and avoid burnout. Your choice of Swift is really appealing to me... I'm not a huge fan of "apps" in general though. Still, I would guess that Swift will be around for a long time.
I'll add that it helps to be financially sorted (and no longer motivated by trying to become uber rich).
>I write native UIKit applications, using Swift. No PWAs, no hybrid systems (like React, Electron, or Ionic).
Sounds like a dream scenario. Pure native Apple development is without a doubt the most seamless, intuitive, and enjoyable dev environment I've ever worked with. And libraries like UIKit put anything the JS ecosystem has on offer to shame.
What type of applications do you? Are you contracted or a solo dev?
> the apps I write are really small, really secure, really fast, accessible, highly usable, use very few system resources, leverage the latest Apple tech, have almost no external dependencies, work extremely well, and I write them very, very quickly.
And they're only available for one proprietary platform [1], no? Excluding half of the user base for phones (in the US), and probably much more for personal computers, seems like a really bad business move in many cases. And depending on the type of application, it could be considered a different type of accessibility problem. It's depressing, but so often we have to compromise technical excellence and even user experience for economic reasons; in this case, using a cross-platform technology to develop a suckier app that can reach all host platforms is often the smart business move.
This is awesome. I too work on mobile app development. I started on Java way back where I use Eclipse IDE for Android development. Then the transition to Android Studio, I remember I was an early AS adopter around version 0.8. Then I started Swift also the same as you, around 2014. Then another transition to Kotlin. I am not sure if I'm a niche programmer but I want to stay in this lane until I get old and for me as someone who's approaching 40 this is a little bit worrying. But reading your story is awesome and gave me hope.
There is a new crop of startups that are going full native, and not using things like React Native, and Flutter and other 'xchross platform' frameworks. They are falling out of the trend as they have the same problem that we have had since the Java Midlet times in the 90s, they tend to be: write once, debug everywhere.
So, keep using the native tools as close to the platform is smart strategy on the long term (as fads come and go).
I love swift but don't do any OS X development and don't want to use XCode. Not sure how the LSP plugin is doing these days but last time I tried it it was pretty unstable (also why can't they have it in the store so you won't need to install manually?). I wish swift for tensorflow had really taken off and put it in a position to compete with python as it's a very enjoyable language.
I love your passion about Swift and UIKit, more power to you! I'm a generalist who spent lots of years trying various cross-platform solutions (Xamarin, C++, RN, KMM etc) and they all fail short when compared to the native apps. XCode sometimes sucks as an IDE but the vertical integration that Apple has is unbeatable.
I got to learn and program Swift at my last job. We needed to integrate a C computer vision library into React Native, so Swift was the answer. I really enjoyed the language. I felt like it gave me a surprising amount of low-level control while still providing high-level abstractions and automated memory management.
I wish I had stuck on with UIKit. SwiftUI has been amazing to build on, and easier than UIKit. The declarative syntax, not worrying about tracking state in the VC, has made readability of views easy.
SwiftUI however has made UI Testing at any level unviable.
> I didn't dive into finding an online Clojure community and none of my programmer friends did Clojure or had heard of it either so I had no idea if the language was gaining popularity or dying.
This is so fascinating to me and I guess just a reminder of the HN echo chamber.
Same, and I was also very surprised to learn of a professional programmer who had never heard of Lisp! Not meaning to condemn the author: apparently I have a bubble around my own head.
Another benefit of legacy niche languages, such as Perl, is less ageism. Clojure is a real joy to work with. Ruby is in an interesting phase approaching niche status with correspondingly high rates.
When I was doing my undergrad at the University of Waterloo in the '90s, my first co-op (internship) placement happened to be at OTI -- a (some might say "the") Smalltalk shop. Smalltalk was very much a niche language even at the time but it opened up opportunities I wouldn't have dreamt of down the road. My last couple co-op jobs took me to Australia and from there to a customer engagement in Thailand. I bet that wouldn't have happened if I just specialized in C++ or whatnot.
All this to say that I heartily endorse the OP's strategy.
Besides niche languages, there are also niche roles.
For example, Data Engineers and DevOps Engineers are both in low supply and high demand.
I've worked at two companies (Apple and Spotify) that I'm pretty sure I would never have been able to get into as a "common" engineer or data scientist with thousands of other applicants for the same role.
My niche is pure JS widgets. That’s 100% Vanilla JS (old or new). No libraries or frameworks. I can create self-contained, state-aware, datastore driven (using session/application storage) interactive mini-applications, tools, widgets, and even games — often with just ONE JS file (CSS and HTML embedded), and fancier apps using maybe just a few supporting resource files. In fact, I am the only dev in my entire project of 100+ devs that has this skill and maintain quite a few of these widgets that I primarily authored. Thus is good and bad. Bad because it means I am stuck with these (and similar maintenance) forever and often get passed up for the newer stuff, but good because I’m almost irreplaceable.
Unfortunately it's not always the case - at least not with Ruby (which I consider somewhat nichy). My experience is the Ruby job interview is just like any other algo/Leetcode type interview - in 90% of interviews they don't bother testing my Ruby knowledge (very likely the interviewer doesn't really know Ruby that well). Maybe 2 companies out of 15 had actual Ruby questions.
So maybe Ruby is not niche enough or the hiring company thinks it's no problem teaching someone Ruby, idk. But I'm surprised again and again how little companies care about my actual experience. It's all algo questions or something about deployments/Kubernetes.
I'm a developer who mostly works with Python and I recently interviewed for a position that seemed to mostly involve Ruby on Rails. I was genuinely excited about working with Ruby, but the interviewer said they are struggling to hire Ruby developers and they are now hiring Python developers instead. It seems to be niche enough that small companies can't afford it.
Ruby is very much main stream. Any non-programmer business type who wants to start a startup immediately think it should be in Ruby or Python because that's what he think is the most popular thing.
Yeah, there all sorts of niche languages out there. Back in the 1980s there were lots so-called "fourth-generation languages" - 4GLs out there. Two that I used were SeaChange, which was for Unix & MSDOS - see https://techmonitor.ai/technology/seachange_launches_seachan... and Nomad/2 on IBM mainframes - see https://en.wikipedia.org/wiki/Nomad_software. Both were quite capable (particularily Nomad) and you could earn quite a bit of change if you knew how to use them.
Oh, and while I'm thinking about it, knowledge of how to program a Transaction Processing Monitor) will rarely go amiss.
The essential idea is apparently to have a central server which does not know your application code directly, spawning workers—application code processes with some communication protocol. The supervisor can then have better uptime guarantees because it doesn't crash when application code crashes. With some more tweaking (what tweaking exactly?) the supervisor is able to enforce transactional consistency: if a worker crashes, we can roll back any partial updates it was doing. Is that about right?
Would be interesting to know about your “how to program” comment in greater detail. Do you mean just the idea of buffering client connections and maintaining a worker pool? Or is there some hard problem around transactionality that needs to be solved and a particular perspective for it? Both? Neither?
Haha, memories. In my first internship I left a great impression by picking up a 4GL that was used for some backend stuff and nobody in the team knew (other than how to trigger pre-defined jobs through a UI). Built a few nice things with it, but boy, it was limited.
I'm a Machine Learning Engineer, and that seems to check all those boxes. It is niche, it has low offer, and crazy high demand. Sure, salaries are high, but the interview process isn't easier, in fact is way harder. As an MLE I need to excel both as a software engineer (yes, that includes leetcode), and in MLE/science/data science.
For example, the last position I entertained included a phone screen and then 4 rounds: behavioral, coding, machine learning expertise, and a science round, where I was given a problem, had to find 2 papers and make a presentation explaining my approach to solve the problem using the ideas from the papers.
At this rate I'm considering leaving Machine Learning altogether, since the barrier to entry is too high for the people already in.
What exactly do you mean by low offer? I mean, my idea of a niche isn't something that is among the top most popular courses on every MOOC platform. What's a barrier to entry for people already in? You mean for switching employers? What do recommend to get in?
Those numbers seem... Odd? Or at least skewed by geography. The typescript number is less than what glassdoor says for junior level JavaScript in my area.
>Anyway, this is all to say that being a niche programmer is not bad at all. Pay is great, competition is low and the interview processes for the most part very humane
This is NOT true of all niches. The pay will only be great if the demand for programmers in that niche is high.
Program PowerPascal;
{$X+}
{
Who: Michael Warot
When: November 12,1989 (my 26'th Birthday!)
What: The beginnings of a language compiler,
takes source from STDIN, and generates
Assembler Source for STDOUT
}
pp002.zip Power Pascal v0.002 (c) 1993 by Mike Warot
Its a very old OS2-oriented Pascal compiler.
Source: .pas (Borland Pascal)
Output: .asm (32-bit => Masm 6.0 + Link386 = > lx .exe)
Documentation: comments in English
What if you really like that niche? That said, with Clojure I can do React.js, Node.js, JVM and, as of recently, even Dart/Flutter development. Within each of those there's a vast array of things that can be done as well, so it really should not get boring anytime soon.
I started using Elixir last year after being a long-time Python dev.
Apart from the pros of using a niche language as espoused in the OP write up, the downside I see can be the lack of community, 3rd party libraries and tools and lived experiences which could be discouraging.
I think Elixir falls into the same category of Clojure when it comes to "niche". However, my experience with Clojure is that the community is small but tight-knit: you can usually easily reach library authors in case there are issues and discuss things on Clojurians Slack. The libraries usually adhere to "don't break" like Clojure itself and when there isn't a library for a specific problem, you can drop down one layer to the host system where there is usually a library for everything (Java, browser, Node.js, ...). So although Clojure is fairly niche, you can use a wide array of mainstream libraries to solve problems.
I guess I'm also sort of a niche developer specialising in web scraping/data extraction. I've been getting some gigs on upwork but been meaning to get off that platform. Does anyone in a similar position have advice on finding clients?
I read about lisp in "The Cathedral and the Bazaar" a long time ago. Then I read "Practical Common Lisp" which was a revelation for me. I never ended up using the language but I still see pieces of code or techniques in other languages that make me think about how it would be much simpler in LISP.
When Clojure came out I learned it as I was also programming on the JVM at that time. I even joined the local Clojure meetup group. I never worked on real world projects in Clojure but the community around it is awesome. I still have fond memories of that time.
I also learned Emacs and the tooling around it. There was a time when I knew that I'm done with Java, but I didn't know what's next. I ended up choosing Kotlin over Clojure. Kotlin is a great language and I don't regret going in that direction but sometimes I still think about what could have been...
Then I moved to node/typescript and now I'm learning Solidity because that's what's being used in the web3 space. I guess it is still not the time for me to finally embrace Lisp.
[+] [-] ChrisMarshallNY|3 years ago|reply
I never thought of myself as a "niche programmer," but, as it turns out, I sort of, am.
I write native UIKit applications, using Swift. No PWAs, no hybrid systems (like React, Electron, or Ionic). I'm pretty good at it. I've been writing Swift, every day, since it was announced in 2014. It's no longer an "edge" language; it is now the baseline, mainstream, native development language for Apple systems, and I'm a fluent speaker.
It means that the apps I write are really small, really secure, really fast, accessible, highly usable, use very few system resources, leverage the latest Apple tech, have almost no external dependencies, work extremely well, and I write them very, very quickly. Also, because they are UIKit, I can get pretty ambitious, as UIKit is a very mature, ship-oriented system. I am looking forward to using SwiftUI, but am yet to be convinced that it is suitable for really ambitious projects.
It's really difficult to find other native Swift developers that work the way that I do. Part of that, I hate to admit, is probably because I'm 60, and I got really sick of sitting in meetups, with a circle of avoidance around me. I have come to understand that I have "cooties." I won't go where I'm not welcome.
But I have also come to realize that an awful lot of apps for Apple systems are written using hybrid systems, and that many folks are unaware that there are Apple app development languages, other than JavaScript.
[+] [-] albrewer|3 years ago|reply
Man, this makes me sad. I come from a traditional engineering field; in meetup situations, the old guys were ALWAYS the most popular people around due to the sheer volume of problems they've solved and situations they'd seen. I got to talk to so many people whose names are synonymous with their (admittedly niche) fields (except for Ted Anderson[0], who's pretty well-known in the relevant industries) and learned a ton from all of them.
[0]https://fracturemechanics.com/
[+] [-] rapind|3 years ago|reply
I've been enjoying Elm for a few years, because it keeps me away from most of the bloat and churn in web UI tech / frameworks, and it's enjoyable (for me) to work in. It really helps to keep my sanity and avoid burnout. Your choice of Swift is really appealing to me... I'm not a huge fan of "apps" in general though. Still, I would guess that Swift will be around for a long time.
I'll add that it helps to be financially sorted (and no longer motivated by trying to become uber rich).
[+] [-] ramesh31|3 years ago|reply
Sounds like a dream scenario. Pure native Apple development is without a doubt the most seamless, intuitive, and enjoyable dev environment I've ever worked with. And libraries like UIKit put anything the JS ecosystem has on offer to shame.
What type of applications do you? Are you contracted or a solo dev?
[+] [-] mwcampbell|3 years ago|reply
And they're only available for one proprietary platform [1], no? Excluding half of the user base for phones (in the US), and probably much more for personal computers, seems like a really bad business move in many cases. And depending on the type of application, it could be considered a different type of accessibility problem. It's depressing, but so often we have to compromise technical excellence and even user experience for economic reasons; in this case, using a cross-platform technology to develop a suckier app that can reach all host platforms is often the smart business move.
[1]: Well, one platform for each form factor.
[+] [-] dirtylowprofile|3 years ago|reply
[+] [-] ardit33|3 years ago|reply
So, keep using the native tools as close to the platform is smart strategy on the long term (as fads come and go).
[+] [-] biellls|3 years ago|reply
[+] [-] FlyingSnake|3 years ago|reply
[+] [-] mind-blight|3 years ago|reply
[+] [-] andersonpaac|3 years ago|reply
SwiftUI however has made UI Testing at any level unviable.
[+] [-] georgeoliver|3 years ago|reply
This is so fascinating to me and I guess just a reminder of the HN echo chamber.
[+] [-] b3morales|3 years ago|reply
[+] [-] cutler|3 years ago|reply
[+] [-] piotrkaminski|3 years ago|reply
All this to say that I heartily endorse the OP's strategy.
[+] [-] paulluuk|3 years ago|reply
I've worked at two companies (Apple and Spotify) that I'm pretty sure I would never have been able to get into as a "common" engineer or data scientist with thousands of other applicants for the same role.
[+] [-] mahathu|3 years ago|reply
[+] [-] e-pelaza|3 years ago|reply
[+] [-] temporallobe|3 years ago|reply
[+] [-] weatherlite|3 years ago|reply
So maybe Ruby is not niche enough or the hiring company thinks it's no problem teaching someone Ruby, idk. But I'm surprised again and again how little companies care about my actual experience. It's all algo questions or something about deployments/Kubernetes.
[+] [-] mkl95|3 years ago|reply
[+] [-] hsn915|3 years ago|reply
[+] [-] flippinburgers|3 years ago|reply
[+] [-] ris|3 years ago|reply
[+] [-] delijati|3 years ago|reply
[+] [-] zabzonk|3 years ago|reply
Oh, and while I'm thinking about it, knowledge of how to program a Transaction Processing Monitor) will rarely go amiss.
[+] [-] crdrost|3 years ago|reply
https://wiki.c2.com/?TransactionProcessingMonitor
The essential idea is apparently to have a central server which does not know your application code directly, spawning workers—application code processes with some communication protocol. The supervisor can then have better uptime guarantees because it doesn't crash when application code crashes. With some more tweaking (what tweaking exactly?) the supervisor is able to enforce transactional consistency: if a worker crashes, we can roll back any partial updates it was doing. Is that about right?
Would be interesting to know about your “how to program” comment in greater detail. Do you mean just the idea of buffering client connections and maintaining a worker pool? Or is there some hard problem around transactionality that needs to be solved and a particular perspective for it? Both? Neither?
[+] [-] t_mann|3 years ago|reply
[+] [-] angarg12|3 years ago|reply
I'm a Machine Learning Engineer, and that seems to check all those boxes. It is niche, it has low offer, and crazy high demand. Sure, salaries are high, but the interview process isn't easier, in fact is way harder. As an MLE I need to excel both as a software engineer (yes, that includes leetcode), and in MLE/science/data science.
For example, the last position I entertained included a phone screen and then 4 rounds: behavioral, coding, machine learning expertise, and a science round, where I was given a problem, had to find 2 papers and make a presentation explaining my approach to solve the problem using the ideas from the papers.
At this rate I'm considering leaving Machine Learning altogether, since the barrier to entry is too high for the people already in.
[+] [-] 6gvONxR4sf7o|3 years ago|reply
[+] [-] t_mann|3 years ago|reply
[+] [-] mdm12|3 years ago|reply
I wish my anecdotal interview experience was LeetCode-less, though :)
[+] [-] schwartzworld|3 years ago|reply
[+] [-] curuinor|3 years ago|reply
[+] [-] zeroonetwothree|3 years ago|reply
[+] [-] draw_down|3 years ago|reply
[deleted]
[+] [-] charcircuit|3 years ago|reply
This is NOT true of all niches. The pay will only be great if the demand for programmers in that niche is high.
[+] [-] MarquesMa|3 years ago|reply
Most of the interviewers don't even know to solve those leetcode problems in an optimal way with Clojure.
It might vary if the programming language is not functional.
[+] [-] mikewarot|3 years ago|reply
[+] [-] fm77|3 years ago|reply
[+] [-] dole|3 years ago|reply
[+] [-] trinovantes|3 years ago|reply
[+] [-] askonomm|3 years ago|reply
[+] [-] aitoehigie|3 years ago|reply
I started using Elixir last year after being a long-time Python dev.
Apart from the pros of using a niche language as espoused in the OP write up, the downside I see can be the lack of community, 3rd party libraries and tools and lived experiences which could be discouraging.
[+] [-] Borkdude|3 years ago|reply
[+] [-] the_only_law|3 years ago|reply
Not nearly as much as Erlang apparently. I can’t ever bring it up without someone trying to drive the convo towards Elixir
[+] [-] mahathu|3 years ago|reply
[+] [-] edem|3 years ago|reply
When Clojure came out I learned it as I was also programming on the JVM at that time. I even joined the local Clojure meetup group. I never worked on real world projects in Clojure but the community around it is awesome. I still have fond memories of that time.
I also learned Emacs and the tooling around it. There was a time when I knew that I'm done with Java, but I didn't know what's next. I ended up choosing Kotlin over Clojure. Kotlin is a great language and I don't regret going in that direction but sometimes I still think about what could have been...
Then I moved to node/typescript and now I'm learning Solidity because that's what's being used in the web3 space. I guess it is still not the time for me to finally embrace Lisp.
[+] [-] markus_zhang|3 years ago|reply
[+] [-] thrower123|3 years ago|reply