Hacker News Reader

Comment by Aloha | Hacker News Reader

Ya, we're in a similar boat - lots of custom versions for customers, we're a large payer in our market too however.

We ship our application as a binary with some premade Delphi form files and a tool we wrote to build DFM files for the customer specific application that limits access to the functions and objects built into the application. I'm part of the group that consumes the application as built and develops customer implementations.

We're slowly transitioning from Delphi to C#, because the language is creaky, and mostly, its become impossible to hire dev's and when we do its months before they can be productive (but boy are they once they are).

I think the move away from Delphi is going to hurt a bunch in the short term, but will probably get us long term benefits.

For me the biggest issue I'm dealing with, is Windows is a treadmill of changes, and its hard-to-impossible to keep up with it.

View on HN

These stories about not being able to hire developers sound like the software industry's version of "No one wants to work [here] anymore." I have real difficulty believing that these positions are as hard to fill they are made to sound. Comments about how it takes "months before [new hires] can be productive" certainly don't help in that regard.

How many people do you know who are fluent in Delphi?

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.

I think there are lots of laudable things to say about Delphi, but like.. developer availability is not one of those things ;-)

I thought the whole appeal of Delphi was how easy it was though. In terms of the base language, Pascal is pretty easy to pick up. Any dev worth hiring would come up to speed pretty quick.

Yeah if you've been exposed to C, C#, Java, Go or similar you should pick it up quite quickly. Unlike C++ the syntax is fairly strict so you get fairly sensible errors most of the time, or a least in a relevant location.

"How many people do you know who are fluent in Delphi?" reads like, "I know I'm a 4 at best, but I'm holding out for my perfect 10. Willing to compromise a bit, but definitely no lower than a 9."

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.

You already questioned 'my six months to be effective' blurb, like, its not a hiring issue, its that people see 'Delphi' and worry about their next job, the one after your company.

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.

> You already questioned 'my six months to be effective' blurb, like, its not a hiring issue, its that people see 'Delphi' and worry about their next job, the one after your company.

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).

There are just not many developers who have any experience with Delphi, and often if they do, it's not recent (as in living) experience. It's a whole lot easier to find C# people, who have been writing C# every day for the last X years.

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 don't understand why this conceptually is so hard to understand

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!

> 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.

> This much is true. However this is also not the reason why we find it difficult to hire.

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.

Of course nobody wants to work there, it's a Delphi shop. It doesn't matter how nice using Delphi might be, it's going to make getting your next job significantly more difficult.

It goes both ways. For someone who wants to work in the same place and retire, in say 10 years, could work out great. Unless the company goes bust using unsexy tech could also be a good thing

So, I've been active on HN for almost 12 years now - I see how developers especially young ones chase the new and shiny over the existing.

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 larger issue is, they dont see the technology work on as a good stair-step on their career progression

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

Some of my job is UI/UX design, some of it is old fashioned unix system administration and shell scripting, some of it is windows administration, I also have to understand telecommunications generally, and networking - at least well enough to design a redundant reliable network.

I get to work on the whole enchilada, not just some narrow part of it, its wonderful.

"I work in an industry with useful, important, specialized, but unsexy technology."

For some reason, I find this very appealing.

It is!

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.

Probably great job stability if you do your work well.

Basically, yes.

I have several coworkers with 30 years of seniority, and some with 40.

It's a job you leave largely of boredom.

Me too. I’m in telco, which is an industry full of weird legacy stuff, but the notion of working in a similar silo that isn’t as full of hype appeals to me.

I couldn't say it better.

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.

I work for a utility. We use technologies spanning decades. We don't change our technology stacks to enhance people's EV's. For us new technology is technology that's 5 years old. We call it "leading edge" and actually have a strategy to avoid "bleeding edge." We like to use technologies that have been tested out, worked out, and shown to work and has mindshare and tooling.

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 do you do for the utility?

Imagine two jobs that in all aspects equal except the technology used. Would you rather use one that would serve you in many other jobs and is well-regarded? Or one that's poorly regarded, limited to a few employers, or outright custom? You'd be a fool to choose the latter. So any employer that wants to make their employees do a custom blend of MUMPS, PHP, COBOL, and an in-house programming language is going to have to pay a lot more, offer really compelling benefits, or something else to compete, or it will have to lower its standards to mop up people who couldn't get more desirable jobs.

Your thought experiment is framed as if it delivers a relevant insight. It doesn't—the conclusion is neither insightful (it's pretty facile and obvious—no need to walk through anything), nor is it dispositive for the actual subject at hand.

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

Presumably they would have to offer so much more than competitors to make the job attractive that it's infeasible and reworking the application into something modern -- something even current employees are likely to be happy about anyway -- is preferable.

Of course we could probably find someone fairly easy if we would hire anyone who walked in the door and said "yay Delphi!".

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.

Just curious, do you understand why you had difficulty with remote work yourselves? Remote work seems like it should be a good fit for jobs with rare language requirements; a lot of companies had fine experiences with remote work during the lockdowns; would be worth seeing if you could root out what the problem was.

> Just curious, do you understand why you had difficulty with remote work yourselves?

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.

The loss of bandwidth with peers is the one thing I miss from being in the office.

> 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.

Shouldn't this be the job of the product manager?

Not with custom systems. Often there will be add on feature development for a single customer.

Perhaps, and our team lead which also has the product manager hat catches many such scenarios, or we catch it during our team meetings.

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.

"after a couple of courses they were good enough to commit solid work."

This Delphi course wouldn't happen to be online would it (or in book format)?

I'm pretty sure they were, however they were not free[1] (I see the advanced one is now physical, perhaps it was online due to lockdown).

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/

[2]: https://learndelphi.org/

Reply on news.ycombinator.com