Background of my working environment

My manager has no background or understanding of computers or software whatsoever. It is highly likely he hasn't seen code in any form (not even from a physical distance of 10 feet or less) in his life.

There is no one who understands the complexity of what I am asked to implement. To the point that if I semi-hardcode no one would know.

On Joel's test we score an unbelievable score 0.

The problems

  • The manager and at times other "senior" keep changing the requirement specification. Changes which, if good engineering be done and not patchy "fixes", require change in the underlying design.
  • There is absolutely no one who looks at code (probably because no one knows how to, or even if it should be done) which means no one will ever be able to:
    • Appreciate the complexity of the problem or the elegance of the solution.
    • Suggest improvement to the approach.
    • Appreciate the quality of the code.
    • Point out where the code can be improved.
  • A lot of jargon is used which makes sense grammatically but fails to make any sense any other way.
  • Doesn't feel, behave or work like a software company.

The question

What should be done? Especially regarding there being no one who would point out improvements in my code.


To answer HLGEM's (and possibly others) question about what I've done to try and fix it. I offered to set up Redmine and introduce source control to everyone. I said I would recommend distributed (git or mercurial) but will also talk about centralized ones and let the team decide. Response was that things are being done and will be done within weeks. Haven't seen that nor am I aware if other parts of the company use it.

  • 36
    to preemt the obvious answer: RUN!!
    – keppla
    Aug 31, 2011 at 10:09
  • 3
    Unless there is something major you are not telling us start looking for a new job.
    – Zachary K
    Aug 31, 2011 at 10:12
  • 11
    "The manager and at times other "senior" keep changing the requirement specification." Well, having a spec would score you a 1 on Joel's test. :P Aug 31, 2011 at 10:40
  • 11
    No organization scores less than 2 on the Joel Test purely because of non-technical managers. There are a number of things you and other technical members of the team can do without input from non-technical managers to boost your score. You have no excuse to blame that solely on the manager.
    – maple_shaft
    Aug 31, 2011 at 10:48
  • 6
    Sounds like you have the sales team as software management too, I sympathise.
    – wildpeaks
    Aug 31, 2011 at 12:30

10 Answers 10


The short version:


The somewhat longer version:

If the manager doesn't know how to run a project, and if the senior goes along with it, then you have next to no chance of fixing things.

In order to manage software projects, a manager does need to understand something about software. If managers don't, they need to learn first. What are your chances you could persuade your management and your senior(s) that they got it all wrong? What are the chances you will teach them something?

I have been in a similar situation once (only there was no senior). I quit after a terrible year, and never looked back (except in disgust).

  • 3
    +1 for this quote: "If the manager doesn't know how to run a program, and if the senior goes along with it, then you have next to no chance of fixing things."
    – maple_shaft
    Aug 31, 2011 at 11:15

...keep changing the requirement specification. Changes which, if good engineering be done and not patchy "fixes", require change in the underlying design.

Sounds like the real world. This happens all the time, everywhere. Yes it sucks, but it's bearable with some sort of agile attitude. Besides, one measure of software goodness is its malleability. Take it as a challenge.

A lot of jargon is used which makes sense grammatically but fails to make any sense any other way.

Again, doesn't sound so unfamiliar ;-)

There is no one who understands the complexity of what I am asked to implement.

Not even you? If you do understand that, then there's one person in the mirror who does understand that. So your responsibility of your company's well-being is probably heavier than your formal title suggests. If you do understand the issues and your manager doesn't, then it's your responsibility to make things clear to the management so that they can properly direct the company. It might be reasonable to assume that your nearest managers should be technically competent (not necessarily as competent as you - while they're managers, you're the expert - but at least a tiny bit competent), but if they obviously aren't and you could help them, why don't you?

A simple escapist solution is to switch company. But as an another option, consider implementing Joel test's items. Although items from 5 on require more co-operation with the management, items 1-4 are such that you could just set them up without asking anyone.

That said, no one here at SE can know your exact situation. It's possible that you're in a company crowded by incompetent jerks, and making something good out of such a mess could be too much for anyone. You must assess the situation yourself.

  • What about someone point out my wrongs? Helping me improve and learn. Aug 31, 2011 at 10:27
  • 4
    @Jungle Hunter: It would of course be easier to be in a company where everything has been readily set up, everyone is already following every imaginable best practice etc. so that you could just be the apprentice and imitate others. But you could also improve and learn a lot by taking the responsibility and being yourself active in improving your company. Improving and learning is ultimately in your own hands. Other people can help, but your boss doesn't have to be one of them. Aug 31, 2011 at 10:33
  • Yeah, you are right. I'm trying to improve but my efforts I think are being seen more of complain than attempt to improve. Honestly my efforts are both, but let's see if I can get them to see the second half - attempt to improve. Aug 31, 2011 at 11:43
  • @Jungle Hunter: I see, the line between complaining and improving can be fuzzy. But it never hurts to lean toward the constructive side. Aug 31, 2011 at 11:57
  • 4
    @Joonas: I have been in companies where I introduced VCS, code reviews, gave C++ seminars, and whatnot, to improve code quality. And I have been in a company pretty much as the OP describes. If it's a hopeless case, you gotta admit defeat and look for a job where your struggling is rewarded by allowing you to succeed.
    – sbi
    Aug 31, 2011 at 14:21

You say in one of the comments that this is your first job. Managers often aren't technical anywhere except a dedicated software shop in my experience. This is part of life, just get used to that.

You cry and whine because there is no one to appreciate the elegance of your solutions. The real problem here isn't that there is no one to appreciate the elegance of your solutions, but that there is no one to teach you that your solutions aren't nearly as good as you think they are. Virtually all new programmers overestimate their actual skills. With no mentor, there is no one to help you to better practices. If there is no one there to mentor you, then join local user groups, actively participate, and get someone there to mentor you. Even better, that will help you find a better job eventually.

You score a zero on the Joel test? If you are the only coder (and it sounds from what you wrote that you are) they why aren't you using source control? What is preventing you? If you aren't the only coder, why is there no one who can do code reviews? All our devs do code review, it isn't a management function especially when the managers are non-technical.

Requirements change in pretty much all places. Business needs change continually and non-programmers often can't visualize what the program will do until they ee something. Then they realize it isn't what they need. That's why Agile came into being really because the older methods were not handling that change well.

Set up bug tracking even if the management doesn't want to enter the data themselves. Be responsible for entering new bug/features as someone mentions them to you. It really helps to be able to tell the manager when he wants a change that you have been assigned 27 other things and here is the list, which one do you want me to move down the priority list to accomodate this new change. It will help at review time because you will be able to count up the number of bug fixes and features you implemented. If everyone isn't using it, then at least you can for your own work. If they won't let you install any software then use an Excel spreadsheet. Take some initiative. Once you can show results, others will be more interested. If you think there is too much work for one person, the bug tracker will help you prove it.

Do not provde polished looking demos! Demos should look as if they are scribbled in pen on a piece of paper. The more polished the interface looks the more the non-technical person thinks it is finished.

Even though no one would know if you don't follow best practices and semi_hard code for instance, you will know and you will get into sloppy, bad habits. That will not serve you well in your next job. So do things as close to the right way that you possibly can under the circumstances. Make sure to write tests (just consider this as part of the development time and put the time to do it in any estimates you give managment even if you don't specifically say that is part of the estimate) and use those test to makes sure later changes don't break something else.

You need to view this as a priceless opportunity to grow and improve. You have more freedom in the actual coding than many people have at that stage of your career. So consider this an opportunity to create a portfolio of successful implemented projects. When you do go looking for that next job, being able to point out such accomplishments as institutited source control, instituted bug tracking, created X number of successful project implementations, etc, will make you stand out from the rest.

You also have a great opportunity here to learn how to manage expectations upward. This is askill that will come in handy the rest of your career. You have nothing to lose in trying to do this here, things are already not good. But you can learn the political skills that will help you in better places later. Learn to do a cost-benefit analysis. Learn to undersatnd the business domain so that you can be convincing when you talk to them. Learn to talk in terms of benfits to the company and profit. Do estimations for every task you are assigned and even if they don't match waht management is giving you, keep records of what you estimated and what it actually took to improve your own ability to estimate work. Once you can show that your estimates historically have been more accurate than managment's, they will be more likely to listen when you tell them the estimate is too low. But you have to build a track record first of both more acfcurate estimates and most importantly, ability to deliver the projects and make them work. Again this is a good skill to have as you move up in your career.

Above all don't be passive and expect improvement to come from above.

  • 1
    This answer has very useful parts. And some things I feel are incorrect about understanding my situation. Like, I mention both cases, no one to appreciate when it's good. No one to point out when I've got it wrong. I use source control, but in a team of 2-3 no one else does. Code, when is shared is shared using pendrives and using Airdrop. If you were reading the comment I think I've also mentioned I've Redmine setup on my laptop which ends up being used only by me. And same with git. Tried to implement these for everyone. My level, fresh out of college. Senior is supposed to code but doesn't. Aug 31, 2011 at 14:04
  • I'll take the advice about building a track-record. I'll remember I've more freedom at my stage than generally speaking. I could learn to manage expectations and other political and soft skills. Aug 31, 2011 at 14:10
  • 3
    Stop giving code to them on pendrives. If they want your code, tell them it's in source control and show them how to use it.
    – Hugo
    Sep 5, 2011 at 5:36
  • 1
    @JungleHunter When they ask for your code, tell them that your halfway through a change that won't run, but they can get the last stable version from source control. Nov 22, 2011 at 3:00
  • 1
    @HLGEM "You cry and whine"? Much too harsh, downvoting for that alone.
    – Ben H
    Mar 13, 2014 at 18:20

If I were you, I would try to find another job. Why? I think you know that, unfortunately, your manager is, well, "not good". You should try to work some stuff out with your manager though.

If you do not want to leave, and/or you're not going to talk to anyone, then you're going to have to find something yourself. If nobody in the company knows about your code, how is your manager supposed to know you meet the requirements? Just saying.

  • He just looks at a demo. Says, let's change this to this way and that to that way. And then there's a flood of jargons. Aug 31, 2011 at 10:16
  • 2
    @Jungle, I wouldn't put hardly any work into demos then since they are bound to change wildly once he sees them. He sounds like a visual person first and foremost. Have you tried drawing up screen shots of different use cases for him? This can be a lot easier to put together than functional prototypes.
    – maple_shaft
    Aug 31, 2011 at 11:18
  • @maple_shaft: I think that's an excellent idea. Aug 31, 2011 at 11:38
  • 1
    @maple_shaft: Or maybe instead of delivering much ahead of time, delivery just towards the end. ;) Aug 31, 2011 at 11:59
  • 1
    Job advice from a middle schooler...
    – user7007
    Nov 8, 2011 at 3:01

Talk to your manager and to the seniors about this. Explain your issues and suggest solutions. Prepare the talk a bit so you know the general message you want to convey.

After the talk, give it some time. See if things change or not. If they don't, try to implement changes yourself and show to the manager and seniors the positive results of your changes.

If the talk doesn't help and your changes are dismissed, you have to evaluate for yourself how much you like to work at that place. Yes, the work might be bad, but maybe the pay is good and you only have a commute of 5 minutes? Do the positive aspects of your job outweigh the negative? I they don't, I'd start looking for a new job.

  • 1
    I talked. I offered to set up a ticketing system, a introduce version control but he doesn't care. Or understand. Or both. I've asked talked to him about having a reliable spec and he agrees. Changes it nonetheless. He's not data driven. (Oh and removed the emphasis on text from my question.) Aug 31, 2011 at 10:13
  • 2
    @Jungle: Then run ASAP.
    – sbi
    Aug 31, 2011 at 11:00
  • 1
    I agree with sbi, if you hadn't of asked already to get shot down you could have legitimately just went out and done this on your own. You have already lost the room and if I were in your situation I would start looking.
    – maple_shaft
    Aug 31, 2011 at 11:14

Your problem is that ticketing systems and version control are TECHNICAL matters and you should be doing this regardless of the input of a non-technical manager. This should be assumed as a best practice technically and if they don't have this set up then you should take it upon yourself to make this happen.

You can't expect a non-technical manager to understand the benefits of defect tracking, source control and continuous integration. This is why they are non-technical, they are not supposed to know or care about that, they are domain and business knowledge experts. The only thing they should be providing is high level direction and requirements.

I have a non-technical manager as well and was able to increase the Joel Test score from a 4 to an 8 just because I went and did them and didn't ask for permission.

Your group needs a strong technical leader and nobody has stepped up to the plate.

Check out http://community.rallydev.com/ they have a community edition that does an excellent job of Agile project management and Defect tracking. That alone will bump up your Joel score and will cost you NO server space or time at all to set up.

  • Yes! That's I think the major issue. We don't have a strong technical leader. Aug 31, 2011 at 16:42

If this is a small shop where you and the other "senior" are basically the only people coding, then it actually might be your responsibility to indicate to the manager what needs to be done to satisfy the "Joel Test".

Changes in requirements will always be there, and your job is to embrace them, which is one of base principles of agile development:

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

But adapting to changing requirements means following other agile principles as well. At management level, this means manager must be able to transparently present to the customer that all such changes come with a cost: either the project's scope must be changed to satisfy deadlines, or deadlines must be shifted (the latter not being recommended).

If this is a sort of a project where your manager is the one who comes up with all the requirements, then you should act like he/she is your agile customer, and explain the same thing to them (scope <--> deadline compromises).

But at the developer's level in a small company, I would say that it is your responsibility is to ensure that coding part conforms to agile recommendations.

These are some steps you absolutely need to do, and probably you will need to do them yourself:

  • you must have a version control system (takes one day to set it up for a small team)
  • you must have build scripts to ensure that you can make releases often (pretty quick to set up also)
  • you must use automated unit tests (this is a way of coding, and it dictates your entire design radically, so it might be difficult to add them in the middle of a tightly coupled project)
  • you could also set up a continuous integration system to ensure automated builds and tests, as well as functional and GUI tests (which are a bit harder to write)

Remember that you can have a SVN repository locally on your own machine. A simple TODO list might serve as a poor-man's bug tracking system (a bit extreme, but hey). And there is no excuse for not having build scripts.

Also, before making any statements about scope/deadline compromises, someone also needs to make predictions about how much time a certain feature will take. This is usually done in "ideal days" in agile world, which means you should do your best to predict the relative effort of each feature, and then use your actual coding speed to see how well you predicted (and scale the "curve" accordingly).

  • For "customer's competitive advantage" is the key. Later today I asked him about why he does this, says, to impress the client. :| Aug 31, 2011 at 16:09
  • I have git/mercurial in place for myself. But I do the testing manually right now. I should look into automated unit tests. Aug 31, 2011 at 16:19

I think there are missing layers of responsibility in your team. There should be a project manager, systems analyst, business analyst and developers. The Project Manager role is responsible for defining and enforcing the customer-project communication strategy (among other tasks).

Managers are not required to understand code or complexities. The need to understand, resources, cost and risk.

Source code versions, code quality, complexity, etc. are either the PM responsibility or the Senior Developer's.

Solution is to:

1-Define the project team structure and their responsibilities

2-Educate the manager in cases of software failures caused to bad management - Stay away from technical details. You can find some examples by googling.

  • "Stay away from technical details." I will try to resist. ;) Thanks for pointing that out. Aug 31, 2011 at 12:01

Especially regarding there being no one who would point out improvements in my code.

Couldn't you try to set up code reviews so that there are people looking at the code? Are there conventions and standards that would help give the code some structure? This is presuming you aren't the only developer there of course.

While you are likely in a less than great place, does it look like it is working in the end? Are projects getting done and things are moving forward? Are things getting done? The Duct Tape Programmer would be the Joel article that you may want to read.

  • I've been thinking of getting my team changed to one that does have people who can look at my code. Or try to get in touch with the folks there to review my code. Like I said in the questions, right now there's no one who can do that. Aug 31, 2011 at 16:13

Option 1 - tell them 'with all the changes you are making to this project, by the time we deploy it, the system will run very slowly' or 'the customer won't be able to figure it out'. Your managers don't care about spaghetti code but they do care about customer. Pitch the problem to them in terms of what they comprehend, not in terms of code writing.

Option 2 - give them what they want. When they complain about something you say 'but that's what you asked for'

  • Before I "run" I'm going to do exactly that. If they want change I'll let them know it's not a minor change here and there so it'll take so much more time. When the customer doesn't sound happy, they'll have nothing to complain because I gave them what they wanted. Sep 5, 2011 at 3:00
  • @jungle hunter - Not everyone has the option of quitting their job, sometimes you have to transcend the situation. I've found the best way to handle craziness is to turn it back on the crazy people. Only the very crazy can argue against their own craziness. good luck.
    – jqa
    Sep 6, 2011 at 16:07

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