I work in an industry with useful, important, specialized, but unsexy technology.
PCM Audio, Multicast, lots of analog connectivity, arcane binary protocols (even widely adopted and interoperable ones), lots of manufacturer specific protocols too. Windows and RHEL. We've only just barely figured out what Web 2.0 is, Javascript based UI is new for us. We also do a bunch of embedded development, RTEMS, now Linux, other shops have some VxWorks too. Plus lots of development on just DSP code. This isnt just us I'll note, its my whole industry.
Technology in our world moves very very slowly. We provide decent wages, good benefits and a no requirement for overtime, but it's not sexy and it's not the way the rest of the technology industry is pivoting. We provide solutions that are reliable, and must work, but dont need to serve billions, just hundreds.
Also, as a deployment engineer it takes someone new into my role, about six months before they understand enough of the system to work unaided. It's not that we cant find developers - its that finding people who understand our industry is hard, and even if we hire someone who isnt in our industry, it does take six months or so before they can be productive. The larger issue is, they dont see the technology work on as a good stair-step on their career progression, so they dont wanna work here.
The web and mobile dev stuff is "comfortable" and "safe" because they (we?) see how ubiquitous it is. Maybe the companies themselves are not, but everyone needs web developers right now.
I recently took a job that is in web development, but is focused on front-end (and I've spent 13 years as a very versatile full-stack dev) and is a much more focused tool (data visualization tool versus an operations management system for everything government public works, including simple data visualization) and even that made me mildly hesitant.
I do dream of some day pivoting entirely into something more low-level and hardware focused. I've done a lot of hobbyist audio production and that's always seemed like a fun niche to build in. Maybe when I'm old :P
I get to work on the whole enchilada, not just some narrow part of it, its wonderful.
For some reason, I find this very appealing.
There are some advantages in working for a company none of your (non-industry) friends have heard of. You get to talk about your job and explain it without preconceived notions.
Also, I feel I'm making an honest to god difference at work, I help people solve difficult problems that are critical for the health of broader society (utilities, transportation, government) that would be hard to solve elsewhere.
I have several coworkers with 30 years of seniority, and some with 40.
It's a job you leave largely of boredom.
XKL sells network switches running TOPS-20 for their management software on an FPGA based PDP-10 (probably the last place one can see and use a 36-biter).
It's exotic legacy stuff, and at the same time a breath of fresh air.
Having been developing for nearly 40 years now the technologies don't really excite me - it's what I'm building and the impact that it's having on its users that motivates me. It sounds like you've found something that motivates you, too.
What is claimed, and what is in contention, is the inability to find developers.*
I could show you some people who don't like to (or can't) eat peanut butter. That's a completely different matter from demonstrating that nobody will eat peanut butter. Your ∃ is not an ∀.
Second: That an employer who wants to hire will have to either pay more (than what they are currently trying to get away with) or lower its standards is a pretty straightforward restatement of what I was already saying. That observation is, again, not some sort of insightful riposte—it's just, you know, arguing for my position...
* which is a claim that the person I first responded to has already walked back
Having such a small team means each person has a huge impact. Hiring a poor fit can be a net negative on the team and thus we'd be better without.
We've had poor experience with remote workers, including ourselves during corona lockdown, so we want someone who can be at the office at least 2-3 days a week. And they'll need to be competent in Norwegian, as most of the gov't documentation and customer interactions will be in Norwegian. So that narrows the pool quite a lot.
We've tried not specifying the language in the job ads, and have almost everyone turn away when they ask and we tell. Clearly many are worried about taking on an unknown, and how that will reflect on their CV.
As for taking months to be productive, that's certainly my experience. Obviously getting productive in Delphi doesn't take much time, our two latest hires had zero Delphi background, mainly Java or Python, but after a couple of courses they were good enough to commit solid work.
However what we need, due to our size, is that our devs can get a task, then go design and develop the solution on their own. Maybe ask some clarifying questions to team leader or customer along the way, but no hand-holding. This requires both acquiring domain knowledge and learning our existing code base.
Personally that took about a year or so, and I didn't get really good at it until after two years. This matches well with those who got hired after me.
I've been trying to think a bit about it. So far what I got is mainly two-fold. The big one is that people seem to find it far easier to ask the colleague in the next office over when they're stuck, compared to over Teams. And it's far easier to tell people about new features you've implemented over lunch or similar.
I also much harder to direct someone over Teams, or illustrate, compared to pointing at their screen and tell them what to do or quickly drawing some flow chart on a piece of paper while together, so teaching is more difficult. We a brand new hire just before the lockdowns hit, so we noticed this very well.
Also you miss out on listening in on the corridor chats. There's quite a lot of stuff I pick up on just by listening in on the other devs or support chatting in the corridor. Oh those customers want something very similar to the feature X I'm working on right now? Let's join the chat and see if we can't satisfy two customers for the price of one. That kinda stuff.
I'm pretty sure if we had been fully geared and prepared for remote work it could work much better, but I do think it requires a different mindset and different management style.
Shouldn't this be the job of the product manager?
But like I said we've got hundreds of customer-specific features and integrations, it's hard to catch everything, so no need to defer things when one of us devs can shortcut the process.
This Delphi course wouldn't happen to be online would it (or in book format)?
Anyway there seems to be a fair collection of free stuff over at Learn Delphi[2] though I haven't checked any of it out so don't know the quality.
[1]: https://alfasoft.science/en/events/category/embarcadero/
Would they relocate to fill a job in a small company that mostly use Delphi?
We're talking about a programming language mostly targetting software for small businesses. A language that has basically no future.
Nothing's impossible, but I'm ready to believe that finding people for these types of job is probably not easy.
Not impossible, just not as easy as finding a Python developer.
If is-already-fluent-in-unsexy-niche is a hiring requirement, then your hiring is totally broken. (To be honest, it's broken even when you broaden it outside "unsexy niche"...)
> finding people for these types of job is probably not easy[...] not as easy as finding a Python developer
Damn, goalpost, you sure do get around.
I dont think python or C# are especially hard to hire for.
I feel like you came to this conversation with a preconceived notion here. Look - not everyone can match the SV pay scale, I'm not on one, there are no stock options floating around here.
I have no idea what this is trying to say here. Yes, I called out the months-to-productivity quip.
> I feel like you came to this conversation with a preconceived notion here.
Right—the one that I said I had: that people who say it's "impossible" to hire developers to work with <X> are the equivalent of other industries' folks who the same thing e.g. about not being able to hire retail workers. When you prod a bit, it turns out it has nothing to do with <X> or workers, but instead pathological hiring behavior and expectations on the part of the companies themselves (with a common one being the "4 who expects to date a 10" effect).
I don't understand why this conceptually is so hard to understand - I know some very obsolete, and arcane shit, some of it, I'm the only person I know who has even a modicum of familiarity with it, as these technologies were no longer in common use by the late 90's (and I suspect most of the other people who still know it, are either, about to retire, retired, or dead). If you put out a req with that experience as a requirement, you're not gonna find people for it, no matter the money offered, or the hiring process.
I've not seen anything that'd lead me to think anyone is expecting 10's here, I think even finding 4's with Delphi experience - just based on the responses to this post, is very very hard.
I understand it fully:
> If you put out a req with that experience as a requirement, you're not gonna find people for it
You're making _my_ point, dude. That's a stupid req.
You said it yourself that the N-months-to-productivity problem (which is par for the course anywhere) is not actually a consequence of language but rather of domain familiarity or business processes or whatever. Again: not a surprise. So whether/if it takes two to ten months to see productivity from your hires no matter which language you're working in, then it's silly to lament the difficulty of being able to hire developers who can write Delphi on day one. You don't even need that!
This much is true. However this is also not the reason why we find it difficult to hire. We don't require someone who can write Delphi from day one. We require someone who is willing to write Delphi from day one.
Obviously past Delphi experience will make that much more likely. But we've tried listing "C#/C++/Java or similar" in the suggested experience part, and most of the people with such backgrounds are not willing to learn Delphi it turns out.
Cool. Would have been nice then to not have brought it up ad nauseam as if it was relevant, rather than a massive distraction masquerading as a mic drop-worthy argument ender.