Slashdot Mirror


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.

45 of 271 comments (clear)

  1. Things to Learn by VorpalRodent · · Score: 5, Funny

    Checklist of things to learn:
    - Hindi
    - Mandarin

    --
    Take it to the limit, everybody to the limit, come on, everybody fhqwhgads.
    1. Re:Things to Learn by prefec2 · · Score: 3, Funny

      You got it all wrong:
      - Mandarin
      - Hindi

    2. Re:Things to Learn by RabidReindeer · · Score: 4, Insightful

      Mandarin's for hardware people. Hindi's for software people.

    3. Re:Things to Learn by Simon+Rowe · · Score: 4, Funny

      That's not right, we all know that marketing people speak b*llocks.

  2. Quite the Opposite by rnicey · · Score: 5, Insightful

    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.

    1. Re:Quite the Opposite by schneidafunk · · Score: 4, Interesting

      Agreed. Your selling point is your knowledge of business as well as technical skills. That combination is ideal for project management or business analyst, and you can get certified relatively quickly.

        http://www.pmi.org/certificati...

      --
      Some people die at 25 and aren't buried until 75. -Benjamin Franklin
    2. Re:Quite the Opposite by Rasperin · · Score: 4, Insightful

      There's a difference between a team lead, architect, PM, and an IT manager. The IT manager strives to learn and understand but basically manages the team, the PM translates the coders and works between them and the business. The team lead needs to understand everything and the architect needs to understand the code capabilities and the bigger picture.

      Here the guy listens, learns from those under him but has the previous technical insight and the business experience to be able to respect the iron triangle and the business while being able to manage money and his department. But hey don't listen to me on these definitions, this is just my experience. (I'm sure I'll get a bit of flame for even suggesting this)

      Though I guess if you haven't ever had a manager role I'd say go PM. But as real advice I'd say read up on modern JS techniques and go in as a front end developer at say a php shop or any shop that separates their front end guys from their back end guys. JS esp. things like node are making a rather big break through imho.

      --
      WTF Slashdot, why do I have to login 50 times to post?
    3. Re:Quite the Opposite by Anonymous Coward · · Score: 4, Insightful

      " It's like having someone in charge of you that doesn't even know how to do your job (on a conceptual level or otherwise). Why are they my manager or supervisor? What qualifies them to tell me what to do?"

      What are you? Twelve?

    4. Re:Quite the Opposite by zacherynuk · · Score: 5, Insightful

      Bollocks. This is the one thing that is killing older techs like us. IF WE DON'T WANT TO MANAGE, WE SHOULDN'T HAVE TO!

      I'm lucky enough to have a diverse enough job now I can pick and choose the things I want to do - indeed I get to delegate managers (I delegate managers to manage me!) and I never delegate decent techs to manage! - they are two very different jobs and mind sets. The payscale, the HR ladder and you, are simply wrong. It's a different job mate. "know your strengths" - if you like doing something you will be good at it, if you are good at5 something you will likely enjoy it.

      If now, at the the age of 49, I was told I couldn't do the things I enjoy doing (for paid work money) I would... I would probably just die, to be frank.

    5. Re:Quite the Opposite by ranton · · Score: 4, Informative

      What a jumbled mush of disgruntled ramblings. I can understand why you are so disgruntled because you are probably upset that none of your coworkers or likely even friends and family listen to your incoherent arguments.

      Making business more reliable and reducing risks is not communism. It isn't even capitalism, it is just good business.

      Part of managing a company is ensuring you do not take unnecessary risks. One very unnecessary risk is relying too much on individual employees. Any employee can be hit by a bus tomorrow, and a well run company can weather the loss of any one employee no matter how skilled. One part of proper knowledge management is codifying and disseminating the intrinsic knowledge of key employees so the company is not too reliant on them.

      --
      -- All that is necessary for the triumph of evil is that good men do nothing. -- Edmund Burke
    6. Re:Quite the Opposite by Maxwell · · Score: 3
      IF WE DON'T WANT TO MANAGE, WE SHOULD KEEP OUR SKILLS CURRENT SO WE DONT WIND UP IN THIS SITUATION

      ftfy

      Random string of lower case letters...Random string of lower case letters...Random string of lower case letters...Random string of lower case letters...Random string of lower case letters...Random string of lower case letters...Random string of lower case letters...Random string of lower case letters...Random string of lower case letters...Random string of lower case letters...Random string of lower case letters...Random string of lower case letters...Random string of lower case letters...Random string of lower case let

    7. Re:Quite the Opposite by dowens81625 · · Score: 5, Insightful

      "Personally, I hate it when I have managers that don't understand what I'm doing. It's like having someone in charge of you that doesn't even know how to do your job"

      I need to disagree with you,

            1. You have your job because the company you work for felt you were the best person to do it.
            2. Your manager has their job because the company you work for felt they were the best person to do it.
            3. Your manager is not there to do or understand your job.
            4. Your manager is there to ensure you do your job, to support you, to coordinate with the rest of the business that your job interacts with, leadership, users, finance etc.
            5. Your manager should be looking to you as the expert in your position. If they are not then you are not doing your job.

      I could go on an on about the differences between an Engineer, a Tech, a Manager, and a Team lead.

      It sounds like what you are looking for in a manager is really a team lead position.

    8. Re: Quite the Opposite by BarbaraHudson · · Score: 2

      Experience. He has been freelancing for more than a decade working in isolation. He cannot show any experience managing to any potential employer. Worse, he is seriously out of date. And no experience as an employee. Even if he was willing to work for free, nobody would hire him because of the cost of his errors of judgment and having to have constant close supervision. He's not even qualified to intern as any sort of management because anyone he manages will see that he's not qualified. Time to use this as an opportunity to get away from the keyboard and experience the real world.

      --
      "Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
    9. Re:Quite the Opposite by Ecuador · · Score: 5, Funny

      I agree with your notes on team lead, architects and IT managers. But I don't think you really get what Prime Ministers do, or how easy it is for the OP to become one.

      --
      Violence is the last refuge of the incompetent. Polar Scope Align for iOS
    10. Re:Quite the Opposite by geoskd · · Score: 2

      1. You have your job because the company you work for felt you were the best person to do it.

      You have your job because the person who hired you liked you the best out of the pool of people available to him or her at that time. This decision may or may not have been based on technical merit. Depends on the person.

      2. Your manager has their job because the company you work for felt they were the best person to do it.

      Your manager has their job because of the same process as above, but likely included more politics and less technical merit. I wouldn't rule out some golf at this level of management.

      3. Your manager is not there to do or understand your job.

      It has been demonstrated that managers that cannot do the job functions of their subordinates have a lower rate of success as measured by average task time to completion, turnover, morale, quality of team work-product, etc... In short, understanding the work that your team does is critical to effective management. That is why promote from within is a thing.

      4. Your manager is there to ensure you do your job, to support you, to coordinate with the rest of the business that your job interacts with, leadership, users, finance etc.

      Finally, one we can agree on.

      5. Your manager should be looking to you as the expert in your position. If they are not then you are not doing your job.

      Depends how long you have been in that position. If it is less than a year, then it is absolutely unreasonable (but not uncommon) for a manager to have that attitude towards an employee. From 1-5 years, it would be reasonable to expect competency. After that, expert level knowledge would be a reasonable assumption.

      --
      I wish I had a good sig, but all the good ones are copyrighted
    11. Re:Quite the Opposite by Etherwalk · · Score: 2

      It's like having someone in charge of you that doesn't even know how to do your job (on a conceptual level or otherwise). Why are they my manager or supervisor?

      Because they have other skill-sets or experience you lack, at least if they were properly promoted.

      A boss who doesn't know how to do your job but who trusts you when you say what you can or can't do or has an understanding of what you can or can't do can still be your boss in a useful way. If you're running a sports stadium, you don't have to know how to drive the Zamboni or run the concession stand, you have to know how to interface with the people responsible for them, as well as with the owners, etc...

    12. Re: Quite the Opposite by BarbaraHudson · · Score: 2

      The city planner probably doesn't know squat about laying bricks. That's why city managers don't manage bricklayers. The foreman who manages them certainly does.

      --
      "Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
    13. Re:Quite the Opposite by ReadParse · · Score: 2

      Who says he has knowledge of business? Just because he's 40-something? And a PMI certification? For the love of God. Here comes another useless PM.

  3. At the companies I've worked with... by Anonymous Coward · · Score: 4, Insightful

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

    1. Re:At the companies I've worked with... by Anonymous Coward · · Score: 2, Insightful

      ....you need to pick a class of application and learn it.

      I don't know about the UK, but in the States you have to have on the job experience for any particular skill for it to count. Taking classes or learning on your own doesn't count. I learned that the hard way. I posted code on GitHub with a reference on my resume and LinkedIN page and zero hits. People just didn't care enough to even look at it.

      And what also stinks is that you are your last job - all your previous experience doesn't seem to matter anymore. I was a senior developer for over 10 years and my company decided to lay off most of us in '09 because "of the bad economy". I took a part-time admin job to keep busy and not look like a "slacker". Well, the only bites I get are for low-level admin jobs - installing software, helping people find the 'start' button, etc ... for less than half what I was making.

      Things are so different than when I started in this business back in the mid-nineties. If you're not a 100% fit for a job then you "don't have the skills" or "you don't fit in" - and that's on the very rare occasion you actually get a response. It's this all or nothing hiring that seems so ridiculous these days.

      I recommend getting out of this industry ASAP. It's just not a viable career path for the long term. I met guys who were able to have 20 -30 year careers and it seems like it just doesn't happen anymore.

    2. Re:At the companies I've worked with... by RabidReindeer · · Score: 2

      I still use Perl when I have something that's heavily regex-based.

      Python's better for when you need something that's readable afterwards and/or leverages a lot of pre-written code.

      Python's equivalent of CPAN provides code that's a lot less fragile than what comes out of CPAN. Probably because it's not having to run a lot of stuff through a C compiler.

    3. Re: At the companies I've worked with... by tnk1 · · Score: 2

      Actually, I have interviewed people with ten years of experience who are shit. It's nice to have, but usually the only thing it guarantees is that they want more money. Sometimes, that experience is worth the money. Sometimes, it isn't.

      I recently interviewed a bunch of former government drones with years of experience. Except not so much. They were constrained by the roles that the government put them in, and they were spoiled by the rate that the government paid them to do as little as they did. They wanted a full-on senior salary, but they didn't want to do anything other than support their one interest area, with their few constrained toolsets. No thanks.

      If this guy came to me and demonstrated that he had experience on real projects in the past and he was excited about using the newer stuff we were using AND came to the interview with enough of an aptitude to demonstrate that he's actually learned something using the whiteboard/laptop, I'd seriously consider hiring him, even if he had a relatively junior position.

      Yes, if I got a senior person in for an interview who had both experience, skills, and versatility, this guy would lose out, but it's not always easy to find experienced people who want to join your team who have all that going for them.

      Note: one major disadvantage. Where he would lose out is salary, at least initially. I won't pay someone like that a full-on senior salary if they are simply an older learner. However, I also wouldn't screw him either. I want people who feel they can stay with the group long term, I don't want to churn and burn team members. If only because I hate having to get reqs and interview people.

  4. Two general directions... by Anonymous Coward · · Score: 4, Insightful

    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.

  5. Database skills by infernalC · · Score: 4, Insightful

    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.

  6. Moose, Moo, Mo by Anonymous Coward · · Score: 3, Interesting

    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.

    1. Re:Moose, Moo, Mo by sjames · · Score: 5, Funny

      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.

      Then learn to affect a cheesy eastern European accent and tell the interviewer you are after Moose and Perl.

  7. Sticking w/ Programming? by Anonymous Coward · · Score: 2, Insightful

    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.

  8. First of all by bferrell · · Score: 5, Insightful

    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.

    1. Re:First of all by rycamor · · Score: 5, Insightful

      Bingo. The real key is to go deep on something and specialize. As a web application developer approaching 50 who did a lot of database work, I realized I had put serious time into learning the ins and outs of the relational model, SQL, business rules thinking, etc... and I had also put lots of time into understanding Linux. Turns out database and Linux skills are in high demand. So I've dropped most of the web app programming (Honestly, in that domain you are competing with a worldwide talent pool, most of whom are willing to work cheaper than you) and really strengthened my enterprise database skills. I now do PostgreSQL consulting almost full-time, and really it is a pleasure to do more serious knowledge work instead of constantly scrambling for scut-level web application work.

      Also as you age, put more time into the things that change least. SQL isn't going away anytime soon. Ditto for Linux. Web app frameworks change every freaking *year*. Leave that stuff to the young guys.

    2. Re:First of all by NickyLogic · · Score: 2

      Well I went deep on astrophysics (stellar evolution) and while it was very satifsying, the career ramifications were less than stellar (pun intended).

  9. You can be anything by Anonymous Coward · · Score: 3, Insightful

    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.

  10. Re:Flip to a modern stack by preaction · · Score: 3, Insightful

    Learn Perl, Mojolicious, ReactJS, Bootstrap.

    Once you learn these, you'll never go back to the "old way" of doing things again.

  11. Sysadmin FTW by ErichTheRed · · Score: 3, Insightful

    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.

    1. Re:Sysadmin FTW by TheCarp · · Score: 2

      I came here to say a lot of this. Especially since, as I have gotten into the devops world myself, and there is a bit of an equalizer in that a lot of the big buzzwords are things that most people have kind of similar and easily obtainable levels of experience with.

      Chef hasn't been around so long that there are many people with more than a couple of years epxerience....but its also all done in ruby, which is decently easy to pick up at a basic level, especially if you know perl. You could easily get yourself up to speed, especially with any sysadmin background.

      If you can make it through the level of the advanced chef courses, which, seriously, for someone who knows what they are doing we are talking, a few weeks here you could be up to speed with most candidates out there. Which isn't a dig on them at all, its just that, most of the experience from administrative work or writing, running services is directly translatable, its really just a new toolbox to get get familiar with; for someone who can already fill admin and dev shoes, its a very natural move

      --
      "I opened my eyes, and everything went dark again"
  12. Look to larger, established companies for testing by doug · · Score: 3, Insightful

    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.

  13. Skill up by gregor-e · · Score: 2

    I'd advise you to paddle your canoe over to Python, Django and AngularJS or similar.

  14. Perl knowledge as an asset by Krishnoid · · Score: 2

    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.

  15. Follow your own passion first. by kyubre · · Score: 3, Interesting

    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.
  16. There are still a lot of Perl shops by oneiros27 · · Score: 2

    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.
  17. Object-orientedness micro-lesson by presidenteloco · · Score: 2

    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?
  18. Stop looking for approval by holophrastic · · Score: 4, Insightful

    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.

  19. Re: WTF by BarbaraHudson · · Score: 5, Funny

    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.
  20. Re:Flip to a modern stack by grcumb · · Score: 2

    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.
  21. Uh oh by khellendros1984 · · Score: 2

    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.
  22. Perl not dead! by hughbar · · Score: 2

    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!