The Workplace Stack Exchange is a question and answer site for members of the workforce navigating the professional setting. It only takes a minute to sign up.
Sign up to join this community
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?
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.
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.
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:
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).
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.
Do I need to do things the way boss asks?
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...
...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.
...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).
...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.
...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.
...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.
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.
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 :)
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."
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.
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.
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.
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.
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:
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.
