5 ms·

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 so

by Aloha 4y ago

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.

cxr 4y ago
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.
- Renaud 4y ago
  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.
  - Aloha 4y ago
    I think there are lots of laudable things to say about Delphi, but like.. developer availability is not one of those things ;-)
    - LeFantome 4y ago
      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.
      - magicalhippo 4y ago
        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.
  - cxr 4y ago
    "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.
    - Aloha 4y ago
      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.
      - cxr 4y ago
        > 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).
        Aloha 4y ago
        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.
- Sophistifunk 4y ago
  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.
  - grugagag 4y ago
    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
- Aloha 4y ago
  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.
  - marpstar 4y ago
    > 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
    - Aloha 4y ago
- emodendroket 4y ago
  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.
  - cxr 4y ago
    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
    - emodendroket 4y ago
      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.
- magicalhippo 4y ago
  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.
  - KerrAvon 4y ago
    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.
    - magicalhippo 4y ago
      > 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.

by Aloha 4y ago

cxr 4y ago

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.

Renaud 4y ago
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.
- Aloha 4y ago
  I think there are lots of laudable things to say about Delphi, but like.. developer availability is not one of those things ;-)
  - LeFantome 4y ago
    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.
    - magicalhippo 4y ago
      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.
- cxr 4y ago
  "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.
  - Aloha 4y ago
    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.
    - cxr 4y ago
      > 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).
      - Aloha 4y ago
        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.
Sophistifunk 4y ago
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.
- grugagag 4y ago
  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
Aloha 4y ago
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.
- marpstar 4y ago
  > 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
  - Aloha 4y ago
emodendroket 4y ago
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.
- cxr 4y ago
  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
  - emodendroket 4y ago
    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.
magicalhippo 4y ago
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.
- KerrAvon 4y ago
  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.
  - magicalhippo 4y ago
    > 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.