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.

  • 2
    Comments are not for extended discussion; this conversation has been moved to chat.
    – Lilienthal
    Commented Apr 2, 2020 at 12:37
  • 12
    To the OP - I strongly recommend removing information which could be used to determine or guess your identity. You don't want your employer reading this and jumping to conclusions. Ex. Remove stuff like "CSV of failed entries via email", "offered the manager a Python script" etc. Looks like the CSV paragraph really means to say that the work was easy and delay in receiving the work request. Does it matter that you had to work with CSV, TSV or pipe separated files ? If I was your boss, reading this, I'd easily figure out who this is.
    – MasterJoe
    Commented Apr 3, 2020 at 22:49

13 Answers 13


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.

  • 93
    Exactly this. Balancing trade-offs to create a solution that is "good enough" to solve the given problem is the most important skill an engineer can have. It's not a side effect of the job, it is the job.
    – Seth R
    Commented Apr 1, 2020 at 16:16
  • 47
    Well, yes, I thought that part too for the first part. On the other hand OP likely makes life hard for himself, his team and his company for the future. Management is typically the last to acknowledge the future cost of technical debt, which is why often enough it falls onto lead devs to push back against such "tomorrow done" stuff. Plus regularly doing such stunts can get the expectation of management up that doing such stunts is all fine and well, when they should be the exception. Because they cost you in the future when you fall over half-heartedly done features. Commented Apr 1, 2020 at 19:06
  • 9
    But in selling themselves sure, this would be a line of arguing. And indeed it is an important skill to deliver based on the requirements, but with it comes the knowledge of when to just go along with a quickfix and when to push back and hold the line to do it "properly". Commented Apr 1, 2020 at 19:07
  • 5
    @Amon I agree the assessment whether this is good or bad application of said skill depends a bit on the actual context etc. It just seemed to have happened a few times now, such that I see a pattern that might well lead down a bad path. Even if that does not apply to OP, a balanced answer might point that risk out. As I'm already seeing someone who regularly goes for the quick and dirty solution citing this as justification...^^ It is a major part of developers roles to ensure certain quality standards, same as bridge builders need to make sure their bridges are not build to last only 6 months Commented Apr 2, 2020 at 17:10
  • 1
    And obviously if you come up with a proper solution that is well and sound and fast, that's awesome, but doesn't seem to fit the question. Commented Apr 2, 2020 at 19:38

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


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.

  • I had to google your fancy wording and it's spelled de rigueur Commented Apr 3, 2020 at 7:10
  • 3
    Alternatively, it's perfectly fine to go big in technical debt to meet a deadline, or get something out of the door, and then go back after the time crunch and clean-up. That's why it's called debt, it's fine to borrow, just be cautious of the interest you repay until it's cleaned up, and avoid bankruptcy. Commented Apr 3, 2020 at 17:34
  • Not a fan of this answer (even if the conclusion is the right one). The customer might be willing to accept a 4 min delay, but the company might not enjoy having to clean up this shite later. And the OP's peers certainly won't.
    – Telastyn
    Commented Apr 3, 2020 at 21:49
  • The problem with that saying is that it's true whether you're advocating perfection, or whether you're advocating "good enough." It's tantamount to saying, "These words mean different things, and these things yield different results."
    – employee-X
    Commented Apr 3, 2020 at 22:11

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

  • This is interesting, because in interview questions I've been asked countless times if I'd rather deliver a perfect project late, or a less than perfect project on time. I always answered the former but I'm not so sure now. When considering the business needs of the client.
    – Amon
    Commented Apr 2, 2020 at 17:00
  • ‘hacking’ is “finding solutions”. Commented Apr 14, 2020 at 20:12

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.

  • 3
    And of course you should consider leaving it off if you don't want to work in such situations in the future ,)
    – eckes
    Commented Apr 2, 2020 at 10:49

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.

  • I agree that involvment of senior devs would be very desirable, but then, I would also expect them to find and consider the shortcuts that allowed hackydude to deliver in time. In my experience, senior devs are mentally so stuck with their way of doing things, the one and only proper way, that they confuse "ugly" with "impossible". Commented Apr 9, 2020 at 9:27
  • 1
    Yes, this! I especially like that the senior dev conditioned the hacky solution on post-op cleanup to improve maintainability.
    – Brandon
    Commented Apr 9, 2020 at 19:59
  • 1
    There is nothing wrong with technical debt. Reckless technical debt with no repayment plan is how products fall apart. It's like money. Taking out a mortgage isn't bad. Refusing to repay the bank, however, will eventually come back to bite you.
    – Brandon
    Commented Apr 9, 2020 at 20:00
  • How often does it take 4 minutes? How many hours of work does it cost the customer, and how much work for you to do it in two or one minutes or in a second? In a way that works?
    – gnasher729
    Commented Aug 13, 2023 at 17:51

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:

Quadrant of Reckless/Prudent and Deliberate/Inadvertent. Deliberate reckless: "We don't have time for design". Deliberate prudent: "We must ship now and deal with consequences". Inadvertent reckless: "What's Layering?" Inadvertent prudent: "Now we know how we should have done it".

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.

  • 4
    But technical debt tend to accumulate until a forced rewrite (very lengthy and expensive). Commented Apr 2, 2020 at 0:54
  • 4
    @PeterMortensen That's where you have to make a prudent decision. If you ship now, get cash from a customer, then you have to pay for technical debt. If you don't ship now, get no cash from a customer, you may go bankrupt and never able to finish the product.
    – gnasher729
    Commented Apr 2, 2020 at 9:37
  • 1
    @PeterMortensen Developers need to communicate the debt status to management. If the developers acknowledge the debt and the managers don't, fudge estimates on other tasks to include time to pay down the debt, and/or start looking for an employer more worthy of your talent. Commented Apr 2, 2020 at 16:42
  • 1
    @PeterMortensen No, technical debt accumulates when you decide let it accumulate (rather than shrinking it as you go along changing the code). It's the developer's choice whether they give estimates that increase or decrease technical debt (though management may force them to work in a way that increases it anyway).
    – cjs
    Commented Apr 3, 2020 at 11:16
  • Some management only understands “it works” or “it doesn’t work”, but not “technical debt”.
    – gnasher729
    Commented Aug 13, 2023 at 17:52

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.


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.

  • 4
    Could you say in which country one mentions a thank you email from the CEO on the resume? I have never heard of this.
    – guest
    Commented Apr 1, 2020 at 20:27
  • 4
    I’ve not heard of putting a reason for your promotion on your resume either. I think the rules have changed since I learned to write resumes.
    – Preston
    Commented Apr 2, 2020 at 16:53

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.


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.


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


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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .