What should I say on my resume if I got promoted for dropping code quality to meet deadlines?

Question

I was on a 12 month contract (I live in a country where this is not usual for new developers) until a couple weeks ago when management at my company gave me an offer and raise to become a permanent employee for them. I like to keep my resume always up to date (especially given COVID) so I Googled around about listing it on my resume.

The advice I found was that I generally should list what achievement it was that prompted the hire. Fair enough.

The problem is, the achievement was always delivering on tight client deadlines and frankly, I did it by deciding that the engineering could be less than stellar in targeted cases (which management agreed to).

I'm a relatively junior dev on a team of 6 developers. However, I have rapidly become one of the devs management trusts the most to deliver stuff when I say that I will deliver it and keep them informed of the relative trade-offs in getting there. In my admittedly short time here, I have always been able to ship something when I have said that I can ship it.

I have had a few cases like this, but this is the one I did just before I was offered the permanent job. One of our products is a batch API which is called once a day by a single client. It does not need to return anything except for a CSV of failed entries via email. They wanted a new feature added and the salesperson had contractually agreed to have it for them by the end of the month. For various reasons, that feature request didn't make it down to us until Monday of the final week of the month.

Senior developer told the manager that development couldn't be done properly and to tell the client that it couldn't be done. I don't contradict the senior devs in sprint planning meetings, but maybe it was obvious that I disagreed with senior guy. Like, not disagreed, but an option existed with certain trade offs. The other devs are also fairly passive, so nobody else contradicted him either. Manager was not happy about this as the client is already angry with us for not delivering when we promise to do so. Manager then summoned me to his office after the meeting to ask whether I saw an alternative. I told him that I could get something to work, but it would probably double the processing time of the API (which would add 4 minutes) since I have no speciality SQL skills. Manager agreed and apparently the client didn't even notice.

I am not sure what the consequences of missing the deadline would have been, but they were steep enough that the CEO of our 1000 person company sent a thank you email to me for delivering it.

Another case did not attract as much attention, but there was a process we needed to run on a database. The correct way to do it would have been to write a proper batch process in the mega Java system we use, send it through all the regular QA processes, and let it pop out the end two weeks later. I offered the manager a Python script which would need to be run manually and would be horrendously inefficient (had to run it overnight), but if triggered once a month, would keep the problem at bay until a permanent fix arrived. This was a production issue, so he agreed to that as a stopgap measure. This was basically just a cheap for loop that checked rows for a certain type of erroneous data and re-formatted it.

Is there a way to list these types of things on my resume that doesn't make me look like a hack programmer who undermines senior devs? I admit that my solutions are technically not sound, but they were sound for the business needs at the time and the inefficiency trade off was largely irrelevant in most cases.

Answer 1

You found several effective (not efficient) ways to solve problems without over-engineering them and "Done is better than perfect"

Finding a solution that is just good enough is an important ability for an engineer as you would otherwise spend a lot of time optimizing something that is not worth optimizing. If something is not used often, it's often not worth to optimize it. There is a nice XKCD-Comic with a table that tells you how much time you should invest in something.

A solution is only worth something if it is (or can be) used, so with a hack you enabled the customer to keep working until you have a solution.

There is no reason to tell anyone that you disagreed with your supervisor. Just go for something like "Able to produce effective solutions under time pressure".

I admit that my solutions are technically not sound, but they were sound for the business needs at the time and the inefficiency trade off was largely irrelevant in most cases.

You had one job: "find a solution that runs within the time limits that solves the job". And that is exactly what you did.

Answer 2

I get the feeling that only management has been giving answers here, because there was nothing but praise in sticking to unreasonable deadlines.

There is another viewpoint: You shouldn't underestimate the social disturbances you ignite within the dev team when management cuts corners and ignores the opinions of senior developers. There is a saying which goes roughly like this:

As long as there is someone who's constantly extinguishing the fire, management will not stop playing with matches.

It's one thing if you once/twice go down the hacky road because you are forced to do so, but a completely different one if it is getting the norm. And from your description it seems to me that management has become quite comfortable with the practice of using you to cut corners. You should seriously consider to raise this issue to your management and senior devs in order to maintain a healthy work environment. A company is a balance between dev and management and not simply a top down structure. There is a reason why the word "no" exists and you should practise using it.

However, this is still more an issue of management than yours. Hence, there is no reason to somehow mention this in your resume. So I would go along with:

able to meet deadlines

Answer 3

As the saying goes "Perfect is the enemy of good" - making technical compromises in order to satisfy business needs is pretty much de rigueur. The good devs/programmers/engineers are the ones who can identify the acceptable trade-offs that can be made.

In your API example the customer was clearly more willing to accept a 4 min delay in processing for something that worked and was delivered on time.

Ideally you should be looking to minimize technical debt when making these compromises - but that's all part and parcel of experience and knowing where you can shave time and when you need to ensure that something is done "right" in order to save more time in the long run.

My fundamental question is, is there a way to list these types of things on my resume that doesn't make me look like a hack programmer who undermines senior devs?

When it comes top your CV there's no need to get into the specifics of your solution - you can simply say that you have a good track record of delivering to deadlines on time-sensitive projects and mention the examples without details of the actual implementation.

Answer 4

What you do is NOT "hacking", it is "finding solutions".

I work as a developer and consultant since 20 years now, and this skill is what employers look for: Don't leave it out of your resume, but emphasise exactly that: You try to find solutions even if that means going "unusual" paths.

Don't write that you do that behind the backs of senior developers but that you do that whenever asked for solutions even if more experienced guys disagree / say its not possible.

There is a great quote that is said to come from Albert Einstein that exactly describes your situation:

Everyone knew it was impossible, until a fool who didn't know came along and did it.

I worked together with a lot of developers and I know every facet of this:

I worked with a developer who is among the top 1% of JavaScript- experts over at stackoverflow. He is a genius and I really admire every line of code he writes. But quite often he did not finish his projects: He'd rather not finish something than finish it when he was not satisfied with the beauty of the code.

And I worked with developers who where extremely efficient, but therefore took a lot of shortcuts that made the solutions almost unmaintainable (hardcoded paths, magic numbers, etc.).

And I always preferred "done" over "beautiful" and in the end my customers also did: They'd rather have "something" when the deadline is there than "nothing but will be beautiful in some more time X"

Just one thing: Workarounds / shortcuts / "hacks" need to be understandable, documented and maintainable, then there is nothing against solutions like you

Answer 5

Sounds like normal tech debt to me. The Senior was probably older and jaded and didn't want to add any more debt to the already overburdened project (a bit like me actually I'd be the one pushing back on this). Or maybe they were just trying to protect the team. Let's look at your question directly though:

is there a way to list these types of things on my resume that doesn't make me look like a hack programmer who undermines senior devs?

Maybe I'm being naive here but you shouldn't be listing these types of things on your resume. Just the overall achievements so if this is the norm for this company it would be that you "worked under tight timescales to deliver solutions to clients" rather than details about how you jacked up a stored procedure or two in a few days to make something that works for the client. If I read a resume that says you deliver under tight timescales I get the point, nuff said.

That's all you should be adding really to your Resume even then I would keep it loose you worked for Blah Inc as a dev working with SQL and whatever else tech. Why does this even need to be on your Resume.

Answer 6

I gotta say, I would not want to hire you, and it's not because you made trade offs. That's an important part of the job and a difficult skill to acquire. It's because you made blind trade offs without the benefit of the experience of the rest of your team.

Exploring potential designs is not "contradicting" a senior dev. The conversation should have gone something like this:

You: What if we did X?

Senior dev: That would probably double the processing time. I don't think the customer would be happy with that.

PM: Actually, I think they would rather have it slow than not at all. I'll follow up with them to make sure.

Other junior: Bob knows a lot about SQL. If we can get him to help, I bet he could cut a lot of that time off.

Senior dev: But I'm still concerned about corner case Y. It would take some time to test that properly. That would be really embarrassing if we got that wrong.

PM: I agree. If you work on the testing, and OP worked with Bob to modify the API like he said, could it get done?

Senior dev: I think so for the deadline, but I'd want to go back and clean it up for the next release. Otherwise we risk Y maintenance headache every time the customer does this.

PM: Okay.

Also, these things do come up in interviews. The interviewer sees something like "recognized for making trade offs to deliver value on tight deadlines" and asks for an example, then he follows up by asking pretty much the same questions your senior dev would have.

Answer 7

You're describing technical debt, and technical debt isn't always bad. The analogy of debt extends to there being plenty of legitimate reasons why a company would take on financial debt. The key is that it's intentional and there's a realistic plan to pay it off. Martin Fowler has written extensively about this, particularly what he calls the technical debt quadrant:

It sounds like you made a prudent decision regarding technical debt. Recognizing where technical debt is prudent and knowing how to manage it are extremely valuable skills.

Answer 8

I'll leave the question "Is your resume the right place for this story?" to one side. Perhaps the resume doesn't have space for such detail, but let's say it's the sort of thing that might come up in an interview, and you're looking to think about how to present it in the best light. In any case, even if nobody talks about it again, it's worth thinking through the implications for your own professional development. Now, here's the one observation that I'd suggest is pertinent which no-one else has mentioned:

You still have the job.

You're looking at how best to present the story, but also have the privilege of being able to change the story.

So, you made a judgement call and took a risk. Because of that, you managed to hit a deadline with full observable functionality, satisfy a client, and impress your managers. Because of that you also delivered a solution with higher than needed execution costs, potentially compromised the design of the codebase, and embarrassed your team leaders. That is a reasonable judgement call to make. Others have already explained how to present that: you leave the intra-team conflict out of the story altogether, you explicitly state the technical problems with your solution that you recognised, together with awareness of the business reality, and you explain that you made a call.

But if you could tell a better story, it would include both taking and clearing this debt. It would include taking a bit of review time now the deadline isn't looming, perhaps to encapsulate the code better and add a few key unit tests. It might mean shaving off two of the extra four minutes, perhaps consulting with your local SQL expert. It would include looking for ways to share the credit graciously with the rest of your team.

If you don't want a reputation as the guy who moves fast and breaks stuff, evaluate the technical, business, and interpersonal messes that your decisions (including tough but very reasonable decisions) make and take responsibility for clearing them up.

You still have the job.

Answer 9

The problem is, the achievement was always delivering on tight client deadlines and frankly, I did it by deciding that the engineering could be less than stellar in targeted cases (which management agreed to).

I am not sure what the consequences of missing the deadline would have been, but they were steep enough that the CEO of our 1000 person company sent a thank you email to me for delivering it.

Is there a way to list these types of things on my resume that doesn't make me look like a hack programmer who undermines senior devs?

You resume should highlight the achievement "... delivered on tight client deadlines and received a thank you email from the CEO".

How you got there may or may not come up in an interview setting, but it doesn't belong on the resume.

Sometimes, business decision require promptness. I can tell you from personal experience that managers value people who can find a way to get important things done.

Answer 10

So you created some software that took four minutes to run (because your code wasn't very good). If it takes me 12 hours to do the work by hand, your software saves me 11 hours 56 minutes. If you wrote better code that runs in 1 second, it saves me 11 hours, 59 minutes, 59 seconds. If the better code was delivered a week later so I had to do the work manually five times, the additional 3 minutes 59 seconds will never make up for the time I lost.

Or make it more extreme. The software needs to run in 24 hours. Your code is bad, so we need a $5,000 computer to run it in 24 hours. With better code, a $2,000 computer could run it in 24 hours. $3,000 savings. If it takes you two weeks to make the code faster, it's an overall loss.

Being able to deliver when it is needed is a very, very good thing. In addition, a very good developer can write bad code in a way so it can be improved later easily. Bad developers write bad code that is a pain to refactor into a good shape, good developers under time pressure write bad code that is easy to improve.

Answer 11

I have no particular opinion about what to put on your resume for this, though I tend to agree with the answers that say that kind of thing doesn't really fit on a resume.

However, I would like to point out what would happen if I were interviewing with you and you described the situation as you did in the question.

My first thought would be, "Good, I like someone who can do what's necessary in the short term while recognizing the trade-offs that he's making." But there's also a pretty clearly identifiable problem in your company's management of its software projects that I'd ask you to identify.

The answer I would want to hear is that someone not on the technical team promised something to a customer by a particular deadline without an estimate in hand from the technical team for when it could be delivered. Doing that is recipe for long-term disaster. If you couldn't identify that kind of problem, I'd be very wary of having you in my team.

Further, once the problem is identified, someone needs to implement long-term fixes for it to make sure that the problem is gradually reduced and, ideally, eventually eliminated. I'd ask you what you, in your new management role, did to make this happen. If you couldn't come up with a good answer to that, again I'd be quite wary about hiring you. Taking responsibility for costly short-term fixes is great, but if you're not taking responsibility for long-term fixes that remove the need for those costly short-term fixes, and save the company time and money overall, I'd consider you fit only for a junior role until you learned to do that.

Answer 12

"What's that, you say?"

The problem is, the achievement(!) was always delivering on tight client deadlines and frankly, I did it by deciding that the engineering could be less than stellar in targeted cases (which management agreed to).

And ...(!)

I am not sure what the consequences of missing the deadline would have been, but they were steep enough that the CEO of our 1000 person company sent a thank you email to me(!) for delivering it.

"Dude....!!!" I wanna hire you!!!

... unless you become a Management Consultant first!

---

Very simply, you need to ... first of all ... recognize that you have become exceptional," by the hard work of your own hands – and that you have been very-properly recognized for it. In your resumes, you should emphasize the very qualities that you have just now outlined in your Original Post.

But also: "Do not overlook your Present Situation." Do not automatically assume that the only way in which you can now advance is by leaving them ... This is where titles such as "Director" and "Chief Technology Officer" and "Executive Vice-President" come from.

Answer 13

Paraphrasing Einstein,

Software quality should be kept as low as possible, but not lower.

I know there are many developers who take pride in the code they write and strongly disagree with this. But from a business perspective, as soon as the software quality target is reached, further improving quality amounts to extra work spent on something you were not asked to do or being paid for. Absolute quality is simply not reachable: no matter how good your software is, there's always room for improvement.

Clearly, you were not praised for dropping code quality. You were praised for maintaining acceptable code quality while also meeting a deadline. That's how you should phrase it in your CV.