1

Over here at the company we have a single lead developer. As we have a mixed working environment, working in 2 different languages. And our lead developer prefers one over the other, he tends to make design choices that make the one language reflect on the other. So that they are "interchangeable"

Recently he made a call to remove something from the project as a whole, which would only have a negative impact for the team I am working in. But does not serve any additional use besides The languages reflecting more to each other.

I as a junior developer objected against this change, as I don't see why a developer would make a change that only creates more work, and negatively impacts the work-flow from there on out. His argument against this was once more, The languages will look more like each other.

I would like to take this problem up with a higher up, but as they don't know the slightest thing of code, I can't really expect them to understand it, even if I do make good arguments regarding pronenesses and maintainability. The would just shove it of as If the lead says so, just do so.

It is not like I am the only other developer that voiced against this change. But to no avail, as our lead developer is quite hard headed. It also doesn't hurt to mention that besides the lead developer, there are only junior developers, as the previous developers got tired of the attitude and left.

How do I present this problem to my and our Lead's superiors so that it is clear that the problem is not just one of a personality clash but that it is creating problems with the team and our ability to deliver a reliable product?

closed as off-topic by IDrinkandIKnowThings, gnat, Richard Says Reinstate Monica, Chris E, JasonJ Sep 23 '16 at 20:29

  • This question does not appear to be about the workplace within the scope defined in the help center.
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    It's a bad fit here too, since the answer is "present a strong technical argument to defend (a) why it matters, and (b) why your approach is actually better. Then shut up and listen carefully to the response. Technical issues aren't the only issues." – keshlam Sep 23 '16 at 17:57
  • This is just extreme. There are a lot similarities but they are different. Why would you even have two projects the do the same thing in different languages. It is so wrong that I don't think logic would help. It would take me like 20% longer to code without enum and it would be double the frustration. Get every to agree to go over his head? – paparazzo Sep 23 '16 at 18:07
  • Why doesn't your lead developer consider php associative arrays? They aren't exactly 1 for 1, bit neither is php closure syntax vs c# lambdas or delegates or a thousand other details. Are you avoiding all of the advantageous features of c# and .NET intentionally? – Craig Sep 24 '16 at 4:29
  • 1
    @DXM - We can not tell you how to change an individuals mind. We can help you provide a reasonable and effective arguement to your superiors. So I have updated your question to reflect that and voted to reopen. – IDrinkandIKnowThings Sep 26 '16 at 14:42
  • 1
    Personal observation - I've seen this type of thing done in several places that used multiple coding languages. The real answer here would be for the lead developer to make a case to completely dump one of them. It generally costs far more for a single company to maintain disparate teams like this. – NotMe Sep 26 '16 at 14:55
12

You have to pick your battles. There's a good chance I wouldn't pick this one.

Yes, the request is silly, ill-founded, and as a developer, it just feels wrong. However, what is the actual cost of this change?

  • It takes some time to implement. You have to remove the enums, obviously. And you may have to add a bit of extra code to do error checking, that wouldn't have been necessary if you had enums. This is obviously a waste of time, but it probably won't add up to much effort unless you have extensive use of enums.
  • The risk of certain kinds of bugs went up...slightly. The enums usefully restrict values so that you don't have to worry about invalid values. This creates safer code...but really, it's only a marginal improvement. These tend to be simple bugs that are easy to avoid. Plenty of languages get by just fine without having enums at all.

So, in most cases, this is a requirement I would probably just put up with. I would raise objections initially (as you already have), but if the team lead stood firm on this requirement, I would simply go with it.

However, if you see a big impact in terms of effort or risk for the code on your particular project, push harder, and make a case that can be understood by non-technical people.

For example, if this meant that you would have to spend a lot of effort redesigning (and possibly introducing bugs) in a stable, mature existing code base, you could make that case in business terms, first to the lead, then to people higher up.

But it has to be a case on the consequences, not merely the fact that you are being asked to follow something other than software development best practice.

  • This would be a good answer on programmers, but not a good workplace answer. It only addresses the specifics of the programming choices made not the dynamics of working with a team. – IDrinkandIKnowThings Sep 23 '16 at 16:21
  • 3
    @Chad Sure, it talks a lot about technical detail, but it talks about it in terms of business costs, making a business case and picking which battles to fight, which are all workplace-oriented advice. – Kaz Sep 23 '16 at 16:36
  • @Kaz - But if you remove the programming specific information the answer becomes completely useless. The answer needs to explain why that business case is important, it is not enough to say what the answer is here, it must explain why it is correct. – IDrinkandIKnowThings Sep 23 '16 at 16:44
  • Unfortunately, this is the best approach. Look at it this way: When you get older, you're going to trade a lot of "dumbest boss/client" stories in conversations. Keep this one in your list. – Wesley Long Sep 23 '16 at 18:13
4

In the workplace, very often managers will make choices that subordinates don't agree with. Sometimes there are no branches of the decision tree that everyone will go along with. But a Technical lead or a manager is paid to make the decisions and the final call is hers or his.

It's important to understand that because there is a 100% chance you will eventually need to implement decisions you don't agree with.

The challenge is how to manage up to get better decisions made so that you have to do fewer things you don't agree with.

The first thing is to be aware of is that you are never going to get a manager to agree with a change you propose if she or he does not respect you professionally.

So your first task is to gain the trust of the manager. You gain that trust by delivering the work with the best quality you can under the particular circumstances.

You gain that trust by letting the manager know when there is a problem headed his way before someone from above asks him or her about it.

You gain that trust by not being a pain to work with (i.e., you do things like timesheets and project management tasks without him having to bug you, you don't embarrass him in from of his peers, subordinates and organizational superiors).

And you gain that trust by supporting his or her decisions. No, that last doesn't mean that you can't disagree, but that once the time for objections is past, you step up and make the decision work. You don't complain about them being his or her back either.

OK suppose you do have your manager's trust. The next part is trickier. You have to be aware of timing when bring up objections. And you have to be careful about your tone of voice and the language you choose to use. No one likes to be told they are stupid and wrong and the decision will become more set in stone if you present your objection in way that makes the manager feel disrespected.

The best time to get in your input is before a decision is made and announced. Now granted, sometimes a decision, like possibly this one, comes as a complete surprise. But when you know that someone is considering methods or you know there is a particular decision point coming up, that is the time to get information to them to help them choose the way you want to them to choose.

After a decision is publicly announced is never the best time to dispute it. If it is just to the team, there is still a chance the decision can be reversed, but if the decision has been announced to Clients, senior managers or to others outside your group, then it is usually best to back off unless the decision is critically wrong. By critically wrong, I mean the decision cannot be implemented without spending a great deal of money or it might cost the company a lot of business. I do not mean it might be inconvenient for you personally.

Now personality type comes into this, too. Some personality types are more amenable to objections than others. I once had a boss who was so rules-based (and one of his rules was that he set the rules) that there was no pushing back on anything no matter how bone-headed. He was a smart guy and I learned a lot from him and he rarely made a truly stupid mistake because he knew his profession in far more depth than I did, but I hated every minute of working with him. If you have that kind of boss, the best you can do is follow his lead until he gets replaced, learn what you don't want to be when you are a manager, and/or move on (follow his lead until you move on though, you can often get a terrific recommendation from this sort of person).

Other personality types are more willing to listen. But you have to know when to catch them. Sometimes the best time to get something you wanted done is after there was a major problem in the very area that you want to change (don't be an "I told you so" person here, that won't help.). Others are best approached only when things are going well. It can help a great deal to read about personality types to understand the best way to approach someone.

It can also help a great deal to read about language use. I have often seen issues where two people were arguing about two completely separate issues and neither one noticed. If your boss isn't hearing you, then read about language styles. This can be particularly true if the two of you are different genders or come from different cultures. (if anyone wants help in understanding the male/female differnt communication styles, I highly recommend: https://www.amazon.com/Talking-Women-Work-Deborah-Tannen/dp/0380717832/ref=pd_bxgy_14_3?ie=UTF8&pd_rd_i=0380717832&pd_rd_r=YBN2YVGRNJMWHTT8KA8B&pd_rd_w=VgumZ&pd_rd_wg=DlFii&psc=1&refRID=YBN2YVGRNJMWHTT8KA8B)

When you do have to object to a particular decision, then you need to present your ideas not only in technical terms, but in business terms. Nothing will get a manager's attention faster than costs (either measurable cost savings with the alternative suggestion or extra costs to implement something you disagree with.) Cost are not all monetary, although leading with those helps. Consider time, risks (risk of introducing new bugs, security risks, risks of losing customers,etc). Learn to do a formal decision analysis. Managers deal better with hard numbers than fuzzy, intangible concepts.

Sometimes you can lead someone to a different decision by simple questioning about the mechanics of implementing the decision. By asking questions that lead them to see the problems, you are not creating a negative by objecting. For instance in your case with the enums, I might have pointed out that we have 237 already in the code and did he want us to redo those or simply refrain from using them in the future. If we do redo them, what QA process do we need to follow? If some of those enums are in a part of the code without unit tests, did he want you to write those tests first? It might take 1500 hours to fix all of those, what priority should we put on fixing them, what should we push to a later sprint to be able to have the time to do that, etc. The key to this technique is to be very sincere. You are trying to get clarity around implementing, not objecting. And you do actually need most of those answers in order to implement. You know you have won when he or she says, "Hold on on that for a bit, I need to think about this some more."

Pick your battles carefully though. You want to concentrate only on the truly critical stuff. If you object to everything, then you will get labeled troublemaker in her or her mind and you won't be listened to when it is important. The more senior you are in the profession and the more trust you have gained, the more things you will able able to steer in the direction you want. I almost always get asked before a decision to give input these days. I worked hard to get to that position, but we hardly ever do anything I seriously object to, now. You will have to work to get to that place as well. But as you start out, truly only pick really big battles to fight.

2

On the surface this is just so silly I don't think logic will prevail.

Why have the same code standards for for two different languages? Why would you need to copy a project from one to the other anyway?

Is this a battle you want to take on? How many developers? Are they all willing to go to management and say this is silly. Even if you win your relationship with you lead will be damaged. If you lose you may lose your job. Try to get the whole team in meeting with your boss (if he will support it).

  • It's not as crazy as it sounds. I've worked on systems where we provided multiple interfaces in different languages which had to be in synch. We were competent so we generated them automatically but it did mean we had to adopt a "lowest common denominator" approach and sacrifice some features of the more advanced languages. – TheMathemagician Sep 27 '16 at 12:39
0

Give him what he wants - a bunch of constants. Build your enums from constants. The constants are "shippable". Presto.

Use this for declarations.

public class myclass {
   public const int xyz = 1;
   public const int abc = 2;
}

Use this throughout the code.

enum mystuff {
    xyzvalue = myclass.xyz,
    abcvalue = myclass.abc,
}

I'll agree with one of the comments. This probably belongs on the Programming SE. But go ahead, give your lead the illusion of control. :) :) :)

  • I'd recommend against this approach. You follow the instructions of the Lead Developer. If you disagree, you try to change his mind, not go rogue. – Wesley Long Sep 23 '16 at 18:05
  • 3
    This isn't going rogue. It's called compromising to meet the needs of the customer. – Xavier J Sep 23 '16 at 18:06
  • Recording engineers do this with so-called producers who insist on tactile contact with the mixing board, even when the producers have no competence with the equipment whatsoever. Give them a knob to tweak. Never mind that it's not actually wired to anything. Everybody goes home happy. – Xavier J Sep 23 '16 at 18:08
  • Yes, I'm VERY familiar with the "Producer Busy Box." - That's not the same thing, here. – Wesley Long Sep 23 '16 at 18:10
  • that is going to cause trouble and would be a CLM for the OP. – Richard Says Reinstate Monica Sep 23 '16 at 18:41
0

If you expect every programming job to make sense and be perfectly like the manuals, you're going to have a pretty short career.

Your manager has asked you to do something.

You suggested a different approach.

Your manager insists on his approach.

All you should do now is to document your different approach, and your agreement to apply the original approach (if everything goes pear-shaped, you can then say 'I told you so'). Once you've done that, in a short email rather than an 80-page thesis, just get your head down and do your job as instructed.

If you don't like it, you should look for another position in a company that suits you better.

0

You are the junior, he's the senior. To someone higher up the food chain, it's plenty clear who has a clue and who hasn't.

If you want to appeal about programming to someone without programming background, you need something that shows you know what you're talking about. That something is certainly not an article that's too long to read, so quoting literature will get you nowhere.

The best thing you can do is get a senior developer to back you up. After all, since you are a junior, there will very likely be several seniors, and a of them are likely reasonable and experienced people. They just lack a junior's enthusiasm to fight over pointless BS like that rule by your boss, but that's something you can provide.

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