Slashdot Mirror
From System Administrator to Developer?
ma11achy asks: "Recently, I have been looking at making a career change from Unix Systems Administrator to programming/software development. I have a CS degree recently obtained through distance education and have been working in the field of Unix Systems Admin for roughly seven years now (in my early thirties). I have reasonable knowledge of C, good knowledge of Perl and excellent knowledge of shell scripting. Is, is there anyone out there that has made the change and could they provide any insights into what it was like for them? Am I just barking up the wrong source tree?"
I went from programming to system administration and back again several times. If you know how computers work, it's not much of a leap to programming them.
Watching Cowboy Bebop in my jammies, eating a bowl of Shreddies.
I've done the sysadmin / programming thing... I hate programming although i'm good at it.. most programmers I know hate programming after about 3-4 years...
I honestly don't want to do this the rest of my life... although I have no idea what i want to do. Programming sucks your brains out...
ChiefArcher
I'm actually doing the same thing as you. I'm not a big fan of programming, so I don't know why you would want to do that. I would suggest studying finance as an alternative and not trying to make the switch over. Programmers are a dime a dozen ;)
(Don't go start a new project. That's the last thing the world needs, another abortive project run by a newbie.)
If programming turns out to be not your thing, you'll find out soon enough, and before you've got yourself mired in. One thing: as a Perl expert, you've most likely picked up habits that would make you an awful programmer. You will have to work hard to unlearn those.
When you go looking for professional programming work, you can point to your substantial contributions, and they will speak for you. Choose your project wisely.
Either way, your job is going to get shipped off to India.
you might want to try posting here: http://ask.slashdot.org/article.pl?sid=03/06/19/23 44253&mode=thread&tid=187
The thing is, you could say the same thing about BASIC programmers, or PHP programmers. And you might often be right, as well. It's a common generalization, a stereotype, if you will.
Perl--like BASIC--gives the programmer a lot of rope to hang himself with. It's quite possible that if that's all you know, you'll have a lot of trouble in a more structured environment. I know I had to learn a lot going from BASIC to Pascal, for example.
However, if you're an experienced programmer, if you learned good habits in the first place, or if you have some sort of bizarre knack for writing structured, well-maintained code in any language, maybe you won't have that many 'bad programming habits'. And after a certain point, a lot of this is subjective, anyhow. One person's bad habits can be another's coding guidelines.
pb Reply or e-mail; don't vaguely moderate.
I started as a sysadmin many years ago and was competent at it but my heart wasn't in it. It felt static to me. I suppose that's what maintenance is in the end, if you're good at it: routine.
I enjoy programming, which I've been doing for about four years, because I get a variety of gratification: short-term: every few days you implement something or fix something that was broken and; long-term: you finish a project or major piece and see a system working as a whole. Neither form of gratification can really replace the other and I found that I didn't get enough of either of these as a sysadmin.
Other than the ways in which the job is rewarding one thing I've really had to learn is to keep expanding my understanding of software and design. If you haven't already you should really look to learning what best practices exist and when/how to apply them; I'm thinking of things like design patterns, analysis patterns (bit dry but good), refactoring, etc.
Good luck!
It sounds like your skills and background are similar to mine. As long as you can show programming experience and skill, whether it is professionally or open software contributions, it is not too hard. However, some companies can be pretty limited in their mind set. A few years ago when I was moving from a sys-admin job to a development job NCAR in Boulder would not even interview me because they thought I had too much sys-admin experience to be a good programmer. they were apparently so limited in their thinking that they did not believe a person could know both fields.
One of my favorite kinds of jobs are the ones that are a cross between sys-admin and development. They require skill in all areas. Higher level sys-admin positions I have been in required a lot of perl, shell script, and even some C programming along with systems/network administration because they have involved developing disaster recovery systems, and writing lots of automation programs, to automate sys-admin, publishing of web pages, etc.
I have seen programmers so handicapped in their skills that they have to call the sys-admin for help just to set permissions on their files. Any company that is worth working for should consider sys-admin skill a plus. So keep looking and don't become discouraged if you encounter closed minded companies. You will be much happier in the long run being choosy about the type of job you accept.
I think making the move is entirely possible for you; you know computers fairly well, have a unique perspective on things that many programmers lack, and are used to being 'in the field'.
:-).
:-) (it would impress me!)
:-). So mentoring is a good deal for both parties. Hopefully, you can find a chance like that.
:-).
Pish-posh to the idiots who say being a Perl programmer somehow taints you. Please. Bad programming habits can occur in any language... the mere fact that you actually *want* to be a developer probably means you would be willing to listen to constructive criticism on how to improve your code. So, regardless of background, you probably could *become* a great programmer if you have any aptitude whatsoever. Enthusiasm is the core attribute most shitty programmers lack, they do it just for the paycheck. Good programmers do it because they dig solving problems
Here are the key things you'll need:
1) Code examples. You need a couple really good examples of problem solving and at least *decent* code. If Perl is your best language syntax-wise, then pick up "Programming Perl", read it over a weekend, observe the good programming habits in the code examples. Download a couple of Perl modules and read those too... that should show you how to write a Perl program while avoiding really nasty habits. Then write a program in that style to solve a personal itch. Get a couple of those that you can show some enthusiasm for, and you will do well in an interview where you get to talk to actual programmers
2) Look for a job where you can join a small-to-medium size team. Ideally, one organized into senior/junior developers. See, you want to learn from senior guys who are actively mentoring juniors. I know I do that, because the more I teach my team members how to most effectively program, the more I can delegate coding efforts to them and know they will do it mostly the way I would do it if I had time
3) If you get a job in a larger group, don't be discouraged. You might be shitty tasks parsed out to you, or you might get overwhelmed with tougher things you don't feel ready to tackle. Either way, forge onwards -- you're a programmer now! Read more good texts on programming (on company time) if you're under-utilized -- I'd hardly fauly anyone on my team who did that! If you're swamped, admit it -- and try to draw others on the team into that mentoring/sharing experience you want. Who knows, you might encourage better teamwork overall... some of the shittiest programming jobs got that way just because the team as a whole lost spirit -- as the new guy, you're the best equipped to cut through that crap (before you get sucked into it too ).
I'd say give it a shot. You'll certainly learn something. In a pinch, you've got a lot of skills to fall back on. I mean, if you were under-utilized as a programmer, maybe you can fill out your time by offering sysadmin advice or picking up all those loose 'admin' tasks the IT department isn't handling
It's a strange world -- let's keep it that way
It sounds like your skills and background are similar to mine. As long as you can show programming experience and skill, whether it is professionally or open software contributions, it is not too hard. However, some companies can be pretty limited in their mind set. A few years ago when I was moving from a sys-admin job to a development job NCAR in Boulder would not even interview me because they thought I had too much sys-admin experience to be a good programmer. they were apparently so limited in their thinking that they did not believe a person could know both fields.
One of my favorite kinds of jobs are the ones that are a cross between sys-admin and development. They require skill in all areas. Higher level sys-admin positions I have been in required a lot of perl, shell script, and even some C programming along with systems/network administration because they have involved developing disaster recovery systems, and writing lots of automation programs, to automate sys-admin, publishing of web pages, etc.
I have seen programmers so handicapped in their skills that they have to call the sys-admin for help just to set permissions on their files. Any company that is worth working for should consider sys-admin skill a plus. So keep looking and don't become discouraged if you encounter closed minded companies. You will be much happier in the long run being choosy about the type of job you accept.
That's why God created expand and unexpand; all you have to do is figure out how to use them once, and then you can make all your tabs/spaces problems go away forever.
Sometimes inconsistency is worth it; it all depends on the situation. Remember, "foolish consistency is the hobgoblin of little minds".
pb Reply or e-mail; don't vaguely moderate.
One of the things that attracts me about sysadmin is the variety of tasks required to do the job well. You have to be good with computer systems, of course. But your computer knowledge has to be broader than average, because solving systems problems frequently requires understanding the system at several different levels at once (Here I use "system" to include multiple computers connected with a network.) You also have to worry about hardware, and may find yourself elbow deep in a rack or under someone's desk. In addition to the technical aspects of the job, you also need to interact with people an awful lot, often under under difficult circumstances.
Computer programming requires a different skill set. Here, intense concentration on a single subject is a key skill. Your knowledge needs to be very deep in the particlar area you are working in. There's less of a premium on people skills. I don't have a college degree, and I've noticed that such degrees are less common among sysadmins than among software engineers. This could just reflect hiring bias, but I suspect it actually means something. Academic training in Computer Science, particularly in algorithms, is probably more useful for a software engineer than for a sysadmin.
For myself, the coding I do is another of the whole suite of tasks I am called upon to address as a sysadmin. I enjoy the intense concentration, but I'm glad I don't have to keep it up year after year. Instead I can jump from task to task, often having several going at once. Or I can learn some new technology that has popped up in the workplace. My jobs have been anything but boring, and boredom is my number one bummer thing.
Shameless plug: It's ironic that people who appear so similar on the surface can be so dissimilar at a deep level. (I've written a whole paper about it. The software it describes is at http://egbok.com/sudoscript
"Even if you are on the right track, you'll get run over if you just sit there" - Will Rogers
But the department I was in had all kinds of programming needs that weren't being met by the programmers. There were a lot of admin. assistants doing tedious manual work when an Excel spreadsheet or Perl script could do it much faster. So I just started doing little apps for the people I knew and got a reputation as someone who could get stuff done.
Then I found another need -- there was a huge hole in our website (campus map for the university where I worked) that nobody had time to fix. So I made my own webapp for it and started talking to the people who ran the official site about using my version instead.
They hired me about six months later.
So my advice is: find an unmet need and meet it. Another post mentioned open source, which could be a good route. But if you fix something your boss needs, it's much more likely to result in a programming job.
-Esme
I followed the same route, here's a brief rundown of what happened.
I found a project that interested me (KDE) and started trying to write my own program for it. I tried to made a graphical version of videogen, which is an XFree86 modeline generator. My version made it a little easier to play with combinations of the various parameters, and therefore scratched my personal itch. IIRC I announced it on freshmeat and got a few emails from people who wanted assistance or to request features.
Now that I had a little experience with writing for KDE, I made my own version of the classic game 'sokoban.' KDE and Qt made this really easy (even for me as a beginner) and I had it usable in a few days, though I hadn't noticed that there was already a sokoban clone in the pipeline for inclusion into KDE, so that little app died off.
At this point, I decided that kmail wasn't as good as I would like, and decided to try and help out, but I was about to lose my internet connection for some months and didn't feel that my skills were good enough to be actually putting code into live KDE apps, so I started my own mail client from scratch.
By the time I got my internet connection back, I had more confidence and started coming up with patches for KDE. From this point, I got more involved with the project and the community. I have my own application in the network module now, and though I don't have time to work on KDE actively right now, the skills I learned have helped me get my current job (where I get to use Qt, which is great for me.)
I would definitely recommend the route of scratching your itches and getting involved with a large project, assuming you are comfortable working in such an environment.
Rik
Since you are posting Stunnix Perl-Obfus ads on slashdot I think I should post a link on its "review".
--
Ilya Martynov (http://martynov.org/)
I'm suprised at the direction of the change..
I grew up with computers, my first being a ZX Spectrum, then graduating through bigger machines until I landed in PC-land.
I fought for a job with a local company a few years back and managed to become a java programmer despite minimal knowledge. Since then I've worked for about four years as a Java/C++ programmer - utilising other skills such as perl, x86 assembly, etc.
After that much time though I realised I actually hated programming for other people - it took most of the fun out of it. (This is a simplification of course).
Luckily I found myself in a position to do 'part time' sysadmining when a colleauge left the job.
Now I'm full-time sole sysadmin for a larger company and I couldn't be happier.
Sure I still write code .. bash scripts, perl code, and other utilities to help myself and my minions - but now I do it for fun.
There's no way that I'd ever go back to being a developer. I like the variety, the challenges, the sheer unpredictability of my current role - becoming a developer would remove so much of that.
II. Everything becomes boring after some time
III. Next career step might be training
IV.
V.
Enjoy ! :-)
I know most people hate testing and see it has a dead end boring job, but if you take the right attitude it can be a good gateway to a future career in development (hey you might even find you like test).
With your skill list, in particular you use of scripting languages, I would say you are ideally placed to join a company as a software tester. While you have no experience as a tester machine maintenance and scripting is always needed, there is usually the opertunity to produce software testing frameworks and "real" code to test your product with.
Do this job for a couple of years, but make sure you build a really good relationship with development during that time, and whenever possible do as much product diagnostic as you can. Once you have proved yourself as a good tester and coder, with good product knowledge, the move into development is easy just talk to the people you know about moving.
This is exactly what I have done, moving from a sys admin role, into software test, and will be moving to developing the product I once tested in a few months time.
Good luck and hope you enjoy it!
If you ever drop your keys into a river of molten lava, let'em go, because, man, they're gone.
Behold the Bastard Developer From Hell.
He makes programs that will surely crash or give false results, thus freaking out the luser.
Rumor says some BDFHs work in Microsoft.
the Knuths! the Knuths! the Knuths are on fi-ah!
There are some really good comments here, but I haven't seen this one yet. I came to understand it because I've had several young people ask me to teach them to program. I'm of a strong opinion that programming can't be taught. At least, not useful, elegant, maintainable, and thrifty coding. I quite agree that coding is an art, and, as such, the old adage "writer's write" is key. I've heard this told to aspiring writers, and it simply means that if you have a future in writing, you will already be, say, keeping a journal, or submitting stories to the local paper, or, these days, keeping a blog. The point is that when someone is at the point you're at (asking if they should go into a field), you can predict their success based on what they're already doing. The bottom line is that if, as a sysadmin, you don't find that you're already writing a lot of programs to help you do your job, then you're probably not really a programmer. Can you do it anyway? Sure. Anyone can do anything they have the talent for given enough determination, but it will just be a job, and that tends to wear thin. I guess I'm in the camp that believes that a being able to write really good code is more of a gift than a talent, and finding your purpose in life is about finding your gifts. If you have that gift, you'll enjoy it. But if you do, you're probably already doing it.
Acts 17:28, "For in Him we live, and move, and have our being."
The same burnout effect can happen to professional atheletes, as well. Ever heard of Alexandre Daigle? He was a first overall NHL draft pick, and was expected to be a superstar. He only played about 5 years and just quit. He said he was bored, and effectively burnt out, after playing hockey since he was a small child. Eventually he admitted that the main reason he played was because he was good at it, not necessarily because he loved to play.
Is that a real poncho? I mean, is that a Mexican poncho or is that a Sears poncho?
See if your current employer has any opportunites. The advantage is that they already know your a good worker (assumption ;) and you may already know some of the managers in the development area and can convince them to take a chance on you. If you have to, offer to keep doing your current system administration duties. This could mean extra work for you, but if you can gain the programming experience you need it will be a win in the end.
My other advice is to keep your system admin skills fresh. I have been doing both sys admin and programming for my entire career (15+ years) and when times are tough, like now, being able to take jobs in either area is a nice advantage to have.
What about moving from programming to system administration?
One problem I percieve is that employers currently have a surplus of canidates and have a luxury of being very choosy. So, for example, I have a stacked resume but not much system-administration-specific work experience, so I am already at a disadvantage relative to someone with even one solid year of sysadmin work under their belt.
It feels as if making any career change, right now, is an uphill battle.
Healthcare article at Kuro5hin
...wanna switch?
It's 10 PM. Do you know if you're un-American?
I think it happened because it was supposed to in
my case. A large part of the admin work I've had
in the past involved task automation. I worked for
a very 'frugal' employer that wasn't interested in
spending money for anything. Over time, the projects
I spent time on got increasingly complex. What
started out in the early years as mostly writing
simple perl glue code to make product A talk to
product B snowballed into writing full shopping cart
programs in C. I made the jump to developer when I
was tasked to write custom web-based applications
for internal customers on the fly utilizing full
project life cycles. Eventually the projects got
big enough that I required a team of underlings
to help me code my visions. I ended up doing less
and less admin work, and more straight developing
until that's all I was doing. I guess the best
advice I can give is a two parter.
#1. Make damn sure you are the kind of person that
can sit down and puke up X number of lines of
half decent code in X number of hours without
going insane eventually. Developing isn't for
everyone. To be honest it ultimately wasn't for me
and I burned out on it.
#2 Help out. Speak up and get yourself involved
with a team working on something that interests
you. If that doesn't work, give some of your time
to a well chosen open source project. I've seen
plenty of developer wannabe's get instant
attention and admiration by putting in time with
an open source project that directly benefits
the company they work for. It's a great way to
get noticed.
Hope this helps
For every annoying gentoo user, are three even more annoying anti-gentoo crybabies. Take Yosh from #Gimp for example.
I started programing in BASIC and then BASICA on an old IBM XT with IBM DOS 3.something. I learned by example from BASIC games in the back of Highlights magazine (science version) borrowed from my JrHigh teacher. I now work at a small game developer in southern California making 35,000USD with only a GED.
I give that background to say that this 0.02USD is coming from the other end of the spectrum, I've taken some CS courses at the local Jr College, but of the 3 professors, 1 is a geneous (worked for JPL out of highschool and designed a guitar pedal for Hendrix) and the other 2 are boneheads, after I did all the courses from the good prof. I quit and am now looking at going back to school for a completely job unrelated major (like english).
Anywho, so I really don't know what your CS studies have given you in the way of preparation for the real world of programing, but if say you were going to come work with me, here's what I'd want from you.
1) DOCUMENTATION! DOCUMENTATION! DOCUMENTATION!
I don't know about undergrad level CS, but the 100 to 200 level courses I've been exposed to lacked grotesquely in this aspect.
Remember, when you get paid for code, sure your check depends on if it works or not, but to give your employer their honest moneys worth you should really supply documentation in the form of at least one technical design document and lots of comments in your code. Also (and this is more personal preference than anything) most compilers in most languages can work with pretty long variable names so use the long names and save on comments (I don't mean never use 1 letter variables, 'i' is fine for a loop incremental, but with more importaint or complex things, go big).
Remember, you're probably not going to be at company X forever. So when the time for feature additions or new platform support comes down the line, the code you can be proud of is code they can throw at a Jr programer for the tweaks and not give him/her an ulcer just trying to figure out WTF you were trying to do, let alone where the bug/incompatiblity is. Also, even if you are at company X forever, you may be busy with project Z when they need work done on project Q from when you first started there. So they give the fixes to another programer, imagine how embarrased you could be if they crack open your source and see a big uncommented mess! Maybe project Z will end up being your last.
2) Avoid band-aids!
Note I say avoid and not never use. When there's a problem with the way an object was designed (possibly due to no fault of your own, being a smaller company in the games buisness, publishers love to throw feature changes at us half way through a project because they can get away with it) take the time to rewrite the object if needed. Of course unless it's the day before your milestone and there just isn't time, then it's okay to do a bandaid, but then document the hell out of so that when/if anybody else has to go into your code you don't look like an idiot.
3) Paper first!
Thats something I learned from the 1 good professor at my community college. When I whip up little tools and such (which I imagine is most of the author's experince, making tools to make admin life easier) I just jump right in and code. However, when it's code in the actual product it's worth it to take the time to sit down and draw it all out on paper. Pseudo-code, object diagrams, hierarchy, sure there's visualization programs out there but it's faster on paper.
One of the big advantages of drawing it out on paper is that as a programer (at least as me) you get attached to that object you stayed up until 3AM writing. Then you find a flaw in it and should rewrite it, but it's so much more tempting to just bandaid it. If it had been written out on paper first, you may've caught the design flaw ahead of time and instead of throwing out all that code, all you're looking at is a little scribble here, jot down some new psuedo-code and a little scribble here, there and there to carry the changes to all the depen
DONT PANIC
If you've been stuck in a job where you've got several projects on the go, possibly all in different languages (plus databases), and with upcoming deadlines: chances are you will at some time face burnout. It's nice in that case to be able to have something to drop back onto. Sysadminning is a decent switch as you still have some coding but are often away from the hardcore coding. In the same aspect, coding can be a nice switch after being a sysadmin where users are screaming at you because their end-of-year reports are due and the server has crashed somewhere...
I've often considered a non-computer job, something in electrical, electronics, or perhaps automotive would be nice. I like to work with hardware, and my car isn't really that much more mystifying than a lot of PC stuff. Having something to switch off can be nice, especially if your current market gets overloaded with applicants.
As for coding, it's almost like a drug. You can become completely involved in a piece of software: resizing arrays in your head, dreaming up functions while you sleep, etc for the length of the project. Then, you almost want to cry when you're 95% done and you have to give up your baby because of a budget slice, or because a cheaper/faster/premade solution presents itself.
I am a web developer but since I am the only technical person in the company (15 employees, ceo and president are a married couple) I end up taking care of all IT. In my previous job IT meant 99.99% Microsoft stuff. Here it is two windows servers, two windows desktops and at least 15 mac desktops. Oh yes, and a freeBSD mail server.
I am noticing that it annoys me less and less to spend the day dealing with IT issues instead of writing code. It's also a lot of hands-on experience I was not getting before. I always assumed I would spin off my own company after I had enough non-programming experience (just because you have been a programmer 15 yrs does not make you qualified to open a programmer business by yourself) but lately I realized theres a lot of technical stuff you always take for granted.
For example, buying a new office phone system is a pain in the ass. Or switching from tapping into somebody elses network (we paid him $500/month, total ripoff) to having your own T1. Or trying to turn on the firewall rules on a goddamn Netopia 4522xl with crappy documentation and conflicting advise from SECOND tier tech support.
I guess most of us will be toeing that line. Most web devs I know are stuck managing their own servers because their clients are too cheap to hire proper help to get their servers setup. And this is stupid stuff like installing a sql server or locking up the SMTP in IIS so it does not end up being abused as an open relay, that kind of thing. Mention Oracle or Sendmail and they freak out.
Pedro
----
The Insomniac Coder
Move up in responsiblity.
As you take on more responsiblity you get farther away from coding and more into a larger scheme of things, technical design, managing people, moving numbers around in budgetting.
Its a whole different set of skills, whole different world and you are leveraging the base/low-level knowledge you have from programming.
Looks good on a resume, its good money and you can always return back when you feel like you are getting "burn-out" from the higher level stuff.
The surprise isn't how often we make bad choices; the surprise is how seldom they defeat us.
Tip #1: Be aware that system administration and programming are different things. Understand the differences - in some cases, your sysadmin background will be invaluable. In other cases, your background will be useless. The rest of this comment is a description of some of the differences.
Tip #2: Software development is largely about solving business problems.
While system administration is largely about keeping machines/networks/infrastructures running, programming is all about building a product for a customer (even if the "customer" is really an internal user and the "product" is just a program). Thus, when you switch over to programming, you focus on building what your [customers|users|product development team] wants. You need more people skils, more UI skills, more "analysis" skills.
Tip #3: Programming is different from "sysadmin scripting".
Other posters have definitely mentioned this, but understand that programming is very different from scripting. Admittedly, some system administration scripting is really programming but most of it isn't. Some of the key differences:
Tip #4: Software development is a team-effort. You'll need to conform.
Software development (in all but the smallest efforts) involves a team. Thus, you'll find:
Tip #5: Good system design/architecture skills are very different from system administration skills.
System design/architecture is complicated - and involves a completely different set of skills than system administration. Don't assume you can build systems just because you can administer them. Luckily, you don't need these skills when you begin - just be aware that system design is very different than programming.
Tip #6: Most programmers haven't a clue about system administration - use this to your advantage!
I apologize to all the great programmers who I'm offending, but most programmers/architects tend to ignore the system administration issues surrounding a system. For example, do they have a rollout/rollback procedure for releasing components? Do they have an interface for stopping/restarting components - or do they just expect the sysadmins to 'know how to do it'? This is one area where
Thank you. What do you find more rewarding? I've done a mix of sysad and ops management, with programming/dev only at the academic level. I found many aspects of management enjoyable and challenging, but am now back to infrastructure management because I worried I strayed too far from the hands-on work that got me to management to begin with. I'm wondering if my future in infotech management will suffer because I don't have professional program development in my resume.
So long, michael. Don't let the door hit you...
this skill combination makes you qualified to work on large projects and gives you the deep admin skills needed to implement/make production ready the app you've developed.
my observation has always been that sysadmins as a group have fewer people skills than developers or people who work closer to the user. Are you user-friendly? Do you tolerate poor or changing requirements? These are bigger issues for developers.
a lot of sysadmins can't write code. Or can only write job-scheduling scripts, however complicated. this is really different from implementing business functions. are you interested in solving the business problem? (a lot of sysadmins here think they solve the business problem. The customer doesn't. the customer thinks the apps that implement their business functions are what solves their problems.)
if you love sysadmin, you should probably stick with it. but if you want to really extend your skills you can become a one-stop shopping expert.
I can't agree with the suggestion that you try OSS work as a way to get started. most customers don't understand it, some are afraid of it. and frankly it's a lot tougher than a lot of commercial programming. better to work your way up to it doing commercial work, getting a paycheck while you learn. an hr rep doesn't understand a job reference from an OSS project.
if you think it is a good personality match, go for it.