Should I convince a recently recruited colleague to use the technical tools everyone else use?





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty{ margin-bottom:0;
}






up vote
0
down vote

favorite












I've recruited a junior profile, recently.



So far, so good, tenacious, learning and willing to stick the hours to do so.



However, one thing is a bit irritating to me and the other members of my team : He doesn't want to use the tools that all of us, use and that have been defined by the sysadmin.



All of our workstation are in Linux and we all use zsh. However, he is very insistent on using some new bash, saying he feels more comfortable with it. The issue is that when we have code reviews, the tools he is using are not configured properly and we waste precious time, retrieving info we should have at hand.



And there are a few other things that he is doing his way, instead of doing the team's way like using DuckDuckGo instead of using Google, to search for technical knowledge.



The issue is that by using these tools, we are often wasting time when retrieving info the name of the branch we are using in term of development, info that are available on my zsh and the zsh of my other team members.



The other issue is that he is not proficient with the tools he is using.



As my team is new and our company small, there is no real procedure on which tools everyone should use. Everyone use the tools he wants.



My questions are a bit sequential:




  • Should I ask my junior profile, to abide with our way of working? I'm not really fond of imposing things but in the same time, this is work where we should have the same environment for everyone to gain efficiency, instead of originality. It is also a way to say that you are part of the team, not some loose spirit who works his own way.



  • In a bigger company, if someone wants to use a tool, there would be proposals for new tools and discussion to implement it. As a smaller company, we have no procedures, everyone wants to use the tools he wants to use.



    Should I define some basic procedure with our sysadmin and ask my colleagues to submit him tools ideas and let the sysadmin, do some optimisation before making it available to our colleagues?




Thanks





Update



Many thanks for your feedback.



After reading all your answers and comments, Gnasher, Fattie, Brandin, Joe , Simon and Emil, I think that what we , as a team, need to have a common work framework with common tools , when working together in particular context.



When we are doing peer code reviewing for example, we need to have the same windows, the same shell. It makes the collaborative work easier.



However, when you are on your own, you are free to use whatever tools you want to use.










share|improve this question
























  • Comments are not for extended discussion; this conversation has been moved to chat.
    – Snow
    2 days ago

















up vote
0
down vote

favorite












I've recruited a junior profile, recently.



So far, so good, tenacious, learning and willing to stick the hours to do so.



However, one thing is a bit irritating to me and the other members of my team : He doesn't want to use the tools that all of us, use and that have been defined by the sysadmin.



All of our workstation are in Linux and we all use zsh. However, he is very insistent on using some new bash, saying he feels more comfortable with it. The issue is that when we have code reviews, the tools he is using are not configured properly and we waste precious time, retrieving info we should have at hand.



And there are a few other things that he is doing his way, instead of doing the team's way like using DuckDuckGo instead of using Google, to search for technical knowledge.



The issue is that by using these tools, we are often wasting time when retrieving info the name of the branch we are using in term of development, info that are available on my zsh and the zsh of my other team members.



The other issue is that he is not proficient with the tools he is using.



As my team is new and our company small, there is no real procedure on which tools everyone should use. Everyone use the tools he wants.



My questions are a bit sequential:




  • Should I ask my junior profile, to abide with our way of working? I'm not really fond of imposing things but in the same time, this is work where we should have the same environment for everyone to gain efficiency, instead of originality. It is also a way to say that you are part of the team, not some loose spirit who works his own way.



  • In a bigger company, if someone wants to use a tool, there would be proposals for new tools and discussion to implement it. As a smaller company, we have no procedures, everyone wants to use the tools he wants to use.



    Should I define some basic procedure with our sysadmin and ask my colleagues to submit him tools ideas and let the sysadmin, do some optimisation before making it available to our colleagues?




Thanks





Update



Many thanks for your feedback.



After reading all your answers and comments, Gnasher, Fattie, Brandin, Joe , Simon and Emil, I think that what we , as a team, need to have a common work framework with common tools , when working together in particular context.



When we are doing peer code reviewing for example, we need to have the same windows, the same shell. It makes the collaborative work easier.



However, when you are on your own, you are free to use whatever tools you want to use.










share|improve this question
























  • Comments are not for extended discussion; this conversation has been moved to chat.
    – Snow
    2 days ago













up vote
0
down vote

favorite









up vote
0
down vote

favorite











I've recruited a junior profile, recently.



So far, so good, tenacious, learning and willing to stick the hours to do so.



However, one thing is a bit irritating to me and the other members of my team : He doesn't want to use the tools that all of us, use and that have been defined by the sysadmin.



All of our workstation are in Linux and we all use zsh. However, he is very insistent on using some new bash, saying he feels more comfortable with it. The issue is that when we have code reviews, the tools he is using are not configured properly and we waste precious time, retrieving info we should have at hand.



And there are a few other things that he is doing his way, instead of doing the team's way like using DuckDuckGo instead of using Google, to search for technical knowledge.



The issue is that by using these tools, we are often wasting time when retrieving info the name of the branch we are using in term of development, info that are available on my zsh and the zsh of my other team members.



The other issue is that he is not proficient with the tools he is using.



As my team is new and our company small, there is no real procedure on which tools everyone should use. Everyone use the tools he wants.



My questions are a bit sequential:




  • Should I ask my junior profile, to abide with our way of working? I'm not really fond of imposing things but in the same time, this is work where we should have the same environment for everyone to gain efficiency, instead of originality. It is also a way to say that you are part of the team, not some loose spirit who works his own way.



  • In a bigger company, if someone wants to use a tool, there would be proposals for new tools and discussion to implement it. As a smaller company, we have no procedures, everyone wants to use the tools he wants to use.



    Should I define some basic procedure with our sysadmin and ask my colleagues to submit him tools ideas and let the sysadmin, do some optimisation before making it available to our colleagues?




Thanks





Update



Many thanks for your feedback.



After reading all your answers and comments, Gnasher, Fattie, Brandin, Joe , Simon and Emil, I think that what we , as a team, need to have a common work framework with common tools , when working together in particular context.



When we are doing peer code reviewing for example, we need to have the same windows, the same shell. It makes the collaborative work easier.



However, when you are on your own, you are free to use whatever tools you want to use.










share|improve this question















I've recruited a junior profile, recently.



So far, so good, tenacious, learning and willing to stick the hours to do so.



However, one thing is a bit irritating to me and the other members of my team : He doesn't want to use the tools that all of us, use and that have been defined by the sysadmin.



All of our workstation are in Linux and we all use zsh. However, he is very insistent on using some new bash, saying he feels more comfortable with it. The issue is that when we have code reviews, the tools he is using are not configured properly and we waste precious time, retrieving info we should have at hand.



And there are a few other things that he is doing his way, instead of doing the team's way like using DuckDuckGo instead of using Google, to search for technical knowledge.



The issue is that by using these tools, we are often wasting time when retrieving info the name of the branch we are using in term of development, info that are available on my zsh and the zsh of my other team members.



The other issue is that he is not proficient with the tools he is using.



As my team is new and our company small, there is no real procedure on which tools everyone should use. Everyone use the tools he wants.



My questions are a bit sequential:




  • Should I ask my junior profile, to abide with our way of working? I'm not really fond of imposing things but in the same time, this is work where we should have the same environment for everyone to gain efficiency, instead of originality. It is also a way to say that you are part of the team, not some loose spirit who works his own way.



  • In a bigger company, if someone wants to use a tool, there would be proposals for new tools and discussion to implement it. As a smaller company, we have no procedures, everyone wants to use the tools he wants to use.



    Should I define some basic procedure with our sysadmin and ask my colleagues to submit him tools ideas and let the sysadmin, do some optimisation before making it available to our colleagues?




Thanks





Update



Many thanks for your feedback.



After reading all your answers and comments, Gnasher, Fattie, Brandin, Joe , Simon and Emil, I think that what we , as a team, need to have a common work framework with common tools , when working together in particular context.



When we are doing peer code reviewing for example, we need to have the same windows, the same shell. It makes the collaborative work easier.



However, when you are on your own, you are free to use whatever tools you want to use.







work-environment teamwork process






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 18 at 13:54

























asked Nov 17 at 23:02









John Legas

7842412




7842412












  • Comments are not for extended discussion; this conversation has been moved to chat.
    – Snow
    2 days ago


















  • Comments are not for extended discussion; this conversation has been moved to chat.
    – Snow
    2 days ago
















Comments are not for extended discussion; this conversation has been moved to chat.
– Snow
2 days ago




Comments are not for extended discussion; this conversation has been moved to chat.
– Snow
2 days ago










4 Answers
4






active

oldest

votes

















up vote
7
down vote



accepted










What you are really discussing is not what shell and search engine should be used (I personally use Bing because I don't trust Google one bit), what you are discussing is who has the power. You want him to do the work the way you want him to do it. Tell you what, if you joined my team you could say goodbye to zsh - oh no, you wouldn't, because I don't try to force my preferences on others.



Joining a team and then being told that you are not allowed to work the way you like it, just because of someone else's different preferences (because frankly the reasons you gave are very unconvincing) will not help with the person's job satisfaction and will just make them want to leave.






share|improve this answer

















  • 2




    I hate to admit but ... you are right. Didn't thought I could be such a poor schm... Thanks for waking me up.
    – John Legas
    Nov 17 at 23:27












  • Imagine the team that makes - oh - the software used to move the control surfaces when you're flying in a jumbo jet. If there was some frankly dickhead on that team who wasn't capable of doing what he/she was told. Who started to - holy fuck - use random tools at their whim. What would you want to happen? The answer is self-evident. The absolute nature of software is that you have to excel and execute in a framework.
    – Fattie
    Nov 18 at 4:24






  • 1




    (Cont ..) I don't know what fields y'all are thinking of here as the putative example, but if it is not life-and-death, there is usually vast amounts of costs and potential profit on the line. The stakes could not be higher. There's zero room for nonsense.
    – Fattie
    Nov 18 at 4:25






  • 2




    Using the same tools are important. If you want to derivate from this, the burden is on you to show you can be at least as productive. This is typically where IntelliJ wins over Eclipse?
    – Thorbjørn Ravn Andersen
    Nov 18 at 16:33






  • 3




    @gnaher729 actually OP gave one good example, of not having appropriate tooling in his preferred shell (such as seeing the name of the branch). Maybe this example hits a little too close to home, but I've recently had to spend time helping someone who is very bad at keeping track of what branch he is on. Every help session basically involved me saying repeatedly, "STOP. Check what branch you are on first. Did you install the thing I recommended? That will show you automaticlally." If the OP's junior dev is unable to use the same functionality in his shell as the team, it's a problem.
    – Chan-Ho Suh
    Nov 18 at 19:34




















up vote
6
down vote













Yes, but only where it matters. What search engine someone uses makes no difference to the finished product. Neither does the text editor they prefer.



If it causes compatibility issues where one person's code won't work (compile/run/whatever) on another person's system, then that matters.



In bigger companies, there will be an approved tool set, with a process for evaluating new tools when people ask for them.






share|improve this answer

















  • 2




    The idea that everyone could use different IDEs is .. incredible. "In bigger companies, there will be an approved tool set..." if anything, there's more cost pressure on in smaller companies and startups, where there's a budget fixed to the cent to get the prototype (or whatever) built.
    – Fattie
    Nov 18 at 4:26






  • 1




    I don't find it incredible at all to use different IDEs. Interfering with other's ability to do code review, I agree, should not happen. But which IDE you use to achieve your task? Not an issue in my mind - use whatever is best for your productivity.
    – bytepusher
    Nov 18 at 14:03






  • 1




    @Fattie raises an important point. Less resources at smaller companies means there might be only one person that is an expert on something and s/he then has to spend time telling the others how to do something. If I rig up something to work similarly in a local environment as in build/deployment, I don't want to have to now tell three different guys three different ways of how to setup their environments. It's incredibly wasteful of my time and frustrating to have to figure out a different way just because, for example, some guy likes a particular dark theme on his IDE.
    – Chan-Ho Suh
    Nov 18 at 19:19












  • Yes, @Chan-HoSuh has expressed this absolutely perfectly. I myself would say the exact same sentence but add various adjectives like "insane" "utterly" etc!
    – Fattie
    2 days ago










  • @bytepusher How can you maintain the system in a buildable state with multiple IDE's. In most cases, it's the IDE that maintains the build configuration and scripts. If one person changes the configuration in their IDE, compiles it, tests it and checks it in, then it's highly likely to not compile, or malfunction when compiled in the other person's IDE.
    – Simon B
    2 days ago


















up vote
4
down vote













You've stated this new developer isn't proficient with his tools. So he has no case.



Your question is broadly phrased as "Should I let a new developer use his tools over the team's standardized tools" but really you are asking, "should I let a noob developer that doesn't know how to do stuff, shoot himself in the foot and waste our time, or should I enforce team standards and make him more productive at the same time?"



Easy answer to that. The answer is "make him more productive and show him at the same time why companies have standardization". You're the experienced developer. He is a noob. Teach him. Don't let him "unteach" you.






share|improve this answer























  • Maybe "company policy" was too strong a term, but he did say "tools that all of us, use and that have been defined by the sysadmin." Sounds like there are tools that the team has agreed upon and are supported by the sysadmin.
    – Chan-Ho Suh
    Nov 18 at 19:11










  • changed "company policy" to "team standards"
    – Chan-Ho Suh
    Nov 18 at 19:37










  • Hi @Chan-HoSuh, we don't have any standards yet... -_- But this is the aim. So yes, hearing you.
    – John Legas
    Nov 18 at 20:05


















up vote
-1
down vote













If a company states which tools must be used,



(yes, even something seemingly as trivial as "their search engine" or "their keyboard")



that's what they use.



There's nothing much else to be said.



{Regarding the off-topic discussion of whether it's petty/sensible to require certain tools: (i) you can trivially see examples where it would be critical that everyone uses those same tools and (ii) interestingly, a really important part of software is you have to have absolute faith in the upwards pipe - on principal. If your architect tells you to do some thing a certain way there's likely a specific reason even if she didn't bother explaining it. All software engineers of basic competence understand this is a fundamental aspect of doin' software.}






share|improve this answer



















  • 4




    This is not helpful for the situation. OP obviously knows she as the boss have ultimate authority so you bring nothing new to the table. You also disregard any negative effects on imposing a certain way of working onto the employees. For example, some employees might decide their time is better spent elsewhere, or they become less productive, or it leads to burn-out having the constant stress of your boss making decisions over your head. All these factors are important to a good manager, and they are worth discussing. If you have "nothing else to say" then don't post a useless answer.
    – Emil Vikström
    Nov 18 at 8:13






  • 2




    Hi @EmilVikström thanks for your feedback. However, IMO, Fattie can express his opinion, I welcome it. As Fattie said, in bigger corporation, you don't have any choices. You like the tools set, fine, you don't like it, you're shown the door. Period. I've been working in places where you cannot install anything on your laptop. My aim is to have the right balance between let-do attitude and expecting efficiency when using the tools. You can use any tools you want as long as your colleague can easily retrieve the info when helping you and not use 1/n
    – John Legas
    Nov 18 at 11:59






  • 1




    (can I use the word waste?) unnecessary time to retrieve the correct info like which branch you are working. 2/n n =2
    – John Legas
    Nov 18 at 12:01











Your Answer








StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "423"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: false,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














 

draft saved


draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f122992%2fshould-i-convince-a-recently-recruited-colleague-to-use-the-technical-tools-ever%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown




















StackExchange.ready(function () {
$("#show-editor-button input, #show-editor-button button").click(function () {
var showEditor = function() {
$("#show-editor-button").hide();
$("#post-form").removeClass("dno");
StackExchange.editor.finallyInit();
};

var useFancy = $(this).data('confirm-use-fancy');
if(useFancy == 'True') {
var popupTitle = $(this).data('confirm-fancy-title');
var popupBody = $(this).data('confirm-fancy-body');
var popupAccept = $(this).data('confirm-fancy-accept-button');

$(this).loadPopup({
url: '/post/self-answer-popup',
loaded: function(popup) {
var pTitle = $(popup).find('h2');
var pBody = $(popup).find('.popup-body');
var pSubmit = $(popup).find('.popup-submit');

pTitle.text(popupTitle);
pBody.html(popupBody);
pSubmit.val(popupAccept).click(showEditor);
}
})
} else{
var confirmText = $(this).data('confirm-text');
if (confirmText ? confirm(confirmText) : true) {
showEditor();
}
}
});
});






4 Answers
4






active

oldest

votes








4 Answers
4






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
7
down vote



accepted










What you are really discussing is not what shell and search engine should be used (I personally use Bing because I don't trust Google one bit), what you are discussing is who has the power. You want him to do the work the way you want him to do it. Tell you what, if you joined my team you could say goodbye to zsh - oh no, you wouldn't, because I don't try to force my preferences on others.



Joining a team and then being told that you are not allowed to work the way you like it, just because of someone else's different preferences (because frankly the reasons you gave are very unconvincing) will not help with the person's job satisfaction and will just make them want to leave.






share|improve this answer

















  • 2




    I hate to admit but ... you are right. Didn't thought I could be such a poor schm... Thanks for waking me up.
    – John Legas
    Nov 17 at 23:27












  • Imagine the team that makes - oh - the software used to move the control surfaces when you're flying in a jumbo jet. If there was some frankly dickhead on that team who wasn't capable of doing what he/she was told. Who started to - holy fuck - use random tools at their whim. What would you want to happen? The answer is self-evident. The absolute nature of software is that you have to excel and execute in a framework.
    – Fattie
    Nov 18 at 4:24






  • 1




    (Cont ..) I don't know what fields y'all are thinking of here as the putative example, but if it is not life-and-death, there is usually vast amounts of costs and potential profit on the line. The stakes could not be higher. There's zero room for nonsense.
    – Fattie
    Nov 18 at 4:25






  • 2




    Using the same tools are important. If you want to derivate from this, the burden is on you to show you can be at least as productive. This is typically where IntelliJ wins over Eclipse?
    – Thorbjørn Ravn Andersen
    Nov 18 at 16:33






  • 3




    @gnaher729 actually OP gave one good example, of not having appropriate tooling in his preferred shell (such as seeing the name of the branch). Maybe this example hits a little too close to home, but I've recently had to spend time helping someone who is very bad at keeping track of what branch he is on. Every help session basically involved me saying repeatedly, "STOP. Check what branch you are on first. Did you install the thing I recommended? That will show you automaticlally." If the OP's junior dev is unable to use the same functionality in his shell as the team, it's a problem.
    – Chan-Ho Suh
    Nov 18 at 19:34

















up vote
7
down vote



accepted










What you are really discussing is not what shell and search engine should be used (I personally use Bing because I don't trust Google one bit), what you are discussing is who has the power. You want him to do the work the way you want him to do it. Tell you what, if you joined my team you could say goodbye to zsh - oh no, you wouldn't, because I don't try to force my preferences on others.



Joining a team and then being told that you are not allowed to work the way you like it, just because of someone else's different preferences (because frankly the reasons you gave are very unconvincing) will not help with the person's job satisfaction and will just make them want to leave.






share|improve this answer

















  • 2




    I hate to admit but ... you are right. Didn't thought I could be such a poor schm... Thanks for waking me up.
    – John Legas
    Nov 17 at 23:27












  • Imagine the team that makes - oh - the software used to move the control surfaces when you're flying in a jumbo jet. If there was some frankly dickhead on that team who wasn't capable of doing what he/she was told. Who started to - holy fuck - use random tools at their whim. What would you want to happen? The answer is self-evident. The absolute nature of software is that you have to excel and execute in a framework.
    – Fattie
    Nov 18 at 4:24






  • 1




    (Cont ..) I don't know what fields y'all are thinking of here as the putative example, but if it is not life-and-death, there is usually vast amounts of costs and potential profit on the line. The stakes could not be higher. There's zero room for nonsense.
    – Fattie
    Nov 18 at 4:25






  • 2




    Using the same tools are important. If you want to derivate from this, the burden is on you to show you can be at least as productive. This is typically where IntelliJ wins over Eclipse?
    – Thorbjørn Ravn Andersen
    Nov 18 at 16:33






  • 3




    @gnaher729 actually OP gave one good example, of not having appropriate tooling in his preferred shell (such as seeing the name of the branch). Maybe this example hits a little too close to home, but I've recently had to spend time helping someone who is very bad at keeping track of what branch he is on. Every help session basically involved me saying repeatedly, "STOP. Check what branch you are on first. Did you install the thing I recommended? That will show you automaticlally." If the OP's junior dev is unable to use the same functionality in his shell as the team, it's a problem.
    – Chan-Ho Suh
    Nov 18 at 19:34















up vote
7
down vote



accepted







up vote
7
down vote



accepted






What you are really discussing is not what shell and search engine should be used (I personally use Bing because I don't trust Google one bit), what you are discussing is who has the power. You want him to do the work the way you want him to do it. Tell you what, if you joined my team you could say goodbye to zsh - oh no, you wouldn't, because I don't try to force my preferences on others.



Joining a team and then being told that you are not allowed to work the way you like it, just because of someone else's different preferences (because frankly the reasons you gave are very unconvincing) will not help with the person's job satisfaction and will just make them want to leave.






share|improve this answer












What you are really discussing is not what shell and search engine should be used (I personally use Bing because I don't trust Google one bit), what you are discussing is who has the power. You want him to do the work the way you want him to do it. Tell you what, if you joined my team you could say goodbye to zsh - oh no, you wouldn't, because I don't try to force my preferences on others.



Joining a team and then being told that you are not allowed to work the way you like it, just because of someone else's different preferences (because frankly the reasons you gave are very unconvincing) will not help with the person's job satisfaction and will just make them want to leave.







share|improve this answer












share|improve this answer



share|improve this answer










answered Nov 17 at 23:22









gnasher729

79.4k34144250




79.4k34144250








  • 2




    I hate to admit but ... you are right. Didn't thought I could be such a poor schm... Thanks for waking me up.
    – John Legas
    Nov 17 at 23:27












  • Imagine the team that makes - oh - the software used to move the control surfaces when you're flying in a jumbo jet. If there was some frankly dickhead on that team who wasn't capable of doing what he/she was told. Who started to - holy fuck - use random tools at their whim. What would you want to happen? The answer is self-evident. The absolute nature of software is that you have to excel and execute in a framework.
    – Fattie
    Nov 18 at 4:24






  • 1




    (Cont ..) I don't know what fields y'all are thinking of here as the putative example, but if it is not life-and-death, there is usually vast amounts of costs and potential profit on the line. The stakes could not be higher. There's zero room for nonsense.
    – Fattie
    Nov 18 at 4:25






  • 2




    Using the same tools are important. If you want to derivate from this, the burden is on you to show you can be at least as productive. This is typically where IntelliJ wins over Eclipse?
    – Thorbjørn Ravn Andersen
    Nov 18 at 16:33






  • 3




    @gnaher729 actually OP gave one good example, of not having appropriate tooling in his preferred shell (such as seeing the name of the branch). Maybe this example hits a little too close to home, but I've recently had to spend time helping someone who is very bad at keeping track of what branch he is on. Every help session basically involved me saying repeatedly, "STOP. Check what branch you are on first. Did you install the thing I recommended? That will show you automaticlally." If the OP's junior dev is unable to use the same functionality in his shell as the team, it's a problem.
    – Chan-Ho Suh
    Nov 18 at 19:34
















  • 2




    I hate to admit but ... you are right. Didn't thought I could be such a poor schm... Thanks for waking me up.
    – John Legas
    Nov 17 at 23:27












  • Imagine the team that makes - oh - the software used to move the control surfaces when you're flying in a jumbo jet. If there was some frankly dickhead on that team who wasn't capable of doing what he/she was told. Who started to - holy fuck - use random tools at their whim. What would you want to happen? The answer is self-evident. The absolute nature of software is that you have to excel and execute in a framework.
    – Fattie
    Nov 18 at 4:24






  • 1




    (Cont ..) I don't know what fields y'all are thinking of here as the putative example, but if it is not life-and-death, there is usually vast amounts of costs and potential profit on the line. The stakes could not be higher. There's zero room for nonsense.
    – Fattie
    Nov 18 at 4:25






  • 2




    Using the same tools are important. If you want to derivate from this, the burden is on you to show you can be at least as productive. This is typically where IntelliJ wins over Eclipse?
    – Thorbjørn Ravn Andersen
    Nov 18 at 16:33






  • 3




    @gnaher729 actually OP gave one good example, of not having appropriate tooling in his preferred shell (such as seeing the name of the branch). Maybe this example hits a little too close to home, but I've recently had to spend time helping someone who is very bad at keeping track of what branch he is on. Every help session basically involved me saying repeatedly, "STOP. Check what branch you are on first. Did you install the thing I recommended? That will show you automaticlally." If the OP's junior dev is unable to use the same functionality in his shell as the team, it's a problem.
    – Chan-Ho Suh
    Nov 18 at 19:34










2




2




I hate to admit but ... you are right. Didn't thought I could be such a poor schm... Thanks for waking me up.
– John Legas
Nov 17 at 23:27






I hate to admit but ... you are right. Didn't thought I could be such a poor schm... Thanks for waking me up.
– John Legas
Nov 17 at 23:27














Imagine the team that makes - oh - the software used to move the control surfaces when you're flying in a jumbo jet. If there was some frankly dickhead on that team who wasn't capable of doing what he/she was told. Who started to - holy fuck - use random tools at their whim. What would you want to happen? The answer is self-evident. The absolute nature of software is that you have to excel and execute in a framework.
– Fattie
Nov 18 at 4:24




Imagine the team that makes - oh - the software used to move the control surfaces when you're flying in a jumbo jet. If there was some frankly dickhead on that team who wasn't capable of doing what he/she was told. Who started to - holy fuck - use random tools at their whim. What would you want to happen? The answer is self-evident. The absolute nature of software is that you have to excel and execute in a framework.
– Fattie
Nov 18 at 4:24




1




1




(Cont ..) I don't know what fields y'all are thinking of here as the putative example, but if it is not life-and-death, there is usually vast amounts of costs and potential profit on the line. The stakes could not be higher. There's zero room for nonsense.
– Fattie
Nov 18 at 4:25




(Cont ..) I don't know what fields y'all are thinking of here as the putative example, but if it is not life-and-death, there is usually vast amounts of costs and potential profit on the line. The stakes could not be higher. There's zero room for nonsense.
– Fattie
Nov 18 at 4:25




2




2




Using the same tools are important. If you want to derivate from this, the burden is on you to show you can be at least as productive. This is typically where IntelliJ wins over Eclipse?
– Thorbjørn Ravn Andersen
Nov 18 at 16:33




Using the same tools are important. If you want to derivate from this, the burden is on you to show you can be at least as productive. This is typically where IntelliJ wins over Eclipse?
– Thorbjørn Ravn Andersen
Nov 18 at 16:33




3




3




@gnaher729 actually OP gave one good example, of not having appropriate tooling in his preferred shell (such as seeing the name of the branch). Maybe this example hits a little too close to home, but I've recently had to spend time helping someone who is very bad at keeping track of what branch he is on. Every help session basically involved me saying repeatedly, "STOP. Check what branch you are on first. Did you install the thing I recommended? That will show you automaticlally." If the OP's junior dev is unable to use the same functionality in his shell as the team, it's a problem.
– Chan-Ho Suh
Nov 18 at 19:34






@gnaher729 actually OP gave one good example, of not having appropriate tooling in his preferred shell (such as seeing the name of the branch). Maybe this example hits a little too close to home, but I've recently had to spend time helping someone who is very bad at keeping track of what branch he is on. Every help session basically involved me saying repeatedly, "STOP. Check what branch you are on first. Did you install the thing I recommended? That will show you automaticlally." If the OP's junior dev is unable to use the same functionality in his shell as the team, it's a problem.
– Chan-Ho Suh
Nov 18 at 19:34














up vote
6
down vote













Yes, but only where it matters. What search engine someone uses makes no difference to the finished product. Neither does the text editor they prefer.



If it causes compatibility issues where one person's code won't work (compile/run/whatever) on another person's system, then that matters.



In bigger companies, there will be an approved tool set, with a process for evaluating new tools when people ask for them.






share|improve this answer

















  • 2




    The idea that everyone could use different IDEs is .. incredible. "In bigger companies, there will be an approved tool set..." if anything, there's more cost pressure on in smaller companies and startups, where there's a budget fixed to the cent to get the prototype (or whatever) built.
    – Fattie
    Nov 18 at 4:26






  • 1




    I don't find it incredible at all to use different IDEs. Interfering with other's ability to do code review, I agree, should not happen. But which IDE you use to achieve your task? Not an issue in my mind - use whatever is best for your productivity.
    – bytepusher
    Nov 18 at 14:03






  • 1




    @Fattie raises an important point. Less resources at smaller companies means there might be only one person that is an expert on something and s/he then has to spend time telling the others how to do something. If I rig up something to work similarly in a local environment as in build/deployment, I don't want to have to now tell three different guys three different ways of how to setup their environments. It's incredibly wasteful of my time and frustrating to have to figure out a different way just because, for example, some guy likes a particular dark theme on his IDE.
    – Chan-Ho Suh
    Nov 18 at 19:19












  • Yes, @Chan-HoSuh has expressed this absolutely perfectly. I myself would say the exact same sentence but add various adjectives like "insane" "utterly" etc!
    – Fattie
    2 days ago










  • @bytepusher How can you maintain the system in a buildable state with multiple IDE's. In most cases, it's the IDE that maintains the build configuration and scripts. If one person changes the configuration in their IDE, compiles it, tests it and checks it in, then it's highly likely to not compile, or malfunction when compiled in the other person's IDE.
    – Simon B
    2 days ago















up vote
6
down vote













Yes, but only where it matters. What search engine someone uses makes no difference to the finished product. Neither does the text editor they prefer.



If it causes compatibility issues where one person's code won't work (compile/run/whatever) on another person's system, then that matters.



In bigger companies, there will be an approved tool set, with a process for evaluating new tools when people ask for them.






share|improve this answer

















  • 2




    The idea that everyone could use different IDEs is .. incredible. "In bigger companies, there will be an approved tool set..." if anything, there's more cost pressure on in smaller companies and startups, where there's a budget fixed to the cent to get the prototype (or whatever) built.
    – Fattie
    Nov 18 at 4:26






  • 1




    I don't find it incredible at all to use different IDEs. Interfering with other's ability to do code review, I agree, should not happen. But which IDE you use to achieve your task? Not an issue in my mind - use whatever is best for your productivity.
    – bytepusher
    Nov 18 at 14:03






  • 1




    @Fattie raises an important point. Less resources at smaller companies means there might be only one person that is an expert on something and s/he then has to spend time telling the others how to do something. If I rig up something to work similarly in a local environment as in build/deployment, I don't want to have to now tell three different guys three different ways of how to setup their environments. It's incredibly wasteful of my time and frustrating to have to figure out a different way just because, for example, some guy likes a particular dark theme on his IDE.
    – Chan-Ho Suh
    Nov 18 at 19:19












  • Yes, @Chan-HoSuh has expressed this absolutely perfectly. I myself would say the exact same sentence but add various adjectives like "insane" "utterly" etc!
    – Fattie
    2 days ago










  • @bytepusher How can you maintain the system in a buildable state with multiple IDE's. In most cases, it's the IDE that maintains the build configuration and scripts. If one person changes the configuration in their IDE, compiles it, tests it and checks it in, then it's highly likely to not compile, or malfunction when compiled in the other person's IDE.
    – Simon B
    2 days ago













up vote
6
down vote










up vote
6
down vote









Yes, but only where it matters. What search engine someone uses makes no difference to the finished product. Neither does the text editor they prefer.



If it causes compatibility issues where one person's code won't work (compile/run/whatever) on another person's system, then that matters.



In bigger companies, there will be an approved tool set, with a process for evaluating new tools when people ask for them.






share|improve this answer












Yes, but only where it matters. What search engine someone uses makes no difference to the finished product. Neither does the text editor they prefer.



If it causes compatibility issues where one person's code won't work (compile/run/whatever) on another person's system, then that matters.



In bigger companies, there will be an approved tool set, with a process for evaluating new tools when people ask for them.







share|improve this answer












share|improve this answer



share|improve this answer










answered Nov 17 at 23:23









Simon B

2,7112816




2,7112816








  • 2




    The idea that everyone could use different IDEs is .. incredible. "In bigger companies, there will be an approved tool set..." if anything, there's more cost pressure on in smaller companies and startups, where there's a budget fixed to the cent to get the prototype (or whatever) built.
    – Fattie
    Nov 18 at 4:26






  • 1




    I don't find it incredible at all to use different IDEs. Interfering with other's ability to do code review, I agree, should not happen. But which IDE you use to achieve your task? Not an issue in my mind - use whatever is best for your productivity.
    – bytepusher
    Nov 18 at 14:03






  • 1




    @Fattie raises an important point. Less resources at smaller companies means there might be only one person that is an expert on something and s/he then has to spend time telling the others how to do something. If I rig up something to work similarly in a local environment as in build/deployment, I don't want to have to now tell three different guys three different ways of how to setup their environments. It's incredibly wasteful of my time and frustrating to have to figure out a different way just because, for example, some guy likes a particular dark theme on his IDE.
    – Chan-Ho Suh
    Nov 18 at 19:19












  • Yes, @Chan-HoSuh has expressed this absolutely perfectly. I myself would say the exact same sentence but add various adjectives like "insane" "utterly" etc!
    – Fattie
    2 days ago










  • @bytepusher How can you maintain the system in a buildable state with multiple IDE's. In most cases, it's the IDE that maintains the build configuration and scripts. If one person changes the configuration in their IDE, compiles it, tests it and checks it in, then it's highly likely to not compile, or malfunction when compiled in the other person's IDE.
    – Simon B
    2 days ago














  • 2




    The idea that everyone could use different IDEs is .. incredible. "In bigger companies, there will be an approved tool set..." if anything, there's more cost pressure on in smaller companies and startups, where there's a budget fixed to the cent to get the prototype (or whatever) built.
    – Fattie
    Nov 18 at 4:26






  • 1




    I don't find it incredible at all to use different IDEs. Interfering with other's ability to do code review, I agree, should not happen. But which IDE you use to achieve your task? Not an issue in my mind - use whatever is best for your productivity.
    – bytepusher
    Nov 18 at 14:03






  • 1




    @Fattie raises an important point. Less resources at smaller companies means there might be only one person that is an expert on something and s/he then has to spend time telling the others how to do something. If I rig up something to work similarly in a local environment as in build/deployment, I don't want to have to now tell three different guys three different ways of how to setup their environments. It's incredibly wasteful of my time and frustrating to have to figure out a different way just because, for example, some guy likes a particular dark theme on his IDE.
    – Chan-Ho Suh
    Nov 18 at 19:19












  • Yes, @Chan-HoSuh has expressed this absolutely perfectly. I myself would say the exact same sentence but add various adjectives like "insane" "utterly" etc!
    – Fattie
    2 days ago










  • @bytepusher How can you maintain the system in a buildable state with multiple IDE's. In most cases, it's the IDE that maintains the build configuration and scripts. If one person changes the configuration in their IDE, compiles it, tests it and checks it in, then it's highly likely to not compile, or malfunction when compiled in the other person's IDE.
    – Simon B
    2 days ago








2




2




The idea that everyone could use different IDEs is .. incredible. "In bigger companies, there will be an approved tool set..." if anything, there's more cost pressure on in smaller companies and startups, where there's a budget fixed to the cent to get the prototype (or whatever) built.
– Fattie
Nov 18 at 4:26




The idea that everyone could use different IDEs is .. incredible. "In bigger companies, there will be an approved tool set..." if anything, there's more cost pressure on in smaller companies and startups, where there's a budget fixed to the cent to get the prototype (or whatever) built.
– Fattie
Nov 18 at 4:26




1




1




I don't find it incredible at all to use different IDEs. Interfering with other's ability to do code review, I agree, should not happen. But which IDE you use to achieve your task? Not an issue in my mind - use whatever is best for your productivity.
– bytepusher
Nov 18 at 14:03




I don't find it incredible at all to use different IDEs. Interfering with other's ability to do code review, I agree, should not happen. But which IDE you use to achieve your task? Not an issue in my mind - use whatever is best for your productivity.
– bytepusher
Nov 18 at 14:03




1




1




@Fattie raises an important point. Less resources at smaller companies means there might be only one person that is an expert on something and s/he then has to spend time telling the others how to do something. If I rig up something to work similarly in a local environment as in build/deployment, I don't want to have to now tell three different guys three different ways of how to setup their environments. It's incredibly wasteful of my time and frustrating to have to figure out a different way just because, for example, some guy likes a particular dark theme on his IDE.
– Chan-Ho Suh
Nov 18 at 19:19






@Fattie raises an important point. Less resources at smaller companies means there might be only one person that is an expert on something and s/he then has to spend time telling the others how to do something. If I rig up something to work similarly in a local environment as in build/deployment, I don't want to have to now tell three different guys three different ways of how to setup their environments. It's incredibly wasteful of my time and frustrating to have to figure out a different way just because, for example, some guy likes a particular dark theme on his IDE.
– Chan-Ho Suh
Nov 18 at 19:19














Yes, @Chan-HoSuh has expressed this absolutely perfectly. I myself would say the exact same sentence but add various adjectives like "insane" "utterly" etc!
– Fattie
2 days ago




Yes, @Chan-HoSuh has expressed this absolutely perfectly. I myself would say the exact same sentence but add various adjectives like "insane" "utterly" etc!
– Fattie
2 days ago












@bytepusher How can you maintain the system in a buildable state with multiple IDE's. In most cases, it's the IDE that maintains the build configuration and scripts. If one person changes the configuration in their IDE, compiles it, tests it and checks it in, then it's highly likely to not compile, or malfunction when compiled in the other person's IDE.
– Simon B
2 days ago




@bytepusher How can you maintain the system in a buildable state with multiple IDE's. In most cases, it's the IDE that maintains the build configuration and scripts. If one person changes the configuration in their IDE, compiles it, tests it and checks it in, then it's highly likely to not compile, or malfunction when compiled in the other person's IDE.
– Simon B
2 days ago










up vote
4
down vote













You've stated this new developer isn't proficient with his tools. So he has no case.



Your question is broadly phrased as "Should I let a new developer use his tools over the team's standardized tools" but really you are asking, "should I let a noob developer that doesn't know how to do stuff, shoot himself in the foot and waste our time, or should I enforce team standards and make him more productive at the same time?"



Easy answer to that. The answer is "make him more productive and show him at the same time why companies have standardization". You're the experienced developer. He is a noob. Teach him. Don't let him "unteach" you.






share|improve this answer























  • Maybe "company policy" was too strong a term, but he did say "tools that all of us, use and that have been defined by the sysadmin." Sounds like there are tools that the team has agreed upon and are supported by the sysadmin.
    – Chan-Ho Suh
    Nov 18 at 19:11










  • changed "company policy" to "team standards"
    – Chan-Ho Suh
    Nov 18 at 19:37










  • Hi @Chan-HoSuh, we don't have any standards yet... -_- But this is the aim. So yes, hearing you.
    – John Legas
    Nov 18 at 20:05















up vote
4
down vote













You've stated this new developer isn't proficient with his tools. So he has no case.



Your question is broadly phrased as "Should I let a new developer use his tools over the team's standardized tools" but really you are asking, "should I let a noob developer that doesn't know how to do stuff, shoot himself in the foot and waste our time, or should I enforce team standards and make him more productive at the same time?"



Easy answer to that. The answer is "make him more productive and show him at the same time why companies have standardization". You're the experienced developer. He is a noob. Teach him. Don't let him "unteach" you.






share|improve this answer























  • Maybe "company policy" was too strong a term, but he did say "tools that all of us, use and that have been defined by the sysadmin." Sounds like there are tools that the team has agreed upon and are supported by the sysadmin.
    – Chan-Ho Suh
    Nov 18 at 19:11










  • changed "company policy" to "team standards"
    – Chan-Ho Suh
    Nov 18 at 19:37










  • Hi @Chan-HoSuh, we don't have any standards yet... -_- But this is the aim. So yes, hearing you.
    – John Legas
    Nov 18 at 20:05













up vote
4
down vote










up vote
4
down vote









You've stated this new developer isn't proficient with his tools. So he has no case.



Your question is broadly phrased as "Should I let a new developer use his tools over the team's standardized tools" but really you are asking, "should I let a noob developer that doesn't know how to do stuff, shoot himself in the foot and waste our time, or should I enforce team standards and make him more productive at the same time?"



Easy answer to that. The answer is "make him more productive and show him at the same time why companies have standardization". You're the experienced developer. He is a noob. Teach him. Don't let him "unteach" you.






share|improve this answer














You've stated this new developer isn't proficient with his tools. So he has no case.



Your question is broadly phrased as "Should I let a new developer use his tools over the team's standardized tools" but really you are asking, "should I let a noob developer that doesn't know how to do stuff, shoot himself in the foot and waste our time, or should I enforce team standards and make him more productive at the same time?"



Easy answer to that. The answer is "make him more productive and show him at the same time why companies have standardization". You're the experienced developer. He is a noob. Teach him. Don't let him "unteach" you.







share|improve this answer














share|improve this answer



share|improve this answer








edited Nov 18 at 19:37

























answered Nov 18 at 16:35









Chan-Ho Suh

2,05411011




2,05411011












  • Maybe "company policy" was too strong a term, but he did say "tools that all of us, use and that have been defined by the sysadmin." Sounds like there are tools that the team has agreed upon and are supported by the sysadmin.
    – Chan-Ho Suh
    Nov 18 at 19:11










  • changed "company policy" to "team standards"
    – Chan-Ho Suh
    Nov 18 at 19:37










  • Hi @Chan-HoSuh, we don't have any standards yet... -_- But this is the aim. So yes, hearing you.
    – John Legas
    Nov 18 at 20:05


















  • Maybe "company policy" was too strong a term, but he did say "tools that all of us, use and that have been defined by the sysadmin." Sounds like there are tools that the team has agreed upon and are supported by the sysadmin.
    – Chan-Ho Suh
    Nov 18 at 19:11










  • changed "company policy" to "team standards"
    – Chan-Ho Suh
    Nov 18 at 19:37










  • Hi @Chan-HoSuh, we don't have any standards yet... -_- But this is the aim. So yes, hearing you.
    – John Legas
    Nov 18 at 20:05
















Maybe "company policy" was too strong a term, but he did say "tools that all of us, use and that have been defined by the sysadmin." Sounds like there are tools that the team has agreed upon and are supported by the sysadmin.
– Chan-Ho Suh
Nov 18 at 19:11




Maybe "company policy" was too strong a term, but he did say "tools that all of us, use and that have been defined by the sysadmin." Sounds like there are tools that the team has agreed upon and are supported by the sysadmin.
– Chan-Ho Suh
Nov 18 at 19:11












changed "company policy" to "team standards"
– Chan-Ho Suh
Nov 18 at 19:37




changed "company policy" to "team standards"
– Chan-Ho Suh
Nov 18 at 19:37












Hi @Chan-HoSuh, we don't have any standards yet... -_- But this is the aim. So yes, hearing you.
– John Legas
Nov 18 at 20:05




Hi @Chan-HoSuh, we don't have any standards yet... -_- But this is the aim. So yes, hearing you.
– John Legas
Nov 18 at 20:05










up vote
-1
down vote













If a company states which tools must be used,



(yes, even something seemingly as trivial as "their search engine" or "their keyboard")



that's what they use.



There's nothing much else to be said.



{Regarding the off-topic discussion of whether it's petty/sensible to require certain tools: (i) you can trivially see examples where it would be critical that everyone uses those same tools and (ii) interestingly, a really important part of software is you have to have absolute faith in the upwards pipe - on principal. If your architect tells you to do some thing a certain way there's likely a specific reason even if she didn't bother explaining it. All software engineers of basic competence understand this is a fundamental aspect of doin' software.}






share|improve this answer



















  • 4




    This is not helpful for the situation. OP obviously knows she as the boss have ultimate authority so you bring nothing new to the table. You also disregard any negative effects on imposing a certain way of working onto the employees. For example, some employees might decide their time is better spent elsewhere, or they become less productive, or it leads to burn-out having the constant stress of your boss making decisions over your head. All these factors are important to a good manager, and they are worth discussing. If you have "nothing else to say" then don't post a useless answer.
    – Emil Vikström
    Nov 18 at 8:13






  • 2




    Hi @EmilVikström thanks for your feedback. However, IMO, Fattie can express his opinion, I welcome it. As Fattie said, in bigger corporation, you don't have any choices. You like the tools set, fine, you don't like it, you're shown the door. Period. I've been working in places where you cannot install anything on your laptop. My aim is to have the right balance between let-do attitude and expecting efficiency when using the tools. You can use any tools you want as long as your colleague can easily retrieve the info when helping you and not use 1/n
    – John Legas
    Nov 18 at 11:59






  • 1




    (can I use the word waste?) unnecessary time to retrieve the correct info like which branch you are working. 2/n n =2
    – John Legas
    Nov 18 at 12:01















up vote
-1
down vote













If a company states which tools must be used,



(yes, even something seemingly as trivial as "their search engine" or "their keyboard")



that's what they use.



There's nothing much else to be said.



{Regarding the off-topic discussion of whether it's petty/sensible to require certain tools: (i) you can trivially see examples where it would be critical that everyone uses those same tools and (ii) interestingly, a really important part of software is you have to have absolute faith in the upwards pipe - on principal. If your architect tells you to do some thing a certain way there's likely a specific reason even if she didn't bother explaining it. All software engineers of basic competence understand this is a fundamental aspect of doin' software.}






share|improve this answer



















  • 4




    This is not helpful for the situation. OP obviously knows she as the boss have ultimate authority so you bring nothing new to the table. You also disregard any negative effects on imposing a certain way of working onto the employees. For example, some employees might decide their time is better spent elsewhere, or they become less productive, or it leads to burn-out having the constant stress of your boss making decisions over your head. All these factors are important to a good manager, and they are worth discussing. If you have "nothing else to say" then don't post a useless answer.
    – Emil Vikström
    Nov 18 at 8:13






  • 2




    Hi @EmilVikström thanks for your feedback. However, IMO, Fattie can express his opinion, I welcome it. As Fattie said, in bigger corporation, you don't have any choices. You like the tools set, fine, you don't like it, you're shown the door. Period. I've been working in places where you cannot install anything on your laptop. My aim is to have the right balance between let-do attitude and expecting efficiency when using the tools. You can use any tools you want as long as your colleague can easily retrieve the info when helping you and not use 1/n
    – John Legas
    Nov 18 at 11:59






  • 1




    (can I use the word waste?) unnecessary time to retrieve the correct info like which branch you are working. 2/n n =2
    – John Legas
    Nov 18 at 12:01













up vote
-1
down vote










up vote
-1
down vote









If a company states which tools must be used,



(yes, even something seemingly as trivial as "their search engine" or "their keyboard")



that's what they use.



There's nothing much else to be said.



{Regarding the off-topic discussion of whether it's petty/sensible to require certain tools: (i) you can trivially see examples where it would be critical that everyone uses those same tools and (ii) interestingly, a really important part of software is you have to have absolute faith in the upwards pipe - on principal. If your architect tells you to do some thing a certain way there's likely a specific reason even if she didn't bother explaining it. All software engineers of basic competence understand this is a fundamental aspect of doin' software.}






share|improve this answer














If a company states which tools must be used,



(yes, even something seemingly as trivial as "their search engine" or "their keyboard")



that's what they use.



There's nothing much else to be said.



{Regarding the off-topic discussion of whether it's petty/sensible to require certain tools: (i) you can trivially see examples where it would be critical that everyone uses those same tools and (ii) interestingly, a really important part of software is you have to have absolute faith in the upwards pipe - on principal. If your architect tells you to do some thing a certain way there's likely a specific reason even if she didn't bother explaining it. All software engineers of basic competence understand this is a fundamental aspect of doin' software.}







share|improve this answer














share|improve this answer



share|improve this answer








edited Nov 18 at 15:40

























answered Nov 18 at 4:14









Fattie

5,77831221




5,77831221








  • 4




    This is not helpful for the situation. OP obviously knows she as the boss have ultimate authority so you bring nothing new to the table. You also disregard any negative effects on imposing a certain way of working onto the employees. For example, some employees might decide their time is better spent elsewhere, or they become less productive, or it leads to burn-out having the constant stress of your boss making decisions over your head. All these factors are important to a good manager, and they are worth discussing. If you have "nothing else to say" then don't post a useless answer.
    – Emil Vikström
    Nov 18 at 8:13






  • 2




    Hi @EmilVikström thanks for your feedback. However, IMO, Fattie can express his opinion, I welcome it. As Fattie said, in bigger corporation, you don't have any choices. You like the tools set, fine, you don't like it, you're shown the door. Period. I've been working in places where you cannot install anything on your laptop. My aim is to have the right balance between let-do attitude and expecting efficiency when using the tools. You can use any tools you want as long as your colleague can easily retrieve the info when helping you and not use 1/n
    – John Legas
    Nov 18 at 11:59






  • 1




    (can I use the word waste?) unnecessary time to retrieve the correct info like which branch you are working. 2/n n =2
    – John Legas
    Nov 18 at 12:01














  • 4




    This is not helpful for the situation. OP obviously knows she as the boss have ultimate authority so you bring nothing new to the table. You also disregard any negative effects on imposing a certain way of working onto the employees. For example, some employees might decide their time is better spent elsewhere, or they become less productive, or it leads to burn-out having the constant stress of your boss making decisions over your head. All these factors are important to a good manager, and they are worth discussing. If you have "nothing else to say" then don't post a useless answer.
    – Emil Vikström
    Nov 18 at 8:13






  • 2




    Hi @EmilVikström thanks for your feedback. However, IMO, Fattie can express his opinion, I welcome it. As Fattie said, in bigger corporation, you don't have any choices. You like the tools set, fine, you don't like it, you're shown the door. Period. I've been working in places where you cannot install anything on your laptop. My aim is to have the right balance between let-do attitude and expecting efficiency when using the tools. You can use any tools you want as long as your colleague can easily retrieve the info when helping you and not use 1/n
    – John Legas
    Nov 18 at 11:59






  • 1




    (can I use the word waste?) unnecessary time to retrieve the correct info like which branch you are working. 2/n n =2
    – John Legas
    Nov 18 at 12:01








4




4




This is not helpful for the situation. OP obviously knows she as the boss have ultimate authority so you bring nothing new to the table. You also disregard any negative effects on imposing a certain way of working onto the employees. For example, some employees might decide their time is better spent elsewhere, or they become less productive, or it leads to burn-out having the constant stress of your boss making decisions over your head. All these factors are important to a good manager, and they are worth discussing. If you have "nothing else to say" then don't post a useless answer.
– Emil Vikström
Nov 18 at 8:13




This is not helpful for the situation. OP obviously knows she as the boss have ultimate authority so you bring nothing new to the table. You also disregard any negative effects on imposing a certain way of working onto the employees. For example, some employees might decide their time is better spent elsewhere, or they become less productive, or it leads to burn-out having the constant stress of your boss making decisions over your head. All these factors are important to a good manager, and they are worth discussing. If you have "nothing else to say" then don't post a useless answer.
– Emil Vikström
Nov 18 at 8:13




2




2




Hi @EmilVikström thanks for your feedback. However, IMO, Fattie can express his opinion, I welcome it. As Fattie said, in bigger corporation, you don't have any choices. You like the tools set, fine, you don't like it, you're shown the door. Period. I've been working in places where you cannot install anything on your laptop. My aim is to have the right balance between let-do attitude and expecting efficiency when using the tools. You can use any tools you want as long as your colleague can easily retrieve the info when helping you and not use 1/n
– John Legas
Nov 18 at 11:59




Hi @EmilVikström thanks for your feedback. However, IMO, Fattie can express his opinion, I welcome it. As Fattie said, in bigger corporation, you don't have any choices. You like the tools set, fine, you don't like it, you're shown the door. Period. I've been working in places where you cannot install anything on your laptop. My aim is to have the right balance between let-do attitude and expecting efficiency when using the tools. You can use any tools you want as long as your colleague can easily retrieve the info when helping you and not use 1/n
– John Legas
Nov 18 at 11:59




1




1




(can I use the word waste?) unnecessary time to retrieve the correct info like which branch you are working. 2/n n =2
– John Legas
Nov 18 at 12:01




(can I use the word waste?) unnecessary time to retrieve the correct info like which branch you are working. 2/n n =2
– John Legas
Nov 18 at 12:01


















 

draft saved


draft discarded



















































 


draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f122992%2fshould-i-convince-a-recently-recruited-colleague-to-use-the-technical-tools-ever%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown











Popular posts from this blog

AnyDesk - Fatal Program Failure

How to calibrate 16:9 built-in touch-screen to a 4:3 resolution?

QoS: MAC-Priority for clients behind a repeater