Overcoming Intuition In Programming (amasad.me)

An anonymous reader writes: Amjad Masad, a programmer who works at Facebook, has put up a post about intuition and programming. It's based on a series of experiments (PDF) into how the presentation of a problem affects the learning involved in solving it. Researchers found that if they made a test deliberately hard to understand, those taking the test would exhibit greater understanding after solving it than those who were presented with a more intuitive wording of the same problem. Masad discusses how the research applies to software engineering: "Programming is an intellectually challenging task, but luckily we invent tools to make it manageable. I find that up to a certain point, the intuitive and easy properties of a given language, framework, or library might start to have negative effects.

From personal experience and from mentoring beginners I noticed that when using tools that allow us to reason within our intuition, anytime we're faced with some difficulty we feel that we've done something wrong. And although we might have the necessary skills to overcome the difficulty, we often start questioning and revising our work." He concludes, "Code reuse, libraries, sharing, and open-source are very important to software engineering, but we should be careful to not enable the belief that programming should be as easy as gluing things together."

Comments

Too Late

[chill]

"Code reuse, libraries, sharing, and open-source are very important to software engineering, but we should be careful to not enable the belief that programming should be as easy as gluing things together."

That is the management view of programming and a major corporate goal. This way it reduces the skills needed to complete the task, and hence you can pay less for the less skilled laborers.

Why do you think the average salary of a Windows Admin is lower than that of a Unix/Linux Admin? Because Microsoft pushed the "we've made it simple, just push the button" marketing drek and aimed it squarely at the management crowd -- who bought it hook, line and sinker.

"They made it easy, so I shouldn't have to pay you as much because anyone can do it. I'll just hire some kid with the latest MS cert..."

Re:Too Late

[TsuruchiBrian]

If MS made their software easy enough to use that a low skilled person can do it, isn't that a good thing?

Re:Too Late

[DigiShaman]

Which is funny, because in the world of Windows Administration, either you're a complete idiot, or an experienced Windows sage that's very good at cleaning up other peoples mess, and running the network properly. There is no middle ground unless you've gained the experience under the wing of such a sage.

Re:Too Late

[TemporalBeing]

If MS made their software easy enough to use that a low skilled person can do it, isn't that a good thing?

Only for Microsoft and their Partner when stuff breaks and you have to bring in experts because it's really foobar'd up the wazoo, so much so that only hands-on work by MS can solve the problem - on and it comes at really high billing rates too.

Re:Too Late

[gstoddart]

Right up until you meet the limits of what a low skilled person can do.

And then you can quickly get into uncharted territory which requires much more understanding.

Sure, that low skilled person can do "some", "many", or possibly even "most" of the tasks. And they can also drive you off a cliff through lack of understanding.

Anybody who has ever dealt with outsourced admins who can follow a script can tell you that when those people go outside of the script they will become utterly useless, if not outright dangerous.

And at that point, you're deeply screwed if there's not someone around who actually understands the rest of the stuff. It's not pretty to watch some noob with a little knowledge completely screw up a corporate environment.

Re:Too Late

[Rhacman]

There tends to be a perception amongst the Linux crowd that things like email and web browsing should be easy (to foster greater Linux adoption) while things like system administration *should* be hard (to discourage newbs / the uneducated, and to forgive clunky, inconsistent, and poorly documented tools).

Re:Too Late

[epyT-R]

There tends to be a perception amongst the windows/mac and web 3.0/mobile crowd that complex things be made simple at any cost, even if the result is only the appearance of simplicity, just to give newbs the impression they understand more than they actually do.

Re:Too Late

[Anonymous Coward]

Why do you think the average salary of a Windows Admin is lower than that of a Unix/Linux Admin? Because Microsoft pushed the "we've made it simple, just push the button" marketing drek and aimed it squarely at the management crowd -- who bought it hook, line and sinker.

"They made it easy, so I shouldn't have to pay you as much because anyone can do it. I'll just hire some kid with the latest MS cert..."

It's more complicated than that. Salaries are lower because there's a herd of "kids with the latest MS Cert" that also bought into the "it's easy" line of thinking. It's not, but it sure looks that way. Managers are always looking to save a dollar of course, and many of them don't have any ability to distinguish talent from dreck. Even after they hire the dreck, they might be forced to put up with it as the "new normal".

It stems from a mentality of measuring salaries, but not measuring consequences of fucking up. Let's say John knows what the hell he's doing, but is paid $120,000 a year and rarely screws things up. John managed to increase productivity and save $50,000 last year through some innovative thinking. Joel is paid $50,000, but is constantly fucking shit up. Just last week Joel took down the network through one of his changes, and cost the company $20,000 in lost productivity. Over the past year Joel has cost the company approximately $200,000 in lost productivity due to his own point/click mentality and a management team that encourages this rather than learning and risk management.

So John costs $70,000 a year, and Joel costs $250,000 if you add up all the costs and savings from each. Yet if you only look at salaries, it looks like John should be replaced with 2 Joels, at a cost savings of $20,000!

So part of the problem is not measuring employees true worth.

Re:Too Late

[yagu]

There should be a moderation category "Scary".

Re:Too Late

[angel'o'sphere]

In my country both get payed the same, actually MS jockeys a bit more as they are rather rare. No one really wants to administrate such systems.

Re:Too Late

[TsuruchiBrian]

First of all I didn't say that MS's software is easy to use. I merely suggested that *if* MS software was easier to use (requiring less skill/effort for the same result), that that would be a good thing. Chill (the person I was responding to, seems to be suggesting the opposite is true (i.e. it's better if the software is harder to use).

Second of all, I would say that the job of software is precisely to make hard things easy. If the goal was to create a jet powered bike, then good software would generate a good design, rather than simply a design calling for the 2 to be duct taped together. You don't even need software to come up with a bad design, humans alone are perfectly capable of doing this without any help.

Re:Too Late

[aix tom]

I always like "update holidays" in our company.

The Windows Admins run around sweating, clicking this clicking that, checking there, trying thing a couple of time in the test environment, then switching to live, etc.....

I recline in my chair, open a terminal to run the update scripts I have tested beforehand, and a Media Player to watch some TV shows while they run. The thing is, the "little things" I have to install on the Windows machines are also scripted the same way, while the "Little things" the Windows Admins need to do on the Linux machines they also use some GUI Tool.

90% of "System Administration" is "knowing how things work" For example the technicalities on how IPs/Network-Masks/Gateways/routes, etc... work are absolutely identical in both Windows, Linux, IOs, whatever. There used to be a time when the only way to set them in Linux was the CLI, and the only way to set them in Windows was the GUI. That is no longer true. Now you can also use a CLI in Windows and GUI-Packages to manage them in Linux. The same way that most Cloud/Web/Whatever applications can be administered either via a GUI or a CLI.

So the difference is not really Linux/Windows any more, it's more of a GUI / CLI thing. So any admin might need to learn three things:

- How "Stuff" works.
- How do set up "Stuff" via the CLI.
- How do set up "Stuff" via the GUI.

It's interesting that even Microsoft (for example with SQLServer) only expose "the most commonly used" settings via the GUI (SQLServer Management Studio), while "all" are available via the sp_configure procedure that can be called from the CLI.

So in system administration I have either the option to:

- Learn "Stuff"
- Learn the GUI
- and then a few month later when I'm bored out of my skull by repetitive steps I need to do over and over in the GUI to learn the CLI to automate it maybe sometime later.

- Learn "Stuff"
- Learn the CLI
- go on learning new "Stuff" after the boring jobs have been automated.

Re:Too Late

[TsuruchiBrian]

Right up until you meet the limits of what a low skilled person can do.

There is always a limit to what a person of any skill level can do. All I am suggesting is that raising that limit is a good good thing, even if it means accomplishing a task pays less money.

For example I don't think it's a bad thing that any idiot can look at google maps and have a very accurate set of directions. I think it would be worse if getting good directions required a very highly skilled and well compensated cartographer.

Re:Too Late

[Pseudonym]

The Principle of Charity is the first lecture in any decent university-level critical thinking course. It should be required knowledge for any Slashdot comment thread.

Re:Too Late

[TsuruchiBrian]

A shallow understanding of the way some things work is necessary to being productive. If a library has a good API I can use it's functionality effectively without understanding exactly how it works. There have been plenty of bad libraries with bad APIs that have forced me to learn exactly how they work, but I wouldn't consider this effective use of my time.

Some things are very important to understand in detail, and some things are not.

In fact part of the art of writing a good library or a good API is making it so that people can use it without knowing the implementation details.

Obviously a "deep" understanding is better than a "shallow" understanding. But usually the tradeoff is broad vs. narrow.

Of all the resources one might consider important to save in the endeavor of software development CPU cycles, memory usage, etc. I would argue that the most limited resource is the man hours of engineers' time. It's not a question of *should* the engineer have a deep understanding of XYZ, the question is, what things are the most important for the engineer to spend time working on and developing an understanding of.

Re:Too Late

[TemporalBeing]

I am not making any claims about how hard or easy or how much skill is required to be a windows admin. All I am asking is this:

Scenario A: It requires 10 highly skilled admins to do job X.

Scenario B: It requires 2 highly skilled admins and 8 low skilled admins to do job X.

Isn't Scenario B better? The person I originally responded to seemed to be suggesting that Scenario A was better because it meant 10 people were highly paid rather than just 2.

I would say it depends on what X is.

My primary point was that X being Microsoft Exchange or any of the other big tools that Microsoft markets towards Scenario B is ripe for problems since those low skilled admins will create a lot of problems that fewer higher skilled admins would have prevented.

And the fact that you're comparing 10 high skilled versus 2 high skilled plus 8 lower skilled also highlights the problem because in reality the comparison would more likely be:

5 high skilled admins to do job X.
1 high skilled admins and 40 low skilled admins to do job X.

1 good high skilled admin is usually worth at least 10 low skilled admins.

The other problem with your scenario is that the low skilled admins work at the behest of the high skilled admin; and they'll usually be LOWER skilled than they should be (e.g fresh off the certificate farm or out of school) so they're really worth even less.

You can often see this in Windows versus Unix admins where a single high skilled Windows admin will only administer a handful (typically 5, though less than 10) boxes at a time, while a typical Unix/Linux admin will be administering 100+. So again, it depends on what X is.

The sad thing is that management will often use the argument you use to "reduce costs" - but in the end cost themselves more because of the foobars of the lower skilled admins or because they changed models from a cheaper model with more highly skilled admins (e.g 5 high skilled Unix Admins with 500 servers) to a "cheaper" model with lower skilled admins (e.g 2 high skilled Windows Admin and 6 low skilled Windows Admin with 40 servers that all cost more than the 500 servers) but they're "saving" on human costs (not really, but that's how they sell it).

Or take the recent off-shoring of technical services (such as Help Desk) where a small team in the US (or Canada or anywhere in Europe) got replaced by a larger and cheaper team in India. They've discovered that it's not really advantageous to do so - it really does cost more to offshore than keep local people because of all the mistakes the cheaper workers will make - whether cultural differences leading miscommunication or other things of similar nature, ultimately costing customers which makes dents in the bottom lines.

So it really does depend on what X is and what you're trying to do with it or whether you're trying to replace Y with it, and how all the numbers work out. You'll often be surprised to find that what you thought was a cheaper route isn't.

Re:Too Late

[TsuruchiBrian]

I would say it depends on what X is.

Of course it does

My primary point was that X being Microsoft Exchange or any of the other big tools that Microsoft markets towards Scenario B is ripe for problems since those low skilled admins will create a lot of problems that fewer higher skilled admins would have prevented.

Sure there are lots of jobs like that. My job is like that.

And the fact that you're comparing 10 high skilled versus 2 high skilled plus 8 lower skilled also highlights the problem because in reality the comparison would more likely be:
5 high skilled admins to do job X.
1 high skilled admins and 40 low skilled admins to do job X.

1 good high skilled admin is usually worth at least 10 low skilled admins.

Sure. For jobs like that you just don't hire low skilled workers, because it is not economically efficient. But if you can make a job a little easier, you should be able to hire at least slightly less skilled workers or at least fewer workers of equal skill.

All I am saying is that if you make a job easier to the point where it is actually easier (i.e.not just perception), that is a good thing. This is in contrast to the suggestion that making jobs easier is not good, because it lowers wages.

And yes, whether you can *actually* make job X easier is always an open question. If you can only make Job X seem easier (but not actually easier) then you shouldn't do that because having bad information just wastes resources (e.g. time, money, etc).

This message brought to you by..

[DarkOx]

Researchers found that if they made a test deliberately hard to understand, those taking the test would exhibit greater understanding after solving it than those who were presented with a more intuitive wording of the same problem.

Paid for by the society of project managers and business software analysts.

Re:Oh you mean you want unintuitive code

[pollarda]

I think that what they are trying to say is that if we all are presented with problems that we solve in assembler then we will develop a very good understanding of how to solve a large number of problems computationally as we will have a very good understanding of the underlying computer architecture. (How's that for a long sentence?)

I've known a lot of brilliant assembler programmers and I have to admit, I've always admired them for their skills. Even so, I can get a whole lot more done than they can using C/C++. I'm sure for a lot of projects someone else can get a lot more done than I can using Python but they will probably not have the same level of understanding as the assembler guy.

Specialization

[Tony Isaac]

Code reuse, libraries, sharing, and open-source are very important to software engineering, but we should be careful to not enable the belief that programming should be as easy as gluing things together

This is the wrong conclusion. Most of the time, we should give preference to tools and practices that have already become best practices, without necessarily questioning each one every time. Of course, there is room for challenging best practices and libraries, but that's for people who are interested more in the best practices and libraries, than for the people trying to use them to create something useful to end users.

You don't need to know how to repair a car to drive one. The guy who repairs your car doesn't need to know how to build a motor or a transmission, only how to install them. The guy who assembles the motor doesn't need to know the finer points of metallurgy. The guy who refines the metals doesn't need to know the finer points of mining. Each of these stages of production can have their own issues that need to be resolved, but the guy driving the car needs to worry only about staying safe on the road and reaching his destination.

Programming should be the same way. I shouldn't have to debug the IP stack to make my program connect to the Internet, nor should I have to reinvent build systems to produce a product.

Specialize!

Re:Specialization

[Ichijo]

You don't need to know how to repair a car to drive one.

Of the two, would you prefer to have a mechanic or a non-mechanic drive you to the other side of the country?

Re:Specialization

[quietwalker]

I've noted that businesses that have historically shown high growth and apparent long term stability seem to be looking for "T-shaped" employees. These are employees who know a little about a lot (a wide horizontal) and a lot about a little (a narrow vertical). Specialization is good, but you have to know enough to be able to respecialize in anything else quickly, which means dabbling in a bit of everything so that it's at least familiar.

Basically, a jack of all trades AND a master of one.

To use your analogy, you don't need to know how to rebuild the motor in order to drive the car, but you should be aware of all the parts and how they operate, so that way when something makes a noise, you not only know what it likely is, you either know how to fix it (or if it even needs fixing) and where to start looking for the information on how to fix it - even if you lack the tools or experience to do so.

Re:Oh you mean you want unintuitive code

[chill]

The key is once you get a good knowledge of assembler, you stop using assembler as a general purpose tool and only use it were it would benefit.

Back in the day ham radio exams in parts of the world required building a functioning radio from supplied parts. You had to know how a radio worked, in the abstract.

That doesn't mean that once you have that knowledge you forever build your own radios from unassembled kit.

Re:Glueing things together is how I teach OO desig

[Austerity Empowers]

C weilding academic to me

Say what? I don't know too many (computer science) academics who'd touch C with a ten foot pole. Those of us who use C do it for real work (and like it/won't get off it).

If I want to live in an ivory tower I'd either a) use the latest theory compliant language/compiler du jour or b) refuse to code at all since that is an implementation issue, and instead pontificate on what is missing from latest language.

Odd title

[Etcetera]

A better title might be "Why Hipster Coders Shouldn't Think Super-High-Level JS-Framework-of-the-Month Calls Mean You're a Good Programmer"

It's hard not to extend this to a #kidstoday rant, and I'm by no means arguing to go back to assembly, but at some point forcing large amounts of programming to the lowered-barrier of entry just reduces the percentage of folks who actually know what they're doing and can critically analyze the situation.

Re:Odd title

[gstoddart]

Yeah, I always found coding (and especially debugging) required a level of intuition ... precisely because it was more than just gluing pieces together.

I understand you don't want to rely too much on intuition, because it's hard to sound like anything other than voodoo, but sometimes the voodoo is still a real thing.

I worked with someone years ago who liked to go on about how everything should be abstracted and pretty/elegant according to whatever was popular that month. He read the books and magazines incessantly, and wouldn't shut up about them.

The problem is he often wrote shit code he couldn't maintain or debug because he'd abstracted things so much it was impossible for him to follow his own code, or know where to look when things went wrong. A small enhancement request left him squealing how the code wasn't designed to do that and he'd have to rebuild it. Meanwhile the rest of us went "so, all of that is in here, and if I just nudge this a little it's all done".

I'm sure he got better over time, but for someone who was so loudly a proponent of the latest language theories and methodologies, he never seemed to understand how his neat intellectual model in no way translated into maintainable, readable, or sometimes even useful code. But his insistence on following all of these things usually had the result of him making absolutely terrible design choices.

These frameworks and methodologies sound awesome on paper, but you can still use them to write complete garbage code which is brittle, inflexible, and often completely wrong for what you're trying to use it for.

Whereas the guys who learned to program and debug without the syntactic sugar and frameworks to build upon, those guys tended to have a bigger picture view of the pieces. Which means you can zero in on where you think it likely went sideways instead of staring blankly wondering why your monument to methodology is now a teetering mess you have no idea where to begin with when there's a problem.

Re:Odd title

[edtice1559]

I don't doubt your story but the problems we are solving today are more complex than the ones of years ago. In the 1970s if you wrote a nifty way to solve the quadratic equation you might be considered a super star. (Okay that was somewhat of a dramatization) But today we are dealing with much more complex domains. In many cases we are trying to model human behavior. It's simply not possible to solve these problems if we didn't have building blocks. What we really need is a good understanding of the problem we are trying to solve and enough technical skills to turn that understanding into something working. Getting the problem description right is where the heavy lifting should be. If the implementation involves fussing with tools rather than working on the problem, the tools should improve.

Re:Glueing things together is how I teach OO desig

[Rei]

Careful, C++ has its own share of unintuitive weirdness. Take the following example:

std::map<int, int> map;
map.emplace(1, 1);
auto iter = map.begin();
std::cout << iter->first << ", " << iter->second << std::endl;
map.emplace(0, 0);
std::cout << iter->first << ", " << iter->second << std::endl;

This prints out:

1, 1
1, 1

Nothing unusual there, right? std::map iterators are non-invalidating and you're not touching "iter", so it should be (and is) remaining the same. But what if we use reverse iterators (and correspondingly switch the side of the iterator we do the insert on)?

std::map<int, int> map;
map.emplace(1, 1);
auto reverse_iter = map.rbegin();
std::cout << reverse_iter->first << ", " << reverse_iter->second << std::endl;
map.emplace(2, 2);
std::cout << reverse_iter->first << ", " << reverse_iter->second << std::endl;

1, 1
2, 2

Despite sounding like the same sort of thing ("iterators"), forward and reverse operators have some very different properties in a key area. A non-invalidating forward iterator will always remain pointing to the exact same element regardless of what happens with other parts of the container. This does not apply to reverse iterators, as they are implemented in a rather unintuitive way - they actually point to the element after the element that they pretend to point to, and so changes to other elements can change what they appear to point to.

There's a lot of things like this in C++ that can slip past a person for years before it actually bites them. Don't get me wrong, I love C++ and think C is a rather dangerous language (from a memory safety standpoint) that requires that its authors reinvent the wheel over and over again. But C++ does have some weirdness in places that can pose hazards. For example, from a more beginner-perspective, what percentage of users have at one point been frustrated by trying to understand why a pointer in one of their classes is getting freed unexpectedly, due to not realizing the dangers of the implicit copy constructor/assignment operator when it comes to pointers? I bet that's bit almost everyone at some point in their career. Sure, you can "reason out" that that would happen, but most people learn it by being bitten once or twice.

Pass me the glue

[zJe]

Gluing things together is how programming works. You start by gluing the small bits together to make bigger bits and so on and so on. Eventually you come to realize that when you need to use "Super Glue" to hold the bits together it's probably broken. Usually you glue bits together at discrete places, if you have to work on bits that have had the glue brushed on in large amounts, that's call accretion, avoid those bits, maybe put a layer of wax around them with tiny spots for glue.

Re:Glueing things together is how I teach OO desig

[quietwalker]

That's my experience as well, at least, as of the middle 90's. Why use a mainstream, commercial language, when you could use a theoretically complete one? One where they recognize that features like "output" and "input" are dirty exceptions that spoil the purity of your program when you're trying to get a good hard proof using Hoare logic.

Better not clutter up the syntax either by using confusing, pre-existing symbols to form constructs, not when you can add whole new symbols requiring a special (APL) keyboard!

I remember having a TA once challenge me - I had written an algorithm to operate iteratively, rather than recursively, because I had noticed the program would run out of memory if I did it the other way when fed large data sets - because to him, recursion was theoretically perfect and not using it was a personal affront. The fact that my code worked and his crashed after 4-5 minutes didn't matter.

To paraphrase a professor of mine, "There's absolutely no reason for a computer scientist to use a computer."

This sort of attitude was pretty rampant all throughout my college career, fairly startling having already been employed in the industry for some years prior. No concept of real world usage at all, or worse, some strange bias against it.

Re:Glueing things together is how I teach OO desig

[Darinbob]

I knew someone in late 90s who was upset that we weren't using Java for a highly complex embedded system used for medical work, and instead used something archaic like C++ (seriously, he thought it was archaic in its heyday). We'd explain to him that we can't throw out all the work and start from scratch without spending years, that Java at the time was terribly slow, that there were no distinct advantages of changing or reductions in complexity, etc. But it was his first job after his master's. Later on he started a (tiny) company and gave a keynote address at a Java conference where I heard third hand that he had put down his former employer for being such a dinosaur. It wasn't even that this guy was an academic idealist but that he merely was caught up in fandom.

Or maybe there was a culling

[EmperorOfCanada]

If something is made hard enough then only the most capable will survive the selection process. Can you imagine the quality of programmer that would exist if we only did everything in ASM? While the understanding that ASM programming might induce would be beneficial the reality is that maybe only 1 programmer in 20 would continue the process. Also productivity would be shot in the face.

For instance I really hate APIs where you have to have this huge pile of boilerplate with all kinds of factory classes pooping out this and that that you assemble into something that every other person using the API will do. Maybe it gives you a better peek into the internals but I would rather some kind of Init or Create function that gives me the end product that I and every other programmer wants. All that boilerplate might make my code look intimidating and keep the weak minded away but it didn't make me a better programmer by any amount to be worth the wasted time.

Re:Glueing things together is how I teach OO desig

[mrchaotica]

There's a lot of things like this in C++ that can slip past a person for years before it actually bites them. Don't get me wrong, I love C++ and think C is a rather dangerous language (from a memory safety standpoint) that requires that its authors reinvent the wheel over and over again. But C++ does have some weirdness in places that can pose hazards.

C++ doesn't have "weirdness," C++ has bad design. Literally anything that you might think C++ would be good for is better solved by either C#, C, or a combination of both.

Re:Glueing things together is how I teach OO desig

[mrchaotica]

If your C code leaks memory, you don't know WTF you're doing -- which is exactly why a department of CS professors who don't use C is so damn scary.

And I don't give a shit if you think you don't need to use pointers; that's fine. You still need to understand them so that -- if for no other reason -- you understand why in Java or C# not every IEnumerable should be a List.

Also, if you think a high-level language will save you from remote code exploits, I've got a bridge to sell you.

Re:Glueing things together is how I teach OO desig

[helixcode123]

I remember having a TA once challenge me - I had written an algorithm to operate iteratively, rather than recursively, because I had noticed the program would run out of memory if I did it the other way when fed large data sets - because to him, recursion was theoretically perfect and not using it was a personal affront. The fact that my code worked and his crashed after 4-5 minutes didn't matter.

Tail recursion optimization usually takes care of problems like that, assuming the problem was running out of stack.

Re:Glueing things together is how I teach OO desig

[Pseudonym]

Literally anything that you might think C++ would be good for is better solved by either C#, C, or a combination of both.

This makes literally no sense. With minor caveats, C++ is C with more stuff. Even if you only use (say) namespaces or a modest amount of ad-hoc overloading, C++ is a better C.

The main cause of problems with C++ is using it as an object-oriented language, but you'd have the same problem in C#. What Alex Stepanov rightly said about Java equally applies to C#: "I spent several months programming in Java. Contrary to its authors prediction, it did not grow on me. I did not find any new insights - for the first time in my life programming in a new language did not bring me new insights. It keeps all the stuff that I never use in C++ - inheritance, virtuals - OO gook - and removes the stuff that I find useful."

Re:Glueing things together is how I teach OO desig

[toddestan]

Even if you only use (say) namespaces or a modest amount of ad-hoc overloading, C++ is a better C.

That's fine for your own projects, but the problem comes in with dealing with other's code. Everyone seems to have their own subset of C++ they like to use. The problem is that everyone's subset is a bit different. So you have to be at least aware of everything in C++, just so you know it when you run across it. (once again, this doesn't apply for your own projects)

Re:Glueing things together is how I teach OO desig

[KGIII]

Let me preface this by saying that I'm a horrible programmer but I wrote many lines (many of which were not needed) in C back in the day.

Eventually, I reached the point where maintaining and improving that code was simply beyond my time limits and my ability. I am not a programmer. I learned because I had to. So, I hired professionals. They taught me a lot but, alas, I am still not a programmer.

If we go back to my initial comment, we see that I wrote many lines of code, many of which were not needed. So, we started a project where these kindly programmers had had enough and wanted to rewrite all of my code. They wanted to use this language called C++. As tempting as it was to deny such requests, I let them write it in C++. Why?

Well, I hired them because I code for shit. They were better than I - that's why I paid them money. If they wanted a tool then, it seemed to me, that they know better than I how to do their job. If I knew better then they, I'd not have had to hire them - I could have just hired monkeys and told them how to do it.

Point is, what's the point of getting in the way of letting the people you hired do the job you hired them to do? If you ask them to complete a task and trust them to complete the task them give them the tools they ask for, shut the hell up, and get out of the way. If your program worked while his broke after some minutes then I don't want him working for me unless he's able to make his program behave like your program.

I may not be the brightest bulb but I've learned a few things and one of them is that if you shut the hell up and get out of the way - you get pretty good results if you have good people. Don't get me wrong, I tried the micromanaging thing. Yeah... Don't do that. Fortunately, I'd hired people who had the brains and balls enough to tell me to shut up and get out of the way. I imagine most people would have fired them for doing so but programmers were a bit different back then so, eventually, I learned to get the hell out of the way and just give them the tools they asked for. Strangely enough, it worked.