This question is as straightforward as it sounds. Do I have the right to demand that he stay out of my projects due to fear he'll not know what he's doing?

He basically googles things and tries them out. This sounds like what I went through in my beginning bootcamp days. I now have way more expertise obviously.

  • 9
    Why does he want to code? Commented Aug 29, 2019 at 20:18
  • I don't know why he wants to code, but it sounds like I have no power to manage my own projects. This would be ideal, save he's responsible for telling a teams when out tech stuff will roll out, so even if he has a dummy system, he would just roll something out without me knowing what he did. It is like having a programmer that doesn't need to be held accountable with versions control.
    – Rose Dern
    Commented Aug 29, 2019 at 20:42
  • 2
    @JCrosby you should post that as an answer, so we can evaluate it. Comments are not for extended answers/discussions Commented Aug 29, 2019 at 21:03
  • 1
    what exactly do you want to happen? what is the current problem? Commented Aug 29, 2019 at 21:04
  • @RoseDern Have you asked him why he wants to code? Because it makes a difference to the answer whether he wants to learn how (so he can manage coders better) or wants to help with development (because he doesn't have enough other stuff to do) or thinks he is actually a better coder than you are. Commented Aug 30, 2019 at 18:53

5 Answers 5


A healthy software development lifecycle will mitigate the pain of an unsupervised junior developer (which is what it sounds like your boss is) trying things out for the first time.

An incomplete list of crucially important things to have are:

  • Source control
  • Unit tests
  • Integration tests
  • Automated functional tests
  • A continuous integration server that builds the project from source control and runs the above tests
  • Development performed on source control branches, and not merged to the main branch until it has been tested and reviewed.

The main theme there is testing. I strongly suggest you review your development process and start doing more of it. When you've got it to a reasonable level, you won't be bothered about your boss contributing to the project - the tests will tell you if anything has broken.

The objection to including more testing in your lifecycle is going to be "we don't have time for that". The reason I'm sure you don't have a sufficient level of testing at the moment is that you're worried about one developer messing things up in ways that are hard to find and fix. Testing and reviewing will drastically decrease this risk, and is really, really important to the stability and reputation of the project. You don't have time not to test.

my projects

A really important lesson to learn in professional software development is that they're not actually "your projects" at all. They belong to the company.

  • This was helpful. While we do test ourselves, we don't have good debug logs.
    – Rose Dern
    Commented Aug 29, 2019 at 21:02
  • I think my final thoughts here would be, technology managers can be junior developers. Stepping up testing and integration tests are a weak point, which could help me deal with this dynamic within the working relationship. If that doesn't make things easier It's time for a new job.
    – Rose Dern
    Commented Aug 29, 2019 at 21:24
  • 3
    "technology managers can be junior developers" yup. There seems to be a common misconception among technical professionals that a manager should be the person who has the best technical skills. Management is a completely different skillset. Being great technically doesn't translate into any sort of management skill, and being able to manage technical people well doesn't require knowing more than them. Of course there's a select few leaders who are strong in both areas, but they're few and far between.
    – Player One
    Commented Aug 29, 2019 at 22:04
  • Indeed, version control is a key part of this, but something not getting its own sufficiently independent bullet point and explanation in your list is code review. It is entirely possible to have irrecoverably horrible, absurdly unwise code that meets all your automated checks. In fact the truly hard problem of programming is not coming up with something that works but deciding what solution is actually wise. Commented Aug 30, 2019 at 13:41
  • Stepping up tests and automation is easier said than done, especially for a developer with no control over priorities and a boss that sounds like he wouldn't understand the technical side of things well enough to prioritize tech debt.
    – b15
    Commented Aug 30, 2019 at 18:05

Not a programmer, but I had a boss (I work in Supply Chain, Purchasing) who oversaw, purchasing, logistics, customs and internal transfers (basically our internal supply chain). He wanted to learn how to purchase. So what we did was gave him a "dummy" system (complete with the real reports) and let him fiddle and he then worked out the min/max, PO amounts, etc. and sent us his work to see if he could do it. (He did have a good reason to want to learn the basics after never doing it in his almost 30yrs in logistics). Maybe something like this would work for you


Do I have the right to demand that he stay out of my projects due to fear he'll not know what he's doing?

You could ask your boss that (which would be a bad idea) but at the end your manager is... well, your manager, so they can involve themselves as much as they want in the projects they give you.

You say that you "fear he'll not know what he's doing", but that is speculation; it does not guarantee that your boss will fail. Chances are that your boss, although not technical, may know their way around code better than you assume.

For example, my boss (the CEO, not programmer by profession) sometimes comes to me with some code snippets or in some cases links to SO or some blog. Quite some of the things my boss showed me were beneficial to the project we were on.

Try to see what approaches or solutions your boss comes up with, test and judge them (best case some of them work perfectly), and only after that proceed to propose and show a better alternative.

  • Well he's building things that I have no idea how they work in Salesforce, which already break ( this isn't programming ) now he's going into the Apex a little (the programming stuff) ....based on history...he shouldn't be doing that. I don't think he trusts me, but this is a case of someone who can't code hiring a coder. I think there will always be a little 'are you really doing anything' mentality going on.
    – Rose Dern
    Commented Aug 29, 2019 at 20:44
  • @RoseDern btw, I think is valuable to mention that it seems we have a Salesforce SE site :)
    – DarkCygnus
    Commented Aug 29, 2019 at 20:45
  • @RoseDern are you new or recent to this job? Seems to me that, based on your comment, perhaps you should put yourself up-to-speed with Salesforce if you are going to be using that tool (or well propose an alternative)
    – DarkCygnus
    Commented Aug 29, 2019 at 20:46
  • I've been working in Saleforce for 2 years now. Our workplace is extremely fast-paced and everything I learned about admin I learned on the job. He didn't train me. Apex I understand more because I come from a programming background. Flow builder I don't understand at all. It just feels like I need to ask for time to learn this tool instead of helping him fix things he's built in it, but it feels like he just wants to keep going in an making fixes to things that run off Apex. Is this bad management or am I going to see this everywhere in technology?
    – Rose Dern
    Commented Aug 29, 2019 at 20:50
  • @RoseDern I mean, how long have you been on this job. Perhaps you started recently and your boss is still not used to delegate the Salesforce stuff to you? Perhaps in this case he is micromanaging a bit, but it's hart to tell if you are going to see this in every other tech you use.
    – DarkCygnus
    Commented Aug 29, 2019 at 21:04

If your boss or manager wants to do some programming, there is no reason to try to stop them.

If they want to do some programming, and expect it to go into the company's products or production code, and if it is your responsibility that your products or production code are of high quality, then their code must be reviewed, and rejected if it has problems, until these problems are fixed. Just like your own code, or anyone else's code. And with the same quality requirements for acceptance.

Now if you have a boss or manager who thinks a bit of programming can't be that difficult, and his code should be put into production, no questions asked, then you have an idiot as a boss or manager. If it's a manager you might be able to do something about it. If it's the boss, analyse their code, figure out what visible bugs it will cause, and ask QA politely to check for all these bugs and report them, assigned to the boss. You can then hope that this will be educational enough. Otherwise, find a new job before the company goes under.


If you're looking for assurances that you're entitled to tell you boss what to do because it's your domain and it's his problem you're going to be disappointed. He's putting you in an awkward position and there's no easy way out for you.

If you have a mature development team with proper testing, code reviews and automation then you're somewhat protected from what is essentially a junior developer wreaking havoc but that doesn't sound like the case.

Again I don't know you or your boss' titles or the structure of your team/company but if this happened to me I would start looking for a new job. What he's doing forces a conflict of interest on you and is obviously inappropriate. If he's a manager (you called him your boss so I'm assuming he is) then this screams incompetence, and being your manager, he's the most important person to your success and happiness at the company. Not a good situation.

You must log in to answer this question.

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