Ask Slashdot: Career Advice For an Aging Perl Developer?
New submitter ukrifleman writes: I've been doing UK based perl, JS, light PHP and JQUERY dev plus Centos/Debian sys admin on a freelance basis for over a decade now. Mostly maintaining older stuff but I also undertook a big, 3 year bespoke project (all written in legacy non OO perl). The trouble is, that contract has now finished and all the legacy work has dried out and I've only got about 2 months of income left! I need to get a full time job.
To most dev firms I'm going to look like a bit of a dinosaur, 40 odd years old, knows little of OO coding OR modern languages and aproaches to projects. I can write other languages and, with a bit of practice I'll pick them up pretty quickly. I really don't know where to start. What's hot, what's worth learning, I'm self-taught so have no CS degree, just 15 years of dev and sys admin experience. I've got a bit of team and project management experience too it's quite a worry going up against young whipper snappers that know all the buzz words and modern tech!
Am I better off trying to get a junior job to start so I can catch up with some tech? Would I be better off trawling the thousands of job sites or finding a bonafide IT specialist recruitment firm? Should I take the brutally honest approach to my CV/interviews or just wing it and hope I don't bite off more than I can chew? What kind of learning curve could I expect if I took on a new language I have no experience with? Are there any qualififcations that I NEED to have before firms would be willing to take me on? I've been sitting here at this desk for 10 years typing away and only now do I realise that I've stagnated to the point where I may well be obsolete! Have a question for Slashdot's readers? Take a look at other recent questions first to see if someone else has had a similar question. And if not, ask away! The more details and context you include, the more likely your question will be selected.
To most dev firms I'm going to look like a bit of a dinosaur, 40 odd years old, knows little of OO coding OR modern languages and aproaches to projects. I can write other languages and, with a bit of practice I'll pick them up pretty quickly. I really don't know where to start. What's hot, what's worth learning, I'm self-taught so have no CS degree, just 15 years of dev and sys admin experience. I've got a bit of team and project management experience too it's quite a worry going up against young whipper snappers that know all the buzz words and modern tech!
Am I better off trying to get a junior job to start so I can catch up with some tech? Would I be better off trawling the thousands of job sites or finding a bonafide IT specialist recruitment firm? Should I take the brutally honest approach to my CV/interviews or just wing it and hope I don't bite off more than I can chew? What kind of learning curve could I expect if I took on a new language I have no experience with? Are there any qualififcations that I NEED to have before firms would be willing to take me on? I've been sitting here at this desk for 10 years typing away and only now do I realise that I've stagnated to the point where I may well be obsolete! Have a question for Slashdot's readers? Take a look at other recent questions first to see if someone else has had a similar question. And if not, ask away! The more details and context you include, the more likely your question will be selected.
Checklist of things to learn:
- Hindi
- Mandarin
Take it to the limit, everybody to the limit, come on, everybody fhqwhgads.
Time to move to management. Fluff the resume a bit and put yourself out there as someone who can manage a decent term project and get stuff done. Job interviews, much like everything in life, comes down to 10% what you say, and 90% how you say it. Come across as wise not old, confident not down on yourself, and have an air of "If you don't hire me you're a f'in moron" without actually saying that, and you might be surprised what you get.
...Python is the new Perl. So if you're looking to continue in the niche of Sysadmin-that-can-script (always in demand) definitely pick up Python.
After that, the question is: What do you *want* to do? It's not specific enough to say you want to code, you need to pick a class of application and learn it. Front end web development is fun, large-scale data processing and mobile applications require very different sets of tools all with their own very different learning curves.
Once you pick the development area you'd like to dive into, then the list of tools you need to be good with are probably in an O'Reilly book. So buy it and dive in. Take whatever job you can pick up in that niche as soon as possible and let a company pay you to move from intermediate to advanced while you make their products work.
Speaking as another aging (37) Perl developer with a somewhat similar background, you have the skillset to get in two potential directions (in this order)
1. You've got Perl + Sysadmin skills, so head towards DevOps positions. Start playing around with all of the Amazon cloud services at home and get used to them.
2. You've been doing web forever, head towards front-end jobs that leverage your existing HTML/CSS/etc and primary in Javascript.
If you worked on something serious, it used an RDBMS or some other better-than-csv database for data storage and retrieval. Don't discount your database skills. Look for jobs requiring experience on that flavor of database, and talk up your skills.
If you plan on staying with Perl, I would highly recommend checking out Moose and the other derivative packages that append object systems to Perl 5.
http://moose.iinteractive.com/en/about.html
Using Moose along with helper packages such as Moose::Exporter, Method::Signatures::Simple allow you to write classes that are familiar to classes in other languages but do things that have yet to be implemented there.
Once you start using a modern object system in Perl it's hard to go back to the old way of doing things, and you shouldn't have to.
If you want to stick with development, I'd get into Python (and the Django framework). Very popular right now and growing, easy to learn and lots of open source community help. Your sys-admin experience will also help a lot.
You could also look at a DevOps position if configuration management doesn't scare you.
40 is not a dinosaur. I'm 57 and have NO difficulty locating work. Fortunately (for me, not so much for employers). Employers have discovered that experience DOES count (and least those with more brains than a raven, those who don't... I don't want to work for anyway).
I also don't insist that I *deserve* every perc on the planet and that my work always be interesting.
Keep in mind, it's your work, not your life.
With this much experience you can do anything. Being a freelance engineer for a longer period of time IMHO qualifies you for any position. You want to keep writing code? Learn JavaScript/CoffeeScript/Node.js/Mongo, spend a couple of nights with it, or port some of your Perl code to Node and put it up on GitHub and you should not have any issues landing a contract. Want to manage? You can be a team-lead or a project-manager right of the bat, if you want to get corporate you'll probably need some certs. Also read up on Agile, Devops, Continuos-(testing/deployment) and try them out and you are set.
Learn Perl, Mojolicious, ReactJS, Bootstrap.
Once you learn these, you'll never go back to the "old way" of doing things again.
I do a strange combination of admin/design/integration work, and one of the reasons I do a decent job is because I can also script and automate stuff. You wouldn't believe how many Windows (and some Linux) admins lack these skills or are very rusty on them. So I'm the admin who can do a little coding -- can you be the coder who can do admin work? I believe the new phrase is DevOps...
I feel your pain and I'm getting older too. The company I work for does industry specific IT work, in an industry with a huge amount of proprietary, barely-transferable knowledge. I've seen people in my group get sucked so far down the proprietary knowledge route that they might as well be in your spot. I've had to really work to keep up to date, and am always trying to rotate my responsibilities around as much as I can to avoid being labelled "The X Guy", where X is some crazy technology that is interesting, but not conducive to employment outside our industry.
One thing I'd recommend is to think twice about management if that's not what you want to do. Most companies try to force good techies into management simply because that's the only promotional path available. However, I've worked for some awful managers who were great techies, and I'm not liking the small amount of management duties that have started creeping into my job description. if you like computers because they're more predictable than people, just wait till your first management job. People are not predictable or easy to deal with unless you have the skills...and it's something you're born with, not something you can acquire.
I've been using perl professionally for 22 years now, and I'm not seeing much of a drop off. I am noticing that a lot of the work is in testing organizations. They've written a lot of code and it needs to be maintained. Look around for automation testing positions and you'll see that a lot of them are in perl. It is not particularly fun and sexy, but you didn't say that was a requirement.
I'd advise you to paddle your canoe over to Python, Django and AngularJS or similar.
To most dev firms I'm going to look like a bit of a dinosaur, 40 odd years old, knows little of OO coding OR modern languages and aproaches to projects. I can write other languages and, with a bit of practice I'll pick them up pretty quickly.
A little tongue-in-cheek, but once you know Perl, you can argue that learning any other language with a fully-BNF-described grammar is much simpler.
I hit this decision point about 10 years ago (soon I'll be 50). Every manager I've ever worked for who moved on from being a crusty coder, sucked as a manager too, where as managers who did what they did because they loved it, where almost always really great. As the technologies I knew well began to fall to the wayside, I didn't not want to become a reluctant manager or lead. So I started over. And I have continued to do that every 3 or so years. Short of using a compiler, there is not one thing I do today that has much of anything to do with what I did 10 years ago, but I love what I do just as much. That's the trick - keep yourself engaged in what makes you excited. If that is managing teams - great. If not, don't become one of "those" mangers that lost his spark.
Nothing evolves faster than the word of god in the minds of men who think themselves divinely inspired.
See http://jobs.perl.org/
A couple of years back, I was trying to hire someone ... although we were hoping for OO Perl skills. We ended up hiring someone with database skills to train up in Perl, instead.
The problem with age isn't so much that you have less portable skills, it's that you have a less portable life -- if you have a sponse & kids, you don't want to move the kids in the middle of a school year and away from their friends ... if you have a spouse, you have the problem of trying to find a place that's convenient for both your jobs.
If you're single with no kids ... Booking.com is hiring in the Netherlands. It's effectively an English speaking country these days (although it's been 30 years since I've been there).
(I have no affiliation with booking.com, other than they were a sponsor for many years of the DC-Baltimore Perl Workshop, which I help to organize)
Build it, and they will come^Hplain.
0. MAKE A CONCEPTUAL MODEL OF THE PROBLEM-DOMAIN THAT YOUR PROGRAM WILL REPRESENT AND WORK ON.
Jot down a circles-and-arrows model (diagram) of the types of entities that exist (and are important as far as your program will be concerned) in your problem domain. The circles, with an entity-type-name written in each, represent the important different kinds of objects/entities in your domain. The arrows, which you may refer to later when defining attributes or functions that work on the entity types, summarize the important relationships you have noticed between the different kinds of entities in your problem-domain. Look around for groups of entity-types in your domain model which are really just different subtypes of a common kind of general entity type in your domain. Create a named circle for the general type of entity, drawing it above the group of more specific subtype entity-type circles, and join the general-entity-type circle, to each of the entity-subtype circles separately, with a different kind/colour of arrow than you used to represent relationships between one kind of entity and a completely different kind in your domain model diagram.
1. TURN THE CONCEPTUAL MODEL OF THE DOMAIN INTO A STRUCT-BASED DATA MODEL
Organize data (variable) definitions in the program you are writing into "struct" definitions, where each kind of struct has a set of attributes that together represent the essential properties of some kind of entity in your problem domain.
(And, for advanced credit, create an additional named struct-type to represent the properties of some kind of abstract record-keeping entity-type you are concocting as part of your "solution" domain. A "solution" domain model is an extension of your model of the problem domain, where you are adding abstractions (new variables) into your problem domain to create a computer model of the solution to whatever problem you've been asked to program a solution for in the problem domain. Some of those solution-domain entity types may not have occurred to you when you first looked around at the external "outside of the program" problem-domain to create your struct-definition-based data model of the problem domain entity types.)
2. NAME YOUR DATA TYPES AFTER THE PRECISE NAMES OF DOMAIN ENTITY TYPES
Use the common (but precise) name of each kind of domain entity as the type-name of the corresponding struct definition.
3. METHODS - are functions/procedures specifically applicable to the attributes of a single struct type.
For each type of struct you have defined, define the interface signature of, and code for the implemention of, a set of functions which access the attributes of, set the attribute values of, or compute some function of the attributes of a single type of struct.
4. INHERITANCE
Object-oriented languages let you create a struct-type which is meant to represent a specific subtype of domain entity, whenever you have already created a struct-type (and its functions) to represent the common attributes shared by several subtypes of entity. That is, you have already created an abstract supertype struct definition to represent general properties of a general category of domain entity, now you want to add attributes (or specific values of attributes) that describe how different subtypes of the general entity differ from each other.
In an object oriented programming language, the subtype of struct can be created so that its definition references (mentions) the supertype struct type by name.
Then any in-memory instance of that subtype struct inherits all the attributes and applicable functions of the supertype struct definition. Then you add more, specific attributes, attribute value settings, and function interfaces or function implementations to the new subtype of struct you are creating.
5. PROGRAM WITH YOUR DOMAIN-ENTITY-MODELLING STRUCTS AND THEIR STRUCT-TYPE-SPECIFIC FUNCTION-SETS
To represent
Where are we going and why are we in a handbasket?
You're 40+, with decades of experience. You're done proving yourself to others. Start selling your experience. Either manage others, or start your own business and manage others.
Clients don't ask suppliers what language is being used behind the scenes. You can keep doing what you do best -- I've got a 20+ year business in web development, and I'm still programming is raw perl -- avoiding new stuff when you have the experience with old stuff has so many advantages, to your clients too.
Modern stuff has a smaller/easier learning curve; but you're already past the learning curve. Anything modern won't be able to output a string of text any better than Perl, provided that you already know Perl, which you do. And since that's all the web is -- a whole whack of markup text -- who the hell cares.
Start your own, do what you like, hire the juniors when you actually want to, and you'll never need to apply for a job ever again. You're 40. It's about time you self-sign your own certificate. You're an expect.
Because the definition of "older" follows Moore's law in this industry. Every 18 months, old is one year less.
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
Learn Perl, Mojolicious, ReactJS, Bootstrap.
Once you learn these, you'll never go back to the "old way" of doing things again.
Also, Mojolicious.
Oh - and Mojolicious.
Okay, seriously: Mojolicious is an excellent and fast way to jump from legacy Perl to modern, rapid turn-around, DevOpsy kinds of web work. I've written a fairly non-trivial web service in it, and it's everything a (Perl) guy could want. The documentation is a little opaque; the authors assumes too much knowledge about the approaches he's taking, but once you learn his... uh.. dialect, I guess.... Once you get the way he expresses stuff, it's pretty easy to do non-trivial work with it.
Also, learn CouchDB or similar, because NoSQL and regexes can do wonderful things together when you're dealing with large amounts of heterogeneous data. And just because some new things are actually worth it, start learning NodeJS and Angular (or similar), because they incorporate some very cool—and accessible—new approaches to things that will appeal to a dyed-in-the-wool PerlMonger.
Me? I'm a 51 year old ex-Web guy who just recently decided to move on to entirely new things after facing a similar dilemma, so pardon my hypocrisy. If I were to stay in software, that's what I'd be doing. :-)
Crumb's Corollary: Never bring a knife to a bun fight.
What kind of learning curve could I expect if I took on a new language I have no experience with?
If you're over 40 and you don't know how to answer that question based on past experience, I think you're in trouble. Picking up new languages, frameworks, APIs, and what have you are just par for the course. Those things have been a constant in every development job I've had. If a language is related to something that I already know, then within a few weeks, I may be writing some Perl-ish looking Python and becoming more comfortable using constructs that don't appear in Perl very quickly.
It is pitch black. You are likely to be eaten by a grue.
I'm 64, a Perl guy and in London. I still get a fair amount of contract work, some of which I turn down. Recently that's included a couple of start-ups. Are you London area? I suspect this may also be a geographical and networking problem. I'm ex-investment bank and people know me.
Meanwhile some of the other advice is great, learn Python [I did], learn Java [I do some, hate it, it reminds me of COBOL], improve Javascript, especially the 'new' frameworks. But, I like to program and I like freelance, if you're programming 'for cash', then the advice about graduating to management is good. At this age, I can look at things and go NOOOOO, often saving others a lot of time, money and heartache, but I don't like meetings/suits etc. etc.
So if you're old, I'm moribund [although 2 hour half marathon suggests otherwise, keep healthy too!], don't despair, very best of of luck from me.
On y va, qui mal y pense!