Dealing with (annoying) people (and their code)

Quote:

What's the best approach if I now have to teach a lot of them how to use blender and povray, and after that python (for use scripting)?

So, what is your relative position? Are you a teacher, a peer, assistant, ....

Very likely you've done a homework assignment for him, which he will hand in under his name.

When someone trows blanket statements like "you should always remember the big-O notation of algorithms you make" at you, you should tell them to go back to class and learn the basics before lecturing you. Or, you should just ignore them in the first place.

A single big-O notation as such means nothing, and someone who deems himself a "contest" coder (whatever that means, anyway -- taking part in a constest does not mean you're winning) should know that. The actual performance of an algorithm depends on a lot more things.

To begin with, the big-O notation does not tell you anything about how fast something will run. It can at best tell you how your runtime will change as the problem size increases. And you cannot even be sure about this, due to cache/bandwidth/latency effects.

Also, there is average and worst case to consider. It can matter a lot whether there is a worst case and whether worst case input can occur, and how often it will occur. It can matter a lot (or can not matter at all) whether you have a guaranteed upper bound or not.

For example, cuckoo hashing has a guaranteed upper bound of 2 hashes and 2 memory accesses, which sounds great, and which can indeed be something you need if you do realtime stuff. Insertions are somewhat more expensive, but so what.
On the other hand, plain normal hashing with chaining can be nearly twice as fast if your table does not fit into the cache.

Having said that, O(n log(n)) or O(n) can very well be faster than O(log(n)). Quicksort is a good example of an algorithm which is not the newest and not the fastest, but still outperforms all "better" algorithms in 99% of all practical cases (especially if the worst case is dealt with separately).

A similar example is hashing with chaining versus binary trees on huge datasets. Hashing alone is of course O(1), but the chaining is O(N). A binary tree is O(log(n)). So, a binary tree is obviously much faster. Yet, when you have a database with a few gigabytes of index, a hash index will usually be the clear winner. Why?
A tree index requires 6-8 random accesses when there are a few million records. The hash index needs exactly one random access.
If only two of the accesses that the tree index must make are not paged in, the time blocking on IO will be a hundred times longer than whatever O(n) time the hash could possibly need to iterate over its puny chain.

Why do you care what they think?

You got interested enough to tell them your view, which is fine since you're in a learning environment. You've shared. That's all you can do. You cannot force them to change their mind, and you shouldn't bother. It is their responsibility, not yours, to learn and develop.

You're in school. Take what they say and learn it, then keep both ways filed away in your brain, using it to improve yourself.

Quote:

Original post by samoth To begin with, the big-O notation does not tell you anything about how fast something will run. It can at best tell you how your runtime will change as the problem size increases. And you cannot even be sure about this, due to cache/bandwidth/latency effects.

Yeah, some valid points there; your mileage can vary, depending on what you are doing. But a high level assessment of performance should be a always priority over any micro-optimisation, in my opinion. Especially in the early design stages of your algorithm, unless you enjoy doing complete tear-downs on a regular basis.

For instance, you'd seriously consider the high level cost of various data structure traversal methods for geometry queries, space partitioning, culling, and so on. Especially when dealing with large databases. The impact of these design decisions generally outweigh most low level, hardware specific penalties by a large margin. Pick any cache friendly algorithm in the world, it will not make a difference if it ends up processing three times as much data, compared to a half decent big-O algorithm that is not cache friendly.

That's not to say that low level impacts are not important, they are, but they can be usually solved once the high level stuff is in place.

Thank you for the replies.
@Antheus:
I'm a peer.
The reason I have to teach them python is because I'm doing it as a part of a series student run initiatives inside our cs club. That said, this does put me in the role of teacher of around ten other students. I've never really become too active within the main branch of the cs club because I've been working on my own projects. Hence, no top scores within competitions to brag about (although I am doing several this year and hope to do well).

@Samoth:
Yeah. My sentiments exactly. I didn't really want to be too harsh because these were some of my first interactions with the guy. O() truly doesn't say much about how fast something runs, but in theory it should (since of course it is a measure of how costly-operations scale with the size of your dataset/other variables)

@frob:
That would be okay if I didn't have to teach ten people with similar mindsets today/every friday for the course of the year. I'm really only doing this because there will be around five people I am teaching who are really friendly and have things to share with me that I might not know about. It would be really nice if I could learn a good way of explaining things to these people such that they would get it, however:
a) They like c code to the point where I'm going to have to give them c programs along with every python script (or include the c equivalent in the comments)
b) They have... odd... beliefs about cs. Another such example is that someone in the class will most definitely try to look smart by pointing out every special case where what I say isn't true. I know this because I have been in a class with him, and he objected to every algorithm my teacher presented by basically saying "Well, if [precondition of the algorithm] wasn't there, it wouldn't work. oops!" (yes, he ended it in oops, always)
c) I am classically bad at explaining things. Generally, I can't give an algorithm outright (in my words at least) to someone and have them understand it. I have to walk them through several examples of how the algorithm accomplishes its function (such as what I'm attempting here).

@Tachikoma:
True. True.

This really has nothing to do with programming. It's a soft-skills issue. As such, moved to the Lounge.

Wow. I'm pretty shocked. I don't get to interact with lots of programmers on a daily basis as I work from a home office. Plus, I can imagine that in your (school) environment, you still have those "cocky-go-lucky" fools just like on our old high school football teams. If we got a penny for every arrogant punk we encountered in school (and another penny if he was full of it and knew nothing), then we'd all be dining with Billy and Donny tonight. :) haha

Just the fact that this guys says "oh Java sucks" and tries to tell YOU what you should be doing demonstrates that you shouldn't care what he says or thinks. I personally don't LIKE Java, but I wouldn't dare say such a thing...one of my favorite simulations of all time is written primarily in Java (IL-2 Sturmovik). He's just a "contest coder", haha. You guys should come up with a derogatory term for them, like "Connies"... Usage: "****, this school is full of baby Connies!" hahaha. :D

And the story about the guy objecting to every algorithm the teacher presented and adding "...oops!" to the end; WOW... WOW... He should find himself hanging from the flagpole by his boxers. heheh! There's a case for everything in programming where it won't work. So I guess we should just stop programming altogether because it won't work under all conditions? :)

@lefthandman:
This sounds a lot like my experience with other programmers in college. Only your peers seem a lot more knowledgeable- probably because my fellow students mostly stayed out of the contest coding scene.

Contests aside, I have noticed that programmers these days are developing a competitive nature about them. Venturing out on a limb here, I would guess this is because programmers tend to be nerdy. Thus, they have little to socially 'show off' outside of of their programming prowess. I'm guilty of this to an extent; I'm just not a douche about it.

The worst thing for me to deal with was the fact that professors and other students gave them praise for their arrogance- thinking that these guys had so much raw knowledge. Of course, this only fueled their behavior, and the cycle continued.

Theories aside, I'll tell you how I dealt with it: I ignored them. I ignored them, continued to teach myself game programming, and let them agonize over their big-o notation ego-parties.

The result?

I've been a professional game programmer since college.
They have either become Java codemonkeys (nothing against Java- I love it, but don't ever get to use it!), or they are unemployed due to not being able to program on a professional level.

So my advice is to ignore them. Don't remove yourself from the social scene however. Just ignore them when they start exhibiting bad behavior. I guess I'd treat it like training a dog without negative reinforcement.

When I went to university I also had to deal with a couple of contest coders myself, but not a lot, fortunately. When they made assertions about something, I always asked them why, and got them to explain in detail. Generally this is the point where I could differentiate between coders who knew what they were talking about and those who didn't.

Also, if someone says that you doesn't need to learn "xyz", because it's inefficient, always tell them that learning weak algorithms are just as important as learning the good ones, so you won't make bad design decisions later.

tell him this: Don't write shit code.

Big O notation can kiss my ass, im still the most efficient coder in my office.

Quote:

Original post by RivieraKid tell him this: Don't write shit code. Big O notation can kiss my ass, im still the most efficient coder in my office.

++1 for the flare and confidence and ++2 for the style. :) That's essentially what it boils down...

Quote:

Original post by lefthandman a) They like c code to the point where I'm going to have to give them c programs along with every python script (or include the c equivalent in the comments)

Or, you could just not give them a C equivalent. If they were learning from a regular instructor they probably wouldn't get this and they would just have to deal with it.

Quote:

c) I am classically bad at explaining things. Generally, I can't give an algorithm outright (in my words at least) to someone and have them understand it.

You should work on this -- not just for your current problem, but because it will be helpful in the workplace and in life in general.

Find other people who are good at explaining things and examine what it is that makes them easy to understand. Get feedback from people on what you could improve. Try recording yourself and listening for things you could have said better.

When explaining something take a moment to consider your words before speaking -- a slight pause seems longer to the speaker than to the listener and should not bother your audience unless it becomes excessive.

Aim to be concise whilst still covering all the relevant details; the shortest explanation that clearly covers all points is usually the best one as it is more easily digested and more likely to be remembered. Apply general public-speaking and speech-writing ideas to your explanations.

Practice, practice, practice. Explaining yourself clearly and efficiently is a skill you can learn and improve, and doing so is well worth some effort.

Quote:

Original post by samoth Very likely you've done a homework assignment for him, which he will hand in under his name. When someone trows blanket statements like "you should always remember the big-O notation of algorithms you make" at you, you should tell them to go back to class and learn the basics before lecturing you. Or, you should just ignore them in the first place. A single big-O notation as such means nothing, and someone who deems himself a "contest" coder (whatever that means, anyway -- taking part in a constest does not mean you're winning) should know that. The actual performance of an algorithm depends on a lot more things. To begin with, the big-O notation does not tell you anything about how fast something will run. It can at best tell you how your runtime will change as the problem size increases. And you cannot even be sure about this, due to cache/bandwidth/latency effects.

Sorry, but you don't sound like you know much about contest programming.

Contest programming (USACO, TopCoder, etc) is NOT software engineering or even really about programming that much. It is much more about mathematics and algorithms and computer science theory. You are not writing code that will ever be used in real life, or needs to be maintainable or readable. It has to work exactly once, on a well-defined set of input ranges.

Good coding practices go out of the window. And big-O is typically king because normally the input data is set up that your very fast O(n^2) will crash and burn on the corner-cases, while a slow O(nlogn) will pass.

It's fascinating and will likely make you feel kind of dumb if you're used to thinking of yourself as a great programmer.

Contest programmers don't automatically make great software developers, the opposite is also true. It's more like being in a competitive math club... the crossover with writing a DB/web-app is quite low.

Question to the OP:
Are we talking about code written for work here? Or hobby programming? Who is right depends on the context. On TopCoder, your friends might be in the right. Writing production code, everyone else is right... in real life application programming, algorithms are rarely (not always) a huge factor unless you are working on something unusual. The number of times I've found dynamic programming/memoization to be useful in application or game development is tiny.

Quote:

It has to work exactly once, on a well-defined set of input ranges.

You just defined engineering.

Quote:

You are not writing code that will ever be used in real life, or needs to be maintainable or readable.

The maintainable and readable is something that is relevant in commodity development. It's the "do not touch handsaw blade while the saw is turned on" label.

Well engineered code does what it has to do in simplest possible way. It is readable by definition, since there exists no simpler way to solve the problem. To paraphrase Gandalf: "A well engineered code is not good or bad. It is precisely as readable and maintainable as it needs to be".

The readable and maintable is hyped in CRUD development, where bulk of people developing the projects are not programmers, CS or SE, they are random participants who went through a two week course in language or framework. Majority of IT does not need, or even want, engineers.

TV and other consumer electronic shops frequently state a requirement: "No electrical engineers". They do not want highly skilled people since all they need is a person to learn how to change an electrical plug or how to replace a fuse. Highly educated/skilled people end up bored on the first day and start exhibiting sub-par performance.

This was determined during Manhattan project. They had brightest minds in entire world. Then they brought in a bunch of operators or technicians, mostly women, who were put in charge of controls. Suddenly, results improved drastically. Explanation is very intuitive. When you are world-class nuclear physicist, pushing boundaries of knowledge, you will not be able to leave a gauge slightly off. You will come up with theories, experiments, endlessly tweaking the knobs, causing all kinds of issues.

Here is where engineering comes in. It's not about perfection. It is about defining operating ranges, then asserting that system operates within. These are called "nominal" values. Car engines operate within nominal values. This is why it's possible to put roughly similar fuel or oil in them. As long as it meets some basic requirements. Meanwhile, F1 or NASCAR use per-molecule tweaks to maximize fuel efficiency.

Quote:

Good coding practices go out of the window. And big-O is typically king because normally the input data is set up that your very fast O(n^2) will crash and burn on the corner-cases, while a slow O(nlogn) will pass.

This is true. Inferior solution will often work for the duration of the project.

The goal of these contests is not that. These contests serve to find those handful of individuals which are, by default, capable of finding superior solutions. Nobody is best - but engineering can be learned, automated or outsourced. The goal of these contests is to raise the bar for free. The potential brilliance of the top coders allows higher abstractions.

Quote:

Contest programmers don't automatically make great software developers, the opposite is also true.

They don't. The probability of finding a good software developer between contenders is same as in general population - software development is orthogonal to math skills.

The goal is to identify best problem solvers, then filter them out by applicability for certain job. With global market it has become possible to filter out from entire population. And there exists a handful of developers which are great problem solvers, fantastic coders and disciplined engineers. There might be only a 1000 world-wide, but to companies that can recruit them they are worth the weight in gold.

Quote:

The number of times I've found dynamic programming/memoization to be useful in application or game development is tiny.

Have you tried solving more difficult problems?

For example, assuming you are running a simple web app. A cheap Django coder can set it up for a few bucks.

How about applying statistics and probability along with artificial model to analyze visitors, then training a genetic algorithm to predict impact of UI changes on conversion rates? Or, doing statistical analysis over operation data to predict or detect failures or deviations or trends?

No, it's not "let's refactor this function using memoization". This is why raising the bar is important. Someone who struggles with for loops will always do so. They will never be able to reach this next level since they won't have time.

The goals of modern recruitment are identifying individuals with highest implicit skills. At this level it's not about saving on training. It's about finding people who operate at highest level by default, and then put them into environment where they can grow beyond that.

Obviously, most IT shops are a far cry from that, they just want $3.99 coders in bulk, hold the onions, while they are bidding time before they become obsolete entirely through automation.

But regardless of which group of people one takes, personality is different from other skills, and all ranges exist in every group. Some are just plain assholes.



How is this relevant to OP:
There is nothing at stake. Regardless of whether a solution presented by either side is good or bad, there is no criteria to determine which is good or bad. The terms good, bad, right, wrong, evil exist in fairy tales.

In IT, it depends solely on what sells and frequently what prolongs the problem.

If it needs to be engineered, there will exist a pass or fail criteria. Solution will either meet it or not. All of this makes the debate completely moot in all cases. Whether it's a n^2 or logn, it will merely pass or fail, there will not be a better or worse solution. Engineering is very boring.

This is why fights in academia are so relentless. The stakes are just too low.

Oh my god. (not like you don't hear this everywhere on the internet already)
Wow, you guys keep on giving me better and better advice! Yeah, I don't really care what they think.
Ok, so what I will be doing next week (after having read all your insightful responses :) ) is trying to get better at just explaining things because there seems to be a general consensus that I should ignore these people and not give in to the dark side and bash them across the face with a verbal shovel. So yeah, basically when they blurt out something frustrating I'm going to ignore it and keep on talking. I'll also try and follow jbadams guidelines because they seem to relate highly to what I am doing wrong right now. I have a great teacher/mentor, and I'm really not taking advantage of that. He is probably the person I should be observing to better my explaining capabilities. Also, good tip about not talking for the sake of trying to fill any gaps in my speech, those gaps do seem really long to me and I'll try just enduring the agony for the sake of letting my mind slow down and think about what I'll say next.
@d000hg:
I'm talking about me (person who doesn't do TopCoder, but might try whatever his friends are doing to finally see what it's like this year) talking to person who may do TopCoder/USACO/other contests. My definition of viable solution is very different from his definition. This doesn't really change the fact that I have to teach them how to do useful things in blender/povray/python. Yeah, basically there's no right/wrong answer, it all depends on what's asked of you. However, I have a feeling I won't get very pretty code out of these people.
"When I went to university I also had to deal with a couple of contest coders myself, but not a lot, fortunately. When they made assertions about something, I always asked them why, and got them to explain in detail. Generally this is the point where I could differentiate between coders who knew what they were talking about and those who didn't.

Also, if someone says that you doesn't need to learn "xyz", because it's inefficient, always tell them that learning weak algorithms are just as important as learning the good ones, so you won't make bad design decisions later." - Tachikoma
Quoted for truth. I think that this will work brilliantly because:
a) It's a short answer compared to the alternative of proving the use of these algorithms to stubborn people.
b) It gives me a way of truly knowing which of these contest coders I would have the most luck explaining things to.
c) It lets me know when I'm logically wrong (aka, they actually answer correctly and prove that their assertion is valid). This is always a good thing, because it's not like every time I say something it's got to be correct. Sometimes some of their assertions might actually be truthful and I can't just rule them out because they give no explanation right off the bat.
Also, Antheus has a good point in that these people probably don't represent all Contest Coders. The point of these competitions is to narrow down the field for potential employers. The ability to spot ~100 truly talented problem solvers is really useful. Also, to further prove his point, I have looked at some of these contests and they actually post the winning code. Yep, that means if these people are winning at contests these employers get to see the code that let them win (which is a really good argument for commented, nicely written code). Not going to generalize that statement to all of them, but for those contests that do do this, it just legitimatizes them further with me.

Quote:

Original post by Antheus...

I can't really see what kind of point you're trying to make. If you look at code written by the top guys in the world at contest programming (who are incredible btw) during a timed contest, it is UGLY. It's not engineered, if you were shown it in a regular context you'd probably struggle to even understand it.

On the applicability of algorithms to real-life... I've been developing in fields from 3D graphics to MMO servers to banking data analysis, rather than mostly doing typical GUI/DB apps. And still, I rarely write anything that merits algorithmical analysis. It's kind of a shame actually, it'd be nice if there were more times I had to spend a few days thinking up a smart algorithm. But considering how few software developers ever study algorithms at any non-trivial level, that tells its own story.

Quote:

Original post by d000hg I can't really see what kind of point you're trying to make. If you look at code written by the top guys in the world at contest programming (who are incredible btw) during a timed contest, it is UGLY. It's not engineered, if you were shown it in a regular context you'd probably struggle to even understand it.

First and foremost, the solution, whatever it is, needs to produce correct results. A pretty solution which doesn't do that isn't worth anything. This is engineering, finding a minimal (cost optimal) solution that completely satisfies the requirements. Those contests perfectly match the requirement, documentation is not relevant considering they are timed competitions and documentation doesn't iterate towards solution faster.

Looking around production code, one quickly learns that there are two types of code: pretty code and one that is actually used. This is simple reality.

At this point one starts talking in shades of gray. Given two solutions to same problem, side by side, one can always choose the "prettier" one.

Regarding "readability" - it's subjective and depends on people working with such code. Every IT developer will agree Linux kernel is a messy pile of crud. Now, if only we could get them to post on kernel mailing list suggest they improve their code. They should start using cutting edge best practices and apply Patterns and BDD. And use Ruby. Oh what fun it would be...

Complex problems require complex solutions. I can read Riemann hypothesis just fine. But I wouldn't know what to do with it to save my life. I understand the text, the symbols, the graphs - but have no clue what it is and likely lack the background to do so, let alone comprehend its applications.

See the problem - there is no absolute scale on what readability and maintainability means. Linux would fail on every count of every criteria, yet it is several orders of magnitude more maintainable than majority of IT applications developed with best practices as proven by actual work done. In IT projects regularly become unmaintainable, where each starts to require man-years of effort.


Ironically, the coding competition solutions are incredibly easy to read. There are only about four classes of algorithms which are used and about two different techniques on how one goes implementing them. It's Algorithms and Data Structures 101 and 201-grade.


The problem I have is with terminology. Too much droning about regarding "best practices" and "readable" and "maintainable". It's bike shed. What companies really mean is "will our off-shore team be able to fix bugs in it and add features". Otherwise - is your coworker happy about it?

It's similar to Sapir-Whorf hypothesis. Language determines concepts that can be expressed. It's dead true in programming, but it cuts both ways. So-called contest coders will almost certainly have problems with typical IT practices and vice-versa. But each of these is solving different problems, so that's fine.


I just get increasingly annoyed with weasel words being thrown around, especially when engineering is discussed. Let's define the parameters and then what is or isn't readable or maintainable becomes just a matter of looking up reference literature and case studies.

A solution to a TopCoder problem might be easy to read/understand if you have the question in front of you, and are familiar with algorithms (this part can maybe be considered a given). If you're just given the code, figuring out why there is a var called v[10][20][5] and what f4() does might be tricky, as might working out on what conditions the thing stops working... like the problem might stipulate the input is always sorted some way, or all strings are upper case, etc.

People who say "standards aren't important" worry me as they sound like they might fall into the stereotype of individuals who can quote the C++ spec backwards and shave 5 bits off the size of a data structure, but are unable to work in any kind of team... refuse to use source control, randomly change other peoples' code to meet their own rules, and generally spend a lot of time telling everyone how great they are.

Certain high-profile folks in the Linux world seem to meet that criteria [wink]. You're happy for the work they've done but would hate to work alongside them and wouldn't hire them to work with your other developers for fear of the whole team quitting. Ultimately software development is a team endeavour, and like sport sometimes the best person for your team isn't the best individual player.