Posted
by
Soulskill
on Wednesday July 03, 2013 @02:33AM
from the it's-just-a-matter-of-code dept.

itwbennett writes "Software developers are, by and large, a cool and analytical bunch, but there are a handful of things that strike terror in their hearts. Phil Johnson scoured developer forums looking for an answer to the question: What's your biggest fear as a programmer? The answers clustered into 5 broad groups ranging from being forced to learn or use a specific technology to working for and with incompetents. What's your biggest fear?"

Because I'd rather work at McDonalds for $8/hr instead of $2/hr as a programmer, but then again I'd probably just go live in solitude in the mountains somewhere, away from technology should she betray me in such a way.

What does that mean. We as a culture have gotten very fearful within the past Decade. The fact that we are afraid of so much stuff has created more problems to be fearful of.

Polarized Government: With people so fearful about a lot of things they will try to pinpoint the government as the major contributor. If you are right of center than Big Government is out to make your lives worse. If your are left of center then it is those Corporations that are out to make your lives worse. Those people who support your opposing side must be corrupted in some way. So they need to be stopped!

Obesity: Lets not leave the confines of our own homes because there are dangerous people around the corner who wants to kill, abduct or mug us. So you stay inside where it is "Safe" after a while you start getting out of shape, then you don't want to go out even more because you are out of shape and are afraid of being insulted by people who don't like the way you work. You would go to the Gym, but only after you lose 20lbs first (so you are not the Fat Guy at the Gym), but losing those 20lbs is hard because you are not going to the gym.

Economy: We need small businesses who can innovate (and much more than silly mobile apps). However people are afraid to start businesses because there is a chance that they will fail. Or get some lawsuit for stepping on some bogus patent or make a product that someone misused and hurt themselves. Combined with the fear trying to meet current regulations that you don't know about. Also fear of looking for an other better job because of uncertainty on how well other companies will last combined with companies fears about the same thing preventing them from hiring.

Economy: We need small businesses who can innovate (and much more than silly mobile apps). [...] Or get some lawsuit for stepping on some bogus patent or make a product that someone misused and hurt themselves.

And this is, I'm afraid, a pretty valid reason not to bother starting up a technologically innovative business in the US. As soon as you gain any traction you will be swamped with patent claims from many different patent trolls.

If you are right of center than Big Government is out to make your lives worse. If your are left of center then it is those Corporations that are out to make your lives worse.

... And the extremists on both sides see the ever-increasing collusion between the two as the real culprit. There's still competition between corporations, but it's competition for influencing the right politicians or bureaucrats, instead of being better at serving customers.

I've heard a lot about outsourcing but from my personal experience outsourcing in real life is pretty much akin to the $5 hair cut. If you don't know what that is basically: A guy runs a barber shop and charges $20 per haircut. He notices that a barber shop is opening up across the street with a big sign that says "$5 Haircuts". So instead of panicing and dropping his price the expereinced barber puts out a sign that says "We fix $5 haircuts".

And in my experience that's usually what happens. Someone gets the idea that outsouring a project would be cheaper and just as good as hiring someone experienced to do the job. To go and take the bargin basement bid from some Indian firm, then inevitably the project goes over deadline, the developer requires more and more money to finish the project, and then they finally bring in a consultant to look at the project, they request the code and the code is usually an unsalivagble mess. Experienced developers fix $5 haircuts, or crappy outsourced code.

The part that can really hurt US developers is the middle ground. While we have all heard (and many of us cleaned up after) disaster stories of bargin bin outsource companies, there really are quite a few out there that are both cheap and have skilled developers. For better or worse, the US has a high cost of living and thus you can pay off shore people less while still having robust competition between those firms.

I've heard a lot about outsourcing but from my personal experience outsourcing in real life is pretty much akin to the $5 hair cut.

Funny, my experience has been more with the $300 salon that takes 3 hours to do the job, and still screws up.

The outsourcing firms I've worked with have typically been the larger three-acronym types, working for clients who have become so terrified over IS and IT solutions that they outsource the whole thing to a big, well known firm and pay a pretty penny doing so.

I've found the technical people at these firms are often either(a) right out of school, and just earning their stripes until they can find a decent job.(b) new immigrants, and just working their until they can find a decent job(c) outsourced entirely, with all the disadvantages of communication and time zones(d) terrible at what they do, and just hiding out

I've seen a few good people, but the firms always seem to add a bureaucratic mess of processes that do nothing but slow down the projects and increase the billable hours for the outsourcer.

And what do these companies offer to command such high rates?Better salespeople.

I'm convinced that many outsourcing firms spend far more time and money hiring and vetting salespeople and PM's than they do on technical resources.

They one thing they are fantastic at is convincing upper management that projects:(a) will take longer than expected(b) will be more complicated than expected(c) need more resources than expected(d) fail due to circumstances entirely outside their control

First off there is a difference between Outsourcing, and Offshoring, which is what I think you are really referring to. Secondly I have yet to find a country where you can higher a programmer for $4160/year ($2/hr * 40 hours * 52 weeks). Yes I know this is 1) The internet, and 2) Slashdot, and 3) I am replying to an AC, but hyperbole just makes it easier to dismiss what you say.

Like everything, there are upsides and downsides to both Outsourcing, and Offshoring. I am a consultant, which means that every single one of my clients has decided to outsource some or all of their work. However because I am domestic, that makes it OK?

It is far better to ask why are they outsourcing? I once worked with a company that decided to move QA to india. The reason had nothing to do with cost savings, but had everything to do with having two teams 12.5 hours apart (well sometimes 13.5, daylight savings). The point wasn't cost savings by offshoring, but to streamline development, and for them it worked. If you look at the world of VisualFX, many of the larger companies are setting up divisions all around the globe so they can have work the "follows the sun".

And then there are companies that do it for the wrong reasons. The think it will save them money, and it can, though not as much as you seem to think (or likely the people whose kneejerk reaction got you to a 5, Insightful at the time of writing this). If you just throw work over the fence, don't provide oversight, don't show that you care, then you are going to get the horror stories you hear about. I've seen that reality too, I have been paid a lot to fix messes like that.

You can outsource and/or offshore for the right reasons, or the wrong reasons. It can be a boon, or it can be disastrous. There are no universal absolutes here. The term you used is too big, too general, and you too — seemingly — misinformed to make a blanket good/bad statement.

Also how would "outsourcing" be a result of technology betraying you? Technology is a tool. Tools don't have to assure you a standard of living, that is a societies job.

On many small places programmers act as sys admin or DBA. But a DBA cannot protect you from a bad update or delete rows statement that programmatically wipes data out because of bad logic. We can go find a backup tape and shut people down while we restore it... That's about it.

The programmers insisted that the production database not have any passwords, for their convenience. The DBA protested mightily, but was overruled. Then it happened. We were in the middle of something else when the company's website stopped responding. It was a mad scramble to find out what the hell had happened. I remember very well the sick look on the DBA's face when he went to check the database and announced in shock and dismayed surprise "it's gone!" First thought was that somehow we had been hacked. The DBA quickly found what was responsible: SQL commands to drop all the tables. The network admin went hopping about like a rabid frog making sure he could still log in everywhere and trying to run down the IP address that had originated that command. A few minutes investigation didn't turn up any supporting evidence for the hacked hypothesis. Had to be an inside job. We had just reached this conclusion when a programmer fessed up. He meant to wipe out and reload a demonstration database, but accidentally targeted the wrong machines and destroyed production. The idea of setting up a slave database didn't protect from this. Then it was discovered another programmer had turned off the daily backup a week before, to free up some CPU cycles. The DBA managed to recover, because he had also had all the transactions logged, but it took a full day to restore the database to a usable point, and then a further 3 weeks to clean up.

The stablest C code I've ever worked on used GOTO for error correction. It was WAY stabler than the C++ code that replaced it using try-catch blocks.

My biggest fear for a long time was templates. The reason I feared them is because I used them to re-write a C graphics engine I got a source copy of into C++. I used a lot of novel approaches that should have sped up the whole thing, including a blitter (that should date me...) that was 4x faster because I used the floating point unit's much wider data path for block memory moves than the C code did, and wrote it in assembly (in fact, that exact same technique was published in a book called The Black Art of Game Design, albeit with slower code than mine, partially because it was not in assembly). When I got it done and compiled it, I was dismayed because my code was slightly slower, and after a few more optimizations, about the same speed. Baffled by this, I profiled the code, and the entire slowdown was template calls at the lowest level that triggered a lookup table that was abysmally slow (templates were REALLY bad in the compiler I was using, which I think was Borland). Unfortunately, it broke the entire codebase and I essentially had to throw away the entire engine and redo it from scratch. On the plus side, the rewritten engine was not based on the existing one and landed me a job writing games, albeit briefly (working 16-18/7 for months during crunch, sleeping at work, etc - very rapid burnout).

There's nothing in that list (with the possible exception of "being forced to use a specific technology") that wouldn't apply to just about any worker.

Programmers fear incompetence because they see it everywhere, even where it is not. They just don't recognize the value of thinking that isn't exactly like their own, or skills they don't have. So, this one applies to many, but to programmers more than anyone.

Programmers fear screwing up because they are in the business of automation. They can screw up many things all at once. Complete failure over a trivial error, because computers don't have common sense to ask, "are you sure you meant to do that?", or, "what does this mean?". This one also applies to anyone building something that can injure people, but not to most other people. Most people can only screw up one thing at a time, or have people receiving the product of their work, who can sanity check it.

There are many things to be afraid of. I think my biggest fear is being irrelevant, something I feel greatly sometimes as the young hotshots come up from below and as more gray hairs appear. And because of my ADHD and dyslexia, I fear not being able to use my intelligence when I need to use it because my brain refuses to work.

But there are more terrible things to fear. The wrath of my evil cat when I step on her tail and what she leaves in the kitty litter that I have to clean up are two such horrible prospects. And when I was married, my wife was quite scary at times.

But really, when one looks at the big picture, the only thing to fear is fear itself (as FDR said). Accepting life on life's terms and not wasting time on trying to change things that can't be changed is what's important to me.

"Hey your software is broken! It doesn't stop me typing "cat" in a date field!"What did it say?"value is invalid"There you go then!"But it didn't stop me typing it!"Because it assumes you are not a moron? You're right, it is "broken"...

This really brought up memories.. (source http://bash.org/?4281 [bash.org] )<Zybl0re> get up<Zybl0re> get on up<Zybl0re> get up<Zybl0re> get on up<phxl|paper> and DANCE* nmp3bot dances:D-<* nmp3bot dances:D|-<* nmp3bot dances:D/-<<[SA]HatfulOfHollow> im going to become rich and famous after i invent a device that allows you to stab people in the face over the internet

True story, at some point in the past I had to work on a company's internal application for data entry. Well, it was a lot of data and, as requested by the PHBs, pretty much half the fields were needlessly mandatory. (Which brings us of the fear of working for incompetent people;))

Most of them were pretty much impossible to validate too, because they were stuff like city or street names, and even in telephone numbers people tend to use letters. So the only real restrictions were field lengths and that they'

Mandatory fields in addresses are a truly insidious form of evil. They screw everything up, because not all addresses have the same structure. I've seen address forms that have mandatory house number/name and street name fields (sure, I can fill those in for my parents' address, but you'll get them the wrong way round when you print them out and the delivery might never arrive). Here in the UK, one thing that really annoys me is mandatory county fields, which you see sometimes. Yes, we have counties, bu

One of the companies we work with has a mandatory fax number on their system. This is truly annoying as there are a fair number of people who have absolutely no access to a fax machine. However, I think the purpose of mandatory address fields is to prevent people from not entering anything at all. People will place orders from stores without putting in their full address, making the item undeliverable. Or they'll leave out both email and phone number (OMG Privacy, Can't give these awasy, might get spam o

Office politics. Just lovely when the management fucks up through sheer stupidity, but still has the cunning to find some way to blame you for it and make it stick.

I'll whip out a car analogy. The bosses direct the driver down the wrong road. The driver questions this, but is told to shut up and drive, he doesn't know what he's talking about. 100 miles later, they realize they're not on the right road, and the screaming starts. They blame the driver for taking the wrong road, and fire him. They hire a map reader. They turn to the mechanic and demand he get 200 mph out of the engine, no excuses will be accepted and if he can't do it, he will be fired and they'll get someone who can. Never mind that the car is a cheap econobox that can't even do 100 mph. The mechanic manages a miracle and coaxes 120 mph out of the engine, and is promptly fired because that's not good enough. Over the protests of the map reader, they elect to take a desperate shortcut on a dirt road, to try to get back on track, and end up stuck in the mud. They fire the map reader, but are still stuck in the mud. With no one left to get them out, and no one left to blame, they finally lose their grip. Customers and supporters abandon them.

Is that still around? I thought when the recession hit most companies realised that one of the first things you should cut is pointless money and time wasting bureaucratic process and just hire people who know what they're on about and have real actual common sense whilst firing those that don't.

Please don't tell me now that the global economy looks like it might be improving again soon that it's going to make a comeback?

Is that still around? I thought when the recession hit most companies realised that one of the first things you should cut is pointless money and time wasting bureaucratic process and just hire people who know what they're on about and have real actual common sense whilst firing those that don't.

Nope. In organizations with more hundreds or thousands of IT people and thousands of systems (not to mention dozens of countries and a handful of sourcing agreements on top), you're gonna need some process to control change and coordinate responsibilities. I'm not saying ITIL is pretty, or should be fully implemented everywhere (perhaps not even anywhere), but doing everything ad hoc, when you can't simply shout at each other across the office, is much, much worse.

I would never suggest doing things ad-hoc. I've worked in such organisations, one had around 6,000 systems and even more users, with a number of distributed sites and I worked in an IT support role at the time and currently in a similar organisation but now as a developer.

I think processes are good, but some of the stuff ITIL mandates is just stupid and sometimes even counterproductive.

Hiring people with common sense and ditching those without doesn't mean doing things ad-hoc and completely without process, it just means having processes that make sense and adapting/destroying them when they don't. Too many organisations blindly follow ITIL even when it works against their interests.

ITIL, and redundant processes in general, are part (or the result) of one my fears: the dumbing down of my job to the point where there's no need for or chance to excel (as in doing a good job and making a presonal difference, I don't mean spreadsheets!). Large organisations need process and structure; they do not need ITIL.

ITIL is still very much around though. Many large companies are reorganising IT and other knowledge work, creating increasingly specialisatized and compartimentalized jobs and teams that appear to be easy to plan, manage, measure and outsource (but aren't in practice). Much of IT is being turned into an assembly line, which might be ok for making cars (although even that industry has thought better of dumbing things down too much, a long time ago), but in my experience works very poorly for knowledge work. It's an attempt to reduce some of the inherent uncertaintly in our line of work, and the effort of managing a diverse set of highly skilled people, by dumbing down the work and replacing intelligent decisions and judgment calls with process and SLAs. Someone coined the term "predictable mediocrity" for this. The result sucks but you know what you're getting, and most managers (the MBA types) actually prefer this.

This way of working adds red tape and communication overhead, as you'll be dealing with more and more specialized teams, and reduces project buy-in: no one gives a damn about any single particular project anymore. I've recently been involved in a project where the ratio of process to doing actual work was around 20:1, I kid you not. And I do include producing useful documentation, agreeing on a support model, and hammering out specifications in the definition of "actual work" here. My fear is that this is the future of IT.

Waking up, and finding myself stereo-typed into one job, one branch, or another. I like the idea of mastering each branch fully, but find that there's never enough time to do everything I'd like to do, or learn everything I'd like to learn. And of course, your job becomes your life...I don't know why, but I had ideas, when younger, of changing that equation, of making jobs more efficient, so more time could be spent elsewhere (leisure, edification, etc.)...and yet, I seem to be spending all my time repairing damaged items or chasing dead-ends, rather than pursuing these agendas. It's like my equation has been turned on its head...and I don't know by whom, or why. Computers are supposed to be freeing man from his burdens, and in doing so, helping advance themselves; instead, they seem to be acting as balls and chains...or worse, in the case of the NSA, where they are being used to spy on people.

Even the work I am doing on my autodidactic program (human learning) or evolutionary program (machine learning) feels like I am chiseling away at a granite mountain with a wooden spoon. Why is this kind of programming so difficult, yet the algorithms to spy on one another seem to flow from the heavens themselves?

They don't, that's why despite MI5 knowing personally a terrorist they still managed to miss the fact he was a threat when he committed a violent murder in the name of terrorism on the streets of London a few weeks ago.

This is why many people including me dislike said algorithms, not because I have an inherent problem with them spying on people if there is just cause and they are an actual threat, but because I know that their algorithms when run against everyone and anyone can't possibly accurately separate real threats from innocent people and will result in manpower being wasted investigating, harassing and harming innocent people whilst simultaneously missing the real actual threats.

I know everyone takes out "job security" flag when lack of documentation or tests is mentioned, but seriously, how frequently does it happen? Most of software is not that sexy that everyone will want to rush in, replace you and keep it same quality level as you are. Of course, management can be a bitch, and threaten with replacement if you request wage rise, but then it's probably not best place to work anyway.

Automated tests do two things. They make sure you don't make the same mistake again, and they give you higher confidence levels when you refactor. They definitely improve quality when done right- which means testing what needs to be tested, not relying on your tests as documentation or correctness proofs (I'm looking at you TDD), and not spending time writing tests that aren't really useful or for modules that aren't really easily testable (for example, testing that the UI is right).

Remember when the Hubble telescope first went up, and could not focus? It had all been tested on the ground on an artificial star target. Unfortunately, the test rig had a plate that was about half-an-inch thick that should have been subtracted from the optical path. So they had a mirror that was accurate to about 1/100th of a wave but half an inch in the wrong place.

There was a rocket where the guidance for the two stages had been coded separately. One stage used a value of -9.8 m/s2 for 'g' because it measured heights upwards and the acceleration was downwards, while the other used a value of +9.8 m/s2 and flipped the sign in the equations. When the rocket took off, the first stage was fine but the second stage suddenly flipped over.

That's what I dread: thinking I have checked everything, and thought of everything, and then finding out publicly and expensively that my regression tests were worthless all along.

That's what I dread: thinking I have checked everything, and thought of everything, and then finding out publicly and expensively that my regression tests were worthless all along.

I believe that an analysis of the Apollo Project and other similar engineering projects has shown that integration malfunctions are the most egregious kind of errors, both in terms of their proportional presence among all failures and in terms of their eventual costs. For example, the infamous "1201 alarm" (that fortunately didn't cause a loss of the vehicle and the crew) in the final phase of Apollo 11's landing was found to be caused by insufficient integration testing (and I also believe that there was a tiny discrepancy in the testing environment that prevented the engineers from finding out about the problem in advance).

Remember when the Hubble telescope first went up, and could not focus? It had all been tested on the ground on an artificial star target. Unfortunately, the test rig had a plate that was about half-an-inch thick that should have been subtracted from the optical path. So they had a mirror that was accurate to about 1/100th of a wave but half an inch in the wrong place.

It gets better. There were *two* tests; the other one was a more basic test that wasn't as accurate--but it was accurate enough to show the m

How do you know which aspects of its behaviour are intentional and which are bugs?

Actually, that's exactly the stuff that writing a test suite and thinking about the examples should help you figure out. If you don't do that in advance, thinking about it when modifying the code is like thinking about the diagnosis when the patiend is already on your operating table with a large hole in his chest.

Worst case was being flown in to summarize a system's functionality (don't know why, but staff was terminated en-mass) only to find the documentation was photocopy pages in boxes. That's it; no folders, no color coding or anything, just loose sheets. Top that with many of the copies being so faded as to require literally fifteen minutes or so each to figure out what things were. After a week and being shown the state of things, they decided to scrap and

in the middle of a long, long, lo000ng and costly number-crunching run, and that just because some management moron thought that we'd save some money by buying cheapo hardware. I fear that with deadly fear.

Half the problems with threads are due to unintended consequences of sharing run paths and globals/statics in the program and in libraries. If a process can only communicate with another process via specific memory addresses and it doesn't shared ANY other data or run path then the unintended consequences will be much reduced.

"e.g. you communicate over pipes or sockets - then your statement would make more logical sense"

To not make the difference in the world in the way that I envisioned. It's everything at once and nothing specific. My betterment of the world doesn't even have to be in programming, although programming is where my best talents are. I've always wanted to leave the world a better place than when I came into it. Unfortunately, I can't say that I feel that way so my biggest fear is coming true and I'm having to learn to cope with the idea that I cannot fix the injustices of the world.

Ah, I remember my 20s.
I wish I could find that comic. Something like:
Just out of university: "I'm going to change the world!"
After one year at first job in your field: "I'm going to change this company!"
After ten years: "I'm going to change the coffee!"

In the project I'm maintaining now, I've discovered such gems as "someVar++// count down" and "if(someDouble == 0 || someDouble == 0.0 || someDouble == 0.00) {... }". Oh, and literally hundreds of global variables whose values are copied in and out of instance and local variables in seemingly random places. I'm sure the guy who wrote it was one of those students who comes to the Java forums begging for help because they didn't pay attention all semester and have absolutely no idea where to begin on their final project, which is invariably due in a few hours. I don't even want to know how much they paid him to write it, but it's cost the company at least 1.5 man-years just to get it into a state that's acceptable to most of our customers, and it's still nowhere near as good as if we'd spent (I would estimate) 0.5 man-years rewriting the whole thing from scratch.

Being stuck at a job, because you drifted away from your main skills, and now have difficulty to catch up. Or more specific: being stuck at a job where you don't want to spend another year or even longer. In the company I'm working I stand alone, being the only programmer, so no support from other programmers. I find it hell to get my skills up to date while doing my job properly.

Average programmers being forced to write parallel code scares me more than anything else. "The multicore dilemma is actually a substantially worse problem than generally understood: we are headed not just for an era of proportionately slower software, but significantly buggier software, as the human inability to write good parallel code is combined with the widespread need to use available CPU resources and the substantial increase in the number of scientists with no CS background having to write code to get their job done." --The multicore dilemma (in the big data era) is worse than you think [flowlang.net]

Average programmers being forced to write parallel code scares me more than anything else. "The multicore dilemma is actually a substantially worse problem than generally understood: we are headed not just for an era of proportionately slower software, but significantly buggier software, as the human inability to write good parallel code is combined with the widespread need to use available CPU resources and the substantial increase in the number of scientists with no CS background having to write code to get their job done." --The multicore dilemma (in the big data era) is worse than you think [flowlang.net]

This is probably the most true thing I've seen in this list, and the fact that you're the only person who posted it is a sign of just how bad of a problem it is.

Rounded to the nearest whole number, I think its absolutely safe to say 0% of programmers understand how to write multithreaded code properly.

Even worse - when you have multicore nodes in a distributed system over CAN and LIN buses with random gateway latencies and different suppliers of every node in the network. It's quite "interesting" when you have some 70 nodes in the net. Add to it that not all nodes may be up and running in some cases.

Enough! Its already got a spec probably more complicated that the space shuttle , just let us get on with using it instead of throwing in ever more useless features that only ever seem to get used in job interview questions!

I mean the new "auto" syntax is clearly just *designed* for job interview pedants rather than making the life of the everyday C++ programmer less tedious and error prone.

And the lambdas. Those are so rare in mainstream programming languages that it's just clearly an academic circle jerk rather than another feature to make programs shorter, less buggy and more readable.

Oh yeah, and honestly, I used to really love pwning n00bz when they got heaps of compile errors for using >> instead of > >. The committee has now spoiled my favourite smug git pass time.

Its already got a spec probably more complicated that the space shuttle

Funnily enough you never hear the same complaints about Java. Fun fact, excluding libraries and the JVM, the latest java language spec is now slightly longer than the latest C++ spec.

The thing is that all languages start off nice and simple. The world however is never simple.

This happened to me. There's just no joy or pride left in my work. I'm in a slow useless never ending zombie mode. Struggling doing something as simple as opening up a code editor. Been looking to change my job for the last year, but I can't find anything of interest. I'm sick of programming, but it's the only thing I'm good at (or used to be good at). Retraining at age 40 to change my career? I think I'd rather just drink myself to death.

Seriously, web programming is for chumps, and it just keeps getting worse and worse.Let's talk about having to support multiple version of multiple browser on multiple versions of multiple operating systems on multiple platforms, all with multiple sized screens.Let's talk about the expectation of being an expert at a horrendous number of technologies like HTML, CSS, Javascript, Ajax, GWT, Java, JSP, EJB, XML, JSF, Facelets, JPA, JPQL, EL, SQL, PL/SQL, Regex, BASH etc. etc....for the one fucking project!Let's talk about the expectation of being an expert at optimising different servers like Apache, Tomcat and JBoss.Let's talk about the expectation of being an expert at load testing using various load testing suits.Let's talk about the dismal state of Flash and Java Applets and HTML5.I pity the poor web programmer (such as myself), for his or hers is surely a tortured life.

Seriously, web programming is for chumps, and it just keeps getting worse and worse.

Having worked on websites since '97 (and learned "on the job", so to speak), I can actually say it's getting better quickly. Standardized approaches like responsive design and Bootstrap [github.io] are helping tremendously. Also, most of the technologies you mention are used in a small percentage of Web applications...for better or worse, most Web developers are dealing with the LAMP stack + HTML + CSS + JavaScript.

> Seriously, web programming is for chumps,Really? The web rules because you don't have to install software on any computer other than your own server and HTTP naturally handles networking and caching for you, allowing your program to run anywhere. True, the W3C is completely impotent and the modern web is a bit of a kluge, but no so much more so than everything else that the no-install, run-anywhere benefits don't dominate. Web is the ONLY way to go.

But XML is the most abysmal failure of a language ever. SQL is really how we represent most useful data, but if falls down when representing hierarchies. That's where XML comes in. But XML fails horribly at relational data. There are (or were) too many supposedly validating parsers that didn't validate the uniqueness of xml:id attributes. And even if yours does, XML data is ugly and nearly impossible to read and write relational data in manually. And, unlike SQL, which is simple and elegant, xpath almost as

Whenever I hear a congresscritter make noise about restricting research, or instituting programming certifications to get a job, or my (now ex-)company requiring a training session on how to walk because someone tripped in the hall, I get scared for the country as a whole because we've cultivated this environment.

You know, when accents on characters show up weird in the browser and you dig deeper and deeper to discover UTF-8 characters in the Latin-1 encoded database, but aren't sure your database client is showing the data in correct encoding and the dump you openend in the editor looks even weirder because it's trying to read the stuff in UTF-16 which the terminal the editor is running in doesn't support etc etc etc.

The biggest fear is that a group of people who are clueless about what actual customers want and never talk to anyone outside their small circle believe that they know more about what customers want than people that actually talk to customers.

The office "power user" who convinces management that he should be able to manage his department's IT infrastructure by himself because "he's more efficient than those guys in tech support".The highly connected programming manager who recommended a new applications platform because "it'll look good on my resume".The large systems salesman who plays golf with the chairman of the board.

I fear the one programmer who write thousands and thousands of lines of spaghetti code that can be done in hundreds of lines if written correctly. Especially if his program "works" well enough in a demo for some idiot middle management guy to think we should make it into a product to sell.....by next week.

Worse is the suits picking up your Pooperpoint, changing it, and selling something which bears almost no resemblance to your original project and should be DOA but now you become the lead for this new and improved version.

I really hate working with lazy stupid programmers who were hired only to fill out an HR racial preference checklist. Nothing is more demoralizing than working with a shiftless, smelly, untalented "winner" of the racial preference lottery.

Y'know, of all the jobs I see filled with useless people, I honestly have never seen that effect in programming.

I've met plenty of coders who the rest of us would all do better if they surfed for porn all day; I've met coders who, once they corner you somewhere will t

C is a fairly simple language to code in and debug. If you have problems with pointers - ie memory addressing - then seriously , find another vocation or stick to HTML because programming computers is not for you.

C has simple semantics certainly. However it provides very little opportunity for automating common programming tasks, which means that everything has to be done by hand. That makes debugging harder since there is 10x the amount of code to wade through all of which could potentially contain an error.

If you have problems with pointers - ie memory addressing - then seriously , find another vocation or stick to HTML because programming computers is not for yo

We run such a shop, but I'm a sysadmin here. I apologize. But you know that guy down the hall. The one who likes to copy.so files around from machine to machine because he thinks he knows what he's doing. The one who installs hundreds of god-only-knows-what pieces of software on his workstation. The one who's computer I can't just reimage because he swears he needs all this stuff that such as process would remove. He's why you're not root. And it turns out there are a lot more of him than you'd think.