3 ms·

I think you might have more success advertising to sysadmins or devops engineer rather than developers. It's precisely the negative attitude, or at least apathy

I think you might have more success advertising to sysadmins or devops engineer rather than developers. It's precisely the negative attitude, or at least apathy, towards packaging that makes it difficult to find employment where packaging is valued. On the other hand, a lot of the packaging related work has traditionally been the remit of the UNIX/Linux system administrator, and that as a profession is slowly moving towards automation as 'devops' - but it's still fundamentally the same concepts. Also, you could sprinkle in some 'optional but desired' skills and experience relating to packaging into your advertisements, anything from CMake and GNU Autotools to Nix and Podman. That would be enough to pique a packager's interest and differentiate it from the 'write-only' coding jobs!

saurik 3y ago
I will second this advice; both of the engineers I have worked with who actively enjoyed being tasked with packaging software identified as systems operations / devops / site reliability engineering.
- 0x0203 3y ago
  These are both very useful comments; thank you! In your experience, do the devops/sys ops engineers typically have useful coding experience? In our environment, porting a package to our OS may require a little, or sometimes a fair bit of modification to make it work and we often need to be able to read/understand the upstream code in whatever language it's in and change/add to it. Hence our (or at least my) assumption that we'd need a "developer."
  - AaronM 3y ago
    Some do, maybe more with SRE title's. Better to put that in ajob description and filter for those with development backgrounds.
  - mch82 3y ago
    In my experience creating packages for an operating system package manager or Docker images, a DevOps or sysadmin mindset is more beneficial than a developer mindset. For those packages, the goal is to follow operating system or deployment best practices. I’ve not created a Python or Rust package or something like that. If you’re creating that type of package, my guess is that it may help a lot to hire a developer who loves to think about the most “idiomatic” way to package your code. Edit: if your package will be published and used by customers, then you might look for DevRel skill as a bonus.
  - faeriechangling 3y ago
    A good sysadmin may not be able to do graphics programming, but they have plenty of practice in the sort of programming used in package management, as well as a fairly good understanding of operating systems. They’re not going to grasp everything as well as somebody with a development background, like learning NEW programming languages on the fly and upstreaming changes, but I don’t think it’s totally outside of what they can learn and hiring a developer would present just as many challenges. I might look more for somebody who bills themselves as “devops” or “sre” than sysadmin though since those job descriptions tend to effectively filter out those who can’t program at all. If anything I see those people as being software developers that specialize in systems administration.
  - stevekemp 3y ago
    In my experience a lot of people who started as developers 20+ years ago move on to system administration, and retitled themselves SRE/Devops over recent years. I don't want to talk about ageism, or hiring biases, but I'd imagine if you found anyone who had an SRE-role and a long history they would be extremely likely to have had serious coding experience. I've run into a few "young" devops engineers, and they tend to be more familiar with k8s, CI, and similar, rather than actually developing. But I guess that could well come down to the random people I've met, I wouldn't like to generalize.
    - prmoustache 3y ago
      > In my experience a lot of people who started as developers 20+ years ago move on to system administration, and retitled themselves SRE/Devops over recent years. Usually they don't retitle themselves, companies do. It seems the whole IT industry just collectively decided to rename the sysadmin role as devops when using cloud and containers technologies regardless if they actually use DEVOPS methodology or not. That is my history as an engineer at least.
      - stevekemp 3y ago
        Agreed. I'm an ex-developer, turned sysadmin. But these days my titles are Devops-This, and SRE-That. I find it hard to take too seriously, but I guess it is what it is.
  - pxc 3y ago
    > In our environment, porting a package to our OS may require a little, or sometimes a fair bit of modification to make it work and we often need to be able to read/understand the upstream code in whatever language it's in and change/add to it. What one needs to understand will vary so much depending on the upstream package and how it's normally built (what it expects) that I think even someone with experience in packaging will sometimes get stuck or need to seek help or advice. The more substantive the porting work is, the more that will be true. That said, this kind of thing is pretty common for Linux distro packagers, and the weirder the Linux distro is, the more true that is. It's not at all unusual for Nix folks to add special build params, patch upstream software, or mangle binaries with sed in a post-build step to get them to understand NixOS' unusual filesystem structure, or to build offline in the restricted sandbox. So I'd reach out to contributors to BSD ports systems, especially if they added ports for Linux-centric software, and contributors to really weird Linux distros (NixOS, GuixSD, GoboLinux, Void Linux, etc.). I've never been in charge of hiring decisions anywhere so idk what the overall landscape of DevOps job candidates looks like. But I've done DevOps and I definitely do, and my friends in roles associated with that title can definitely do at least some coding and scripting in a way that I think suits most packaging tasks well. If a DevOps person has a CS degree of previously worked as a developer, they can probably figure out what they need to when it comes to patching upstream software to get it to build. Even if they don't, if they do some recreational programming, they can probably push through.
  - prmoustache 3y ago
    As a sysadmin I used to do package management for different OSes but this is not necessarily the most rewarding job. Atmo, most engineers doing that are juniors or started doing that as junior and never cared exploring anything else / moving company.
larusso 3y ago
I not 100% convinced that profile works either. I tried multiple times to hire for my team which works with a combination of library maintenances build tool development and package management. I even tried a junior developer with an open mind. The skills needed for this job is sadly to broad. One needs to know the platform/language and tools to package software. And don‘t get me started with CI etc. Sysadmins and what most understand of DevOps are not the right kinda people. Not to say there are not people among this group.
- devonkim 3y ago
  The most appropriate group of folks may be those that already maintain software for the OSS community. The skillset more resembles trades where time and experience matters substantially more than any intrinsic talent or overall intellect to be effective at the job. Honestly, sometimes I wonder if this is perhaps an under-considered area for Generative AI applications given how much drudgery is involved yet precision tends to matter.
  - larusso 3y ago
    Maybe… I mean yes at the bottom most package system are a zip with some kind of manifest or a manifest which describes where and how the lib can be build from which sources. If an AI could deal with the fine details of these systems… I mean Debian packages are harder than Arch packages, or at least that is my experience. There packages which are super easy to work with like native python, ruby and Java. But mix it with c extensions and boom. The CI can get complicated.
    - devonkim 3y ago
      If there's a lot of thankless, mundane work for the majority of projects that seems rather routine from what I've seen described thus far across multiple decades, so this seems quite ripe for some form of automation sans projects that seem to keep requiring changes constantly. C extensions, interop across languages, and ABI considerations are certainly much more complicated and require a lot of complicated work but given that 90% of the issues even power users run into are things like "the lxml library I installed won't get detected by package X when I run autoconf, please help." There's nothing sustainable as an industry about something like software dependency management and versioning being so critical for things "just working" while people are sticking their heads in the sand saying "not my problem" as a rule. I'm so tired of solving the same problems that were already solved in the past because of developers wanting to work on "more interesting things" and doing the bare minimum to get stuff compiling and running again regardless of the package format. In fact, Docker may have made this situation even worse with so many Dockerfiles that will basically be unable to work. This is part of why I'm interested in the Nix ecosystem because there's so much work being done to make software installations repeatable and easier to manage. Unfortunately, it's squarely aimed at developers and is way, way too complex for most sysadmins to put the time into understanding, especially when they're so overwhelmed like everyone else with so many tasks.

saurik 3y ago

I will second this advice; both of the engineers I have worked with who actively enjoyed being tasked with packaging software identified as systems operations / devops / site reliability engineering.

0x0203 3y ago
These are both very useful comments; thank you! In your experience, do the devops/sys ops engineers typically have useful coding experience? In our environment, porting a package to our OS may require a little, or sometimes a fair bit of modification to make it work and we often need to be able to read/understand the upstream code in whatever language it's in and change/add to it. Hence our (or at least my) assumption that we'd need a "developer."
- AaronM 3y ago
  Some do, maybe more with SRE title's. Better to put that in ajob description and filter for those with development backgrounds.
- mch82 3y ago
  In my experience creating packages for an operating system package manager or Docker images, a DevOps or sysadmin mindset is more beneficial than a developer mindset. For those packages, the goal is to follow operating system or deployment best practices. I’ve not created a Python or Rust package or something like that. If you’re creating that type of package, my guess is that it may help a lot to hire a developer who loves to think about the most “idiomatic” way to package your code. Edit: if your package will be published and used by customers, then you might look for DevRel skill as a bonus.
- faeriechangling 3y ago
  A good sysadmin may not be able to do graphics programming, but they have plenty of practice in the sort of programming used in package management, as well as a fairly good understanding of operating systems. They’re not going to grasp everything as well as somebody with a development background, like learning NEW programming languages on the fly and upstreaming changes, but I don’t think it’s totally outside of what they can learn and hiring a developer would present just as many challenges. I might look more for somebody who bills themselves as “devops” or “sre” than sysadmin though since those job descriptions tend to effectively filter out those who can’t program at all. If anything I see those people as being software developers that specialize in systems administration.
- stevekemp 3y ago
  In my experience a lot of people who started as developers 20+ years ago move on to system administration, and retitled themselves SRE/Devops over recent years. I don't want to talk about ageism, or hiring biases, but I'd imagine if you found anyone who had an SRE-role and a long history they would be extremely likely to have had serious coding experience. I've run into a few "young" devops engineers, and they tend to be more familiar with k8s, CI, and similar, rather than actually developing. But I guess that could well come down to the random people I've met, I wouldn't like to generalize.
  - prmoustache 3y ago
    > In my experience a lot of people who started as developers 20+ years ago move on to system administration, and retitled themselves SRE/Devops over recent years. Usually they don't retitle themselves, companies do. It seems the whole IT industry just collectively decided to rename the sysadmin role as devops when using cloud and containers technologies regardless if they actually use DEVOPS methodology or not. That is my history as an engineer at least.
    - stevekemp 3y ago
      Agreed. I'm an ex-developer, turned sysadmin. But these days my titles are Devops-This, and SRE-That. I find it hard to take too seriously, but I guess it is what it is.
- pxc 3y ago
  > In our environment, porting a package to our OS may require a little, or sometimes a fair bit of modification to make it work and we often need to be able to read/understand the upstream code in whatever language it's in and change/add to it. What one needs to understand will vary so much depending on the upstream package and how it's normally built (what it expects) that I think even someone with experience in packaging will sometimes get stuck or need to seek help or advice. The more substantive the porting work is, the more that will be true. That said, this kind of thing is pretty common for Linux distro packagers, and the weirder the Linux distro is, the more true that is. It's not at all unusual for Nix folks to add special build params, patch upstream software, or mangle binaries with sed in a post-build step to get them to understand NixOS' unusual filesystem structure, or to build offline in the restricted sandbox. So I'd reach out to contributors to BSD ports systems, especially if they added ports for Linux-centric software, and contributors to really weird Linux distros (NixOS, GuixSD, GoboLinux, Void Linux, etc.). I've never been in charge of hiring decisions anywhere so idk what the overall landscape of DevOps job candidates looks like. But I've done DevOps and I definitely do, and my friends in roles associated with that title can definitely do at least some coding and scripting in a way that I think suits most packaging tasks well. If a DevOps person has a CS degree of previously worked as a developer, they can probably figure out what they need to when it comes to patching upstream software to get it to build. Even if they don't, if they do some recreational programming, they can probably push through.
- prmoustache 3y ago
  As a sysadmin I used to do package management for different OSes but this is not necessarily the most rewarding job. Atmo, most engineers doing that are juniors or started doing that as junior and never cared exploring anything else / moving company.

larusso 3y ago

I not 100% convinced that profile works either. I tried multiple times to hire for my team which works with a combination of library maintenances build tool development and package management. I even tried a junior developer with an open mind. The skills needed for this job is sadly to broad. One needs to know the platform/language and tools to package software. And don‘t get me started with CI etc. Sysadmins and what most understand of DevOps are not the right kinda people. Not to say there are not people among this group.

devonkim 3y ago
The most appropriate group of folks may be those that already maintain software for the OSS community. The skillset more resembles trades where time and experience matters substantially more than any intrinsic talent or overall intellect to be effective at the job. Honestly, sometimes I wonder if this is perhaps an under-considered area for Generative AI applications given how much drudgery is involved yet precision tends to matter.
- larusso 3y ago
  Maybe… I mean yes at the bottom most package system are a zip with some kind of manifest or a manifest which describes where and how the lib can be build from which sources. If an AI could deal with the fine details of these systems… I mean Debian packages are harder than Arch packages, or at least that is my experience. There packages which are super easy to work with like native python, ruby and Java. But mix it with c extensions and boom. The CI can get complicated.
  - devonkim 3y ago
    If there's a lot of thankless, mundane work for the majority of projects that seems rather routine from what I've seen described thus far across multiple decades, so this seems quite ripe for some form of automation sans projects that seem to keep requiring changes constantly. C extensions, interop across languages, and ABI considerations are certainly much more complicated and require a lot of complicated work but given that 90% of the issues even power users run into are things like "the lxml library I installed won't get detected by package X when I run autoconf, please help." There's nothing sustainable as an industry about something like software dependency management and versioning being so critical for things "just working" while people are sticking their heads in the sand saying "not my problem" as a rule. I'm so tired of solving the same problems that were already solved in the past because of developers wanting to work on "more interesting things" and doing the bare minimum to get stuff compiling and running again regardless of the package format. In fact, Docker may have made this situation even worse with so many Dockerfiles that will basically be unable to work. This is part of why I'm interested in the Nix ecosystem because there's so much work being done to make software installations repeatable and easier to manage. Unfortunately, it's squarely aimed at developers and is way, way too complex for most sysadmins to put the time into understanding, especially when they're so overwhelmed like everyone else with so many tasks.