91

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

  • 17
    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 Dec 24 '18 at 18:02
  • 4
    @Džuris I've now been working at a company for many years and have seen the same types of bugs introduced in three generations of some pieces of software. In my view, delete-and-rewrite is dangerous unless the developers are experienced in the functionality required (so not new hires then). On the other hand, I agree that refactoring is a good idea - and very good training too. – Alchymist Dec 27 '18 at 14:54
  • 1
    Another question is why do I have to be always interested in what I'm doing. It's work after all. People do it to earn money. – Gherman Dec 27 '18 at 16:59
  • 1
    @Džuris: From one of the founders of this site... joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i – Mehrdad Dec 28 '18 at 10:22
  • 1
    @mehrdad I just want to copy and paste whole paragraphs of that article into the question 😆 thank you, it's brilliant! – yochannah Dec 28 '18 at 10:28
114

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.

  • 6
    This is a great answer, I started to write my own but eventually realised I was just rewording this one. – davnicwil Dec 24 '18 at 13:39
  • 2
    @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 Dec 24 '18 at 16:32
  • 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 Dec 24 '18 at 17:02
  • 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 Dec 25 '18 at 11:45
  • 1
    @Michael that's actually an interesting problem in recruitment - assuming recruiters know you'll be using something. A good example might be version control, or Linux command line. A lot of people know how to use it, but someone reviewing your CV/resume can't be sure you do know it and may not be able to shortlist you because of that lack. Same goes for interviews- mentioning skills that seem obvious - ideally only briefly - is important. – yochannah Dec 26 '18 at 17:25
93

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

  • 19
    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 Dec 25 '18 at 12:26
  • 7
    @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 Dec 25 '18 at 14:52
  • 10
    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 Dec 25 '18 at 18:43
  • 2
    This widely missed the point of the question asked, which was about finding people willing to work with the existing code and avoiding those whose answer to everything is to tear it up and replace it. It's not about allocation of time to maintenance vs. features, it's about engineer's willingness to do maintenance vs impulsively make ill-conceived change. – Chris Stratton Dec 26 '18 at 23:22
  • 3
    @ChrisStratton There is already an excellent answer to the question "as asked". I chose to provide an answer that tackles what I believe might be an underlying issue. Showing the value of maintenance in a successful, healthy organization is likely enough for these "new stuff only" devs to learn that there's a better way - eventually making hiring easier because you know your organization does things right and can assimilate any reasonable developer. Then your task simply becomes how to filter unreasonable people, which should already be any interviewer's goal. – BinaryTox1n Dec 27 '18 at 15:29
45

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.

  • 35
    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 Dec 24 '18 at 14:39
  • 3
    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 Dec 25 '18 at 5:52
  • 1
    I'd agree with that, especially as I am one of those consultants! – Owen C. Jones Dec 27 '18 at 10:35
12

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):

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.

  • 2
    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 Dec 26 '18 at 10:01
  • 3
    @yochannah - They "overlook" experience due to the persistence of the "older worker" myths I mentioned and (indirectly) linked to. More than 50% of the available workforce is over the age of 40 now and yet the hiring demographic does not reflect that. One word that is utterly illogical and yet used all the time is "overqualified", as if it is a bad thing to know more than the job requires. – O.M.Y. Dec 26 '18 at 19:54
  • "experience and discipline" - in my experience, this has materialised as hubris, inflexibility and resistance to change. – Gusdor Dec 28 '18 at 9:59
  • 1
    @cHao - that may be true for younger (age < 40) workers who can easily find new jobs, but the older a worker gets the more they value stability and long term employment partially because they have responsibilities like a mortgage and a family but mostly because the next job is not a sure thing. For more than 4 decades now the US Judiciary have officially recognized that companies often use the phrase "overqualified" as code for "too old" in a number of age discrimination cases and yet HR departments continue to defend it using the exact same argument you just made. – O.M.Y. Dec 28 '18 at 17:43
  • 1
    @cHao - one more thing. At one time I was a Critical Severity Incident Manager for a major international corporation. It was a high paying job with a lot of visibility and a very high stress level with 24/7 oncall. Today I would not take that job if you offered me a million dollars a year. While I could easily do the work -- I am very good at it -- I simply do not want that kind of stress any more, My priorities have changed: my mortgage is done and I have almost no debt, my family has scattered to the winds and live in other parts of the country, and I simply need very little income anymore. – O.M.Y. Dec 28 '18 at 18:17
11

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.

  • 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 Dec 24 '18 at 17:59
  • Whereas I would likely go for just such a job since I actually enjoy analyzing code and tweaking it for improvement. As a kid, before the days of home PC's, I learned how to program on paper by becoming a human emulator / human code interpretter of a game program that I loved and was given a printout of the source listing. Ever since I have had an affinity for such work. – O.M.Y. Dec 28 '18 at 17:18
6

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.

  • +1 from the office chasing a Jan 1st deadline for an extra paycheck's bonus. – Bardicer Dec 25 '18 at 20:15
2

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.

  • 1
    Kudos @AnoE! You have recognized what so few do. The purpose of the interview is not primarily to double-check their CV (though it plays a small part) since that can be done by tests before the interview. Rather the interview is the best opportunity to find out if the person is a good fit for the company and the team. Great skills with the wrong personality type can destroy an existing team. – O.M.Y. Dec 28 '18 at 17:27
-1

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.

  • "most developers love to do an easy job based on a well structured framework " -- I most genuinely am sad to hear such a comment. In my experience the best developers love challenges and are willing to work as hard as necessary (if they are appropriately compensated and appreciated) to solve problems. If your experience -- especially as recruiter -- is different then I am frightened for the future of code development. – O.M.Y. Dec 28 '18 at 17:35
  • @O.M.Y. My experience is limited to smaller startup projects especially in Germany. The number of personally known developers might not be representative as well as Germany is a very special case. Most developers here have experienced that great ideas are not really wanted by the industry. They are forced to do their job in quick'n'dirty way to comply with very short deadlines. However, doing your job efficiently based on well structured framework is not a bad thing. – Quasimodo's clone Dec 29 '18 at 10:06
  • The problem is that constructing such a framework, generic and reusable code consumes time which often does not fit the company's budget. Thus the wheel is invented again and again by writing similar codes multiple times. In Germany we experience that people lose their job when they do not seem to be efficient in a single project. What I meant is there has to be a balance between using existing code vs rewriting if necessary. – Quasimodo's clone Dec 29 '18 at 10:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.