Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

The Ways Programming Is Hard

Soulskill posted about 3 months ago | from the or-annoying-or-frustrating-or-etc dept.

Programming 278

An anonymous reader writes "Those of us who spend our days sitting in front of a screen trying to make computers do our bidding know how difficult programming can be. But from an outside perspective, there's not much to indicate difficulty. Most of us have heard somebody compare our job to digging ditches, or some other manual labor, meant to contrast easy (sitting around and typing) versus hard (muscle-wearying work). Now, Peter Welch has written an amusing essay to help combat that point of view, titled Programming Sucks. He compares bridge building to a big software project. Here's a small part of it:

'You start by meeting Mary, project leader for a bridge in a major metropolitan area. Mary introduces you to Fred, after you get through the fifteen security checks installed by Dave because Dave had his sweater stolen off his desk once and Never Again. Fred only works with wood, so you ask why he's involved because this bridge is supposed to allow rush-hour traffic full of cars full of mortal humans to cross a 200-foot drop over rapids. Don't worry, says Mary, Fred's going to handle the walkways. What walkways? Well Fred made a good case for walkways and they're going to add to the bridge's appeal. Of course, they'll have to be built without railings, because there's a strict no railings rule enforced by Phil, who's not an engineer. ... Would you drive across this bridge? No. If it somehow got built, everybody involved would be executed. Yet some version of this dynamic wrote every single program you have ever used, banking software, websites, and a ubiquitously used program that was supposed to protect information on the internet but didn't.' Welch goes on to gripe about all the ways in which programming is almost awesome, but ends up being annoying."

cancel ×

278 comments

Sorry! There are no comments related to the filter you selected.

i've worked on that bridge (1)

maliqua (1316471) | about 3 months ago | (#46875835)

he's right it does suck

Re:i've worked on that bridge (5, Insightful)

TheLink (130905) | about 3 months ago | (#46875981)

He's wrong though.

Bridge building is more like compiling.
Bridge designing is more like programming/program designing.

And there's the big difference.

Civil Engineering:
Design Phase costs about 10% of Build Phase
Build Phase involves tons of construction workers and heavy machinery.
The blueprints and plastic models are way cheaper to make than the Real Thing.
Management often doesn't mind spending a bit extra to get the design better, because the budget only allows for one big Build.

Software Engineering:
Design Phase costs more than 1000 times the Build Phase.
Build Phase involves the programmer typing "make all" and going to read Slashdot or fetch a coffee.
The plastic models cost as much to make as the Real Thing.

Management often sells the blueprints/plastic models as v1.0 because they compile and "kinda run" and the budget only allows for one big Design... ... Aaaand the customers often buy it :).

It should be no surprise then that the plastic models regularly fail.

Re:i've worked on that bridge (1)

Anonymous Coward | about 3 months ago | (#46876027)

No, both bridge building and bridge designing are like programming and program designing. That's how i feel. You not only need to do the actual coding, but you need to design the software too and how users are going to use it. Atleast that's how i've had to all my projects. Well alright, i actually work with hardware too, but i don't get a say in the hardware part. I'm just given some hardware and told "it's supposed to do everything and do it right" and then i need to make a program for it and maybe the UI also. And when things don't work out in the physical world, i need to fix it in software.

Software engineering build phase is not the "make all"-part. It's the part where you type the code. "Make all" is just the part where you clean up after building.

Re:i've worked on that bridge (0)

Anonymous Coward | about 3 months ago | (#46876079)

And you miss the point completely. Coding is design not building. The Software Engineering build phase is still what would be a design phase in Civil Engineering.

The bridge construction workers follow a plan that has already been decided, they don't get to change the design and decide whether to add another beam or not. So they are not coders - they are compilers", like software compilers they can make some "optimizations" but they are not supposed to deviate significantly from the design.

Due to real world issues, there may be some changes in the final bridge build when compared to the design- but any significant change requires the designers to be involved.

Once you understand this you'll understand why things are the (seemingly messed up ) way they are.

Re:i've worked on that bridge (2)

JaredOfEuropa (526365) | about 3 months ago | (#46876569)

Good point about the hardware: it's not just about the design and building, but also about the materials you get to work with, and the environment. Bridge builders use structural steel elements, bolts, cables, and need to account for environmental factors like the ground they're building on; software designers rely on computer hardware, the OS, the network, and they will also use APIs and libraries to build the software.

The problem with software components is that they are difficult to test completely compared to physical elements (it can be done but it's often cost prohibitive, and even then it is all too easy to make a mistake). Also, software doesn't fail gracefully but chaotically: small errors can have large consequence, and even a bug in an unimportant feature of the software can bring the whole thing down. In terms of our bridge: mount the railing next to the walkway incorrectly, and the bridge comes crashing down. Use Traffic Signs v3.0 together with Overhead Girders v5.41, and things come down; not just the traffic signs or the girders, but the whole bridge, and somehow the town downstream gets flooded, too. And god forbid you forgot to account for the brand and colour of the cars that will pass over your bridge; because the red ones will behave differently, and cause troubles. That's how software fails.

Re:i've worked on that bridge (1)

gl4ss (559668) | about 3 months ago | (#46876281)

well to build a bridge you need awful lot of guys who work with wood since that's what you usually use to hold the concrete in place while it sets..

Re:i've worked on that bridge (2, Insightful)

Anonymous Coward | about 3 months ago | (#46876479)

>Bridge Analogy Time
And when you are supplied with help, most of them have never used construction tools but still claim to have years of experience building bridges. You assign them a section to tighten bolts and after a few days check and see that nothing is done because they're all crowded around an incorrectly sized bolt and trying to make it fit. After showing them the correct bolt size, they swing the wrench around wildly trying to turn the bolt by hammering the edge. When you ask what they are doing, they say that they only have experience with hammers. So, you grab a bolt, put it in your hand and proceed to show them how to tighten a bolt and check with a torque wrench. You go back to the large section of the bridge roadwork you were assigned, but now horribly overdue for the CEO to drive his car around on. Days later, your boss checks on how the other workers are doing. Since they haven't accomplished much, they claim that your example was bad and they had to research on the internet how to tighten bolts. They proceed to pick up a bolt and tighten it with their hand, following your example _exactly_. "See? The bolts are not getting into the bridge! Only my hand!" Your boss looks at you accusingly and says "you should have tightened the bolts for them on the actual bridge!".

This is the point where you proceed to jump off said bridge.

Perfect example (0, Troll)

Anonymous Coward | about 3 months ago | (#46875845)

Of why programmers can't be engineers. It's even worse in open source where people really can get away with doing whatever the fuck they want.

Re:Perfect example (2)

x0ra (1249540) | about 3 months ago | (#46875941)

Because the code I wrote is not what is being executed, and if it was, we would not have the level of performance we have today. Moreover, the level of complexity of today's computer. Moreover, tolerance are such in the physical world that a construction guy can afford to "cut corners", whereas software is a lot less tolerant to a bad input, remember, it's a dumb automaton.

Re:Perfect example (5, Interesting)

Anonymous Coward | about 3 months ago | (#46876463)

The article is very funny, and makes a lot of good points, but it's not really addressing the question. It gives reasons software projects are difficult. Not why programming as such is. The engineering part, if you will.

The reason programming is difficult is because it's discrete. Whereas most (all?) other engineering is continuous.

If you try to bend a steel rod, there's going to be a range of strain for which nothing will happen, another where it will flex and recover, another where it will flex permanently, and finally a point where it will fail. This is all contiguous, and you can reduce it to a few numbers that will accurately predict the behavior of identical rods. Depending on the expected load, and the desired behavior, you can then pick the right rod, that will behave the way you need it to, with a good and predictable safety margin, because you know when what will happen.

Software, on the other hand, is discrete. That linked list can behave correctly as you add elements, then remove them, all good, then fail when you remove the last one and it (should) become empty again. There's no hint of that unless you test the very specific condition. There is no failure progression. There is no concept of safety margin.

That's why software regularly blows up. That's why it's difficult to make it not blow up. It's always on the edge.

Re:Perfect example (1)

Anonymous Coward | about 3 months ago | (#46875945)

This is a real problem. Open source projects have a very varying degree of Quality Assurance.

Re:Perfect example (1)

x0ra (1249540) | about 3 months ago | (#46876011)

Because proprietary software is better ?

Re:Perfect example (4, Insightful)

antifoidulus (807088) | about 3 months ago | (#46876049)

It is....sometimes. The biggest problem with Open Source QA is also one that affects a lot of research, everyone wants to code, nobody wants to be a reviewer/bug fixer.

Look at the HeartBleed bug, there was only one source review before release. There could have been more, but open source suffers from the peer-review paradox: the people with the ability and resources to do thorough reviews are the ones least likely to want to do reviews. Quite simply, there isn't any "glory" in it, and it isn't nearly as much fun as creating new code yourself. Now in big commercial operations, especially web sites, there are large QA departments where everyone has a financial motivation to scrutinize code and find weak spots. Really if companies like Google et. al want to help open source, they shouldn't just contribute code, they should donate their QA team's time and talents to doing really thorough reviews on critical open-source code before it's merged into the main branch.

Re:Perfect example (2)

Opportunist (166417) | about 3 months ago | (#46876115)

Where's the paradox, it's the same in science. Everyone wants to make the new discovery, nobody wants to review and verify them.

Re:Perfect example (1)

antifoidulus (807088) | about 3 months ago | (#46876181)

Well, the paradox is that open source and science both depend on peer-reviews, but the only people capable of doing them don't want to do them.

Re:Perfect example (2)

Opportunist (166417) | about 3 months ago | (#46876255)

That's true for both. When was the last time you saw a Nobel Prize winner repeat an experiment from someone else just to prove his colleague?

Re:Perfect example (0)

Anonymous Coward | about 3 months ago | (#46876303)

Open source certainly does not depend on peer-review. You can write any old crap for any purpose and give users the code. You obviously don't follow any open source projects. The vast majority of code review is mostly about style and not whether it works.

Re:Perfect example (0)

Anonymous Coward | about 3 months ago | (#46876121)

Because proprietary software is better ?

Maybe, maybe not. That question does not change the fact that open source projects still need better QA procedures. But if you want to make the comparison, then yes, I would say that proprietary software usually at least tries to do some kind of real QA.

It is a hot question for OSS indeed. We already have lots of good open source software, but there's also good amount of bugs, missing features, lacking documentation, unoptimized code and security vulnerabilities. It is lacking the final polish to make it a nice and robust package.

Re:Perfect example (1)

Anonymous Coward | about 3 months ago | (#46876327)

If you aren't making a comparison you shouldn't draw a distinction. If closed-source software isn't better then the distinction in source-openness is irrelevant and misleading.

Re:Perfect example (2)

Opportunist (166417) | about 3 months ago | (#46876111)

If you're not satisfied with the level of quality in open source software, you're free, actually encouraged, to improve it.

Re:Perfect example (3, Insightful)

MadKeithV (102058) | about 3 months ago | (#46876113)

This is a real problem. Open source projects have a very varying degree of Quality Assurance.

Look at the name - Quality Assurance. QA can only tell you it's bad, it doesn't make anything better. And what they can look at is usually only the external, visible part, which may seem to be working nicely but built from spit and wire on the inside, ready to fall apart at the next version update of the printer driver. That doesn't mean QA is useless, it's just a final double-check to see that you've built the right thing.
No, writing good quality software is a team effort of everyone involved. As a developer in the middle, you should be able to smile at the great design documents given to you by the system analysts, telling you what's needed and how, while having enough freedom to do it in the best way given the tools and frameworks you work with. And you should be able to high-five the QA people when they fail to find anything wrong when you deliver it, because you know that if they give their OK you can sleep on both ears and the users will be able to do what they need to do. And that's a good month's work if you managed to get there on the third try :P.

"there's not much to indicate difficulty" (5, Insightful)

FireballX301 (766274) | about 3 months ago | (#46875849)

Only complete idiots/tools think this way about any profession. Brick laying looks easy, but I wouldn't trust someone who's never picked up a trowel in their life before to put up a brick wall. Anyone 'outside the profession' should only be concerned that the code works, is maintainable, and is to spec, along with passing a security audit.

Re:"there's not much to indicate difficulty" (1, Interesting)

KingOfBLASH (620432) | about 3 months ago | (#46875969)

Well that's not completely true. I'm quite sure an intelligent person could learn how to be a bricklayer if they really wanted to. I'm not quite as sure that an uneducated brick layer could learn to code if they really wanted to.

Although that's not to say a highly intelligent individual might not decide to become a bricklayer instead of a programmer [wikipedia.org] .

Case in point: how many people who are not in construction go to Home Depot on the weekend as a sort of entertainment. It's interesting to figure out how to build something, and a form of entertainment (and pride) to be able to put something together. How many people can you say that about programming?

Re:"there's not much to indicate difficulty" (1)

x0ra (1249540) | about 3 months ago | (#46876017)

The week-end trip at Home Depot is more about fixing the house than "entertainment". Let's face it, most jobs are about trying to keep the damn thing running for one more day.

Re:"there's not much to indicate difficulty" (2)

KingOfBLASH (620432) | about 3 months ago | (#46876125)

Disagree. How much do you make an hour? Logically if you make more than a builder, it is better to work overtime and pay the builder.

My father was like that. He could spend his entire weekend fixing something that would take a "pro" an hour or two. He made more in an hour or two than a pro made, so logically it made no sense to give up his weekend. But there was a significant entertainment value to him to going to home depot and figuring out how to fix it.

Of course, if you make close to what a builder makes per hour, you may see things differently. But that does not mean that most of the people who go to home depot to fix things themselves are not there for entertainment. If you don't believe me just look at how many riding mowers and tractors the Home Depot sells. There is no need for a person with a normal yard to buy one of those things, if it was really about saving a buck they'd go with the cheaper walking mowers.

Re: "there's not much to indicate difficulty" (1)

cbart387 (1192883) | about 3 months ago | (#46876529)

That assumes that working more hours translates to more money. Our bonus "takes into account" overtime, but it is not directly for every xxx hours we get xxx more. So I may make more a t my profession, but that does not mean that monetary it will save me money if I hire someone else to do work around the house.

Now, there is probably some type of heuristic I could use to determine at what point it is not worth my time, since some jobs would take me to long or I do not have the skill, but my point is that is little more complicated than just looking at pay.

Re: "there's not much to indicate difficulty" (1)

KingOfBLASH (620432) | about 3 months ago | (#46876671)

Many jobs do allow you to forego working for extra vacation days, at a pre-specified rate. So you DO have a specific "value" to your free time, as set by your employer. Even if you may have trouble redeeming it at that rate by someone who is not your employer.

You do however have the opportunity to pick up some consulting jobs, to do side jobs, or perhaps pick up some side projects. But, depending on what you do, YMMV. A lawyer, web designer, or other profession may have no problems picking up a few extra hours on the side, while you may not find this to be possible

Re:"there's not much to indicate difficulty" (0)

Anonymous Coward | about 3 months ago | (#46876631)

"Logically if you make more than a builder, it is better to work overtime and pay the builder."

That argument dubiously assumes that saving money is your only concern. For many people, it is not. E.g. many people also consider it logical to learn new skills, to be more self-sufficient, to get some variety in their lives, and so on.

Re:"there's not much to indicate difficulty" (2)

MadKeithV (102058) | about 3 months ago | (#46876069)

How many people can you say that about programming?

About 30-35 years ago I remember how people would be playing around in Basic on the weekend for entertainment. It really isn't that far-fetched, and messing around with the tape deck and volume control just to let things load made people realize that programming is a lot like Building in the Real World, where having a PZ screwdriver instead of the PH you really need sort-of-works but makes your life a hell of a lot harder.
I don't know what it's really like today, I've been doing it professionally for too long, but I still see quite a few newbie questions around Stackoverflow, Gamedev.net, people reading about the Raspberry Pi on the train, etc. etc. I think it's still going on.

Maybe I'm biased, because I've done some pretty crazy remodeling on a house, but building software is a LOT like building houses, lots of people just have really strange misconceptions about how well houses are(n't) built. Those same people are often in management, have to get an expensive second contractor in after the first one totally cocked up the extension to their 5-bedroom house because the I-beams he brought were a couple of inches shorter than spec but oh well, there is NO WAY that correlates to writing software (even though that's supposed to be their management expertise).

Programmers aren't special little snowflakes. People generally just do stupid things.

Re:"there's not much to indicate difficulty" (1)

wonkey_monkey (2592601) | about 3 months ago | (#46876071)

I'm quite sure an intelligent person could learn how to be a bricklayer if they really wanted to.

All they need is a Bricky [youtube.com] .

There's something about that one that I could watch for hours.

Then there's this guy [youtube.com] .

Re:"there's not much to indicate difficulty" (4, Insightful)

Opportunist (166417) | about 3 months ago | (#46876145)

As someone who has spent quite a lot of time in "menial" jobs during my university years to get enough money together to get by, I can inform you that most jobs where you'd say "an idiot can do that" from watching are harder than they look. Mostly because you're usually watching people who have been doing it for years and practice does make perfect.

It will probably take longer to teach someone programming "from scratch" than it would to make him a decent bricklayer, but I wouldn't simply assume that it's easy because it looks that way.

Re:"there's not much to indicate difficulty" (1)

KingOfBLASH (620432) | about 3 months ago | (#46876373)

Well it is a craft and requires practice. And programming requires practice as well. But it also requires a higher level of intelligence and problem solving. You can be an idiot and so long as you know how to put in bricks, if I say "Build wall here" you could do what you need. I've seen plenty of "programmers" who just lacked any sort of problem solving skills and ran into a wall (pun intended)

Re:"there's not much to indicate difficulty" (2)

Opportunist (166417) | about 3 months ago | (#46876483)

I'm in IT security. This involves amongst other things code reviews. In other words, I get to see a lot of code.

And judging from quite a bit of code I've had to see lately, I can only assume that the level of intelligence and problem solving skill required to enter into programming has been lowered by some kind of leg-up, no-dud-left-behind program...

Re:"there's not much to indicate difficulty" (1)

Anonymous Coward | about 3 months ago | (#46876413)

" I'm quite sure an intelligent person could learn how to be a bricklayer if they really wanted to."
And that's the reason why the "armchair generals" are convinced they're always right.

Re:"there's not much to indicate difficulty" (3, Insightful)

ubersoldat2k7 (1557119) | about 3 months ago | (#46876073)

Actually, your simile with brick laying is what I found fits better with how software projects work. I mean, you build a bridge and be gone. Most software projects start as "we want to build a wall", but then they switch to "we want a wall with a door and greco-roman finishes", and it keeps growing and growing until you have the Pisa tower with a kitchen in the roof top, all made of small bricks and lot of glue.

Re:"there's not much to indicate difficulty" (1)

khchung (462899) | about 3 months ago | (#46876141)

Only complete idiots/tools think this way about any profession.

Agree, but it seems like the whole world is filled with idiots...

Re:"there's not much to indicate difficulty" (2)

TapeCutter (624760) | about 3 months ago | (#46876277)

I'm 10yrs from retirement I dropped our of HS in 1976 and have spent the last 26 as a degree qualified developer. Before my degree I spent 15yrs as a labourer, I did a stint as a brickies labourer, spent a year in a remote Aussie sawmill, farm hand, deck hand, concrete formwork, and many more "strong back, weak head" style jobs, I married young and had a wife a two young kids, I'd willing have done pretty much anything people were willing to pay me to do....

- The most physically demanding was deck hand on a fishing boat in the notorious "Bass Straight" although the sawmill comes a close second the boat involved working 36hrs straight (30 min break every 5hrs), plus 30hrs travel time where you were either on 2hr watch in the wheelhouse, or hanging on to your bunk for dear life. The visual and auditory hallucinations from lack of sleep on the boat were a bit concerting at first but mine were the comedic variety, about 1 in 4 new deck hands have the horrific variety and quit after the first voyage. Oddly I look back at both of these with fond memories, possibly because it's when I was at peak fitness and surrounded by wilderness and good mates. There was "something good" about those jobs that you just don't get in an office building, I have never been to war but I imagine the comradely found in a foxhole is a more extreme example of what I'm talking about.
- The most stressful and mentally draining job was 12hrs behind the wheel of a city taxi.
- The most unhealthy and socially isolating job was 5yrs rotating shift work in a nylon factory
- The most ridiculous, sweeping a 5 acre concrete slab with a yard broom. (2 days, if you're wondering).
- The most uncomfortable - empting one ton bags of lime into a hopper, under a bare tin roof, on a 45degC day.

Software development - "find a job you love and you'll never have to work again".

Re:"there's not much to indicate difficulty" (1)

Anonymous Coward | about 3 months ago | (#46876349)

I think the point he was trying to make is that it's easier for anyone to see a bridge and get some idea of the difficulty of building it. Of course, the larger bridges give a bigger sense of awe than the smaller ones, or even the older ones where you say "wow, people really did this way back when!". It has to do with the tangible, physical, visually evident thing that's before them.

A bit of text on a screen that begins to flash red in ever-increasing frequency to alert of a "major" event looming in the near future. Not so impressive... because the difficulty of getting from zero to there is not evident to the average person. And you might say that there's a monitoring station in the antarctic that connects a system of buoys in the ocean with all kinds of sensors for tides, currents, temperature, salinity, pH levels and whatnot that sends the data over a satellite network (because Line-of-sight) and then to land-based station that shoots it over the internet to a big cluster of computers that make all sorts of complex predictions based on that new data and all the data that came before it (even the stuff from the 1930's we had digitized), and then sends and priority 1 message with an alert that in X hours some farm animals might experience dew... but, fuck, all they see is a little bit of text that's flashing red. Whatever lies behind what the person sees is not evident, tangible or even physical, so without the explanation you can't really make much of it. It's just not fucking there, like the bridge.

So now imagine you see the bridge and they tell you all the bullshit that went into building it... then you might say "wow, it's a wonder that thing is even standing"... and that is when you make the connection to the programming part.

Call it software engineering, software design, coding, programming, development or whatever else you might choose. If it's done "professionally" in a work environment where there are budgets, and customers, and deadlines, and teams of developers, and marketing, and non-techie bosses and all kinds of things; you're going to run into that bullshit.

And, in conclusion: http://www.youtube.com/watch?v=BKorP55Aqvg

Re:"there's not much to indicate difficulty" (0)

Anonymous Coward | about 3 months ago | (#46876351)

I think he's missing the point that writing "Good Code" is difficult even without the dysfunctional organizations, and most people hired to code aren't good enough to do that. I'm an elitist asshole, but honestly, writing code isn't for everyone and I spend far too much time cleaning up the mess left by incompetent programmers who couldn't "Hello World" to save their lives. Nothing tells me things are different at other places of work.

Re:"there's not much to indicate difficulty" (1)

cowwoc2001 (976892) | about 3 months ago | (#46876409)

1. "code works": Easy to say, hard to check. It might work today in some circumstances but fail tomorrow in other circumstances.
2. "is maintainable": That's a subjective criteria which is impossible to enforce.
3. "is to spec": Again, easy to check for common pathways, but hard to catch all the nuances (for the same reason that no one has 100% code coverage in their unit tests).
4. "passing a security audit": This helps, but as well all know by now it does not guarantee that the code is secure. Code usually depends on 100s of transitive dependencies. No one in their right mind includes transitive code in their security audits, unless you're the military and have that kind of money.

I'm not saying that building a house is any easier. I'd simply point out that we evaluate houses and bridges after a 30-year track record. If bad things happen, people get sued and there is some form of liability.

How many people behind software development (from the programmers up to the project managers) are liable for their work 30 years later?

Until we become liable for our work there will be no incentive to measure and improve some of these metrics. Just my 2 cents.

Re:"there's not much to indicate difficulty" (0)

Anonymous Coward | about 3 months ago | (#46876597)

While I generally agree that blue collar jobs require their own expertise, let's not pretend that there is no difference in complexity and difficulty. I am not a tradesman, but even for one-of jobs, I can often fix what "professional" tradesmen couldn't fix properly (and built wrong in the first place). Of course it takes me much longer than it would if I had experience in doing these things, but at least I get a result I can live with. And I don't think I'm exceptionally good at this. Not long ago a friend of mine complained about a flaky Ethernet socket that he had had a professional install. What did he do? Opened it, found way too much of the shield stripped, wires untwisted and badly punched down. Needless to say, he did a better job himself and the socket is now working fine.

I sincerely doubt that any of these tradesmen could do what I do, let alone be better at it, no matter how much time they can sink into the job.

wimp (2)

zephvark (1812804) | about 3 months ago | (#46875863)

Wimp working for an excessively-large company with rules that might allow "casual Fridays" with strict dress codes. He's whining about corporate culture, not programming. The "Neo" problem that first gave you the hint that he wasn't an actual hacker, just some script kiddy in a minimum-wage cubicle farm.

Wait, did I just hear you denying that the general (2)

aussersterne (212916) | about 3 months ago | (#46875883)

problem of "other peoples' code" is an actual problem?

Because if so, I think you may be the script kiddy in a minimum-wage cubicle farm.

Re:Wait, did I just hear you denying that the gene (5, Insightful)

MadKeithV (102058) | about 3 months ago | (#46876077)

(Wait, did I just hear you denying that the general) problem of "other peoples' code" is an actual problem?

Because if so, I think you may be the script kiddy in a minimum-wage cubicle farm.

Bonus points for realizing that your own code from three months ago is also "other peoples' code".

Re:Wait, did I just hear you denying that the gene (4, Insightful)

ATMAvatar (648864) | about 3 months ago | (#46876095)

The best part is when you find out that the "other guy" who put in the stupid code is you from months or years ago. You start to get incensed and rant about what idiot would write such awful code, check the commit logs, then facepalm as you realize it was you.

I occasionally wonder if that kind of thing would happen less frequently if our profession wasn't so quick to fire the guys whose gems turned black.

Re:wimp (1)

KingOfBLASH (620432) | about 3 months ago | (#46876003)

The "minimum-wage cubicle farm" culture is the problem. Reading his story, I can pretty much think of someone in my career who filled the shoes of each person mentioned. You know it's funny, if we want to engineer a bridge, or a skyscraper, there is a consistent order and process to putting it together and documenting it. If we want to do that with programming, people just do whatever they want, put some duct tape here and there, and hope it doesn't fall apart. Of course part of that is management generally doesn't want to pay for properly engineered solutions. But it is indeed a problem.

Re:wimp (4, Insightful)

Cenan (1892902) | about 3 months ago | (#46876097)

Software Development is still a young field. Someone who wants a bridge built can look back in history and see all the horrible consequences of not shutting up and listening to the people who know better than them. There are strict regulations, there are guidelines to follow. Humans have been building stuff since the first ax hit a tree, while the consequences of faulty software has just recently started to manifest itself to the general public. Comparing software engineering to regular engineering is an unfair comparison when regular engineering is built upon hundreds, if not thousands, of years of experience.

I heard a saying once, maybe it was here on /. The reason an older programmer is slower than a younger one is because of the number of answers he has to the question "what could possibly go wrong?". That is true on a larger scale for engineering vs. software engineering.

Most large software projects are run by people who have fuck all clue what it entails to produce good software, people who don't see the value in spending another couple grand on a few more weeks of design, people who have clients they sold vapor to and now need the product yesterday. Software that works is easy to produce, and nobody can see the rickety scaffolding underneath, so it is really hard to argue with a non technical manager that something needs to be changed - after all, the shit works doesn't it?

Re:wimp (1, Insightful)

KingOfBLASH (620432) | about 3 months ago | (#46876131)

Comparing software engineering to regular engineering is an unfair comparison when regular engineering is built upon hundreds, if not thousands, of years of experience.

I'd disagree. Programming is a form of engineering and should be treated with no less respect.

Re:wimp (0)

Anonymous Coward | about 3 months ago | (#46876197)

You missed the point. He's saying regular engineering has had thousands of years to look at their failures, try new ideas, and to come up with what works today. Software engineering has had only decades. In thousands of years (hopefully sooner), software engineering projects will be near perfect. There will be some well know path of project management that has proven itself to work over and over throughout the decades.

Until then, comparing it to current engineering practices is comparing seeds to apples. People should instead compare software engineering to the earliest engineers who built whatever however they wanted and many of those projects failed. For example look at the pyramids. Err, crap.

Re:wimp (2)

KingOfBLASH (620432) | about 3 months ago | (#46876325)

Bollocks. Aerospace engineering doesn't have thousands of years of history to fall back on yet we can still build planes that don't blue screen of death out of the sky.

The difference is that, when lives are at stake, people make damned sure things are reliable.

Another example would be engineering of chips. When's the last time you heard of a bug in your CPU creating issues? IIRC the last one was the infamous pentium bug from the 90s.

Transistors on a chip cpu engineering has been around for less time than software, yet they get it right...

Re:wimp (1)

Cenan (1892902) | about 3 months ago | (#46876667)

That was the point though. But software engineering is not treated with respect because 90% of the product is invisible. With regard to the reply you've made below about aerospace engineering, you're right, that is a new field too - but the product is visible, you can see what your money is buying. And even though it's flight, it still builds upon engineering principles accrued over a much longer time span than software engineering does. There no MBAs heading up engineering teams designing and building planes. There are very, very few amateur plane builders selling their rickety winged contraptions (at least not ones made for passenger flights).

Good article (2)

msobkow (48369) | about 3 months ago | (#46875899)

It's a good article, and all too true. Software is a house of cards at best, with your boss shaking the table, the hackers throwing ping-pong balls at the house, and the NSA coming down the hallway with a baseball bat.

Re:Good article (1)

Opportunist (166417) | about 3 months ago | (#46876153)

Nah, the NSA is more that asshole that comes sneaking up to your house of cards and keeps wiggling at the cards looking for the one they can pull out without having the whole thing collapse, then laugh with glee when they find one, dance around the house and that's when the whole thing comes down from the vibration they make on the floor.

Programming is "hard" ... (2)

Ihlosi (895663) | about 3 months ago | (#46875901)

... because gratification is delayed and not necessarily guaranteed.

Compare this to digging a ditch, which is hard labor, but provides almost instant gratification (you can always look at how much of the ditch you've already dug), and you're not likely to fail completely (unless you're trying to dig in solid rock).

Re:Programming is "hard" ... (0)

Anonymous Coward | about 3 months ago | (#46876057)

My super power is patience.
I need this because when programming hardware you spent a half year to a year coding VHDL before you can actually see it work for the first time.

Re:Programming is "hard" ... (1)

MadKeithV (102058) | about 3 months ago | (#46876119)

... because gratification is delayed and not necessarily guaranteed.

Compare this to digging a ditch, which is hard labor, but provides almost instant gratification (you can always look at how much of the ditch you've already dug), and you're not likely to fail completely (unless you're trying to dig in solid rock).

No, but what happens is that the architect comes along and tells you that the foreman picked the wrong side of the plot markers when telling you where to dig the ditch, so it's exactly a ditch-breadth off from where it should be. Please fill it up again and dig a new one to the side before the concrete for the foundation is poured, and by the way, the cement truck is arriving in 30 minutes.

Re:Programming is "hard" ... (0)

Anonymous Coward | about 3 months ago | (#46876243)

Except you're not the one who gets accused (directly or indirectly) of being a lazy idiot when the ditch isn't already dug 30 minutes later because any idiot understands that you can't dig a ditch that big in 30 minutes and you weren't the one who placed the markers.

In software development it's a constant battle to document all the crazy orders you get and in the end you're sitting in a meeting with the 12-page spec and another 40+ pages of printed out emails telling you to ignore the spec for just this one specific issue. And they'll still try to blame you.

Re:Programming is "hard" ... (1)

Opportunist (166417) | about 3 months ago | (#46876159)

Programming is digging a trench in a puddle. You don't see what you're doing, you don't see your progress and due to the water seeming to rise as you dig away more of the ground you're standing on, it seems to get worse and worse with every load you throw out.

Here's his problem (1)

phantomfive (622387) | about 3 months ago | (#46875909)

Here's his problem:

Every programmer starts out writing some perfect little snowflake like this. Then they're told on Friday they need to have six hundred snowflakes written by Tuesday, so they cheat a bit here and there and maybe copy a few snowflakes and try to stick them together or they have to ask a coworker to work on one who melts it and then all the programmers' snowflakes get dumped together in some inscrutable shape and somebody leans a Picasso on it because nobody wants to see the cat urine soaking into all your broken snowflakes melting in the light of day.

If you start cutting corners, you're going to end up with a mess. If you're a good programmer, you know how to write solid code even under time constraints [canonical.org] . If you're having trouble with it, then you should probably look into the YAGNI principle, or get better at estimating how long your tasks will take. Because those are the two things that seem to afflict programmers who are chronically behind schedule.

Don't write bad code though, because you'll need to maintain it.

Re:Here's his problem (0)

Anonymous Coward | about 3 months ago | (#46875939)

I can estimate how long a project will take just fine.

My managers, not so happy with reality so they invent their own numbers ....

And their managers .....

Then there's the plan change week three ...

Re:Here's his problem (1)

phantomfive (622387) | about 3 months ago | (#46875993)

Then there's the plan change week three

Changes in plan are part of the reality of programming. Include them in your estimate. Write flexible code, that is part of YAGNI

If you have confidence in your estimates, don't let your manager push you around. Stand by it. Be kind, and tell him you will estimate anything he wants, but it will still not get done any shorter than your original estimate.

And make sure you hit your estimates. Programmers who have trouble with their bosses changing their estimates are usually the types of people who don't hit their estimates.

Re:Here's his problem (1)

Salafrance Underhill (2947653) | about 3 months ago | (#46876577)

Expect the unexpected!

Hmm...

Re:Here's his problem (4, Insightful)

Opportunist (166417) | about 3 months ago | (#46876191)

That joke actually stems from Soviet times and was making fun of perceived and reported field yield vs. real, but it works just as well for management and projects.

A programmer has to estimate how long he'd take to get something done. He ponders, calculates and finally decides: 3 months.
His supervisor isn't happy with this, 3 months, that's probably too long. He notices the programmer has a vacation planned and there are a few holidays that he could work overtime in, he cuts those and corrects the estimate to 2.5 months.
The group's superior isn't happy with that. The quarter report is due in about 2 months. But if they think they can do it in 2.5 months, they sure can do it in a week or two less by cutting time somewhere or working overtime, so he puts down 2 months.
The department head doesn't like what he hears. The general meeting of the shareholders is in 6 weeks and he sure wants that prestigious project to be mentioned in there. But maybe somehow we can cut 2 weeks somewhere, probably we'll hire a temp or some other way that doesn't cost ... anyway, they can do it in 6 weeks, too, I'm confident!
The project lead finally gets the estimate and is very happy. 6 weeks! We have almost 3 months time left! Time to push for those features I wanted, they said they'd tack 2 months onto the project, but somewhere they can surely shave off 2 weeks of those and we'll be done in time!

Re:Here's his problem (2)

dcollins (135727) | about 3 months ago | (#46876109)

"get better at estimating how long your tasks will take"

At my last programming job, the head of engineering took all my time estimates for a project and arbitrarily cut them in half, because "we're smarter than most companies".

Comedy != Informative Editorialism (2)

originofstorms (1330935) | about 3 months ago | (#46875919)

The author has a great sense of humor, and ripostes some of programmings possible pitfalls into clever and hilarious absurdities. However, I strongly refute that this article is a remotely accurate portrayal of programming, and I hope it is not taken as such by prospective coders on the fence. In my view, programming is possibly one of the few havens of relative sanity available (although with wood-working and pure mathematics probably have it beat). The true insanity is HUMANS TRYING TO COLLABORATE WITH OTHER HUMANS. If in doubt, please re-read the article with that in mind, and I think you'll find all the admittedly hilarious conceptions boil down to that issue, and that issue is pervasive in nearly any job you could name. Programming is an oasis from insanity, not ground zero.

Re:Comedy != Informative Editorialism (0)

Anonymous Coward | about 3 months ago | (#46875979)

Come back in 20 years and tell us if this is still your assessment ;)

Programming is the easy part (4, Insightful)

clickclickdrone (964164) | about 3 months ago | (#46875933)

What I struggle with is translating badly worded/badly thought through/incomplete business requirements into program logic. All too often something which seems straight forward to a business person is a can of worms when it comes to implementing it.

Re:Programming is the easy part (5, Insightful)

Opportunist (166417) | about 3 months ago | (#46876215)

This. A billion times this.

Back when I was still programming, i once got a spec sheet written on a post-it. Yes, a post-it. Half of it was a diagram. Ok, granted, that was a VERY special case where everyone involved had a kinda-sorta idea what's going to get programmed and it was by no means very complicated, but it showcases very well the problem.

Later, when I was the one organizing a team of programmers, it was my policy that I get a written and signed spec sheet from the project sponsor. If he can't be assed to write specs, my team can't be assed to write code. And that was when I had the revelation: They don't really know what they want themselves. They only know one thing, they don't want what you will produce. They usually want something akin to a magical box that fulfills their wishes. And sometimes I get the hunch, especially with some of the older stakeholders, that this is pretty much how they view a computer. And programmers are some kind or arcane wizards who make the kettle boil and bubble until the program emerges somehow magically.

They fully expect you to know their needs and usually have a very hard time communicating them because a lot of things that make no sense to you are obvious to them because it's their daily bread and butter. And hence these things will be sorely missing in the specs.

I soon learned that it is a good idea to write the specs together with them if you want a project to succeed. You could tell I wanted your project to fail if I had no time to do that...

Development Sysadmin... (0)

Anonymous Coward | about 3 months ago | (#46875991)

Programmer insanity is why I read BOFH !!! I chuckle at some of the Simon and PFY exploits. Other are starting to sound like good ideas.
Treat your systems and network guys like (possibly evil) minor gods. Ply them with drink and goodies

Just answer their questions honestly and try not to annoy them during non scheduled hours or their lunch (or post lunch nap) and you might survive the project.

and remember nobody uses tapes anymore, but tape cabinets are priceless.

programming is hard (-1)

Anonymous Coward | about 3 months ago | (#46876005)

first world problems....

Re:programming is hard (1)

Opportunist (166417) | about 3 months ago | (#46876223)

Newsflash: We're living in the first world. If you want different problems, you have to move.

Not going to? Gee, wonder why. Could it be that you prefer having first world problems?

Re: programming is hard (1)

cyber-vandal (148830) | about 3 months ago | (#46876285)

I'm glad I'm not the only one who hates that patronising phrase. You're not dying of starvation or disease so you should be happy all the time.

Hyperbole much? (0)

Anonymous Coward | about 3 months ago | (#46876021)

Why does every description and story I've ever heard related to programming use such excessive hyperbole? Where are all the honest, adjective-free post-mortems of projects that actually go into technical detail with code examples of how they managed to tackle difficult problems and what sorts of areas they had to compromise and weren't happy with but couldn't come up with a solution?

Why is everybody an idiot that didn't write it exactly like you would have (why didn't you just do it if you're going to be so picky?) -- especially when the compiler ends up optimizing it to be the same thing anyway?

I've been programming since I was six years old and I'm getting really sick of the human element of working with overly emphatic, emotional programmers...

This guy really has his nerve (1)

mbstone (457308) | about 3 months ago | (#46876045)

Writing a piece on how programming sucks, in a typeface that hurts my eyes to read.

You know what professions are difficult? (3, Insightful)

Begemot (38841) | about 3 months ago | (#46876047)

Portable toilet cleaner
Sewers cleaner
Animal masturbator
Janitor at a porno theater ...

Programming is bonanza

Re:You know what professions are difficult? (4, Funny)

hawkinspeter (831501) | about 3 months ago | (#46876139)

Animal masturbator

What? I can get paid to do that?

Re:You know what professions are difficult? (1)

Anonymous Coward | about 3 months ago | (#46876339)

Congratulations - you can turn your hobby into a job!

Re:You know what professions are difficult? (1)

SeaFox (739806) | about 3 months ago | (#46876421)

Animal masturbator

What? I can get paid to do that?

At the zoo. Rare species that are almost gone from the wild but exist in captivity and they are trying to build up the population of.

Re:You know what professions are difficult? (0)

Anonymous Coward | about 3 months ago | (#46876429)

Where do you think milk comes from? There's a lot of rubbing and squeezing happening for that

Re:You know what professions are difficult? (1)

DoofusOfDeath (636671) | about 3 months ago | (#46876693)

I think it might be done sometimes in animal husbandry.

I caught part of a documentary one time that was talking about needing to manually give female pigs an orgasm, but they didn't point that out to the workers doing that because it would be too horrifying. I suspect it was after the sows were injected with semen, to facilitate its passage to the right place.

Shudder....

Re:You know what professions are difficult? (1)

Opportunist (166417) | about 3 months ago | (#46876231)

They're not really difficult. They're just really unattractive (well, to the average person, I'm pretty sure there are people who enjoy wanking bulls).

Re:You know what professions are difficult? (1)

TeknoHog (164938) | about 3 months ago | (#46876433)

They're not really difficult. They're just really unattractive

In some sense, these two can be the same thing. For example, I find working as a teacher more difficult than any of the science/programming I've ever done, even though the individual technical challenges may seem much easier. Dealing with troubled kids from day to day can make your life feel difficult in a grander scale.

Re:You know what professions are difficult? (1)

Opportunist (166417) | about 3 months ago | (#46876465)

Dealing with kids is easy. What makes it hard is that the law for some reason prohibits shooting them.

Overgenralized scenario. (2)

Ajay Anand (2838487) | about 3 months ago | (#46876105)

When people work in a group as a team this inevitably happens and that's all right. Building a perfect software that satisfies everyone is a hard NP problem. What's the point of being perfectionist if that 10% you wish to polish it going to consume 90% of your time and money.

ER, stat (1)

Anonymous Coward | about 3 months ago | (#46876137)

Fred only works with wood?
Perhaps he should consult a physician.

Plumber-architects (2)

bmimatt (1021295) | about 3 months ago | (#46876195)

The comparison that has been coming to my head, regardless of whether I was self- or otherwise- employed is: coders are the plumbers of the Internet age. Furthermore, we are the electricians, the elevator drivers, the janitors, the security guards, the dealers, the cops, the architects. All generalized comparisons apply, because the Net is a representation of the world. Slightly skewed, a representation nonetheless.
I am proud of the being an Internet plumber and cheers to others who spend their days trying make it work smoothly.

Re: Plumber-architects (1)

cyber-vandal (148830) | about 3 months ago | (#46876337)

Until you have to unblock a toilet.

Actual bridge building (1)

rasmusbr (2186518) | about 3 months ago | (#46876203)

From what I've heard, actual construction engineering is typically not that far removed from the description in the article.

Sure, the designs in construction engineering are way better proven and tested than the designs in software engineering, but the building process is in many ways still a trial and error affair where things can and usually will go wrong. Then the post mortems sometimes come with literal post mortems attached to them. How well do you think those engineers sleep at night?

One nice thing about computers is that they usually have nowhere near enough mass to crush a person to death.

Re:Actual bridge building (2, Insightful)

Anonymous Coward | about 3 months ago | (#46876279)

As someone who had a part-time construction job in college: It's amazing how many people doing that actual building on construction projects who fuck shit up and then hide it long enough that by the time it's discovered the designers have to tweak their near-perfect designs to incorporate workarounds.

Thankfully you don't get that in software development, it'd be like a world in which developers wrote near-flawless code but your average compiler/interpreter played it fast and loose and did shit like randomly round numbers up and down. Random rounding was actually pretty common when I did construction, the design clearly states that each section between two windows needs to be 1.9 meters, there are 12 windows on that side of the building and the sections come prefabbed in 2 meter segments that you're supposed to cut 10 cm from to get 1.9 meter segments? Yeah, Bob the 47-year-old foreman will shoot down any attempts to "waste time" by cutting the segments and suddenly you have to settle for just 11 windows because the total length of the wall is 1.1 meters too long. Because Bob thinks engineers are a bunch of pedantic wusses. Sort of like if your compiler were to try "optimizing" your floats and doubles to ints

True for two main reasons (4, Informative)

petrus4 (213815) | about 3 months ago | (#46876217)

a} Clueless psychopathic suits in management, who make impossible schedule demands, and have no programming background themselves.

b} The use of popular, but garbage programming languages. C++, PHP and Perl are probably the main three culprits here. Dishonourable mention also goes to XML, JavaScript, and the XHTML Document Object Model. I have never encountered a "Web application," yet, which wasn't a disorganised, bloated, CPU hogging abomination.

For the last two months I've been economically forced to use a dual core 1.5 ghz laptop with 2 gb of RAM, and it can only barely keep up with the inefficient, JavaScript-infested obscenity that the Web has become. Virtually none of said JavaScript ever provides truly valuable functionality, either; most of it is just trackers of various kinds.

It's also purely due to Capitalism; all of it. Why have Red Hat had Lennart try and force systemd, GNOME, and the rest of their corporate crapware on Linux users? Their desire for a corporate monopoly, that's why.

What caused the UNIX wars? Corporations wanting to add their own non-standard extensions, to ensure their coveted Unique Selling Positions.

We must get rid of the suits.

Re:True for two main reasons (1)

Anonymous Coward | about 3 months ago | (#46876405)

C++, PHP and Perl are Turing complete. You can write beautiful code with them, and awful code. You can also write beautiful code and awful code with darling languages like Python. The real problem is, regardless of programming language, the people who write the code.

Re:True for two main reasons (1)

Anonymous Coward | about 3 months ago | (#46876641)

Ook and Brainfuck are also Turing complete. Turing completeness is not sufficient to imply that you can write beautiful code in a language.

Re:True for two main reasons (1)

Begemot (38841) | about 3 months ago | (#46876559)

Following your post, if by any chance you haven't seen the Expert video [youtube.com] yet, it's a must :)

Re:True for two main reasons (5, Insightful)

jandersen (462034) | about 3 months ago | (#46876659)

Clueless psychopathic suits in management, who make impossible schedule demands, and have no programming background themselves.

Yeah, I can feel like that too, sometimes. However, I don't agree with the picture you paint - it isn't the case that all management is always useless and harmful and all engineers are always competent and beneficial, but so completely restricted in their options that they can't write good code. Most managers in most IT companies are in fact willing to listen to sensible advice and make concessions that make life easier for their staff; after all, a manager's success is measured by how well his team as a whole does, so a successful manager is likely to be one who is able and willing to communicate with his employees. But it only works if the employees are able and willing to communicate facts to the manager in a language he can understand and use to make sensible decision with; and engineers are notoriously bad at doing that.

The use of popular, but garbage programming languages. C++, PHP and Perl are probably the main three culprits here. ...

There is an old saying that goes something like: Don't blame the tool for bad craftsmanship. If you are a good programmer, then you can write good code in any language that you know - COBOL, FORTRAN, ... Haskell, C, C++, ... - even Intercal. The problem with some languages is that they demand much more of the developer - using C++ well requires a much higher level of theoretical understanding of good design than using a simple language like C, so it is much easier to loose your way in obscure and misunderstood constructs in C++.

Re:True for two main reasons (1)

Anonymous Coward | about 3 months ago | (#46876711)

"The use of popular, but garbage programming languages. C++, PHP and Perl are probably the main three culprits here. Dishonourable mention also goes to XML, JavaScript, and the XHTML Document Object Model."

I have seen very well organized code in PHP and JS, and therefore the conclusion is that the culprit is not the language but the programmer and maybe improper management expectations.

I honestly cannot imagine that somebody who cannot do proper application architecture design, will be magically able to do so, if he switches to a different languages.

Conversely I do not see a reason, why somebody who can do proper application architecture design, cannot do so in PHP or JS.

Programmers just need to have a look at frameworks like Symphony or AngularJS, and grasp the basic object design patterns. Many programmers are not capable of this and switching language will not save it. They just need somebody to write class and method stubs for them, otherwise they always design garbage.

It's hard but not that hard (2)

purnima (243606) | about 3 months ago | (#46876439)

Thinking is hard, but there is a kind of thinking that is harder.
Rough order of thing (easiest to hardest).

1) lounging around doing nothing (easiest)
2) doing what you are told to do without physical exertion (menial white-collar work)
3) doing what you are told to do with physical exertion (menial blue-collar work)
4) independent thinking about things not involving organising other humans (programming, painting, composing music, solving systems of equations)
5) independent thinking about things involving organising other humans (managing programers)
6) independent thinking about things involving organising other humans who are in turn doing independent thinking involving organising other humans (hardest)

Glad (1)

sjames (1099) | about 3 months ago | (#46876525)

I'm glad he's not bitter about that shit!

Reading this article (0)

Anonymous Coward | about 3 months ago | (#46876603)

also reminds me that people always want to assert how important, difficult and taxing their profession and job is, regardless of what it is they do.

Woe, is me... (0)

lasermike026 (528051) | about 3 months ago | (#46876619)

I'm an egotistical programmer who can't conceive of anyone position but my own. They should pay me more.

Segmentation: core dumped (1)

jenatremens (249314) | about 3 months ago | (#46876645)

</rant> tag was not correctly open... I got down reading the whole article, but that thing crashed me!

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>