I am Elvis, trying very hard to learn to be Einstein. I work for Mort.

What the hell is this crazy idiot talking about!?!? (You only need to read the first few paragraphs)

If you don't feel like reading that link, basically, I am a professional programmer, and my boss is (this is scarily accurate):

the professional line-of-business programmer who lacks a degree in computer science but has a great deal of familiarity with Office and VBA, and who typically writes productivity applications shared amongst his coworkers

All that said, a large portion of my job is taking his cobbled together code and making it production ready. However, the very poor style and cargo-cultism makes this difficult. This is compounded by the fact that he is unwilling to read programming books or allow me to help him refactor his code.

Are there some other strategies for helping someone who is not a professional programmer, never will be a professional programmer write code going forward that is more legible and usable for me to use and interpret?

  • 3
    There seems to be a good question for workplace.stackexchange.com to be hidden in there, but I am not sure the question will be well received in its current form. May 12, 2014 at 14:39
  • 3
    @BartvanIngenSchenau I considered posting it there but I chose here because the issues are very programming specific. I consider this to be (from the help) development methodologies and processes and software engineering management. I'm not asking about general workplace issues, office politics, I'm asking "what software development strategies can I use to work with such a person".
    – durron597
    May 12, 2014 at 14:43
  • 3
    @gnat I think this is not a duplicate thanks to one major difference : in that duplicate, the bad code was already written. Here, the question is how to prevent this bad code to be written in the first place, by someone else.
    – Euphoric
    May 12, 2014 at 14:57
  • 6
    The question is: can you do anything when you are the subordinate in this situation?
    – Philipp
    May 12, 2014 at 15:18
  • 4
    I don't see a problem to be solved here. Are you getting problems from other people in the company because of his low quality of work? Are you missing important deadlines because of the maintenance cost, or is the software constantly misbehaving causing you and or him to be troubled by your users? If none of the above, then I think the low quality work you and your boss are generating is exactly what the business wants and needs, and there's really no problem other than you want a different job. At which point only you can decide how much you want a different job, if it's worth the risk May 12, 2014 at 16:27

4 Answers 4


In looking at your responses in several of the comments I don't know if you realize that what you are experiencing is quite common, particularly when working in specialty fields where it takes domain experts (let's call them the scientist) to figure out how to incorporate and tailor algorithms for problems at hand.

Rather than complain about the scientist and expected them to change, just realize that you shouldn't expect the scientist to care much about "code quality". It is frequently hard to get other software developers to care about "code quality" let alone someone whose main interests lie in the domain and not the programming.

Where you go from here depends largely on the degree of confidence the "scientist" has in your ability to understand their work. If they have confidence that you can understand their code and won't muck it up when you modify things then there usually isn't an issue. They'll rely on your expertise.

However, if the scientist does not want you changing their code then it is highly likely that you haven't "earned" their confidence yet. If that is the case then rather than focusing on fixing the scientist, you should focus on "fixing" yourself. What I mean by that is to take steps towards gaining their confidence. Probably the easiest way to do this is as follows:

As part of your testing process:

  1. Start turning the algorithms into something easier to understand (e.g. diagrams, PDL, math notation)
  2. Learn to understand the algorithms.
  3. Be sure to identify the edge cases.
  4. Ask the scientist if your simplified "alternate" representation is correct
  5. AND MOST IMPORTANTLY identify problems that you found; AND without sounding "accusatory" say something like "I was looking at the algorithm and noticed XYZ is it supposed to do this or is it supposed to do that?". Nothing will gain their confidence better than this bullet.

Once you start finding bugs AND have demonstrated an interest in their area of interest then the odds become much higher that at the very least they'll let you start modifying the code to make it more "professional". Frequently, they won't even feel the need to code up a prototype any longer. They'll just write something up in one of those "alternate" notations that you've taught them (without them even realizing it) and they'll have confidence that you'll know what they mean.

By all means, my first attempt would be to offer some suggestions on how the scientist could best help "communicate" better in order to help you; but it sounds like you've tried that. So the only step that you have control over is what you do. Earn their confidence and almost always the domain expert will be relieved to pass coding off to someone else and not have to worry about all the little details that go into writing code. They'd much rather be focusing on improving algorithms.

Sometimes, all you can do is offer a suggestion and leave it be after that. You won't impress your boss or a senior if you keep harping on something that they've already rejected or decided they don't want to do, even if you are 100% correct. In fact, this will damage a relationship, whether you are the suggestor or suggestee. Just focus on what YOU can do to make your job easier.


When he is really "someone who is not a professional programmer, never will be a professional programmer" as you say and when a large part of your work is really "taking his cobbled together code and making it production ready", it sounds like your two-man team would be more productive when he would leave the programming to you and concentrate on the managerial part of the project.

However, this assumes that you are right. We programmers always tend to disregard code written by other people as much worse than our own. This preconception is really hard to defeat and leads to us underestimating our colleagues. What you consider "cargo cult programming" might be "proven best practices" from his perspective, and what you consider "elegant application of object-oriented patterns" might be "unnecessary overengineering" for him. Hard to tell for me, because I only know your side of the story.

The disdain for other peoples code becomes stronger the more different our programming styles are. In that case that's a positive instinct, because mixing different programming styles in one project makes it very hard to maintain.

When both of you are unable to mimic the style of the other, then you could define clear responsibilities. Make one person responsible for one part of the application and the other person for the other. Define clear interfaces between both modules together, but leave the internal implementation to the one responsible. To make him more aware of bugs in his code, you could write unit-tests for him and point out when his code obviously doesn't behave according to the interface contract you specified together.

Through establishing clear code-ownership you can reach a better coexistence of your different styles. Also, when both of you are responsible for fixing the bugs in their own code, you won't have to navigate each others code often.

  • 3
    I would love to do this. The problem is, if we each work for 40 weeks now, this would turn the division of labor into more like 20 and 60, and he'd have little to do with the rest of his time. Our need for more staff (so that he doesn't have to program) is something we both want, but there are financial issues at the moment.
    – durron597
    May 12, 2014 at 15:33
  • 4
    This is not what we do, but imagine you were working on a project that analyzes DNA. Your boss writes a crappy program that analyzes one small set of data for various things, verifies correctness, and then your job is to run that program on the entire Human Genome Project database. I don't just have clean up style, I also have to improve the algorithm for performance. But his job (the reason he has a salary) is expertise in the "correctness" part, which isn't really a programming issue and I don't have the same expertise.
    – durron597
    May 12, 2014 at 15:59
  • 4
    @durron597: It sounds like he hacks out a rough proof-of-concept and then gets you to make it nice and polished and production-ready. May 12, 2014 at 16:08
  • 4
    @durron597 If he's the domain expert who is able to verify correctness, would he be open to the idea of writing unit tests that would fully specify everything? Basically instead of him prototyping the functionality, you guys would do a form of TDD where he writes the tests to make sure that everything is correct and you do the actual implementation?
    – Evicatos
    May 12, 2014 at 17:08
  • 4
    @durron597 (following a wild hare sparked by one of the comments:) would you be able to write a(n E)DSL which would enable him to more concisely express his logic in a way that wouldn't require a rewrite on your part?
    – paul
    May 12, 2014 at 17:44

You've got to ask yourself: what is your ultimate goal here? 1. to help your boss? 2. to help the company? 3. to help yourself? And before you answer "all of the above", slow down. Your first task is to clearly define your primary objective, because the answer depends on it.

If you goal is to:

  1. Help your boss? Give It Up. He doesn't appear to be asking for it. You said, "He knows his code is bad, but it does what he needs." Well then, end of discussion. Unless and until your boss is dissatisfied with the current situation, he is not going to change, and he will resent your efforts to help him. If at some point in the future he does "feel the pain" of the status quo, hopefully you will have established yourself as a trustworthy mentor and he will know where to come for help.

  2. Help your company? Is the current situation threatening the bottom line? Are deadlines at risk? Is upper management increasing its heat? If not, then Give It Up. (This is essentially the point that Jimmy Hoffa made in his comment to your original post.) If, however, the current situation does in fact represent an unacceptable risk to your department/company, then a change of process is in order. In that case I would suggest that you sit down and outline a different division of labor. The key here is to explain that the time you spend refactoring your boss' code would be better spent writing new code. You say you don't have time writing it all yourself, but that's not what I'm suggesting. You need to figure out how to maximize your respective strengths. Stop thinking of him as a Mort, and think of him as a junior developer with superior domain knowledge. That is a very common working arrangement in the industry, and it would behoove you to learn how to thrive in it. For example, make sure that he knows that you know how essential his expertise is (repeat this step often), and then humbly suggest the following strategy (or something similar) as a quicker path to get his knowledge to the market: (a) break the work into "agile" sprints, (b) collaborate heavily up-front (in each sprint) defining the over-all requirements and architecture. (c) Let him go off and build the prototype to work out all the algorithmic decisions, while you build the infrastructure that you agreed upon in previous step. (d) Implement his algorithms into your structure while he builds tests to verify it. (e) Conduct your V&V together in a peer-programming environment. (e.g., "This test failed; why? algorithmic logic error or coding mistake?"; iterate here).

  3. Help yourself? Be honest here. If all you are doing is complaining that you don't enjoy your job, I suggest you need to spend more time thinking about #2 above. If you don't care about the company AND you don't enjoy your job, start distributing your resume. If you DO care about your company but don't enjoy your job, then focusing on #2 should help on BOTH accounts. But in that case, it is a "win-win" only if it is clear to everyone that your passion genuinely stems from a desire to Help The Team, and not just from a self-centered frustration in your assignment.

  • 1
    Great answer. It's definitely #2, and your description of what to do is similar to what we have discussed in the last few days. We definitely do not communicate enough.
    – durron597
    May 15, 2014 at 22:06
  • I just added one last sentence in the 3rd point. Perhaps the most important of all. Re-read your post and honestly ask yourself if that's the way you are coming across to others.
    – kmote
    May 15, 2014 at 23:19

I'm not sure I will add something to this discussion, but having worked in similar scenarios where an Access violation is hitting at a line with ShowMessage('Hello'); or similar, only to find out that the same line has more code, out of the screen to the right,

I believe that you have two basic options:

  1. Let the code run. If the code is working and doing what it should do, unless your boss is specifically asking you to fix their code, just leave it as it is. That may also lead him to understand that your code looks nicer and leave the work to you (as also pointed by Dunk in his answer).
  2. If you are very determined to make the code professional, build a library / framework that he can use. If there is a pattern on the errors / strategies that you commonly fix, you may be able to wrap those up into a few library files and give it to him as a "base library for the company", which you can also use as a common interface.
  • "Build a library / framework" I've been trying to do that whenever I get free time, but the problem is that project keeps getting pushed off for "immediate short term concerns"
    – durron597
    May 13, 2014 at 14:42
  • 1
    I've been to that place. I had a boss who used to give me a business card of the client, and asked me to "create a website in a couple of days" for this client (without actually having any other information other than the business card). You may want to consider telling him about your plan to prepare a library, and how this will boost your production, so that you can save up some time. May 14, 2014 at 4:38
  • Building a library should start with simple collection of the small programs that you've already written after you fixed just one of his programs.
    – DougM
    May 15, 2014 at 20:21

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