How to hold back from interfering with students' inefficient-but-not-wrong work?

Question

I'm a new and junior group leader. I therefore work quite closely with my (also new) MSc students.

I try to let them work and figure out things as independently as they can, but have my door open so they can ask me for help. When they do, it will often be about scripting.

In these cases I sit with them and we work together for a little bit. That's when I see that students often work in ways that are clearly inefficient, but not objectively wrong.

I don't want to interfere too much. This is a learning process and it takes time to learn from one's own mistakes. But I have to really force myself to not suggest they use keyboard shortcuts, a bigger editor window to see more code, more sensible file and variable names, use Dropbox instead of emailing, etc etc.

I think it's important that I hold back: it would be annoying of me to point out every little thing, especially if, as I said, it's not actually wrong. Is there a good way to suggest solutions but not be unnerved if students don't use them?

Answer 1

Does your research group have weekly meetings? If so, you could devote 5-10 minutes at the beginning of each meeting to workflow/development hacks that you think would be helpful. If your group does not have periodic meetings, it may be worth implementing some even just solely for this purpose. Students may not like this at first, but the net productivity increase will be beneficial to everyone. Also, you won't have to point out individual inefficiencies to multiple students (at least not as often).

I implement something similar when I teach, but this is more geared towards undergraduate stuff. I discuss things like how/where to apply for scholarships and internships, tips for getting into grad school, navigating workplace politics, and also some simple workflow things from time to time. Students have commented that this has been very beneficial.

I like @Nate Eldredge's idea of coming up with a list of general development tips, but I think this alone might have some shortcomings. It may be time-consuming to write up something really high quality that covers everything. Some students may not even read it (but these students probably won't pay attention to anything you say during a meeting either). Other students might not understand your suggestions until they see it in practice. This actually happened to me the other day. I knew of Emacs' Tramp, but never understood how to implement it. I saw a tweet with an animated .gif demonstrating how it worked, and I've been using it everyday since. Perhaps discussing these things in meetings and building a list of development tips over time may work well.

You could also make some group requirements that make your life easier. For example, you could require that your group use Dropbox (or something similar) to share documents, and in the process that may encourage them to use it for their own material. (You could keep the development tips document in a shared folder on Dropbox as a start!) I do think pointing out inefficiencies in person could be worthwhile, but you definitely would have to pick your battles and only do this from time to time.

---

EDIT

Some of the comments indicated that the several of the OP's recommendations are "objectively wrong," but I think that this misses the point. If a more senior researcher sees ways that her/his group could be more efficient, these are likely worth sharing even without possessing the perfect workflow. Sharing code through Dropbox may not be the best solution, but it'd certainly be better than emailing files back and forth. (I'm not even sure the OP was suggesting that the group share code on Dropbox; this is just an example). Also, it's possible that the students may have suggestions for the group (or even group leader), and these could be fleshed out by gathering everyone together.

One comment also suggested not getting into a Vim/Emacs holy war... but do the students know about Vim, Emacs, other editors/IDEs, and their capabilities in the first place? I certainly didn't know about these as a Master's student, and developing skills with an editor would have helped me tremendously (I'm not in a STEM field, so these tools are uncommon; I'm not sure about the OP's field, but again, this is just an example). You could definitely discuss features and capabilities without getting into a holy war. Mere exposure might be tremendously beneficial.

Answer 2

What if you were to write up a list of "general development tips"? Then you can share it with everybody once instead of constantly giving unsolicited advice.

You can also then give it to future students and hopefully get them started off well from Day 1.

Answer 3

My approach would be much more subtle compared to João's method. Instead of out right telling them what to do, I would show them my workflow while answering a similar question. Make sure to do this on your own computer, do not 'drive' on someone else's PC.

An example would be to show them your "development method", with a large code window. Use shortcuts or the CLI while they're watching what you're doing. You can say something like "foobar saves me a lot of time", but not too much. The students which want the higher efficiency in their workflow will naturally pick up what works for them.

"You can lead a horse to water, but you can't make them drink"

Answer 4

Personally, this is what I tell my students at the beginning of their work, and my justification in the parentheses.

1. Use Dropbox/GDrive/what have you for backups (if you lose your work 1 week before submission you are screwed).

2. Set up a wiki for project documentation in the faculty server (if you don't take notes later you don't know what to write in the dissertation).

3. Use Mendeley for reference management (spend time writing .bib's or writing your dissertation, your choice).

4. Set up LaTeX and write their dissertation in it (Word is good for up to 3-page documents).

5. Use Virtual Machines for their work environment and keep regular backups (Don't waste time setting up things again and again).

6. Email to both supervisors in CC and always use "Reply all" to work-related emails (I cannot help you if I don't know what you are doing).

7. Show up at the lab often (just by talking with senior researchers you learn the quickest and smartest ways to your goals).

8. Send me progress reports often (if you don't ask for reviews I have no idea if your work is ready for them).

(Optional)

1. Get an SSD for their laptop if they can afford it (patience is worth more than money).

As for stopping myself from pointing out every little thing, it's easy: it's their work, and their choice to do a good one or not. In the words of Morpheus, "I can only show you the door. You're the one that has to walk through it."

Answer 5

Choose the few things that are important and count as 'best practices', (being sensible or having some standard about file and variable names seems a lot more important than the size of the edit window or keyboard shortcut to me). Give some rules or examples that show the guidelines in action and go ahead and be a bit picky about those.

The other things - (use a bigger edit window, shortcut) are really not 'important' as best practice. Standing over a student's shoulder and saying, press that key, etc etc is really irritating and can be overwhelming if too much information/detail is being thrown at them. (Which detail is important, which is just you being helpful?) And, they actually may have pretty valid reasons after time to do it differently (they may find other shortcuts that work better with their 'style' or that you find useful if you observe them.

However, that being said - it is very true that time-saver techniques that will save them frustration are not immediately obvious to novices. I've found the best way is to let someone play with the tools first so that they might run across some of the frustrations. But mostly, simply answer the basic questions and if there is specific question about 'easier' ways to do it, then tell them. Then later - do the one-on-one to show how you would do the task pointing out your own practices and how they avoid particular frustrations. However, at that point, just let then choose to do it how they find best. It isn't useful to keep suggesting it every time you are helping them out.

While I'm not involved in training students in coding, we do have to train novice users on equipment that is a bit tricky and has a long training period to becoming expert so the process has some similarities.

Choose the aspects that are almost non-negotiable because they are important. Don't sweat it too much when the novices keep choosing to ignore the hints you've given them that are based one what the experts typically have found 'useful' strategies to make their own life easier.

Answer 6

@haff suggested in a comment:

If your research group has weekly meetings, you could also devote 5 minutes or so at the beginning of each meeting to demonstrating development/workflow hacks.

An interesting idea! Now, let's vary it a bit:

Devote some group meeting time (not necessarily 5 minutes only, and not necessarily at each meeting) to going round robin, giving students the opportunity to share their own workflow hacks with each other.

Do give them a heads-up in an email in advance so they can think about what workhack(s) they'd like to share or demo. In other words, don't catch them by surprise. And allow individuals to choose not to share something.

In addition, you can have some workshop-type meetings where someone volunteers to be in the demo chair, doing some code development or testing on the fly, kind of like a master class in a music department. Then invite the students to comment constructively, with the goal being that each student find something to praise. If they want to make some constructive suggestions on how to debug more effectively or efficiently, that's fine, but the main goal should be to learn to provide positive feedback to peers.

It is remarkable how much more effective tips and corrections from a fellow student are, compared to having them all come from the professor.

Answer 7

I see nothing wrong with making suggestions. After all you are teaching them and it seems not unreasonable to offer advice on how to improve the way they work, especially if the suggestion is to make something objectively more efficient.

I entirely agree that it may not be a good thing to force students to work in a certain way if it really doesn't make sense to them. Certainly my experience is that one of the most useful things about working with someone experienced (whether in a formal teaching setting or not) is that they will know a lot of useful tricks which aren't necessarily intuitively obvious.

Once you've made the suggestion you can leave it up to them whether they want to act on it or not but at least then they have the information.

Answer 8

TL;DR: Make a distinction between 'tips and tricks' and 'guidelines/good practises'. Give hints towards the first, and try to enforce the latter.

If it is possible in your situation, you might want to organize a small presentation. Something like 'EditorX tips and tricks'. Where you can share with them some tips and tricks on using the editor in a better way, without pointing out any student in particular.

This is not that different from industry. I work as a software engineer, and we have weekly talks where we can give a demo on something interesting in the field. Every few weeks someone will give a small demo of some tips and tricks. Everyone is encouraged to do this.

The benefit of this approach, to me, is that you make other people see the benefit (faster development, for example) with a small demo. You'll also make them curious to finding more tips and tricks that they can share.

This being said about tips and tricks, there are also other things that are not simply tips and tricks but rather guidelines and good practises that should be followed. Wether you use a shortcut or not is quite optional, or wether you realise there is a Zero Latency Typing setting in IntelliJ (an IDE) and want to use it. Yet on the other hand we have things like Version Control, sensible variable names, keeping some documentation, which they really should be doing. The way in which they use it is once again in the 'tips and tricks' part, but they should at least know the benefit of using it and be strongly encouraged to do it.

The way I did this when teaching (academic setting), was by enforcing the usage of these things. I am not sure if you can enforce this in your position, but if at all possible I would do so. Can you set some 'guidelines' for your group? If so, enforce coding guidelines and have them documented somewhere. Put anything relevant in that document, such as if you want snake case or camel case. Give some tips on how to come up with good variable and class names. Enforce pushing to git (svn,..) and show example of good commit messages.

(A way to enforce good code style could be to use a tool that checks the syntax, variable name patterns etc.. There are some good linters available for many languages)

The ones whom I have taught did not always see the benefit of these things - but in the end turned around 180 degrees. It made me happy to see the guidelines being respected and having the students actually see the benefit of this.

Answer 9

it is a process, I agree, but if you don't point out the "mistakes", how would they know that they could be improved?

Personally, I nitpick everything, and so far it has worked well. I also like to make clear this exact point and remember to congratulate them when they actually do stuff right on the first try (Otherwise it seems you focus too much on the negative feedback).

Of course, it is important to remember that ultimately it is not your decision. You present all sides, pros, cons, and they decide. Another way of saying this is that you mention each thing thrice at most :)

Answer 10

I suggest you approach this part of teaching the craft of programming as if you were a theater director.

Tell your students you will take some time to observe each of them working and give them notes afterward.

Observe a student and take notes. Keep silent during observation.

After your observation, "give your notes:" have a conversation where you tell the student your observations of their work, and offer your suggestions for improvement. This way you're offering your suggestions in a structured way, and not nagging them. Be sure to tell them they're not being marked or graded on this.

You can also encourage them to do this for one another.

Answer 11

I'll try to answer the question you are actually asking - i.e., the questions about you, not your students:

How to hold back from interfering with students' inefficient-but-not-wrong work?

...and...

Is there a good way to [...] but not be unnerved if students don't use them?

(And my answer is strictly about advice that was not asked for, like in your case. Nothing of this obviously applies when your students ask you how to improve.)

Unfortunately, you are up to something quite profound with your questions. There are two facts which can make people like you (or me), who have very efficient techniques for doing stuff, very unhappy by witnessing other people plodding along excruciably slowly - for whatever reason, not necessarily related to their intelligence at all.

1. Not every technique (of using an editor, upload tool or whatever) works the same for every person out there. What you may find very obvious (e.g., having most Emacs hotkeys pat down, being able to envision a good on-the-fly keyboard macro streaming right from your fingers during editing, etc.) may be utterly impossible for others. You arrived at your techniques by thinking very long and hard about it, or by intuitively finding something which matches how your brain is wired. That is not necessarily applicable to other people. Hence the VI/Emacs, Windows/Linux, PC/Mac wars, etc.
2. Not every person is actually able to take advice, however well meant, and apply it to their own work, for different reasons. In fact, in my experience in all venues of life (university, work, family, friends), there were only very, very few people who were at all able to take any un-asked-for advice whatsoever.

Now. I will not go into the specific reasons for these two facts, because there are many, and it does not matter. Just an example: for "1." the other person might just not know about it; his "thought routines" might just not match up with how an editor works, and so on. For "2.", you might just not be able to explain it in the words they need to hear, they might be blocked by pride etc. There may be plenty of other reason, but my answer is not about those reasons at all. Sure, for many of them, there is a way around it. But you will always end up in the position that you feel pain because you so dearly want to help but they just don't get it.

How to hold back

Just do it. Sit patiently while they do their inefficent thing. Yes. Obviously you can show them how you work, but frankly, they see that simply by watching you, if you are working in a peer environment. You do not need to make a "thing" out of it. They are students and should be used to use their brain; if they see you working blazingly fast while they take a loooooong time, they should be able to figure out that there's something going on. The point is that it is not you that needs to do something. It's not you that is responsible here.

If they see you working fast, then they are free to

• Ask you to explain how you do it.
• Feel bad about it and practice at home.
• Sit together with their friends and "compare notes".
• Buy some book and read up about it, whatever "it" is.
• Download the tools you use and figure them out.
• Or not be bothered about it at all and stick to their slowness.

And probably other things.

How to not get unnerved if they do not use your tips

The secret about not getting unnerved is to think this through upfront, and remove the idea that you can somehow change someone else right out of your head. You cannot change another being, ever. You can coax them, force them, lead by example or whatever, and you can enjoy the situations where they indeed improve, but you cannot really make them change.

So, by pure logic, it makes zero sense to get unnerved. That's a case of not seeing reality as it is. If you accept that things are as they are, your becoming unnerved will reduce, for sure.