Recruiting people who maintain & improve, not just chase the new and shiny












58














My work will be recruiting soon, and one thing I'd like to do is screen out people who are more excited about writing new, exciting code than fixing older code, and more generally, people who recognise that good code is about more than lines of code written per day, and that design, documentation and testing are also part of being a coder.



If I ask straight out "How do you feel about working with other people's code and fixing bugs as opposed to writing new code?", I suspect a lot of people will say what they think they're supposed to say - i.e. "fixing bugs is important", but this may not reflect their actual working practices.



What questions or polite (not overly time consuming) tests would you ask to find someone who is interested and willing to maintain and improve code?



Edit to add: The role would definitely involve some new work - I don't want to give the impression it's maintenance only! This is more about screening out people who prefer to delete-and-rewrite every time, rather than fix a bug...










share|improve this question




















  • 8




    There's a similar issue with steering people away from always using new unproven tech in their code. You want to give them some, but not too much because it will sink a project.
    – Mark Rogers
    yesterday






  • 3




    Are you sure there are any people who are more excited about fixing older code? I'd say providing fixes and other no-rewrite solutions is more like a devops job. But in my opinion delete-and-rewrite is what should be done in most cases. At least refactor. See 2.11 in this
    – Džuris
    yesterday






  • 1




    I think the importance of code maintenance is learnt over time so a mature developer is likely to respect maintenance more. Also rewriting code is a lot easier because you do not need the ability to understand the old code, therefor I assume mature developers will be more willing to improve old code rather than rewrite it.
    – Damien Golding
    9 hours ago


















58














My work will be recruiting soon, and one thing I'd like to do is screen out people who are more excited about writing new, exciting code than fixing older code, and more generally, people who recognise that good code is about more than lines of code written per day, and that design, documentation and testing are also part of being a coder.



If I ask straight out "How do you feel about working with other people's code and fixing bugs as opposed to writing new code?", I suspect a lot of people will say what they think they're supposed to say - i.e. "fixing bugs is important", but this may not reflect their actual working practices.



What questions or polite (not overly time consuming) tests would you ask to find someone who is interested and willing to maintain and improve code?



Edit to add: The role would definitely involve some new work - I don't want to give the impression it's maintenance only! This is more about screening out people who prefer to delete-and-rewrite every time, rather than fix a bug...










share|improve this question




















  • 8




    There's a similar issue with steering people away from always using new unproven tech in their code. You want to give them some, but not too much because it will sink a project.
    – Mark Rogers
    yesterday






  • 3




    Are you sure there are any people who are more excited about fixing older code? I'd say providing fixes and other no-rewrite solutions is more like a devops job. But in my opinion delete-and-rewrite is what should be done in most cases. At least refactor. See 2.11 in this
    – Džuris
    yesterday






  • 1




    I think the importance of code maintenance is learnt over time so a mature developer is likely to respect maintenance more. Also rewriting code is a lot easier because you do not need the ability to understand the old code, therefor I assume mature developers will be more willing to improve old code rather than rewrite it.
    – Damien Golding
    9 hours ago
















58












58








58


8





My work will be recruiting soon, and one thing I'd like to do is screen out people who are more excited about writing new, exciting code than fixing older code, and more generally, people who recognise that good code is about more than lines of code written per day, and that design, documentation and testing are also part of being a coder.



If I ask straight out "How do you feel about working with other people's code and fixing bugs as opposed to writing new code?", I suspect a lot of people will say what they think they're supposed to say - i.e. "fixing bugs is important", but this may not reflect their actual working practices.



What questions or polite (not overly time consuming) tests would you ask to find someone who is interested and willing to maintain and improve code?



Edit to add: The role would definitely involve some new work - I don't want to give the impression it's maintenance only! This is more about screening out people who prefer to delete-and-rewrite every time, rather than fix a bug...










share|improve this question















My work will be recruiting soon, and one thing I'd like to do is screen out people who are more excited about writing new, exciting code than fixing older code, and more generally, people who recognise that good code is about more than lines of code written per day, and that design, documentation and testing are also part of being a coder.



If I ask straight out "How do you feel about working with other people's code and fixing bugs as opposed to writing new code?", I suspect a lot of people will say what they think they're supposed to say - i.e. "fixing bugs is important", but this may not reflect their actual working practices.



What questions or polite (not overly time consuming) tests would you ask to find someone who is interested and willing to maintain and improve code?



Edit to add: The role would definitely involve some new work - I don't want to give the impression it's maintenance only! This is more about screening out people who prefer to delete-and-rewrite every time, rather than fix a bug...







software-industry recruitment






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited 2 days ago

























asked 2 days ago









yochannah

4,59063050




4,59063050








  • 8




    There's a similar issue with steering people away from always using new unproven tech in their code. You want to give them some, but not too much because it will sink a project.
    – Mark Rogers
    yesterday






  • 3




    Are you sure there are any people who are more excited about fixing older code? I'd say providing fixes and other no-rewrite solutions is more like a devops job. But in my opinion delete-and-rewrite is what should be done in most cases. At least refactor. See 2.11 in this
    – Džuris
    yesterday






  • 1




    I think the importance of code maintenance is learnt over time so a mature developer is likely to respect maintenance more. Also rewriting code is a lot easier because you do not need the ability to understand the old code, therefor I assume mature developers will be more willing to improve old code rather than rewrite it.
    – Damien Golding
    9 hours ago
















  • 8




    There's a similar issue with steering people away from always using new unproven tech in their code. You want to give them some, but not too much because it will sink a project.
    – Mark Rogers
    yesterday






  • 3




    Are you sure there are any people who are more excited about fixing older code? I'd say providing fixes and other no-rewrite solutions is more like a devops job. But in my opinion delete-and-rewrite is what should be done in most cases. At least refactor. See 2.11 in this
    – Džuris
    yesterday






  • 1




    I think the importance of code maintenance is learnt over time so a mature developer is likely to respect maintenance more. Also rewriting code is a lot easier because you do not need the ability to understand the old code, therefor I assume mature developers will be more willing to improve old code rather than rewrite it.
    – Damien Golding
    9 hours ago










8




8




There's a similar issue with steering people away from always using new unproven tech in their code. You want to give them some, but not too much because it will sink a project.
– Mark Rogers
yesterday




There's a similar issue with steering people away from always using new unproven tech in their code. You want to give them some, but not too much because it will sink a project.
– Mark Rogers
yesterday




3




3




Are you sure there are any people who are more excited about fixing older code? I'd say providing fixes and other no-rewrite solutions is more like a devops job. But in my opinion delete-and-rewrite is what should be done in most cases. At least refactor. See 2.11 in this
– Džuris
yesterday




Are you sure there are any people who are more excited about fixing older code? I'd say providing fixes and other no-rewrite solutions is more like a devops job. But in my opinion delete-and-rewrite is what should be done in most cases. At least refactor. See 2.11 in this
– Džuris
yesterday




1




1




I think the importance of code maintenance is learnt over time so a mature developer is likely to respect maintenance more. Also rewriting code is a lot easier because you do not need the ability to understand the old code, therefor I assume mature developers will be more willing to improve old code rather than rewrite it.
– Damien Golding
9 hours ago






I think the importance of code maintenance is learnt over time so a mature developer is likely to respect maintenance more. Also rewriting code is a lot easier because you do not need the ability to understand the old code, therefor I assume mature developers will be more willing to improve old code rather than rewrite it.
– Damien Golding
9 hours ago












8 Answers
8






active

oldest

votes


















74















What questions or polite (not overly time consuming) tests would you
ask to find someone who is interested and willing to maintain and
improve code?




In general, I find that the key is to ask more open-ended questions, rather than question which can be answered with a simple Yes or No, or a very short answer.



Something more along the lines of "Tell me about the kind of work you enjoy doing" would give you better clues. If it's all about creation/invention and nothing at all about improvement/testing/refinement, then the candidate might not be happy filling the role you have.



Once past that question, you can dig in with something like "Tell me about a time when you had to dig in and maintain some difficult code."



At some point in the interview process, you want to make the details of the role clear. And you want to be clear how long that role would last and what it might lead to. It would be silly to set the wrong expectations for a new hire.



As others have pointed out, a good job description will help attract the right kind of candidate and let others self-select themselves out. A job description which incorporates the thoughts in "people who recognise that good code is about more than lines of code written per day, and that design, documentation and testing are also part of being a coder" could help.






share|improve this answer



















  • 5




    This is a great answer, I started to write my own but eventually realised I was just rewording this one.
    – davnicwil
    yesterday






  • 1




    @XavierStuvw - I don't think I understand "Which ones could they be?" means here.
    – Joe Strazzere
    yesterday






  • 1




    @davnicwil It is a good approach, but beware. If the answer was, "I ripped it all out and rewrote it" you might not actually have a person doing maintenance in a safe way. You might have a person doing greenfield work on an existing project. There are times where a module should just be rewritten from scratch, but they are rare, and typically are rewritten to satisfy full unit testing suites.
    – Edwin Buck
    yesterday






  • 2




    @JoeStrazzere Fantastic! I just saw the prompt to ask the question, but I didn't notice any hints on how to evaluate the answers. Many people need that latter part, even if this OP and you are not in that set of people :)
    – Edwin Buck
    yesterday






  • 3




    Yes, this is the way to do it. I like to ask something along the lines: "what did you like the most & the least in that particular job and why?" When the candidate replies "I hated/loved maintaining legacy applications because I have to work with code that is not mine", you take a hint.
    – Eleshar
    yesterday



















43














In my experience, the attitude of engineers is not usually the reason legacy code doesn't see improvement. If you are able to foster an environment where maintenance, refactoring, and improvement of existing code is valued and encouraged then you will get the results you are looking for.



Typically I see pressure from the business to deliver features, or criticism from management (Roger spent all this time in codebase X and there's no functional difference! Why did we spend all this time/money?).



Most engineers I've worked with hate to be stymied by legacy infrastructure and will happily refactor or replace it given the right environment. Try the following steps:




  • Encourage refactoring as you go

  • Regularly discuss the value of maintenance

  • Acknowledge the success of maintenance projects, both to engineers and management


  • fight for your team's maintenance time, even if you have to bake it into estimates for new features


Once you've created an environment that values continual improvement, you can list that as a perk in the job description. "Our company values testing, refactoring, CI/CD, and continual improvement. We don't let code rot, and we won't let you rot either."






share|improve this answer

















  • 5




    This answer IMO is important because it flips the assumptions. The question and current top two answers all assume that no one does code maintenance is the fault of the coder... But I agree with @BinaryTox1n writes... That assumption isn't always true... Most good coders would happily replace/refactor old important ugly code... But if there no support/reward from their boss and/or co-workers and/or most important management... Then doing the right thing and improving old code can become near very very hard.
    – syn1kk
    yesterday






  • 2




    @syn1kk absolutely. I have finally convinced management that all the shiny new features they want will take 10x longer to develop because of the legacy infrastructure we have. Now I’m happy because I get to be the one to replace that legacy crap with something that will simultaneously benefit the company and my ability to tolerate the code base.
    – Chris Cirefice
    21 hours ago






  • 3




    IMO this is the only real answer to the question. 95% of the developers I know would love to have some time to improve the codebase they are working with/on. Management does not approve in the majority of cases. To fix that issue, you don't need to change the recruitment process. You need to make management understand that technical debt, just as monetary debt, will come back to bite you VERY hard unless you pay it off
    – marstato
    17 hours ago





















36














So, I'd say a few things will help you with this:




  • Be willing to employ more experienced (and thus more expensive) developers, as these will often have got over the 'ooh shiny new tech' stage of their careers

  • Create a package of benefits aimed more at this group (think more pensions, remunerations, working atmosphere, and less table tennis, fussball, and X-boxes)

  • Given that you want to get people to do a fair bit of work on legacy code, improvements, business-as-usual, etc., try to introduce opportunities to do a bit of more cutting edge work for a small portion of the time. Allowing people to spend time on personal projects is a good way to do this. Remember that if you need your devs to use current or older tech, they will fall behind with tech that will advance their careers in their next job - so let them keep up too.


Having a - no offence - duller project you need devs for, is one of the bigger challenges in IT recruitment, because you can't highlight all the buzzwords you need to, so most of the way you can get good staff is by having other things to appeal to them.






share|improve this answer

















  • 28




    Another point to add, start rewarding those who maintain and improve code. Often this is seen as second-tier work, when in reality is is harder to write code that is both better than the original, and seamlessly integrates into the messy stuff. If you show off your new tech internally in the company, and barely mention major rework, you will get what you reward.
    – Edwin Buck
    yesterday






  • 1




    I agree with all of this with two additional comments (that I don't feel are worthy of another answer for a question that already has 7 answers). 1) Experienced consultants are good for this kind of thing as they can get paid ($$$) and then move on. 2) In your interviews ask how the candidate would handle fixing software that was in production where it is absolutely essential that the software run 24/7 with no downtime due to regressions (and without CI/CD!) - possibly due to the $$$ loss involved with such downtime. (I recently finished a 2yr consulting contract with this constraint ...)
    – davidbak
    yesterday





















10














I think the other answers are good but I would add extra emphasize that a good job description/advert will allow people to self screen. You should then be able to use your interview questions to judge who has actually read it properly and clearly understands it.






share|improve this answer








New contributor




Dustybin80 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.














  • 2




    Indeed, I would screen out the offer myself if it was honestly presented that they have old codebase and they don't want it thrown out and rewritten.
    – Džuris
    yesterday



















5














I think you are approaching this from the wrong perspective. It's not a problem of recruiting, it's a problem of leadership. Virtually every programming job is a mix of writing new and maintaining older code.



How they are led and motivated will be the key to getting the vast majority of developers to perform well.



Does their manager communicate the companies priorities clearly to them? Most devs are motivated and happy do whatever is most important to the companies success.



Do you makes sure they are rewarded for their contributions and made to feel the company cares about them and their efforts?



Do the company priorities make sense? Jerking devs around from one project to another, or burying them in endless bug fixing work over trivial problems is a great way to dis-motivate your devs. Does your organization regularly make schedules and problems "urgent" and require devs to constantly work over-time to solve them?



Does their manager and the company foster a team oriented atmosphere? When it's crunch time do their manager and upper execs there to help out, or do they just expect the lower ranking devs to work "death marches" to solve whatever their "urgent" problem of the day is?



Your job as a recruiter is to communicate reasonable expectations of the work environment. If it's mostly maintenance work, your applicants will filter themselves out nicely if they don't want to do it.






share|improve this answer





















  • +1 from the office chasing a Jan 1st deadline for an extra paycheck's bonus.
    – Bardicer
    16 hours ago





















1














In my interviews, sure, I ask technical questions, especially to figure out unclear bits of the CV, or to dig deep into topics they say they're experts in.



Aside from that, I spend as much time as possible to simply talk with them about our field. I'm open and honest about what the goal of the current discussion is (i.e., in an early phone call, I would say "this call is just so we can get to learn to know each other, this is not a test" etc.; or in an on-site interview I might say "part of this interview is to find out the exact team in my company where you can start working, matching your interests as well as possible", and I mean it).



This is not made to let them lower their guard, or trick them, but just to get an honest discussion going. Frankly, this gives me the most useful information about the person. And as part of it, if I know that I need someone to work on older software (which, in fact, I sometimes do), then I will describe plainly and clearly what I need. I usually can tell from their reaction whether they like that kind of work, even if they don't but still say "yes".




What questions or polite (not overly time consuming) tests would you ask to find someone who is interested and willing to maintain and improve code?




My question would be: "Are you interested and willing to maintain and improve code?" Plain and simple. Honest and direct. Everything else would waste their and my time. If their reaction shows me that the answer is "no", I go on from there. If it's "yes", I'll do the usual (dig deeper, let them explain their understanding of this, etc.).



Their reaction goes into my overall evaluation afterwards. I.e., if they don't want the maintain work, but have plenty of other skills that we need, and if I'm sure that the current team structure can handle someone like that, then all is well. Or if they do want this, but somehow could not convince me that they really meant (or understood) it, and did not bring much else to the table, then we'll part ways.






share|improve this answer































    1














    I am going to add one new dimension to the answers already given. In a nutshell my advice on this question is: Look seriously at older workers for this particular role.



    The IT industry has long been affected by the issue of ageism, preferring the fast young minds of youth over the slightly slower minds of older workers. That said, those slightly slower minds have a wealth of experience and discipline that many younger workers often lack, and maintenance coding requires just such discipline.



    Hiring new coders seldom requires much experience because you will be teaching them all the idiosyncrasies of your company's codebase and work methods. A "kid" fresh out of college might know the latest and greatest ways to (as you put it) chase the new and shiney but you cannot teach the instinct for finding bugs or the mindset required for plodding through miles of unfamiliar code. Experience is what provides those attributes and experience requires time thus years thus age.



    Take 2 minutes and click the following two Google queries. Then for each of these two queries skim the content of any 3 hits (6 articles total):




    • Query #1 : myths about hiring older workers

    • Query #2 : myths about hiring older programmers


    Also we all know that once a programmer has mastered one particular language they seldom have trouble learning new ones. Look to see if their work history shows they adapt well to new environments. Look at how many languages these older workers have, not if they know the cutting edge ones or even possibly the exact one you need. If their experience is close they will learn and thrive on that learning. You are hiring them for legacy work, exactly the opposite of cutting edge.



    So do your due diligence. Never use age alone as a reason to hire or not hire, but in a case like this consider that age and experience are real assets and any preconceptions you may have about hiring someone perhaps age 50 or more should be carefully examined because you might just be missing out on exactly the skills and attitudes you asked about in your OP.



    Oh and one last thing. Do not be surprised if you get some evasive push-back from your HR department. For complicated (but erroneous) reasons based in those aforementioned myths, HR departments are often prone to try and filter out older applicants in IT departments. So be aware that you may need to educate your own manager and HR department that you reject these myths, provide them some of the studies you will easily find online from those links above, and insist that they are not to reject the so called "over qualified" job seekers but rather to send them through to the interviews.






    share|improve this answer





















    • I really love this answer! Experience and maturity can count for so much, it's odd that people so willingly overlook it. That said, there's also the chance of the newbies being taught well if they're very inexperienced, I suppose. 😄
      – yochannah
      2 hours ago



















    0














    In my opinion it is not the point how people feel about refactoring vs recreating code. The question is why or when, a question of reasons for a decision in particular cases. I want to explain why:



    Writing new code including a setup of a new concept is often experienced as a thankless job since the economy usually puts pressure on developers to work efficient in the purpose of generating volume of sales in shortest time.



    Not infrequently I got an interesting project to be extended. After several hours of code review I was horrified about the misconcepted code base. It was not really concepted in an extensible way and had several security vulnerabilities. Building additional code dependent on that base had lead into a hardly predictable behaviour.



    I experienced many situations when I had to suggest to do a complete rework based on a new concept while including existing algorithms of the old project. And that did not cause much enthusiasm on my mind facing a huge task.



    My conviction is that most developers love to do an easy job based on a well structured framework - so far it exists. I do. Why to rack one's brain when there is a much more comfortable way to do it?



    Thus when looking for new team members we should ask candidates for scenarios in which they would prefer to rewrite an existing code base prior to refactoring/extending and for detailed explainations for their reasons. We want to know if the candidate is able to take reliable decisions conforming with our company policy.






    share|improve this answer










    New contributor




    Quasimodo's clone is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.


















      Your Answer








      StackExchange.ready(function() {
      var channelOptions = {
      tags: "".split(" "),
      id: "423"
      };
      initTagRenderer("".split(" "), "".split(" "), channelOptions);

      StackExchange.using("externalEditor", function() {
      // Have to fire editor after snippets, if snippets enabled
      if (StackExchange.settings.snippets.snippetsEnabled) {
      StackExchange.using("snippets", function() {
      createEditor();
      });
      }
      else {
      createEditor();
      }
      });

      function createEditor() {
      StackExchange.prepareEditor({
      heartbeatType: 'answer',
      autoActivateHeartbeat: false,
      convertImagesToLinks: false,
      noModals: true,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: null,
      bindNavPrevention: true,
      postfix: "",
      imageUploader: {
      brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
      contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
      allowUrls: true
      },
      noCode: true, onDemand: false,
      discardSelector: ".discard-answer"
      ,immediatelyShowMarkdownHelp:true
      });


      }
      });














      draft saved

      draft discarded


















      StackExchange.ready(
      function () {
      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f125255%2frecruiting-people-who-maintain-improve-not-just-chase-the-new-and-shiny%23new-answer', 'question_page');
      }
      );

      Post as a guest















      Required, but never shown




















      StackExchange.ready(function () {
      $("#show-editor-button input, #show-editor-button button").click(function () {
      var showEditor = function() {
      $("#show-editor-button").hide();
      $("#post-form").removeClass("dno");
      StackExchange.editor.finallyInit();
      };

      var useFancy = $(this).data('confirm-use-fancy');
      if(useFancy == 'True') {
      var popupTitle = $(this).data('confirm-fancy-title');
      var popupBody = $(this).data('confirm-fancy-body');
      var popupAccept = $(this).data('confirm-fancy-accept-button');

      $(this).loadPopup({
      url: '/post/self-answer-popup',
      loaded: function(popup) {
      var pTitle = $(popup).find('h2');
      var pBody = $(popup).find('.popup-body');
      var pSubmit = $(popup).find('.popup-submit');

      pTitle.text(popupTitle);
      pBody.html(popupBody);
      pSubmit.val(popupAccept).click(showEditor);
      }
      })
      } else{
      var confirmText = $(this).data('confirm-text');
      if (confirmText ? confirm(confirmText) : true) {
      showEditor();
      }
      }
      });
      });






      8 Answers
      8






      active

      oldest

      votes








      8 Answers
      8






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes









      74















      What questions or polite (not overly time consuming) tests would you
      ask to find someone who is interested and willing to maintain and
      improve code?




      In general, I find that the key is to ask more open-ended questions, rather than question which can be answered with a simple Yes or No, or a very short answer.



      Something more along the lines of "Tell me about the kind of work you enjoy doing" would give you better clues. If it's all about creation/invention and nothing at all about improvement/testing/refinement, then the candidate might not be happy filling the role you have.



      Once past that question, you can dig in with something like "Tell me about a time when you had to dig in and maintain some difficult code."



      At some point in the interview process, you want to make the details of the role clear. And you want to be clear how long that role would last and what it might lead to. It would be silly to set the wrong expectations for a new hire.



      As others have pointed out, a good job description will help attract the right kind of candidate and let others self-select themselves out. A job description which incorporates the thoughts in "people who recognise that good code is about more than lines of code written per day, and that design, documentation and testing are also part of being a coder" could help.






      share|improve this answer



















      • 5




        This is a great answer, I started to write my own but eventually realised I was just rewording this one.
        – davnicwil
        yesterday






      • 1




        @XavierStuvw - I don't think I understand "Which ones could they be?" means here.
        – Joe Strazzere
        yesterday






      • 1




        @davnicwil It is a good approach, but beware. If the answer was, "I ripped it all out and rewrote it" you might not actually have a person doing maintenance in a safe way. You might have a person doing greenfield work on an existing project. There are times where a module should just be rewritten from scratch, but they are rare, and typically are rewritten to satisfy full unit testing suites.
        – Edwin Buck
        yesterday






      • 2




        @JoeStrazzere Fantastic! I just saw the prompt to ask the question, but I didn't notice any hints on how to evaluate the answers. Many people need that latter part, even if this OP and you are not in that set of people :)
        – Edwin Buck
        yesterday






      • 3




        Yes, this is the way to do it. I like to ask something along the lines: "what did you like the most & the least in that particular job and why?" When the candidate replies "I hated/loved maintaining legacy applications because I have to work with code that is not mine", you take a hint.
        – Eleshar
        yesterday
















      74















      What questions or polite (not overly time consuming) tests would you
      ask to find someone who is interested and willing to maintain and
      improve code?




      In general, I find that the key is to ask more open-ended questions, rather than question which can be answered with a simple Yes or No, or a very short answer.



      Something more along the lines of "Tell me about the kind of work you enjoy doing" would give you better clues. If it's all about creation/invention and nothing at all about improvement/testing/refinement, then the candidate might not be happy filling the role you have.



      Once past that question, you can dig in with something like "Tell me about a time when you had to dig in and maintain some difficult code."



      At some point in the interview process, you want to make the details of the role clear. And you want to be clear how long that role would last and what it might lead to. It would be silly to set the wrong expectations for a new hire.



      As others have pointed out, a good job description will help attract the right kind of candidate and let others self-select themselves out. A job description which incorporates the thoughts in "people who recognise that good code is about more than lines of code written per day, and that design, documentation and testing are also part of being a coder" could help.






      share|improve this answer



















      • 5




        This is a great answer, I started to write my own but eventually realised I was just rewording this one.
        – davnicwil
        yesterday






      • 1




        @XavierStuvw - I don't think I understand "Which ones could they be?" means here.
        – Joe Strazzere
        yesterday






      • 1




        @davnicwil It is a good approach, but beware. If the answer was, "I ripped it all out and rewrote it" you might not actually have a person doing maintenance in a safe way. You might have a person doing greenfield work on an existing project. There are times where a module should just be rewritten from scratch, but they are rare, and typically are rewritten to satisfy full unit testing suites.
        – Edwin Buck
        yesterday






      • 2




        @JoeStrazzere Fantastic! I just saw the prompt to ask the question, but I didn't notice any hints on how to evaluate the answers. Many people need that latter part, even if this OP and you are not in that set of people :)
        – Edwin Buck
        yesterday






      • 3




        Yes, this is the way to do it. I like to ask something along the lines: "what did you like the most & the least in that particular job and why?" When the candidate replies "I hated/loved maintaining legacy applications because I have to work with code that is not mine", you take a hint.
        – Eleshar
        yesterday














      74












      74








      74







      What questions or polite (not overly time consuming) tests would you
      ask to find someone who is interested and willing to maintain and
      improve code?




      In general, I find that the key is to ask more open-ended questions, rather than question which can be answered with a simple Yes or No, or a very short answer.



      Something more along the lines of "Tell me about the kind of work you enjoy doing" would give you better clues. If it's all about creation/invention and nothing at all about improvement/testing/refinement, then the candidate might not be happy filling the role you have.



      Once past that question, you can dig in with something like "Tell me about a time when you had to dig in and maintain some difficult code."



      At some point in the interview process, you want to make the details of the role clear. And you want to be clear how long that role would last and what it might lead to. It would be silly to set the wrong expectations for a new hire.



      As others have pointed out, a good job description will help attract the right kind of candidate and let others self-select themselves out. A job description which incorporates the thoughts in "people who recognise that good code is about more than lines of code written per day, and that design, documentation and testing are also part of being a coder" could help.






      share|improve this answer















      What questions or polite (not overly time consuming) tests would you
      ask to find someone who is interested and willing to maintain and
      improve code?




      In general, I find that the key is to ask more open-ended questions, rather than question which can be answered with a simple Yes or No, or a very short answer.



      Something more along the lines of "Tell me about the kind of work you enjoy doing" would give you better clues. If it's all about creation/invention and nothing at all about improvement/testing/refinement, then the candidate might not be happy filling the role you have.



      Once past that question, you can dig in with something like "Tell me about a time when you had to dig in and maintain some difficult code."



      At some point in the interview process, you want to make the details of the role clear. And you want to be clear how long that role would last and what it might lead to. It would be silly to set the wrong expectations for a new hire.



      As others have pointed out, a good job description will help attract the right kind of candidate and let others self-select themselves out. A job description which incorporates the thoughts in "people who recognise that good code is about more than lines of code written per day, and that design, documentation and testing are also part of being a coder" could help.







      share|improve this answer














      share|improve this answer



      share|improve this answer








      edited yesterday

























      answered 2 days ago









      Joe Strazzere

      242k1177071003




      242k1177071003








      • 5




        This is a great answer, I started to write my own but eventually realised I was just rewording this one.
        – davnicwil
        yesterday






      • 1




        @XavierStuvw - I don't think I understand "Which ones could they be?" means here.
        – Joe Strazzere
        yesterday






      • 1




        @davnicwil It is a good approach, but beware. If the answer was, "I ripped it all out and rewrote it" you might not actually have a person doing maintenance in a safe way. You might have a person doing greenfield work on an existing project. There are times where a module should just be rewritten from scratch, but they are rare, and typically are rewritten to satisfy full unit testing suites.
        – Edwin Buck
        yesterday






      • 2




        @JoeStrazzere Fantastic! I just saw the prompt to ask the question, but I didn't notice any hints on how to evaluate the answers. Many people need that latter part, even if this OP and you are not in that set of people :)
        – Edwin Buck
        yesterday






      • 3




        Yes, this is the way to do it. I like to ask something along the lines: "what did you like the most & the least in that particular job and why?" When the candidate replies "I hated/loved maintaining legacy applications because I have to work with code that is not mine", you take a hint.
        – Eleshar
        yesterday














      • 5




        This is a great answer, I started to write my own but eventually realised I was just rewording this one.
        – davnicwil
        yesterday






      • 1




        @XavierStuvw - I don't think I understand "Which ones could they be?" means here.
        – Joe Strazzere
        yesterday






      • 1




        @davnicwil It is a good approach, but beware. If the answer was, "I ripped it all out and rewrote it" you might not actually have a person doing maintenance in a safe way. You might have a person doing greenfield work on an existing project. There are times where a module should just be rewritten from scratch, but they are rare, and typically are rewritten to satisfy full unit testing suites.
        – Edwin Buck
        yesterday






      • 2




        @JoeStrazzere Fantastic! I just saw the prompt to ask the question, but I didn't notice any hints on how to evaluate the answers. Many people need that latter part, even if this OP and you are not in that set of people :)
        – Edwin Buck
        yesterday






      • 3




        Yes, this is the way to do it. I like to ask something along the lines: "what did you like the most & the least in that particular job and why?" When the candidate replies "I hated/loved maintaining legacy applications because I have to work with code that is not mine", you take a hint.
        – Eleshar
        yesterday








      5




      5




      This is a great answer, I started to write my own but eventually realised I was just rewording this one.
      – davnicwil
      yesterday




      This is a great answer, I started to write my own but eventually realised I was just rewording this one.
      – davnicwil
      yesterday




      1




      1




      @XavierStuvw - I don't think I understand "Which ones could they be?" means here.
      – Joe Strazzere
      yesterday




      @XavierStuvw - I don't think I understand "Which ones could they be?" means here.
      – Joe Strazzere
      yesterday




      1




      1




      @davnicwil It is a good approach, but beware. If the answer was, "I ripped it all out and rewrote it" you might not actually have a person doing maintenance in a safe way. You might have a person doing greenfield work on an existing project. There are times where a module should just be rewritten from scratch, but they are rare, and typically are rewritten to satisfy full unit testing suites.
      – Edwin Buck
      yesterday




      @davnicwil It is a good approach, but beware. If the answer was, "I ripped it all out and rewrote it" you might not actually have a person doing maintenance in a safe way. You might have a person doing greenfield work on an existing project. There are times where a module should just be rewritten from scratch, but they are rare, and typically are rewritten to satisfy full unit testing suites.
      – Edwin Buck
      yesterday




      2




      2




      @JoeStrazzere Fantastic! I just saw the prompt to ask the question, but I didn't notice any hints on how to evaluate the answers. Many people need that latter part, even if this OP and you are not in that set of people :)
      – Edwin Buck
      yesterday




      @JoeStrazzere Fantastic! I just saw the prompt to ask the question, but I didn't notice any hints on how to evaluate the answers. Many people need that latter part, even if this OP and you are not in that set of people :)
      – Edwin Buck
      yesterday




      3




      3




      Yes, this is the way to do it. I like to ask something along the lines: "what did you like the most & the least in that particular job and why?" When the candidate replies "I hated/loved maintaining legacy applications because I have to work with code that is not mine", you take a hint.
      – Eleshar
      yesterday




      Yes, this is the way to do it. I like to ask something along the lines: "what did you like the most & the least in that particular job and why?" When the candidate replies "I hated/loved maintaining legacy applications because I have to work with code that is not mine", you take a hint.
      – Eleshar
      yesterday













      43














      In my experience, the attitude of engineers is not usually the reason legacy code doesn't see improvement. If you are able to foster an environment where maintenance, refactoring, and improvement of existing code is valued and encouraged then you will get the results you are looking for.



      Typically I see pressure from the business to deliver features, or criticism from management (Roger spent all this time in codebase X and there's no functional difference! Why did we spend all this time/money?).



      Most engineers I've worked with hate to be stymied by legacy infrastructure and will happily refactor or replace it given the right environment. Try the following steps:




      • Encourage refactoring as you go

      • Regularly discuss the value of maintenance

      • Acknowledge the success of maintenance projects, both to engineers and management


      • fight for your team's maintenance time, even if you have to bake it into estimates for new features


      Once you've created an environment that values continual improvement, you can list that as a perk in the job description. "Our company values testing, refactoring, CI/CD, and continual improvement. We don't let code rot, and we won't let you rot either."






      share|improve this answer

















      • 5




        This answer IMO is important because it flips the assumptions. The question and current top two answers all assume that no one does code maintenance is the fault of the coder... But I agree with @BinaryTox1n writes... That assumption isn't always true... Most good coders would happily replace/refactor old important ugly code... But if there no support/reward from their boss and/or co-workers and/or most important management... Then doing the right thing and improving old code can become near very very hard.
        – syn1kk
        yesterday






      • 2




        @syn1kk absolutely. I have finally convinced management that all the shiny new features they want will take 10x longer to develop because of the legacy infrastructure we have. Now I’m happy because I get to be the one to replace that legacy crap with something that will simultaneously benefit the company and my ability to tolerate the code base.
        – Chris Cirefice
        21 hours ago






      • 3




        IMO this is the only real answer to the question. 95% of the developers I know would love to have some time to improve the codebase they are working with/on. Management does not approve in the majority of cases. To fix that issue, you don't need to change the recruitment process. You need to make management understand that technical debt, just as monetary debt, will come back to bite you VERY hard unless you pay it off
        – marstato
        17 hours ago


















      43














      In my experience, the attitude of engineers is not usually the reason legacy code doesn't see improvement. If you are able to foster an environment where maintenance, refactoring, and improvement of existing code is valued and encouraged then you will get the results you are looking for.



      Typically I see pressure from the business to deliver features, or criticism from management (Roger spent all this time in codebase X and there's no functional difference! Why did we spend all this time/money?).



      Most engineers I've worked with hate to be stymied by legacy infrastructure and will happily refactor or replace it given the right environment. Try the following steps:




      • Encourage refactoring as you go

      • Regularly discuss the value of maintenance

      • Acknowledge the success of maintenance projects, both to engineers and management


      • fight for your team's maintenance time, even if you have to bake it into estimates for new features


      Once you've created an environment that values continual improvement, you can list that as a perk in the job description. "Our company values testing, refactoring, CI/CD, and continual improvement. We don't let code rot, and we won't let you rot either."






      share|improve this answer

















      • 5




        This answer IMO is important because it flips the assumptions. The question and current top two answers all assume that no one does code maintenance is the fault of the coder... But I agree with @BinaryTox1n writes... That assumption isn't always true... Most good coders would happily replace/refactor old important ugly code... But if there no support/reward from their boss and/or co-workers and/or most important management... Then doing the right thing and improving old code can become near very very hard.
        – syn1kk
        yesterday






      • 2




        @syn1kk absolutely. I have finally convinced management that all the shiny new features they want will take 10x longer to develop because of the legacy infrastructure we have. Now I’m happy because I get to be the one to replace that legacy crap with something that will simultaneously benefit the company and my ability to tolerate the code base.
        – Chris Cirefice
        21 hours ago






      • 3




        IMO this is the only real answer to the question. 95% of the developers I know would love to have some time to improve the codebase they are working with/on. Management does not approve in the majority of cases. To fix that issue, you don't need to change the recruitment process. You need to make management understand that technical debt, just as monetary debt, will come back to bite you VERY hard unless you pay it off
        – marstato
        17 hours ago
















      43












      43








      43






      In my experience, the attitude of engineers is not usually the reason legacy code doesn't see improvement. If you are able to foster an environment where maintenance, refactoring, and improvement of existing code is valued and encouraged then you will get the results you are looking for.



      Typically I see pressure from the business to deliver features, or criticism from management (Roger spent all this time in codebase X and there's no functional difference! Why did we spend all this time/money?).



      Most engineers I've worked with hate to be stymied by legacy infrastructure and will happily refactor or replace it given the right environment. Try the following steps:




      • Encourage refactoring as you go

      • Regularly discuss the value of maintenance

      • Acknowledge the success of maintenance projects, both to engineers and management


      • fight for your team's maintenance time, even if you have to bake it into estimates for new features


      Once you've created an environment that values continual improvement, you can list that as a perk in the job description. "Our company values testing, refactoring, CI/CD, and continual improvement. We don't let code rot, and we won't let you rot either."






      share|improve this answer












      In my experience, the attitude of engineers is not usually the reason legacy code doesn't see improvement. If you are able to foster an environment where maintenance, refactoring, and improvement of existing code is valued and encouraged then you will get the results you are looking for.



      Typically I see pressure from the business to deliver features, or criticism from management (Roger spent all this time in codebase X and there's no functional difference! Why did we spend all this time/money?).



      Most engineers I've worked with hate to be stymied by legacy infrastructure and will happily refactor or replace it given the right environment. Try the following steps:




      • Encourage refactoring as you go

      • Regularly discuss the value of maintenance

      • Acknowledge the success of maintenance projects, both to engineers and management


      • fight for your team's maintenance time, even if you have to bake it into estimates for new features


      Once you've created an environment that values continual improvement, you can list that as a perk in the job description. "Our company values testing, refactoring, CI/CD, and continual improvement. We don't let code rot, and we won't let you rot either."







      share|improve this answer












      share|improve this answer



      share|improve this answer










      answered yesterday









      BinaryTox1n

      57238




      57238








      • 5




        This answer IMO is important because it flips the assumptions. The question and current top two answers all assume that no one does code maintenance is the fault of the coder... But I agree with @BinaryTox1n writes... That assumption isn't always true... Most good coders would happily replace/refactor old important ugly code... But if there no support/reward from their boss and/or co-workers and/or most important management... Then doing the right thing and improving old code can become near very very hard.
        – syn1kk
        yesterday






      • 2




        @syn1kk absolutely. I have finally convinced management that all the shiny new features they want will take 10x longer to develop because of the legacy infrastructure we have. Now I’m happy because I get to be the one to replace that legacy crap with something that will simultaneously benefit the company and my ability to tolerate the code base.
        – Chris Cirefice
        21 hours ago






      • 3




        IMO this is the only real answer to the question. 95% of the developers I know would love to have some time to improve the codebase they are working with/on. Management does not approve in the majority of cases. To fix that issue, you don't need to change the recruitment process. You need to make management understand that technical debt, just as monetary debt, will come back to bite you VERY hard unless you pay it off
        – marstato
        17 hours ago
















      • 5




        This answer IMO is important because it flips the assumptions. The question and current top two answers all assume that no one does code maintenance is the fault of the coder... But I agree with @BinaryTox1n writes... That assumption isn't always true... Most good coders would happily replace/refactor old important ugly code... But if there no support/reward from their boss and/or co-workers and/or most important management... Then doing the right thing and improving old code can become near very very hard.
        – syn1kk
        yesterday






      • 2




        @syn1kk absolutely. I have finally convinced management that all the shiny new features they want will take 10x longer to develop because of the legacy infrastructure we have. Now I’m happy because I get to be the one to replace that legacy crap with something that will simultaneously benefit the company and my ability to tolerate the code base.
        – Chris Cirefice
        21 hours ago






      • 3




        IMO this is the only real answer to the question. 95% of the developers I know would love to have some time to improve the codebase they are working with/on. Management does not approve in the majority of cases. To fix that issue, you don't need to change the recruitment process. You need to make management understand that technical debt, just as monetary debt, will come back to bite you VERY hard unless you pay it off
        – marstato
        17 hours ago










      5




      5




      This answer IMO is important because it flips the assumptions. The question and current top two answers all assume that no one does code maintenance is the fault of the coder... But I agree with @BinaryTox1n writes... That assumption isn't always true... Most good coders would happily replace/refactor old important ugly code... But if there no support/reward from their boss and/or co-workers and/or most important management... Then doing the right thing and improving old code can become near very very hard.
      – syn1kk
      yesterday




      This answer IMO is important because it flips the assumptions. The question and current top two answers all assume that no one does code maintenance is the fault of the coder... But I agree with @BinaryTox1n writes... That assumption isn't always true... Most good coders would happily replace/refactor old important ugly code... But if there no support/reward from their boss and/or co-workers and/or most important management... Then doing the right thing and improving old code can become near very very hard.
      – syn1kk
      yesterday




      2




      2




      @syn1kk absolutely. I have finally convinced management that all the shiny new features they want will take 10x longer to develop because of the legacy infrastructure we have. Now I’m happy because I get to be the one to replace that legacy crap with something that will simultaneously benefit the company and my ability to tolerate the code base.
      – Chris Cirefice
      21 hours ago




      @syn1kk absolutely. I have finally convinced management that all the shiny new features they want will take 10x longer to develop because of the legacy infrastructure we have. Now I’m happy because I get to be the one to replace that legacy crap with something that will simultaneously benefit the company and my ability to tolerate the code base.
      – Chris Cirefice
      21 hours ago




      3




      3




      IMO this is the only real answer to the question. 95% of the developers I know would love to have some time to improve the codebase they are working with/on. Management does not approve in the majority of cases. To fix that issue, you don't need to change the recruitment process. You need to make management understand that technical debt, just as monetary debt, will come back to bite you VERY hard unless you pay it off
      – marstato
      17 hours ago






      IMO this is the only real answer to the question. 95% of the developers I know would love to have some time to improve the codebase they are working with/on. Management does not approve in the majority of cases. To fix that issue, you don't need to change the recruitment process. You need to make management understand that technical debt, just as monetary debt, will come back to bite you VERY hard unless you pay it off
      – marstato
      17 hours ago













      36














      So, I'd say a few things will help you with this:




      • Be willing to employ more experienced (and thus more expensive) developers, as these will often have got over the 'ooh shiny new tech' stage of their careers

      • Create a package of benefits aimed more at this group (think more pensions, remunerations, working atmosphere, and less table tennis, fussball, and X-boxes)

      • Given that you want to get people to do a fair bit of work on legacy code, improvements, business-as-usual, etc., try to introduce opportunities to do a bit of more cutting edge work for a small portion of the time. Allowing people to spend time on personal projects is a good way to do this. Remember that if you need your devs to use current or older tech, they will fall behind with tech that will advance their careers in their next job - so let them keep up too.


      Having a - no offence - duller project you need devs for, is one of the bigger challenges in IT recruitment, because you can't highlight all the buzzwords you need to, so most of the way you can get good staff is by having other things to appeal to them.






      share|improve this answer

















      • 28




        Another point to add, start rewarding those who maintain and improve code. Often this is seen as second-tier work, when in reality is is harder to write code that is both better than the original, and seamlessly integrates into the messy stuff. If you show off your new tech internally in the company, and barely mention major rework, you will get what you reward.
        – Edwin Buck
        yesterday






      • 1




        I agree with all of this with two additional comments (that I don't feel are worthy of another answer for a question that already has 7 answers). 1) Experienced consultants are good for this kind of thing as they can get paid ($$$) and then move on. 2) In your interviews ask how the candidate would handle fixing software that was in production where it is absolutely essential that the software run 24/7 with no downtime due to regressions (and without CI/CD!) - possibly due to the $$$ loss involved with such downtime. (I recently finished a 2yr consulting contract with this constraint ...)
        – davidbak
        yesterday


















      36














      So, I'd say a few things will help you with this:




      • Be willing to employ more experienced (and thus more expensive) developers, as these will often have got over the 'ooh shiny new tech' stage of their careers

      • Create a package of benefits aimed more at this group (think more pensions, remunerations, working atmosphere, and less table tennis, fussball, and X-boxes)

      • Given that you want to get people to do a fair bit of work on legacy code, improvements, business-as-usual, etc., try to introduce opportunities to do a bit of more cutting edge work for a small portion of the time. Allowing people to spend time on personal projects is a good way to do this. Remember that if you need your devs to use current or older tech, they will fall behind with tech that will advance their careers in their next job - so let them keep up too.


      Having a - no offence - duller project you need devs for, is one of the bigger challenges in IT recruitment, because you can't highlight all the buzzwords you need to, so most of the way you can get good staff is by having other things to appeal to them.






      share|improve this answer

















      • 28




        Another point to add, start rewarding those who maintain and improve code. Often this is seen as second-tier work, when in reality is is harder to write code that is both better than the original, and seamlessly integrates into the messy stuff. If you show off your new tech internally in the company, and barely mention major rework, you will get what you reward.
        – Edwin Buck
        yesterday






      • 1




        I agree with all of this with two additional comments (that I don't feel are worthy of another answer for a question that already has 7 answers). 1) Experienced consultants are good for this kind of thing as they can get paid ($$$) and then move on. 2) In your interviews ask how the candidate would handle fixing software that was in production where it is absolutely essential that the software run 24/7 with no downtime due to regressions (and without CI/CD!) - possibly due to the $$$ loss involved with such downtime. (I recently finished a 2yr consulting contract with this constraint ...)
        – davidbak
        yesterday
















      36












      36








      36






      So, I'd say a few things will help you with this:




      • Be willing to employ more experienced (and thus more expensive) developers, as these will often have got over the 'ooh shiny new tech' stage of their careers

      • Create a package of benefits aimed more at this group (think more pensions, remunerations, working atmosphere, and less table tennis, fussball, and X-boxes)

      • Given that you want to get people to do a fair bit of work on legacy code, improvements, business-as-usual, etc., try to introduce opportunities to do a bit of more cutting edge work for a small portion of the time. Allowing people to spend time on personal projects is a good way to do this. Remember that if you need your devs to use current or older tech, they will fall behind with tech that will advance their careers in their next job - so let them keep up too.


      Having a - no offence - duller project you need devs for, is one of the bigger challenges in IT recruitment, because you can't highlight all the buzzwords you need to, so most of the way you can get good staff is by having other things to appeal to them.






      share|improve this answer












      So, I'd say a few things will help you with this:




      • Be willing to employ more experienced (and thus more expensive) developers, as these will often have got over the 'ooh shiny new tech' stage of their careers

      • Create a package of benefits aimed more at this group (think more pensions, remunerations, working atmosphere, and less table tennis, fussball, and X-boxes)

      • Given that you want to get people to do a fair bit of work on legacy code, improvements, business-as-usual, etc., try to introduce opportunities to do a bit of more cutting edge work for a small portion of the time. Allowing people to spend time on personal projects is a good way to do this. Remember that if you need your devs to use current or older tech, they will fall behind with tech that will advance their careers in their next job - so let them keep up too.


      Having a - no offence - duller project you need devs for, is one of the bigger challenges in IT recruitment, because you can't highlight all the buzzwords you need to, so most of the way you can get good staff is by having other things to appeal to them.







      share|improve this answer












      share|improve this answer



      share|improve this answer










      answered 2 days ago









      Owen C. Jones

      806913




      806913








      • 28




        Another point to add, start rewarding those who maintain and improve code. Often this is seen as second-tier work, when in reality is is harder to write code that is both better than the original, and seamlessly integrates into the messy stuff. If you show off your new tech internally in the company, and barely mention major rework, you will get what you reward.
        – Edwin Buck
        yesterday






      • 1




        I agree with all of this with two additional comments (that I don't feel are worthy of another answer for a question that already has 7 answers). 1) Experienced consultants are good for this kind of thing as they can get paid ($$$) and then move on. 2) In your interviews ask how the candidate would handle fixing software that was in production where it is absolutely essential that the software run 24/7 with no downtime due to regressions (and without CI/CD!) - possibly due to the $$$ loss involved with such downtime. (I recently finished a 2yr consulting contract with this constraint ...)
        – davidbak
        yesterday
















      • 28




        Another point to add, start rewarding those who maintain and improve code. Often this is seen as second-tier work, when in reality is is harder to write code that is both better than the original, and seamlessly integrates into the messy stuff. If you show off your new tech internally in the company, and barely mention major rework, you will get what you reward.
        – Edwin Buck
        yesterday






      • 1




        I agree with all of this with two additional comments (that I don't feel are worthy of another answer for a question that already has 7 answers). 1) Experienced consultants are good for this kind of thing as they can get paid ($$$) and then move on. 2) In your interviews ask how the candidate would handle fixing software that was in production where it is absolutely essential that the software run 24/7 with no downtime due to regressions (and without CI/CD!) - possibly due to the $$$ loss involved with such downtime. (I recently finished a 2yr consulting contract with this constraint ...)
        – davidbak
        yesterday










      28




      28




      Another point to add, start rewarding those who maintain and improve code. Often this is seen as second-tier work, when in reality is is harder to write code that is both better than the original, and seamlessly integrates into the messy stuff. If you show off your new tech internally in the company, and barely mention major rework, you will get what you reward.
      – Edwin Buck
      yesterday




      Another point to add, start rewarding those who maintain and improve code. Often this is seen as second-tier work, when in reality is is harder to write code that is both better than the original, and seamlessly integrates into the messy stuff. If you show off your new tech internally in the company, and barely mention major rework, you will get what you reward.
      – Edwin Buck
      yesterday




      1




      1




      I agree with all of this with two additional comments (that I don't feel are worthy of another answer for a question that already has 7 answers). 1) Experienced consultants are good for this kind of thing as they can get paid ($$$) and then move on. 2) In your interviews ask how the candidate would handle fixing software that was in production where it is absolutely essential that the software run 24/7 with no downtime due to regressions (and without CI/CD!) - possibly due to the $$$ loss involved with such downtime. (I recently finished a 2yr consulting contract with this constraint ...)
      – davidbak
      yesterday






      I agree with all of this with two additional comments (that I don't feel are worthy of another answer for a question that already has 7 answers). 1) Experienced consultants are good for this kind of thing as they can get paid ($$$) and then move on. 2) In your interviews ask how the candidate would handle fixing software that was in production where it is absolutely essential that the software run 24/7 with no downtime due to regressions (and without CI/CD!) - possibly due to the $$$ loss involved with such downtime. (I recently finished a 2yr consulting contract with this constraint ...)
      – davidbak
      yesterday













      10














      I think the other answers are good but I would add extra emphasize that a good job description/advert will allow people to self screen. You should then be able to use your interview questions to judge who has actually read it properly and clearly understands it.






      share|improve this answer








      New contributor




      Dustybin80 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.














      • 2




        Indeed, I would screen out the offer myself if it was honestly presented that they have old codebase and they don't want it thrown out and rewritten.
        – Džuris
        yesterday
















      10














      I think the other answers are good but I would add extra emphasize that a good job description/advert will allow people to self screen. You should then be able to use your interview questions to judge who has actually read it properly and clearly understands it.






      share|improve this answer








      New contributor




      Dustybin80 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.














      • 2




        Indeed, I would screen out the offer myself if it was honestly presented that they have old codebase and they don't want it thrown out and rewritten.
        – Džuris
        yesterday














      10












      10








      10






      I think the other answers are good but I would add extra emphasize that a good job description/advert will allow people to self screen. You should then be able to use your interview questions to judge who has actually read it properly and clearly understands it.






      share|improve this answer








      New contributor




      Dustybin80 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.









      I think the other answers are good but I would add extra emphasize that a good job description/advert will allow people to self screen. You should then be able to use your interview questions to judge who has actually read it properly and clearly understands it.







      share|improve this answer








      New contributor




      Dustybin80 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.









      share|improve this answer



      share|improve this answer






      New contributor




      Dustybin80 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.









      answered yesterday









      Dustybin80

      1,081115




      1,081115




      New contributor




      Dustybin80 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.





      New contributor





      Dustybin80 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.






      Dustybin80 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.








      • 2




        Indeed, I would screen out the offer myself if it was honestly presented that they have old codebase and they don't want it thrown out and rewritten.
        – Džuris
        yesterday














      • 2




        Indeed, I would screen out the offer myself if it was honestly presented that they have old codebase and they don't want it thrown out and rewritten.
        – Džuris
        yesterday








      2




      2




      Indeed, I would screen out the offer myself if it was honestly presented that they have old codebase and they don't want it thrown out and rewritten.
      – Džuris
      yesterday




      Indeed, I would screen out the offer myself if it was honestly presented that they have old codebase and they don't want it thrown out and rewritten.
      – Džuris
      yesterday











      5














      I think you are approaching this from the wrong perspective. It's not a problem of recruiting, it's a problem of leadership. Virtually every programming job is a mix of writing new and maintaining older code.



      How they are led and motivated will be the key to getting the vast majority of developers to perform well.



      Does their manager communicate the companies priorities clearly to them? Most devs are motivated and happy do whatever is most important to the companies success.



      Do you makes sure they are rewarded for their contributions and made to feel the company cares about them and their efforts?



      Do the company priorities make sense? Jerking devs around from one project to another, or burying them in endless bug fixing work over trivial problems is a great way to dis-motivate your devs. Does your organization regularly make schedules and problems "urgent" and require devs to constantly work over-time to solve them?



      Does their manager and the company foster a team oriented atmosphere? When it's crunch time do their manager and upper execs there to help out, or do they just expect the lower ranking devs to work "death marches" to solve whatever their "urgent" problem of the day is?



      Your job as a recruiter is to communicate reasonable expectations of the work environment. If it's mostly maintenance work, your applicants will filter themselves out nicely if they don't want to do it.






      share|improve this answer





















      • +1 from the office chasing a Jan 1st deadline for an extra paycheck's bonus.
        – Bardicer
        16 hours ago


















      5














      I think you are approaching this from the wrong perspective. It's not a problem of recruiting, it's a problem of leadership. Virtually every programming job is a mix of writing new and maintaining older code.



      How they are led and motivated will be the key to getting the vast majority of developers to perform well.



      Does their manager communicate the companies priorities clearly to them? Most devs are motivated and happy do whatever is most important to the companies success.



      Do you makes sure they are rewarded for their contributions and made to feel the company cares about them and their efforts?



      Do the company priorities make sense? Jerking devs around from one project to another, or burying them in endless bug fixing work over trivial problems is a great way to dis-motivate your devs. Does your organization regularly make schedules and problems "urgent" and require devs to constantly work over-time to solve them?



      Does their manager and the company foster a team oriented atmosphere? When it's crunch time do their manager and upper execs there to help out, or do they just expect the lower ranking devs to work "death marches" to solve whatever their "urgent" problem of the day is?



      Your job as a recruiter is to communicate reasonable expectations of the work environment. If it's mostly maintenance work, your applicants will filter themselves out nicely if they don't want to do it.






      share|improve this answer





















      • +1 from the office chasing a Jan 1st deadline for an extra paycheck's bonus.
        – Bardicer
        16 hours ago
















      5












      5








      5






      I think you are approaching this from the wrong perspective. It's not a problem of recruiting, it's a problem of leadership. Virtually every programming job is a mix of writing new and maintaining older code.



      How they are led and motivated will be the key to getting the vast majority of developers to perform well.



      Does their manager communicate the companies priorities clearly to them? Most devs are motivated and happy do whatever is most important to the companies success.



      Do you makes sure they are rewarded for their contributions and made to feel the company cares about them and their efforts?



      Do the company priorities make sense? Jerking devs around from one project to another, or burying them in endless bug fixing work over trivial problems is a great way to dis-motivate your devs. Does your organization regularly make schedules and problems "urgent" and require devs to constantly work over-time to solve them?



      Does their manager and the company foster a team oriented atmosphere? When it's crunch time do their manager and upper execs there to help out, or do they just expect the lower ranking devs to work "death marches" to solve whatever their "urgent" problem of the day is?



      Your job as a recruiter is to communicate reasonable expectations of the work environment. If it's mostly maintenance work, your applicants will filter themselves out nicely if they don't want to do it.






      share|improve this answer












      I think you are approaching this from the wrong perspective. It's not a problem of recruiting, it's a problem of leadership. Virtually every programming job is a mix of writing new and maintaining older code.



      How they are led and motivated will be the key to getting the vast majority of developers to perform well.



      Does their manager communicate the companies priorities clearly to them? Most devs are motivated and happy do whatever is most important to the companies success.



      Do you makes sure they are rewarded for their contributions and made to feel the company cares about them and their efforts?



      Do the company priorities make sense? Jerking devs around from one project to another, or burying them in endless bug fixing work over trivial problems is a great way to dis-motivate your devs. Does your organization regularly make schedules and problems "urgent" and require devs to constantly work over-time to solve them?



      Does their manager and the company foster a team oriented atmosphere? When it's crunch time do their manager and upper execs there to help out, or do they just expect the lower ranking devs to work "death marches" to solve whatever their "urgent" problem of the day is?



      Your job as a recruiter is to communicate reasonable expectations of the work environment. If it's mostly maintenance work, your applicants will filter themselves out nicely if they don't want to do it.







      share|improve this answer












      share|improve this answer



      share|improve this answer










      answered yesterday









      SafeFastExpressive

      2006




      2006












      • +1 from the office chasing a Jan 1st deadline for an extra paycheck's bonus.
        – Bardicer
        16 hours ago




















      • +1 from the office chasing a Jan 1st deadline for an extra paycheck's bonus.
        – Bardicer
        16 hours ago


















      +1 from the office chasing a Jan 1st deadline for an extra paycheck's bonus.
      – Bardicer
      16 hours ago






      +1 from the office chasing a Jan 1st deadline for an extra paycheck's bonus.
      – Bardicer
      16 hours ago













      1














      In my interviews, sure, I ask technical questions, especially to figure out unclear bits of the CV, or to dig deep into topics they say they're experts in.



      Aside from that, I spend as much time as possible to simply talk with them about our field. I'm open and honest about what the goal of the current discussion is (i.e., in an early phone call, I would say "this call is just so we can get to learn to know each other, this is not a test" etc.; or in an on-site interview I might say "part of this interview is to find out the exact team in my company where you can start working, matching your interests as well as possible", and I mean it).



      This is not made to let them lower their guard, or trick them, but just to get an honest discussion going. Frankly, this gives me the most useful information about the person. And as part of it, if I know that I need someone to work on older software (which, in fact, I sometimes do), then I will describe plainly and clearly what I need. I usually can tell from their reaction whether they like that kind of work, even if they don't but still say "yes".




      What questions or polite (not overly time consuming) tests would you ask to find someone who is interested and willing to maintain and improve code?




      My question would be: "Are you interested and willing to maintain and improve code?" Plain and simple. Honest and direct. Everything else would waste their and my time. If their reaction shows me that the answer is "no", I go on from there. If it's "yes", I'll do the usual (dig deeper, let them explain their understanding of this, etc.).



      Their reaction goes into my overall evaluation afterwards. I.e., if they don't want the maintain work, but have plenty of other skills that we need, and if I'm sure that the current team structure can handle someone like that, then all is well. Or if they do want this, but somehow could not convince me that they really meant (or understood) it, and did not bring much else to the table, then we'll part ways.






      share|improve this answer




























        1














        In my interviews, sure, I ask technical questions, especially to figure out unclear bits of the CV, or to dig deep into topics they say they're experts in.



        Aside from that, I spend as much time as possible to simply talk with them about our field. I'm open and honest about what the goal of the current discussion is (i.e., in an early phone call, I would say "this call is just so we can get to learn to know each other, this is not a test" etc.; or in an on-site interview I might say "part of this interview is to find out the exact team in my company where you can start working, matching your interests as well as possible", and I mean it).



        This is not made to let them lower their guard, or trick them, but just to get an honest discussion going. Frankly, this gives me the most useful information about the person. And as part of it, if I know that I need someone to work on older software (which, in fact, I sometimes do), then I will describe plainly and clearly what I need. I usually can tell from their reaction whether they like that kind of work, even if they don't but still say "yes".




        What questions or polite (not overly time consuming) tests would you ask to find someone who is interested and willing to maintain and improve code?




        My question would be: "Are you interested and willing to maintain and improve code?" Plain and simple. Honest and direct. Everything else would waste their and my time. If their reaction shows me that the answer is "no", I go on from there. If it's "yes", I'll do the usual (dig deeper, let them explain their understanding of this, etc.).



        Their reaction goes into my overall evaluation afterwards. I.e., if they don't want the maintain work, but have plenty of other skills that we need, and if I'm sure that the current team structure can handle someone like that, then all is well. Or if they do want this, but somehow could not convince me that they really meant (or understood) it, and did not bring much else to the table, then we'll part ways.






        share|improve this answer


























          1












          1








          1






          In my interviews, sure, I ask technical questions, especially to figure out unclear bits of the CV, or to dig deep into topics they say they're experts in.



          Aside from that, I spend as much time as possible to simply talk with them about our field. I'm open and honest about what the goal of the current discussion is (i.e., in an early phone call, I would say "this call is just so we can get to learn to know each other, this is not a test" etc.; or in an on-site interview I might say "part of this interview is to find out the exact team in my company where you can start working, matching your interests as well as possible", and I mean it).



          This is not made to let them lower their guard, or trick them, but just to get an honest discussion going. Frankly, this gives me the most useful information about the person. And as part of it, if I know that I need someone to work on older software (which, in fact, I sometimes do), then I will describe plainly and clearly what I need. I usually can tell from their reaction whether they like that kind of work, even if they don't but still say "yes".




          What questions or polite (not overly time consuming) tests would you ask to find someone who is interested and willing to maintain and improve code?




          My question would be: "Are you interested and willing to maintain and improve code?" Plain and simple. Honest and direct. Everything else would waste their and my time. If their reaction shows me that the answer is "no", I go on from there. If it's "yes", I'll do the usual (dig deeper, let them explain their understanding of this, etc.).



          Their reaction goes into my overall evaluation afterwards. I.e., if they don't want the maintain work, but have plenty of other skills that we need, and if I'm sure that the current team structure can handle someone like that, then all is well. Or if they do want this, but somehow could not convince me that they really meant (or understood) it, and did not bring much else to the table, then we'll part ways.






          share|improve this answer














          In my interviews, sure, I ask technical questions, especially to figure out unclear bits of the CV, or to dig deep into topics they say they're experts in.



          Aside from that, I spend as much time as possible to simply talk with them about our field. I'm open and honest about what the goal of the current discussion is (i.e., in an early phone call, I would say "this call is just so we can get to learn to know each other, this is not a test" etc.; or in an on-site interview I might say "part of this interview is to find out the exact team in my company where you can start working, matching your interests as well as possible", and I mean it).



          This is not made to let them lower their guard, or trick them, but just to get an honest discussion going. Frankly, this gives me the most useful information about the person. And as part of it, if I know that I need someone to work on older software (which, in fact, I sometimes do), then I will describe plainly and clearly what I need. I usually can tell from their reaction whether they like that kind of work, even if they don't but still say "yes".




          What questions or polite (not overly time consuming) tests would you ask to find someone who is interested and willing to maintain and improve code?




          My question would be: "Are you interested and willing to maintain and improve code?" Plain and simple. Honest and direct. Everything else would waste their and my time. If their reaction shows me that the answer is "no", I go on from there. If it's "yes", I'll do the usual (dig deeper, let them explain their understanding of this, etc.).



          Their reaction goes into my overall evaluation afterwards. I.e., if they don't want the maintain work, but have plenty of other skills that we need, and if I'm sure that the current team structure can handle someone like that, then all is well. Or if they do want this, but somehow could not convince me that they really meant (or understood) it, and did not bring much else to the table, then we'll part ways.







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited yesterday

























          answered yesterday









          AnoE

          5,425826




          5,425826























              1














              I am going to add one new dimension to the answers already given. In a nutshell my advice on this question is: Look seriously at older workers for this particular role.



              The IT industry has long been affected by the issue of ageism, preferring the fast young minds of youth over the slightly slower minds of older workers. That said, those slightly slower minds have a wealth of experience and discipline that many younger workers often lack, and maintenance coding requires just such discipline.



              Hiring new coders seldom requires much experience because you will be teaching them all the idiosyncrasies of your company's codebase and work methods. A "kid" fresh out of college might know the latest and greatest ways to (as you put it) chase the new and shiney but you cannot teach the instinct for finding bugs or the mindset required for plodding through miles of unfamiliar code. Experience is what provides those attributes and experience requires time thus years thus age.



              Take 2 minutes and click the following two Google queries. Then for each of these two queries skim the content of any 3 hits (6 articles total):




              • Query #1 : myths about hiring older workers

              • Query #2 : myths about hiring older programmers


              Also we all know that once a programmer has mastered one particular language they seldom have trouble learning new ones. Look to see if their work history shows they adapt well to new environments. Look at how many languages these older workers have, not if they know the cutting edge ones or even possibly the exact one you need. If their experience is close they will learn and thrive on that learning. You are hiring them for legacy work, exactly the opposite of cutting edge.



              So do your due diligence. Never use age alone as a reason to hire or not hire, but in a case like this consider that age and experience are real assets and any preconceptions you may have about hiring someone perhaps age 50 or more should be carefully examined because you might just be missing out on exactly the skills and attitudes you asked about in your OP.



              Oh and one last thing. Do not be surprised if you get some evasive push-back from your HR department. For complicated (but erroneous) reasons based in those aforementioned myths, HR departments are often prone to try and filter out older applicants in IT departments. So be aware that you may need to educate your own manager and HR department that you reject these myths, provide them some of the studies you will easily find online from those links above, and insist that they are not to reject the so called "over qualified" job seekers but rather to send them through to the interviews.






              share|improve this answer





















              • I really love this answer! Experience and maturity can count for so much, it's odd that people so willingly overlook it. That said, there's also the chance of the newbies being taught well if they're very inexperienced, I suppose. 😄
                – yochannah
                2 hours ago
















              1














              I am going to add one new dimension to the answers already given. In a nutshell my advice on this question is: Look seriously at older workers for this particular role.



              The IT industry has long been affected by the issue of ageism, preferring the fast young minds of youth over the slightly slower minds of older workers. That said, those slightly slower minds have a wealth of experience and discipline that many younger workers often lack, and maintenance coding requires just such discipline.



              Hiring new coders seldom requires much experience because you will be teaching them all the idiosyncrasies of your company's codebase and work methods. A "kid" fresh out of college might know the latest and greatest ways to (as you put it) chase the new and shiney but you cannot teach the instinct for finding bugs or the mindset required for plodding through miles of unfamiliar code. Experience is what provides those attributes and experience requires time thus years thus age.



              Take 2 minutes and click the following two Google queries. Then for each of these two queries skim the content of any 3 hits (6 articles total):




              • Query #1 : myths about hiring older workers

              • Query #2 : myths about hiring older programmers


              Also we all know that once a programmer has mastered one particular language they seldom have trouble learning new ones. Look to see if their work history shows they adapt well to new environments. Look at how many languages these older workers have, not if they know the cutting edge ones or even possibly the exact one you need. If their experience is close they will learn and thrive on that learning. You are hiring them for legacy work, exactly the opposite of cutting edge.



              So do your due diligence. Never use age alone as a reason to hire or not hire, but in a case like this consider that age and experience are real assets and any preconceptions you may have about hiring someone perhaps age 50 or more should be carefully examined because you might just be missing out on exactly the skills and attitudes you asked about in your OP.



              Oh and one last thing. Do not be surprised if you get some evasive push-back from your HR department. For complicated (but erroneous) reasons based in those aforementioned myths, HR departments are often prone to try and filter out older applicants in IT departments. So be aware that you may need to educate your own manager and HR department that you reject these myths, provide them some of the studies you will easily find online from those links above, and insist that they are not to reject the so called "over qualified" job seekers but rather to send them through to the interviews.






              share|improve this answer





















              • I really love this answer! Experience and maturity can count for so much, it's odd that people so willingly overlook it. That said, there's also the chance of the newbies being taught well if they're very inexperienced, I suppose. 😄
                – yochannah
                2 hours ago














              1












              1








              1






              I am going to add one new dimension to the answers already given. In a nutshell my advice on this question is: Look seriously at older workers for this particular role.



              The IT industry has long been affected by the issue of ageism, preferring the fast young minds of youth over the slightly slower minds of older workers. That said, those slightly slower minds have a wealth of experience and discipline that many younger workers often lack, and maintenance coding requires just such discipline.



              Hiring new coders seldom requires much experience because you will be teaching them all the idiosyncrasies of your company's codebase and work methods. A "kid" fresh out of college might know the latest and greatest ways to (as you put it) chase the new and shiney but you cannot teach the instinct for finding bugs or the mindset required for plodding through miles of unfamiliar code. Experience is what provides those attributes and experience requires time thus years thus age.



              Take 2 minutes and click the following two Google queries. Then for each of these two queries skim the content of any 3 hits (6 articles total):




              • Query #1 : myths about hiring older workers

              • Query #2 : myths about hiring older programmers


              Also we all know that once a programmer has mastered one particular language they seldom have trouble learning new ones. Look to see if their work history shows they adapt well to new environments. Look at how many languages these older workers have, not if they know the cutting edge ones or even possibly the exact one you need. If their experience is close they will learn and thrive on that learning. You are hiring them for legacy work, exactly the opposite of cutting edge.



              So do your due diligence. Never use age alone as a reason to hire or not hire, but in a case like this consider that age and experience are real assets and any preconceptions you may have about hiring someone perhaps age 50 or more should be carefully examined because you might just be missing out on exactly the skills and attitudes you asked about in your OP.



              Oh and one last thing. Do not be surprised if you get some evasive push-back from your HR department. For complicated (but erroneous) reasons based in those aforementioned myths, HR departments are often prone to try and filter out older applicants in IT departments. So be aware that you may need to educate your own manager and HR department that you reject these myths, provide them some of the studies you will easily find online from those links above, and insist that they are not to reject the so called "over qualified" job seekers but rather to send them through to the interviews.






              share|improve this answer












              I am going to add one new dimension to the answers already given. In a nutshell my advice on this question is: Look seriously at older workers for this particular role.



              The IT industry has long been affected by the issue of ageism, preferring the fast young minds of youth over the slightly slower minds of older workers. That said, those slightly slower minds have a wealth of experience and discipline that many younger workers often lack, and maintenance coding requires just such discipline.



              Hiring new coders seldom requires much experience because you will be teaching them all the idiosyncrasies of your company's codebase and work methods. A "kid" fresh out of college might know the latest and greatest ways to (as you put it) chase the new and shiney but you cannot teach the instinct for finding bugs or the mindset required for plodding through miles of unfamiliar code. Experience is what provides those attributes and experience requires time thus years thus age.



              Take 2 minutes and click the following two Google queries. Then for each of these two queries skim the content of any 3 hits (6 articles total):




              • Query #1 : myths about hiring older workers

              • Query #2 : myths about hiring older programmers


              Also we all know that once a programmer has mastered one particular language they seldom have trouble learning new ones. Look to see if their work history shows they adapt well to new environments. Look at how many languages these older workers have, not if they know the cutting edge ones or even possibly the exact one you need. If their experience is close they will learn and thrive on that learning. You are hiring them for legacy work, exactly the opposite of cutting edge.



              So do your due diligence. Never use age alone as a reason to hire or not hire, but in a case like this consider that age and experience are real assets and any preconceptions you may have about hiring someone perhaps age 50 or more should be carefully examined because you might just be missing out on exactly the skills and attitudes you asked about in your OP.



              Oh and one last thing. Do not be surprised if you get some evasive push-back from your HR department. For complicated (but erroneous) reasons based in those aforementioned myths, HR departments are often prone to try and filter out older applicants in IT departments. So be aware that you may need to educate your own manager and HR department that you reject these myths, provide them some of the studies you will easily find online from those links above, and insist that they are not to reject the so called "over qualified" job seekers but rather to send them through to the interviews.







              share|improve this answer












              share|improve this answer



              share|improve this answer










              answered 12 hours ago









              O.M.Y.

              1616




              1616












              • I really love this answer! Experience and maturity can count for so much, it's odd that people so willingly overlook it. That said, there's also the chance of the newbies being taught well if they're very inexperienced, I suppose. 😄
                – yochannah
                2 hours ago


















              • I really love this answer! Experience and maturity can count for so much, it's odd that people so willingly overlook it. That said, there's also the chance of the newbies being taught well if they're very inexperienced, I suppose. 😄
                – yochannah
                2 hours ago
















              I really love this answer! Experience and maturity can count for so much, it's odd that people so willingly overlook it. That said, there's also the chance of the newbies being taught well if they're very inexperienced, I suppose. 😄
              – yochannah
              2 hours ago




              I really love this answer! Experience and maturity can count for so much, it's odd that people so willingly overlook it. That said, there's also the chance of the newbies being taught well if they're very inexperienced, I suppose. 😄
              – yochannah
              2 hours ago











              0














              In my opinion it is not the point how people feel about refactoring vs recreating code. The question is why or when, a question of reasons for a decision in particular cases. I want to explain why:



              Writing new code including a setup of a new concept is often experienced as a thankless job since the economy usually puts pressure on developers to work efficient in the purpose of generating volume of sales in shortest time.



              Not infrequently I got an interesting project to be extended. After several hours of code review I was horrified about the misconcepted code base. It was not really concepted in an extensible way and had several security vulnerabilities. Building additional code dependent on that base had lead into a hardly predictable behaviour.



              I experienced many situations when I had to suggest to do a complete rework based on a new concept while including existing algorithms of the old project. And that did not cause much enthusiasm on my mind facing a huge task.



              My conviction is that most developers love to do an easy job based on a well structured framework - so far it exists. I do. Why to rack one's brain when there is a much more comfortable way to do it?



              Thus when looking for new team members we should ask candidates for scenarios in which they would prefer to rewrite an existing code base prior to refactoring/extending and for detailed explainations for their reasons. We want to know if the candidate is able to take reliable decisions conforming with our company policy.






              share|improve this answer










              New contributor




              Quasimodo's clone is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
              Check out our Code of Conduct.























                0














                In my opinion it is not the point how people feel about refactoring vs recreating code. The question is why or when, a question of reasons for a decision in particular cases. I want to explain why:



                Writing new code including a setup of a new concept is often experienced as a thankless job since the economy usually puts pressure on developers to work efficient in the purpose of generating volume of sales in shortest time.



                Not infrequently I got an interesting project to be extended. After several hours of code review I was horrified about the misconcepted code base. It was not really concepted in an extensible way and had several security vulnerabilities. Building additional code dependent on that base had lead into a hardly predictable behaviour.



                I experienced many situations when I had to suggest to do a complete rework based on a new concept while including existing algorithms of the old project. And that did not cause much enthusiasm on my mind facing a huge task.



                My conviction is that most developers love to do an easy job based on a well structured framework - so far it exists. I do. Why to rack one's brain when there is a much more comfortable way to do it?



                Thus when looking for new team members we should ask candidates for scenarios in which they would prefer to rewrite an existing code base prior to refactoring/extending and for detailed explainations for their reasons. We want to know if the candidate is able to take reliable decisions conforming with our company policy.






                share|improve this answer










                New contributor




                Quasimodo's clone is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                Check out our Code of Conduct.





















                  0












                  0








                  0






                  In my opinion it is not the point how people feel about refactoring vs recreating code. The question is why or when, a question of reasons for a decision in particular cases. I want to explain why:



                  Writing new code including a setup of a new concept is often experienced as a thankless job since the economy usually puts pressure on developers to work efficient in the purpose of generating volume of sales in shortest time.



                  Not infrequently I got an interesting project to be extended. After several hours of code review I was horrified about the misconcepted code base. It was not really concepted in an extensible way and had several security vulnerabilities. Building additional code dependent on that base had lead into a hardly predictable behaviour.



                  I experienced many situations when I had to suggest to do a complete rework based on a new concept while including existing algorithms of the old project. And that did not cause much enthusiasm on my mind facing a huge task.



                  My conviction is that most developers love to do an easy job based on a well structured framework - so far it exists. I do. Why to rack one's brain when there is a much more comfortable way to do it?



                  Thus when looking for new team members we should ask candidates for scenarios in which they would prefer to rewrite an existing code base prior to refactoring/extending and for detailed explainations for their reasons. We want to know if the candidate is able to take reliable decisions conforming with our company policy.






                  share|improve this answer










                  New contributor




                  Quasimodo's clone is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                  Check out our Code of Conduct.









                  In my opinion it is not the point how people feel about refactoring vs recreating code. The question is why or when, a question of reasons for a decision in particular cases. I want to explain why:



                  Writing new code including a setup of a new concept is often experienced as a thankless job since the economy usually puts pressure on developers to work efficient in the purpose of generating volume of sales in shortest time.



                  Not infrequently I got an interesting project to be extended. After several hours of code review I was horrified about the misconcepted code base. It was not really concepted in an extensible way and had several security vulnerabilities. Building additional code dependent on that base had lead into a hardly predictable behaviour.



                  I experienced many situations when I had to suggest to do a complete rework based on a new concept while including existing algorithms of the old project. And that did not cause much enthusiasm on my mind facing a huge task.



                  My conviction is that most developers love to do an easy job based on a well structured framework - so far it exists. I do. Why to rack one's brain when there is a much more comfortable way to do it?



                  Thus when looking for new team members we should ask candidates for scenarios in which they would prefer to rewrite an existing code base prior to refactoring/extending and for detailed explainations for their reasons. We want to know if the candidate is able to take reliable decisions conforming with our company policy.







                  share|improve this answer










                  New contributor




                  Quasimodo's clone is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                  Check out our Code of Conduct.









                  share|improve this answer



                  share|improve this answer








                  edited 18 hours ago





















                  New contributor




                  Quasimodo's clone is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                  Check out our Code of Conduct.









                  answered 19 hours ago









                  Quasimodo's clone

                  1092




                  1092




                  New contributor




                  Quasimodo's clone is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                  Check out our Code of Conduct.





                  New contributor





                  Quasimodo's clone is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                  Check out our Code of Conduct.






                  Quasimodo's clone is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                  Check out our Code of Conduct.






























                      draft saved

                      draft discarded




















































                      Thanks for contributing an answer to The Workplace Stack Exchange!


                      • Please be sure to answer the question. Provide details and share your research!

                      But avoid



                      • Asking for help, clarification, or responding to other answers.

                      • Making statements based on opinion; back them up with references or personal experience.


                      To learn more, see our tips on writing great answers.





                      Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


                      Please pay close attention to the following guidance:


                      • Please be sure to answer the question. Provide details and share your research!

                      But avoid



                      • Asking for help, clarification, or responding to other answers.

                      • Making statements based on opinion; back them up with references or personal experience.


                      To learn more, see our tips on writing great answers.




                      draft saved


                      draft discarded














                      StackExchange.ready(
                      function () {
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f125255%2frecruiting-people-who-maintain-improve-not-just-chase-the-new-and-shiny%23new-answer', 'question_page');
                      }
                      );

                      Post as a guest















                      Required, but never shown





















































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown

































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown











                      Popular posts from this blog

                      What visual should I use to simply compare current year value vs last year in Power BI desktop

                      How to ignore python UserWarning in pytest?

                      Alexandru Averescu