# How to help students avoid being distracted by bells and whistles

I teach Windows Forms programming, and now ASP.Net (essentially the same thing, except you view it in a browser) and I am dismayed that students seem to spend an enormous amount of time straining at gnats, trying to get picky details of the appearance correct. This involves them attempting to do extra things, like adding backgrounds, and putting images in to buttons and carefully positioning and sizing everything. This eats up masses of time and energy and they constantly ask me for help with details that I know nothing about, like obscure subtleties of CSS and so on.

Is there some way to get students to focus on the point of a lesson, which is to understand programming concepts, and not just stare in fascination at the colors and shapes on the screen?

(I learned programming in a command-line environment, without Windows or web browsers, so I am at a loss as to why all of this is so interesting to the students. My attempts to add even small enhancements to appearance for my demonstrations are such a time-sink that I tend to drop them in favor of getting something to work. For example, try to change the color of a Jumbotron.)

• Could you not provide the necessary bells and whistles for them? Provide them with some standard CSS to use and tell them not to deviate from it. Apologies if this constitutes a full answer... – ESR Mar 20 '18 at 2:28
• "so I am at a loss as to why all of this is so interesting to the students". I can answer this. There is immediate gratification when you change the styling. Change 1 line, refresh the page, immediate results. It's easy to work by always changing small things and see the page evolve constantly from absolutely crap to something that actually looks good. Now compare this to writing a procedure to insert a record in a database. You can't easily split this in tiny chunks you can test separately. so they have to work more before getting results. – MrZarq Mar 20 '18 at 8:21
• If you are just trying to teach core programming concepts, and don't want students to be distracted by a GUI, which you yourself avoided by learning in command line programming, have you tried teaching them in command line programming? The GUI can come when they need to learn about the GUI. – Tom Bowen Mar 20 '18 at 9:03
• The look and feel of things is an essential part of human interaction and engagement. This is as true for your teaching practice as it is for the end result of any assignment. While it may not be within the scope of your course to teach this, I still think it's important that students understand how the css feed into the code - and how the manipulation of one can impact the behaviour of the other. – Strawberry Mar 20 '18 at 12:11
• As others have said it's easier and more gratifying to create visual changes than writing code that works in the background, this doesn't apply to only students either. If you've ever been a developer for a company that needs to appease shareholders you'll know what it's like to spend months rewriting an entire site architecture to increase maintainability and reuse and receive little praise, but then reskin a few buttons on the homepage and you've saved the day. – DasBeasto Mar 20 '18 at 13:24

This is a very common problem. Students tend to focus on the stuff they can see, which can be to your benefit (visual programs are more engaging than command line applications), but like you've discovered, it can also be very distracting.

I think a lot of the problem can be prevented by adding a disclaimer at the top of assignments. Something like this:

Please note that I am not grading you based on what your program looks like. It can be tempting to obsess over the look and feel, but try to resist that urge! Graphic design is an important field, but this course focuses on [insert focus here]. If you want to explore topics like graphics and design, please do so only after you've finished the main assignment. You also might want to check out [insert graphics course here] after you finish this course.

You might also include guidelines on what's "in scope" for an assignment and what's outside the scope. Something like this:

Although this assignment includes visual elements, please note that I'm only grading you on your core logic, not what it looks like.

The following are in scope for this assignment:

• Changes to server-side files.
• Showing the correct components on the client side.
• Getting input from the client to the server.

The following are not in scope:

• The look and feel of the client side.
• CSS changes.
• Layout or style changes.

If you're interested in exploring the out-of-scope topics, make sure you do so after completing the in-scope topics.

Or maybe something as simple as this:

Make sure the basic functionality works before working on the look and feel of your program! Remember: it's better to have an ugly program that works correctly than it is to have a beautiful program that doesn't work.

You might also explain the concept of minimum viable products. It might also be useful to mention feature creep and bike shedding.

A lot of this just comes down to communicating your expectations.

• From my own ancient experience your first set of guidelines might carry more weight thn the simpler set (this isn't a new problem, I got bogged down in look&feel 20+years ago in Pascal) – Chris H Mar 20 '18 at 15:12
• I really like this answer compared to the others, as it doesn't restrict student freedom or expression. If the students have a good UI and get a bad grade on the assignment, it teaches them a lot about requirements prioritization. – Clay07g Mar 20 '18 at 18:56
• If only students were the only ones distracted. I've worked on websites, and I can tell you that during prototyping most non-technical persons (notably managers and clients) will focus on the appearance of the draft and completely ignore the underlying functionality :/ – Matthieu M. Mar 22 '18 at 8:14
• @MatthieuM. See the link on bike shedding in the answer. – Kevin Workman Mar 22 '18 at 16:05
• @MatthieuM. I see. In my case we usually show the mockups made by the graphic designers to the clients first, then we show them an interactive version of the program even if the UI is half-baked or still ugly. So they know upfront what they will eventually get. – Andrea Lazzarotto Mar 22 '18 at 19:25

Make the bells and whistles part of the problems you want them to solve.

This is actually a great situation, since your students seem to be really interested in those things and show some intrinsic motivation on working on them. Just think about this, they are actually spending time doing extra work that you didn't even ask them to do! Now you just need to make sure that they still understand the mandatory stuff.

Ask yourself, why is it more interesting for a student to fiddle with those boring visual things instead of the exciting stuff that you are trying to teach? Because to them, it's the opposite. What you teach is the boring stuff, but oooh, look at this shiny little button I just created! And now I changed its color to orange, how fancy is that!

The good news for you is that with this boring programming logic you are trying to teach, you can create far more interesting visual effects than what they can come up with through their tinkering.

Want to teach them loops? Have them draw some fancy Logo flowers:

They will probably still spend most of the lesson tweaking the colors, but soon they will realize that they can achieve the most interesting effects by playing around with the loop variables. Nesting loops gives super cool results here. And the playing around can actually give them a great understanding in how loops work.

Similarly, one of the strongest motivations for the adoption of object-oriented programming techniques came from problems in GUI programming. Hand-tweaking a GUI to look nice becomes a nightmare once your number of widgets gets larger. Add resizable windows to that and your students will quickly come to the end of their tinkering abilities. This is where your boring programming techniques come to the rescue! Show them how OOP allows splitting the problem of layouting the different widgets into distinct sub-problems which can then be easily composed later.

You can find similar examples for almost any problem in computer science. Instead of stopping your students from what they are doing, embrace the fact that they are showing interest and shape your teaching examples in a way that it makes use of that interest.

The downside is that coming up with nice examples here is not easy and can be quite an effort. I've never had a course where every single exercise was exciting and fun. But the good courses made sure they did one of them every once in a while to remind us that all this hard work pays off in the end.

• +1 Some serious work goes into making bells and whistles useful. PyTorch is an example of a tool whose distinguishing feature is its use off "bells and whistles" to make programming machine learning systems easier to manage. – pojo-guy Mar 21 '18 at 2:40
• I agree with the sentiment of this answer, and it's why I recommend Processing in many of my other answers here. This is especially useful for beginner classes. But at some point you need to go beyond the visual, at which point you'll need to solve this problem one way or another. – Kevin Workman Mar 21 '18 at 19:07
• +1 because it's unexpected that something visually nice would come out from Comic Sans MS. :P Seriously though, embracing seems a more viable strategy than forbidding. – Andrea Lazzarotto Mar 22 '18 at 17:59
• See also python's turtle module for another environment which can make these: docs.python.org/3/library/turtle.html – Yet Another User Mar 22 '18 at 18:04

I am dismayed that students seem to spend an enormous amount of time straining at gnats, trying to get picky details of the appearance correct.

So they are tackling a front-end programming assignment in a way that reflects the reality of the majority of front-end programming. Getting this stuff right or wrong can make the difference to the viability of a product.

This eats up masses of time and energy

Yes, it does. Front-end detail is time consuming. For our (commercial, not pedagogical) projects, we have a project-wide CSS style based of a company wide SASS styles merged in with bootstrap or other frameworks. That saves us a lot of time and makes our various sub-sites consistent.

I'd suggest you create a CSS for your students, and tell them to use only classes defined in it, and no other styling. I'd base it off a bootstrap theme, which can be configured using something like https://pikock.github.io/bootstrap-magic/app/index.html#!/editor .

This way you shouldn't have CSS questions beyond 'what class to use for a large button?', which can be answered from the documentation, and it won't be very far from what happens in the real world.

• I think this is the best approach. Provide them with requirements that the interface provided is used and not changed. – Adam Davis Mar 22 '18 at 15:47

If you are just trying to teach core programming concepts, and don't want students to be distracted by a GUI, which you yourself avoided by learning in command line programming, have you tried teaching them in command line programming? The GUI can come when they need to learn about the GUI.

Get the students to learn the core programming concepts they need to learn in command line with no other distractions. This will even work if you want a very basic UI, like a basic "snake" game can output a grid to a command line for them to manipulate.

Just to check, are you setting expectations correctly?

For example, perhaps the reason why the students are focusing so much on the visual appearance is because they think that's the core "point" of the lesson (or the class). If so, that could perhaps be something you could clarify in your rubric or syllabus -- make it clear that you care more about the underlying functionality of their code, that you're ok if the final product looks a little visually unpolished, and that if they want to go above and beyond, they may have to do some independent studying.

It might be worth setting these expectations explicitly whenever you release your first assignment/exercise, especially if you tend to get a lot of students like this.

Or alternatively, you could perhaps do this implicitly by doing with Buffy suggests -- restructure your assignment so there are distinct divisions between the "frontend" and "backend" logic, and provide the student with assignment specifications that focus heavily on the underlying backend logic, give them a bunch of tests for the backend, etc...

Or perhaps your students are restless and are doing extra work because they genuinely do want to make the best product that they can? In that case, something you could do is to redirect them by suggesting more productive extra enhancements, which they can perhaps do for some minor extra credit. That way, they're still learning, but are focused on topics you feel are more relevant to the course.

Anything positional fails on a different sized screen anyway...

Did you try telling them that? It might be worth mentioning this explicitly and giving examples of what good responsive design looks like. (And if this isn't one of the focuses of your class, mention it off-hand and link to resources the students can read if they're curious and want to learn more).

Perhaps you could use this to actually explicitly make the point that trying to control the appearance down to the last pixel is a huge timesink, and that your time is better off making a design that's robust to minor changes, especially for web development? (You could talk about how fonts differ from OS to OS, how browsers can alter the page to help with accessibility, etc...)

Basically, if they're going to keep focusing on visual appearance, you might as well spend some time making sure they're at least doing it right.

Part of it may be wanting to have pride in their work, and not knowing (yet) how to direct that urge productively.

I also learned in a predominantly CLI environment and I can remember, with a certain degree of chagrin, the things I did beyond the scope of the assignments that are entirely analogous to fiddling with backgrounds and layout.

One of the biggest helps in the journey towards directing this urge productively was a teacher who kept (with permission) old projects they considered exemplary. They shared these after each assignment was turned in.

This provided both direction and incentive - we really wanted one of our assignments to be chosen to be one of the exemplars, and it laid out the areas we'd need to focus on to get there.

• One of the bells and whistles I've learned NEVER to leave out, even in supposedly "throwaway" scripts, is complete usage information for a command line tool when run with --help as an argument. Actually, I usually write that usage message first, which forces me to design the script to be usable before I start implementing it. Boy do the sysadmins I work with love me for it. – Wildcard Mar 20 '18 at 5:45
• @Wildcard This is why I love Python's argparse and similar libraries. Lets you set up your command-line arguments and get the help built-in! – JAB Mar 20 '18 at 15:55
• @JAB and they're often easier than parsing it yourself, so there's nearly zero reason not to – Morgen Mar 20 '18 at 16:15

## This is an important teachable moment

One of the most annoying traits in newer engineers is their "helpfulness." They may not realize that working on tasks outside of their assigned scope can actually be harmful. Often there are separate team members who are specifically assigned the visual stuff, and sometimes there are strict standards, compliance issues, accessibility issues. When somebody else decides to be "helpful," it can actually cause a huge setback for those specialized developers. Or sometimes the "extra" work was excluded from the contract and giving the client free work can harm sales. Either way, it is a critical soft skill for engineers to learn to "stay in their lane."

This topic is important enough for its own lesson. Let them fail at this on their first assignment, and then use the next class to Tell them this is important. And that they will be marked down if they do it again. If students do extra work anyway, it should result in a decreased grade.

If you feel bad marking them down, you can offer an opportunity to fix their mistake, e.g. grant them extra credit for rolling back the code to the original version. Then you can teach them about the importance of source control too. Two teachable moments in one!

• Welcome to CSEducators and thanks for this perspective. Come back often. – Buffy Mar 21 '18 at 17:30
• I'd soften this by making the interface available and a requirement that it not be changed. As written there could be a lot of questions about the interface requirement, and a lot of straining over getting it right so it's not something you get marked down on. Simply provide the interface, require them to use it, and mark them down if it's not used or if it's broken. – Adam Davis Mar 22 '18 at 15:49

I'll have to admit to not actually using Windows Forms Programming, but MS seems to indicate that it is a variation on Model-View-Controller (MVC), in which an underlying model is viewed by one or more Views and controlled by one or more Controllers that connect the Model to the Views. Other systems, such as most of early Java GUI programming fit the same model.

The correct way to program in such a system is to rigidly separate the three kinds of components so that a model has no knowledge of how it might be viewed.

For your dilemma, I think the solution is for you to provide the view and at least a framework for the controllers (event handlers). Then, if you want your students to learn programming in general, and not just making things pretty, then have them supply the model so that it fits within your framework.

On the other hand, user interface design is a very important topic, but its implementation and thought processes are quite different from what it takes to do model building. But it also takes a study of things like Psychology, so may be best to isolate it from an early course.

One way to provide the entire framework is to imagine some empty model that the controllers talk to via accessor methods (to get info to be displayed) and mutators (to update the model when something changes). These can provide default information in your framework and be updated by the students along with their model. Your View won't show much that is interesting until the students provide the backbone, of course, but it will force them to focus their efforts there. It will also give them good habits of separating concerns in programming which is a valuable skill even outside MVC.

• Windows Forms don't require an MVC approach. You might be thinking about WPF. – IMil Mar 21 '18 at 22:11

I think these are actually two separate problems.

• Tweaking very specific details
• Wanting to do stuff beyond the scope of the course

The former is potentially harmful.

Stress that they will get no points for having a good looking website and that they only get points for functionality.

Perhaps even enforce this by restricting the students to using a colour palette that you have selected or requiring that they only use default colours if the environment provides them. If students are forced to use a restricted colour palette then they cannot spend time tweaking the colours.

Perhaps also consider being specific about where their elements should be placed. For example, require that button X should be in the bottom right hand corner and that button Y must be in the left hand corner. They can still move things by a few pixels if they're that obsessive, but they won't be burdened by the desire to keep reshuffling all the elements.

Alternatively, make the students design their UI before doing any programming and penalise students for deviating from their design for cosmetic reasons. (Allow deviations for things that genuinely cause an issue, but require that the student documents the issue.)

These suggestions not only kill the problem, but they also force students to exhibit skills that they might need in a work environment (documenting changes and fulfilling the customer's requirements).

The latter on the other hand should be encouraged.

Wanting to learn beyond the scope of the assignment is a good thing. It's a sign that the students want to be doing this and that they have the potential to become good programmers because they're inquisitive and willing to put in effort.

Don't crush this, simply tell them that they are only allowed to do extra things like that when they have fulfilled all the other requirements.

Perhaps enforce this by making students show you their work when they are finished so that you can give them permission to start adding extra functionality.

Make it clear that the assessment is about providing "what the customer wants", not about showing off, and that any 'extra features' will be completely ignored and won't impact anyone's grades.

There's also nothing wrong with admitting that you don't know the answer.

A little anecdote:

(TL;DR: encouraging students to check the documentation instead of asking you is a good thing in the long run.)

When I was learning programming at college my programming teacher didn't know how to use the open file dialogue in winforms, so I simply went away and asked the internet instead. That was a good thing, it gave me practice at referring to the documentation and made me realise that in fact my teacher did not know as much as I originally thought. Once I had gotten used to the documentation I stopped asking my teacher and started referring to the documentation first. Before long my teachers were sometimes asking me questions.

• While I generally agree, the issue really only becomes a problem when students neglect what they are meant to do, rather than when they want to go beyond the requirements. Of course, spending too much time on ephemera is a problem in its own right. – Buffy Mar 20 '18 at 14:39
• @Buffy Hence "Perhaps enforce this by making students show you their work when they are finished so that you can give them permission to start adding extra functionality.". If they have to prove that they have done what they are supposed to before they are allowed to work on other things then it's harder for them to neglect things. Naturally the viability of this varies with the environment (i.e. it's easier with pre-college/pre-uni environments). The time taken to check students' work would have to be factored into lesson time as well. – Pharap Mar 20 '18 at 14:45
• Yes. Interaction and advice are always a good thing. – Buffy Mar 20 '18 at 14:52

I feel that there is a little bias at play here. In addition to all the answers above, I'd like to mention that you feel that tweaking UI is a waste of time. That's because you inherently feel that such tweaking is off-topic as far as your course is concerned.

However, isn't software development all about the complete package? While everyone from your course may not go on to become full stack developers, what they are striving for now - perfection - is actually something that will help them out later.

As a possible solution, how about tasking them with manipulating the UI so many times, and with such complication that the changes begin to become difficult for them to tweak manually. That is when you show them the beauty of doing things programmatically, and by that logic, how back-end operations work.

Alternate solution would be to link the algorithms that you're teaching, ergo, programming concepts, into UI.

• Welcome to Computer Science Educators! You add an interesting view. I hope we'll see more great content from you in the near future! – ItamarG3 Mar 22 '18 at 10:47
• In my experience, "perfect" is more often than not the enemy of "good enough". There seems to be a consensus that software is "good" if the answers to both of the following are "yes". 1. Did you build the thing right? 2. Did you build the right thing? I think an argument could be made that UI tweaking is, in this case, not the "right thing" -- because it's not what the "customer" wants. – David Mar 23 '18 at 14:53
• However, there does seem to be a mismatch between the course goals and the technologies in play. If the focus is really on core programming concepts, the students should probably be writing command-line programs, not WinForms and/or Web apps. That mismatch may be due to instructor bias ... but it could very well also be a poorly designed course. – David Mar 23 '18 at 14:56
• ItamarG3 : Thank you for the feedback and the welcome. I hope so too. @David : I disagree with the argument that UI teaking is not what the customer wants, but I'll admit there's a possibility. On the other hand, I agree with your second comment. And combining your two possibilities, it's also probable that the course could have been poorly designed DUE to instructor bias. Maybe prior hands-on experience with .NET programming has the OP resort to relying on WinForms/ASP to teach fundamentals instead of other languages. – ValarMorghulis Mar 26 '18 at 6:51
• On a different note, I do not see why programming basics are being taught with such high level framework-based languages. If the course is about the languages themselves, then shouldn't there already be a CS 1001 course (I mean a basic one) where students are taught these fundamentals? If that responsibility also lies with the OP, then maybe we can start off with some <insert basic language here> programming in the first few weeks of the course before moving on to ASP .NET. – ValarMorghulis Mar 26 '18 at 6:54

Consider taking off points for failure to follow clear instructions about project guidelines.

This isn’t as harsh as it may seem, because in the real-world clients and employers will not be pleased about “wasted” effort spent outside of the scope of the task assigned.

For example: If the clients wants a working prototype ASAP but you deliver a pretty mock-up instead then you will have problems.

• What you say is certainly true about most employers (startups possibly excepted), but a kinder approach to students should be explored first, I think. The carrot is normally preferred to the stick, as long as the lesson is properly learned. – Buffy Mar 20 '18 at 15:57
• And Welcome to CSEducators. Your profile indicates experience. It might be good to expand your post a bit about how your experience relates and reinforces your answer. Normally longer answers have higher "value" here. – Buffy Mar 20 '18 at 15:59

One effective way is to state beforehand exactly what will be graded, perhaps give an example of bare-bones "enough" solution. You might go so far as to announce that "bells and whistles" will be penalized.

One example that still makes me cringe was a database homework asking for a simple query to a preexisting database under IBM VM/CMS. Doing the query was a few minutes, students spent literally days tweaking the UI in the bletcherous environment offered by the text-only terminals.

If you are concentrating on some programming technique/data structure, use the idea used e.g by ACM-ICPC: Data are standard input, spartan format, no validation required; output is standard output, simple, rigid format. A nice plus is that the running on sample test data for validation is much simplified (no TA clicking madly and typing the same junk over and over into dozens of programs).

In a "Programming Languages" course I used to teach we had a generic rubric for programs: so much for correct answers for the examples provided with the homework, so much for other test data. Then general criteria like reasonable split into functions, good use of language facilities (use a dictionary and not a list if you want to search for a datum), reasonable naming, enough (not excessive, informative) comments, ... This was published beforehand.

Grading assignments can have an influence how much effort and/or focus students exert. Have you tried giving the "distracted" students poor grades? or rewarding the students that stick to your rigid guidelines?

You may also try connecting with your students by learning some of the "obscure subtleties of CSS" they are interested in. If you are able to instruct how to do Windows Forms programming, and now ASP.Net, CSS should be very straightforward to understand.

• "Have you tried giving the "distracted" students poor grades?" That's unethical, students should be graded based on how well they achieve the task/demonstrated the required skills, not how "distracted" they get. If they spend 2 hours tweaking colours but do everything the coursework/task/exam requires, then the fact they spent 2 hours tweaking colours is irrelevant and should not impact their grade. – Pharap Mar 21 '18 at 15:19
• @Pharap #1, the question has nothing to do with an ethical response, the OP asked for motivational techniques. #2, you are making an assumption as to how that class is graded. it's only unethical if the class only bases grades on performance and not on participation as well. If the instructor tells the students they will take points away for being off-topic, then that's how it goes – RrB Mar 22 '18 at 18:32
• But where does it end? Is briefly staring out the window off-topic? Is going to the toilet off-topic? What if the student has already completed all the work? Should they be banned from tweaking the colours on a finished program? Should they be banned from doing work for another class (since that's definitely off-topic)? – Pharap Mar 23 '18 at 19:48
• If the task has clearly defined guidelines AND clear instructions not to deviate from those guidelines, then it is entirely up to the teacher to enforce the with grading. I don't see that as unethical, but that would be for the school board to decide if there was enough complaint. – user4725 Mar 24 '18 at 16:31

I am someone who is often distracted by what should not be the focal point of a situation, and I believe that it relates to your question and the basis of your frustration with your students. I believe that all of us, whether we're computer programmers or newspaper columnists or waiters at Applebee's or cashiers at WalMart....no matter your occupation or position in life, being seen as a unique and solo, unto only yourself and visible in a singular light/frame of reference is an almost involuntary compulsion that belongs to all of us as human beings.

We especially feel pushed to "shine alone" when in a setting such as your classroom, where there is but ONE FINITE end to the means, the answer or completion to what is facing your students on the screen, and there is no varying or alternate in the way of the result.

Each person you're teaching will have the exact same result for you to see when they finish your assignment, right? And no individual indicators whatsoever will be evident by you or any of them in the final answer they arrive at. But the mundane focus of their minds when they are faced with your problem to solve with it's finite, absolute answer with no variables at all is, NATURALLY. magnetic in it's attraction and pulls all focus toward it because it involves THEIR SIGNATURE or a sign of their "mark" on the entire exercise.

And I don't think we are even participants sometimes in our own branding of ourselves when a scenario like this source of your frustration takes movement. There is no human "thumbprint" or signature with a heart over the "i" to single you out in the computer lab as I remember it. it's been a long time, but I don't remember there being a whole lot of gray area once arrival at the equation or programs' answer was reached by the whole of the class. It's correct or you know ahead of time that you're all wrong and you go backwards and begin again until you arrive at the exact precise and without any mark of who you are or how you arrived there or what went through your brain in getting to the same place as every other person in that space sitting at their screens got to answer....it's a non-negotiable and one way road with no shoulder or guard rails for anything unexpected because it's not flexible. It's automated and drone-ish in it's culmination.

So the very focus to someone who ahead of time knows that they get no individual "great theory" or "loved your process along the way" kind of strokes in a personal way for completing what is on that screen - they have no control over their brain focusing on what is NOT what your curriculum intended to grab their focus and is the thorn in your side and so frustrating to you. Because the human can't help but make their own flag to fly in self promotion of their very existence, even when they object to being seen or heard sometimes.

That's why they focus on what you think is mundane and counterproductive but is their focus only due to something innate and involuntary in our thinking minds, but is a circuitry phenomenon in-factory setting in us all. When there are nothing but parameters and rigid lines to stay between and all those around are confined to the same one dimensional confines, an errant spark fires off and focus is directed toward some little mark of individuality and "I counted and stood unique and with no other duplicate" and makes a classroom of computer screens change their priorities for a second in the name of our narcissism and the "id" portion of who we are at our core. Needy and attention-seeking as being recognized to be special and outstanding or remarkable in at least one small way.

Your source of angst is the students' fingerprint on the class because there aren't any other ways to mark their having existed there. I'm not sure you can come up with any kind of strategy to keep them from detailing their assignments, although maybe acknowledging that you are aware of the desire they may have to indulge that need or make the colorization the priority and the first thing they work on. Point out, maybe? that time doesn't allow for extended personal touches so to practice discretion and remain focused on the problem at hand and those identifiers can be done at the end of their assignments?

I'm grasping at suggestions because I think the DNA is too powerful and redirection of the focus is not probable. Ego-driven forces are in power and it's not a democracy.

• Welcome to CSEducators. You seem to have had a terrible educational experience. I'm sorry that happened. It should not have happened. There are educators who try to assure that it doesn't happen, but it seems we failed you. I think we need to hear more from you. – Buffy Mar 25 '18 at 9:51

Answer because I am not registered to make a comment (and am not going to so please do not implore) Yes, we did actually teach months of fundamentals, beginning with Console mode programs, before reaching Windows Forms and then ASP.Net (Web Forms).

I agree with the recent answer that says that people want (even unconsciously) to distinguish themselves. Fair enough. But there are more programmatic changes that can be made, instead of only colors and sizes on the screen. Just getting the bare Bootstrap to render properly is actually difficult, and an achievement in itself. In the "real world" (hopefully not like the "real world" that Morpheus showed Neo) someone else will probably be doing the visual design, and programmers have their hands full just getting that to render correctly, on everything from a phone to a wall-sized screen, using only Bootstrap (or whatever).

But, having been a programming student for decades, a Teaching Assistant grading the code of novices, and a professional programmer working with colleagues, I can assert positively that everyone's code will look very different, and two programmers will write quite different solutions, even if they function and look identical.

As a simple example, you would think that Morse Code going out over radio would be the most machine-like and identical thing, but it is not. Every human being sending Morse Code with a hand key will sound recognizably different (speaking from long experience). Even different semi-automatic keys of the exact same design will sound different, and further, many electronic means of generating 'perfect' code will sound recognizably different! I have participated in contests and known from just a couple letters that I had already contacted someone that I could hear again later on, so different was the sound.

There are lots of ways to distinguish oneself, and to me as an Instructor, the style of students' code, their idioms, how clear and understandable it is... are all as obvious and unique as the nose on your face. No need for applying makeup to your screens.

• Not imploring. The reason for registering is that you (a) get to edit your posts for clarification, and (b) avoid others editing them beyond your recognition. Also, you could consider it to be a curtesy to those who want to assist you. You can still be anonymous, as I am. One question that we suspect was written by yourself was closed simply because we couldn't be sure of your intent and didn't know how to improve it. It became a kind of cruft. But you may not even see this comment, not being registered and therefore notified of its existence. – Buffy Mar 27 '18 at 17:42