65

I'm a junior level programmer in a company. My boss gave me a task to do a job in a particular way, but I think it is too complicated, and also requires some studying. I can do the task in my own way, which requires using a particular open source program.

Should I just do the task the way my boss says, or do it in my own way?

  • 172
    Do not use any outside software without letting your boss have the licensing terms checked. – Patricia Shanahan Apr 27 '17 at 17:45
  • 60
    you may try suggesting it and make sure you are able to justify it – overloading Apr 27 '17 at 17:53
  • Comments are not for extended discussion; this conversation has been moved to chat. – Jane S Apr 29 '17 at 0:33
  • I feel like this question is a bad question as written. Thus the proliferation of low quality answers and flamewars about open source projects in the comments. It needs a lot more detail in key areas to be able to provide a useful answer. – Coxy Apr 29 '17 at 12:12
  • @Coxy I disagree. There are a couple of very useful answers (providing different opinions). Any question with this level of popularity will draw low-quality answers. – Brian McCutchon Apr 29 '17 at 14:20

13 Answers 13

104

Should I just do the things the way boss says, which requires some studying, or do the task my way, which requires using a particular open source program?

I would strongly urge you to use the methodology and technology outlined by your boss. He is more experienced than you, and has more business and technical domain expertise.

Once you get a few projects under your belt, then feel free to offer up suggestions that could make a task quicker to complete. Don't be surprised that when you do, you might be challenged to justify your suggestion from a time to market, initial cost, and total ownership perspective.

  • 12
    I am considering a downvote merely for "Once you get a few projects under your belt" because of how it is applied. If OP were to merely offer suggestions, then a few projects under your belt is completely unnecessary. I cringe at groups that put down new devs so bad that they cannot even make suggestions. Let them suggest; a suggestion is not a decision. Do not let them spend everyone's time suggesting bad ideas all the time, but please do let them suggest. – Aaron May 1 '17 at 16:00
  • There is a bit of a false dichotomy here. Often in situations like this, a easier approach can be used as a testing tool. When this implementation produces different results, then the developer digs into why. This is a great learning exercise for the developer. It also offers an opportunity to demonstrate the alternative and discuss the pros and cons. Discussing a working approach is different than discussing an idea. Obviously time is a concern. If you get bogged down in your 'easy' idea, it should be abandoned, at least in the short term. – JimmyJames May 1 '17 at 16:33
  • @Aaron totally agree. New pair of eyes, new brain, fresh ideas are always nice. Suggestions are good. This guy was hired for a reason. Having a chat about how and why for projects is a great mental exercise. Helps you prove you know your domain. Sometimes gotta cut the discussions short, but I always prefer asking+discussions rather than grumpy mumbling about 'my way is better'. This helps both the boss and the new hire. This isn't working in a fast food place, it's programming. – basher May 4 '17 at 18:45
203

Discuss your approach with the boss. Do not make it sound like your approach is better and you are disregarding his approach.

Boss, I analyzed this task, and I was wondering about the following alternate approach. What do you think about it?

There are two main outcomes, both of which can be beneficial to you:

  • Boss explains to you1 why the approach he suggested is better

    This shows you some part of the bigger picture and a free sneak peak into what goes behind the scenes when bosses make these decisions. As you climb up the corporate ladder, you will be responsible to make these decisions yourself, so these insights would help you later on.

    Your company is doing business, and software development is just a part of that business. Hence, business considerations take precedence over your personal preferences. As a junior developer, you may be focused almost entirely on the software development part, but your boss is responsible to make the correct business decision.

  • Boss realizes that your approach is better

    This is less likely, but not impossible. In this case, not only do you get to do the task your way, but also create a positive impression. The next time this task or something similar has to be done, your boss will remember you as the person who found a better way of doing it2.

Then you should do what the boss says, in either case. However, with the above approach, your boss would see that you are actually thinking about the work you are doing. This is also often an important consideration when deciding on promotions at the junior levels. A junior developer who just does what he is told needs constant supervision and will not be promoted, while someone who persistently tries to contribute and understand how things work can be trusted with greater responsibility.


1 If the boss is unwilling to explain, you can politely ask him, but don't pester him. Sometimes, the boss decides that getting the work done is of utmost importance and convincing a junior employee is very low on his priority list. In that case, just get the job done as he says, and maybe ask questions later when he is more willing to spare some time for the explanation.

2 Unless your boss is a jerk who takes offense to it, in which case you have a much bigger problem, which is out of scope of this question.

22

When you should follow your boss
When your boss gives you explicit instruction on how something should be done, you should do the work the way they describe. Generally they don't go out of their way to outline how something should be done unless they care about the how.

You should especially not 'go rogue' doing your own thing after the boss gives you instruction if that involves using 3rd party libraries. There are usually numerous issues that could arise from using 3rd party software, and as a new developer this is not a good idea. Using 3rd party software (especially without approval) could result in one or more of the following:

  • Stability issues
  • Legal ramifications
  • Violation of company policy with respect to the approval process of adding new libraries to the system.
  • Vulnerabilities or security risks
  • Needing to re-do the work because any of the above were an issue

If you have issues with how the boss is asking you to do the work and are confident that there is a better way, you should present your findings to your boss and get approval before doing work your own way. It is generally frowned upon when new developers demonstrate that they think they know better than the senior engineers and don't take instruction.

When you should take initiative
Once you fully understand the system, and the business needs behind a project and are given the freedom to complete a project without additional instruction or supervision on how the project should be done, you may feel free to do so the way you see fit. Generally newer developers should undergo code-reviews so the senior and mid-level engineers can review the work until everybody is comfortable with the quality of the work being performed. (Really code-reviews should continue and involve everybody, but this is far less often followed and is another discussion for another forum).

  • 13
    Indeed. I've let a number of devs go after repeatedly not following my requests. And I normally don't have time to explain the big picture in enough detail to enable those devs to see and understand the light. A quick "what's the problem with this open source solution?" should get (from a good manager) a 20 second explanation like "that will preclude us from efficiently integrating single sign on in sprint 15" – Brian Leeming Apr 27 '17 at 19:32
  • 12
    @BrianLeeming isn't explaining the big picture to the devs 50% of your job as a manager? With the other 50% being making sure nobody disturbs them while working on it? – Erik Apr 27 '17 at 21:40
  • 4
    To be fair, Erik is right. The team should at least have visibility of the overall picture, if you expect them to get any actual satisfaction from their work. Try to keep them in the loop, @Brian, at least at some level. And, who knows, maybe you'll find that one of them has a bright idea that can make things easier for everybody. Isn't that what they're there for? – Lightness Races with Monica Apr 28 '17 at 0:40
  • 5
    @BrianLeeming why would you hire people who don't care about the goals of the business? They don't sound very productive. – Erik Apr 28 '17 at 12:12
  • 3
    @erik, if hiring were that simple... – Brian Leeming Apr 28 '17 at 13:13
16

Listen to your boss

Junior developers often fail to see the maintainability aspect of proposed solutions. Yes, you might have a whiz bang open source approach to solving the problem, but it doesn't help your boss (or the company) in the long term if you're the only person on the team who knows how to support it. Think about what happens if you go on vacation or get sick or leave. What happens then? It's not your issue, but your boss may catch hell over it.

This is not to kill your innovative spirit, but there's a bigger reality to consider whenever you introduce something new.

  • Yes. And making yourself even frictionally irreplaceable is not a favourable thing to do while there's still a "junior" and while you probably cannot carry the weight of your decisions yet. – rackandboneman Apr 27 '17 at 19:35
  • 3
    It's completely the other way round in my experience. If you write something proprietary, you're much more likely to lose the knowledge of how it works when someone leaves. Open source projects have a community, however small, that you can rely on. – Michael Apr 28 '17 at 8:55
  • 1
    @Michael As someone who was tasked with rewriting an entire module left behind by someone who left, I agree with you completely. He had even left behind decent documentation. We could understand how the code worked, but a few bugfixes was all it took for the pack of cards to fall apart. He probably had a better way in his mind of doing those fixes, but we figured out rewriting it from scratch (with generous reuse of some methods from his code) would be cheaper in the long run. We even jokingly called it the Fermat's Last Module. – Masked Man May 1 '17 at 17:33
11

Do I need to do things the way boss asks?

YES

You always have to do it the way your boss asks.

If you have a solid alternative and your boss is open to input, you may convince them to ask you to do it differently, but you would be still doing it the way your boss asked.

Suppose I am your boss. If I tell you to do A...

  1. ...and you do B, you are a bad employee and I will probably be mad or disappointed at you. I will trust you less, since you do what you please.

  2. ...and you convince me that B is better, then I will ask you to do B and you will do as you are told. I will hold you in high esteem. You both (found a better way to do something) and (did what you were told).

  3. ...and you fail to convince me that B is better, and you do A, I will hold you in better esteem. You proposed an alternative, which could have been better, but accepted the higher orders. I appreciate both.

  4. ...and you fail to convince me that B is better, and you do B... see (1). Probably worse: you can't claim ignorance or good will, since I explicitely told you not to do B.

  5. ...and you fail to convince me that B is better, and you do both to "prove it to me" that it's better... it's a risky move. You would spend more time, maybe unnecessarily, and even if you were right, I could resent your defiance. It REALLY depends on my personality, current mood and your relationship with me. It's risky and I would only advice it if you KNOW your boss and you REALLY THINK it's gonna work ok. Even then, it's risky.

So if you really think your way (B) is better, you should make a really good case for it, enough for your boss to say "Ok, go ahead and try it". Dont be annoying or over-insistent. If you don't get his approval, just leave it. Do it how they say. Earn their trust and respect with solid work and probably the next time they'll be more open to your suggestions.

  • 2
    I really like this answer. I had a manager who told me explicitly and urgently to do something that was damaging. I did it without thinking about it to ill effects. I then apologized because with my expertise I should have immediately warned him but I got caught up in the urgency. To my great surprise, he turned around and apologized to me and told me it was his fault. That was the first, and possibly only time I ever heard him say he was wrong about anything. In other words, he appreciated my following his direct orders even though I should have known better. – adg Apr 29 '17 at 2:43
  • 2
    This advice is pretty terrible. The reason you should listen to your boss is because they have more knowledge or a higher view/better context of a situation. If you know of a better way to do something than your boss, then either you know something your boss doesn't, or your boss knows something that you don't, and it's your responsibility as an employee to bridge the gap. As a manager, the worst employees I've ever had were mindless drones that did exactly what I told them. I'd rather hire someone to think independently, while checking with me on the broader vision. – user1234567890abcdef Apr 29 '17 at 19:21
  • If you have a job where you don't have to think, then fine, follow what your boss says so that you can keep your job. If you actually want to be happy in your work while contributing something bigger than your immediate work, push the envelope and always strive to improve. If your boss is irrational and doesn't want you to do this, do what you have to to get by until you find a better job. – user1234567890abcdef Apr 29 '17 at 19:23
  • 1
    @user1234567890abcdef " If you know of a better way to do something than your boss ... it's your responsibility as an employee to bridge the gap." To me, this answer seems to be saying the same thing. I am sorry I don't understand your concern here. – Masked Man Apr 30 '17 at 16:26
10

Your boss is, well, your boss.

They are literally in charge of what you do. That is their job. It is their purpose for being. They are there to tell you what to do.

Sometimes they may decide they want to listen to your advice, and sometimes they may even decide to take your advice. But they don't have to, because they are your boss.

It is their decision.

This is not hard.

  • Yes and no. No decent boss wants to be a micromanager. The boss is hiring the employee's brain and initiative as well as just their hands. – superluminary Apr 28 '17 at 10:27
  • 2
    @superluminary: Yes, I said that the boss may listen to you and do as you recommend. But the point is that they are the boss. You do what they ultimately instruct. The OP is wondering whether this is optional; it is not. – Lightness Races with Monica Apr 28 '17 at 10:34
  • And if you as the boss don't like their advice, you unleash your dragons on them and melt their face. Right? Simple. :) – Wildcard Apr 29 '17 at 3:24
  • @Wildcard: That could work. – Lightness Races with Monica May 1 '17 at 20:52
2

In a word, yes.

While using an open source program to solve the problem may work in the short term, there's no way of knowing what its status will be in the future. Companies will spend a bit more time to make something on their own so that maintenance of that software is ensured, because it's dealt with in-house.

Also, you may consider that your boss is presenting this task to you as a learning experience. There's nothing wrong with honing skills :)

2

Consider yourself to have a certain budget of social capital that can be used by "defiant" behavior. Even a new junior hire has some of this budget.

However, consider yourself to have a scanty supply of this budget for the foreseeable future. If you overspend, consequences happen, up to and including termination.

In a situation like this, the core question is, "Is this worth pushing my boss that much closer to firing me?"

If the issue is just that your boss has told you to do something a particular way without using open source tools, you really don't want to be squandering your social capital budget on this. It may take longer and require debugging that the open source project already has done, but the correct answer, for an employee who wants to be in the same job a year later, is, "No."

1

As a junior level developer (or as a junior level anything for that matter), it is not your job to reinvent the wheel or to be "creative" - your job is to establish yourself as a trustworthy and credible resource.

While you definitely can ask why your boss wants it done in a certain way, but don't be surprised if you don't get a satisfactory answer (in your opinion).

There's nothing more annoying to a manager than an employee that thinks s/he is smarter than her/his manager. Repeatedly defying your boss is what is known to experts as a "career limiting move" and believe me, people remember those much longer than you can possibly imagine.

  • 5
    "There's nothing more annoying...". I completely disagree. As a manager, it is your job to hire people that are smarter than you. Management and technical skill sets are different and as pointed out in other answers, developers frequently have more knowledge than their managers. – adelphus Apr 28 '17 at 18:04
  • @adelphus True but it's not wise for a junior developer to assume he is smarter than his manager. He says himself that the manager's method would require some studying to implement, so obviously he isn't that familiar with it, and as such I'd argue that he's in no position to decide whether his way is better. – UpAllNight Apr 28 '17 at 20:55
  • There's nothing stupider than one who revels in his stupid belief that everyone else must be smarter. – Wildcard Apr 29 '17 at 3:25
  • @UpAllNight, I want you to implement a web server in assembly language. If implementing that would require some study for you, then obviously you're in no position to decide another way is better. – Wildcard Apr 29 '17 at 3:26
  • The fact is it has nothing to do with "being smarter." It has to do with everyone's responsibility to understand his duties and tasks. And, a group member must insist upon his right to have initiative. If he sees what appears to him to be a better way to accomplish the group's purposes, but it must not be done that way, he has a right to understand why not. – Wildcard Apr 29 '17 at 3:29
1

It will be better if you listen to your boss properly and do program as per instruction.

  • The main reason behind it is that you may not be only single programmer for the project, so if you follow the guideline, that will be good for fellow programmers and the programmers who will work after you.

  • Every company has some special working structure/culture, here I mean the software model. if all programmers follow the same guideline, then it will be easy for all to understand the code of others.

1

If you're a junior developer, then, yes. Your role is baked into your title. Junior developers are brought on to do grunt work. It may sound a bit exploitative, but at the same time, doing the grunt work helps developers understand the code and become familiar with patterns and processes, especially as they relate to how your particular organization utilizes them.

Do things as your boss says to do them, but you can still get creative while coloring within the lines. Look for innovative ways to improve the efficiency, readability, and stability of your code. Make sure it's thoroughly tested, and think of edge-case scenarios to test. Just about any junior developer's code will be reviewed at some point, and if the reviewer consistently sees solid, efficient, fully-tested, and well-documented code, then your opinion will carry much more weight. Eventually, you might be able to suggest new ways of doing things, because you've then demonstrated a good work ethic and solid coding practices. You're also more likely to be promoted into a position with more autonomy at that point, as well.

Remember as well that for better or worse, the programming community is very caste-based. Senior developers do not always take kindly to junior developers thinking they know better, even if they do. Ultimately, you should display respect in all you do. Even if you know a particular developer, your boss, etc. are just flat-out wrong, don't just come out and say that. Instead, approach conflicts from a learning perspective. Ask your boss or whoever (kindly) to explain why a thing should be done the way they say it should, so you can truly understand. You can often begin conversations in this way and potentially pitch your ideas in a more relaxed manner, where your boss doesn't hear "you're wrong" as much as "let's work together to figure out the best way".

Finally, don't get cocky. All developers of every level of experience always think they're rockstars. It's a side effect of what we do, as the act of creation makes one feel god-like. The simple truth, though, is that there's always something new to learn and always areas where you can improve. I've been programming the majority of my life, and still learn new things every day, still have head-smacking moments of stupidity every day. That's fine. That's normal. The danger comes when you think you know everything, because then you're unteachable.

0

Yes, I have been down this road so many times, your boss will hopefully have oversight of the whole picture. I have lost count of the times I could do things quicker and more efficiently only to be told later about a dependency/feature that completely changes the game. Follow the procedure set out and afterwards, if appropriate, suggest improvement/feedback.

0

As others have said, the short answer is "yes". Do what your boss told you to do.

You may think that your way is "better", but your boss's definition of better might be different from yours. If you're a junior programmer, then, generally your boss will have much broader knowledge and experience than you do. For example, he will know about things like:

  1. What has been tried before at the company, and why some things worked and others failed. The causes of failure are often not technical; they might be more related to staff expertise, willingness to invest, organisational structure, or even internal politics.
  2. What future projects are dependent on the current one.
  3. The company's strategic plan; specifically the company's vision of what they want to be known for.
  4. What attributes customers value in your products
  5. What kinds of things can be explained by your Sales/Marketing people (if any), and therefore used to sell the product.
  6. The legal implications of doing things one way versus another.
  7. The broad economic/financial impacts of doing things one way versus another.
  8. The intended life-span of the code you're writing.
  9. Plans for maintaining/enhancing it.

In an ideal world, your manager would explain all of these things to you, so that you know the full context of the work you're doing. But not all managers have the time/inclination to do that. You can push for these explanations, but stop pushing if you sense any annoyance. Without these explanations, you can't say which approach is "better", so just do what your boss told you to do.

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