Seriously, slashdot has been providing us a great site for how many years now? And at the first sign they are doing something we might not like everyone turns on them like a pack of rabid wolves. It's a bit disappointing.
Yeah, the beta site is ugly, and it lacks a bunch of features. it's *BETA*, as in NOT FINISHED YET. Can we give them a little room to work on it before leaving en-masse? "Release early, release often" is how you get software into shape. When they asked for feedback, they needed constructive criticism, not useless abuse. So they didn't instantly respond to everything you posted complaints about. THEY'RE BUSY. Give them a little time.
This avalanch of ranting, conspiracy theories and threats isn't helping any, and it's a poor way to repsond to people who have supported our community for so long.
I had various problems with email address collisions as well. Then when I had to change ISPs, I decided to get my own domain name. It's a little different when you own your own email address. If you register a domain, you can be firstname@lastname-variation.net or such. Then you just forward from your actual email host to the registered email address. It's only a few dollars a year. Then YOU decide who gets an email address for your domain, and you can have whatever policy you want to avoid collisions.
There are three methods of authentication: Something you know, something you have, something you are. Passwords are the first category. In the case of amnesia, you lose all that. Any method of reclaiming passwords that also requires you to know something will also fail with amnesia, so a device with a PIN or another layer of passwords or those stupid "security questions" won't work. You can transform case 1 into case 2 easily by putting your passwords in some type of lock box. However, if you have amnesia, how do you remember where you put it, and how to open it? If you do get into your safety deposit box and find a piece of paper with 'myxlplix' on it, how do you know what that means, or what it's for, if you can't remember? The third category is basically biometrics, which might work, unless the same accident that gave you amnesia also cut off your right hand, or put out your eye, or lost whatever body part is needed to authenticate you. And of course, you have to remember that you have biometric authentication, how to use it, and what it's for.
And then there's this: any method for storing or reclaiming passwords that is outside your head weakens the security of your passwords. If you can get your passwords back without needing to know something only you know, then someone else can as well.
I for one would love to have a smart license plate. Just think of the hacking opportunities!
Jailbreak your license plate and display snarky messages to the other drivers on the road. Change your state to "confusion". Temporarily change your plate number and see how many red light cameras you can trip in a row. "Borrow" your rude neighbor's id and run up their toll bill. Steal a smart plate and hack it so you don't have to pay to register your vehicle. The possibilities are endless.
Any "smart" whatever can and will be hacked. If the incentives are large enough, those hacks will get widely distributed and used. How many incidents of license plate hacking will it take before the police decide it's just an expensive way to enable smart criminals? Not too many, I'd guess.
As a user, I am often frustrated by the terse, non-informative error messages I get when something goes worng. "Cannot open file" is typical. Which file? In which directory? Why couldn't it be opened? What is the file for? What is supposed to be in it? What part of the program was trying to open the file? The available on-line help is mostly not helpful in these cases, and FAQ's written by the developers, not the users are useless. Even finding out where the log is kept, much less actually seeing useful information in it? Good luck with that. How can I as a user file an informative bug report with such scarce information?
So first suggestion: build into your programs meaningful error messages, along with enough information to accurately diagnose the problem. Include options to turn on debug output. When an error is detected, log complete information about it into the log file (the location and format of which should be documented). That way the user has a chance of making a good bug report. And be sure to ask for that information when the bug is filed, with specific directions about how to find and include it. "Append log file" isn't enough, you have to tell them where and how to find the log file.
As a developer, I know the frustration of vague bug reports, that leave out vital information. Simple things like which version of the program was being used, or the configuration settings. You have to make it clear to the reporter that you cannot solve the problem if you don't have enough information. One company I worked for actually had a bug state named "Not Enough Information." The only cure for this is to engage with the end user who reported the bug. And the biggest incentive for that person to engage with you, is the prospect of getting his bug fixed, soon.
So second suggestion: be very reactive to people who report bugs. Get back to them, tell them what's going on, ask questions, and let them test the fix. There is nothing that kills the enthusiasm for bug reporting like going through the process, waiting weeks to get a response, and then be told "Yeah, OK, it'll be fixed in the next version, due out in about 9 months. Thanksbye." And don't underestimate the effect of some user saying to his peers "I reported this bug, and they fixed it for me" to encourage others to report bugs, and make good bug reports.
Of course, there will always be lame bug reports, no matter how you do it. But you can at least encourage good ones, raising the signal to noise ratio.
What is your hardware background? 0 electronics experience? Can wire a bread board? Can Solder? Make your own PCBs?
How much do you want to spend? A couple of paychecks? A couple hundred bucks? Coffee money? Pocket change?
What tools do you have available? Machine shop? 3-D printer? Garage full of power tools? Dremel and a glue gun? Swiss army knife?
What aspect interests you the most? Mechanics? Electronics? Programming? Artistry?
The answers to these questions will determine how you approach the field of robotics. You are getting in at a good time: there are tons of options. Here are a few to get you thinking:
Pre-assembled robots. Cost from $100 to $100,000. If you don't want to mess with building your own, and want to get straight to the programming aspects you can just buy a robot. They range from things like the Scribbler to something from Willow Garage. The more complex behaviors, actions and programming you want to do, the more it's going to cost you. Best option for a beginner: probably the 3pi from Polulu.
Robot kits. Cost anywhere from $25 to several thousand. These come with all the parts, but you put it together. Some of them allow customization, some of them are just the one thing. The simplest ones aren't programmable at all: they just have various behaviors. These may be a good way to get started if you need to learn to solder. Examples: mousebot, BOEbot, many many others (google!).
Robot construction sets. Costs a couple hundred to a few hundred $. If you don't want to get into the electronics, but are interested in mechanics and software, a construction set may work for you. You build your robot out of sets of parts and program it yourself. There's no soldering involved (usually) and you can get right to building something as soon as you open the box. Most notable examples are Mindstorms (Lego) and Vex.
DIY robot parts. ~$100. Basically, you pick out the parts you want to use, buy and assemble them and program your robot. Requires soldering skills, mechanical inclination and some engineering. For example, an arduino with a motor controller shield and a Tamiya tracked base. Takes a lot of work to get all the parts to work together smoothly. You'll spend a lot of time learning and building.
Scrap/salvage parts. Very low budget option, but lots of fun. Instead of buying robot parts, you get the parts by salvaging pieces of broken or abandoned toys, electronics and appliances. You may need to buy a microcontroller "brain", but everything else can come from garage sales and thrift stores (or just stuff tossed out by friends, family and neighbors). You could start with a remote-controlled toy as the base, add sensors from things like dead VCRs, flatbed scanners or burglar alarms, and program a microcontroller to give it behaviors.
And of course, you can combine any of those options. Lots of people start out with Mindstorms or a BOEbot and end up building custom parts for them, or using salvaged parts to add on to a pre-built robot like a Roomba.
Two suggestions. First, you will need a support group to talk out problems and ideas. Online is fine, in person is more inspiring.
Second, find a good book on what you want to do. There are several mindstorms books, there's several arduino books, and of course there is The Robot Builders Bonanza for the DIYer.
When I was in grad school the local ACM/IEEE chapter sponsored a programming contest for several local high-schools. This is a fun way to get kids interested in programming and computers in general. Competitive games are a draw. Contact the ACM, IEEE or your closest university and see if they have any contests in your area. If not, maybe they will help YOU host one. Your kids will get to meet students from other schools with the same interests, polish their programming skills and have some fun. Cool prizes help.
Another area with some cool factor to it is robotics. There are FIRST and BEAM leagues all over the place. Check them out. You could spend a few months getting a contest entry together, involving not just programmers, but budding engineers as well. Even without a contest, having a school robot is cool. And they have something tangible to show off to the rest of the school.
I first learned to code by reading the BASIC manual of my Sinclair ZX-81 and laboriously typing out programs one keyword at a time on that little keypad (after assembling it myself). It's amazing what you can do with 1K of RAM.
> Imagine the power of being able to hire a recent college graduate who has been taught how to develop system diagrams, Using which tool? > build complex SQL, For which implementation? > run log analysis, On which platform? > set up a cloud test environment, On who's cloud stack? > and write automation scripts. In which language?
Sure, it would be great to hire someone who could do all that right out of college. But 5 years later, he'd be unemployable because all the specific skills he learned will be obsolete. What is he supposed to do then, go back and get another BS in software QA?
Hire people who know the fundamentals. Choose people who can learn new skills. Train them. Sure, they won't know the specific tools and environment your particular company uses. But you have to invest in people to get the most out of them. The more highly specialized the job, the more time and money you need to invest in training them. If you concentrate on hiring those who can learn, rather than those who happen to match your particular requirements at the moment, then they can do more than just the one job on the current project. Imagine not having to fire people when the project is over, but instead just move them to something else, even if it requires a different skill set.
> No more crossing your fingers that this eager young face in front of you can really pick up those skills, > and no more investing so much time and money in training them on the job. We ask no less from > Technical Writing and Development. Why do we have such different expectations for one of the most > important functions on the team?" If you can't tell whether or not the person you are hiring can learn the skills needed to do the job, you need to revise your interview process. Sure, there's no 100% way to tell the gems from the lemons, but you should be able to consistently identify applicants who can do the job.
The fact that development jobs often demand a high degree of specialization is, IMHO, a bug, not a feature.
It's true that even an obsolete smart phone has lots of integrated features that you would be hard pressed to find or add to a micro-controller or tiny PC ( like the PI). There are even a few models that have some primitive IO capability, and lots of them at least have a serial port. So you can, with some effort, get some IO going.
But.
The huge advantage of the PI (and Arduino et al) is the development environment. It's free. It comes with the device. You can roll your own OS, drivers, libraries, programs and interfaces. Or build on the work of others via the community of developers who share their code. In other words, it's an open platform (yeah, yeah, quit nit picking).
A smart phone, on the other hand, is going to be much more difficult to develop for, unless you just want to make apps like everyone else. Many of those neat pieces of highly integrated hardware are not documented, proprietary, and don't give you the source code you need to made modifications. Yes, there's Android, but even there doing low-level things like single pin IO, or even just using the components to their full capabilities, is going to be hard, if not nearly impossible.
So for example if you want to make a robot controller, and you have an old iphone 3 lying around, and compare it to a Ras Pi. The Pi isn't going to have built-in screen, wifi, accelerometers, audio, battery and charger. But the Pi is going to be much easier to use for this application. The number of hoops you'd have to jump through to get the iphone working would make it a much harder prospect to use. By the time you finish getting, or custom making, the connectors/cables/circuits needed to hook it up, you'll have spent as much as a Pi or arduino costs. And that doesn't even address the development environment you'd need. Android phones have it much better off, but it's still not as easy as hooking up and programming a Pi or arduino.
Yes, you have a perfectly good cell phone that could, with some work, be used instead of a Pi. The problem is that the cell phone is going to take a lot more time and effort to hack than the Pi.
That's so wrong. Imagine you are on the other end of this process, trying to use that code. You'll never be certain which combination of features exist and are supported and which have either been deleted or not implemented. If you have a logically orthogonal set of features, removing or not implementing a random subset just leaves gaping holes where your users are going to be very frustrated on the day they try to do something you thought was of "zero value".
Just -In-Case development prevents problems in the future, which is what good programming does. Just-In-Time development is a shortcut and leads to incomplete code.
Take something he wrote several months ago, that he's not likely to have on the top of his brain. Then ask him to debug, add to, modify or analyze his own code. Or just ask him to give you an explanation of how it works. It might dawn on him that his own code is unreadable and hard to maintain, if you do it right.
I'd also push back on your manager, to make it policy that until this guy gets his code in shape, he is the one who has to maintain it. Bad code is bad even to those who wrote it. Make him work on his own code.
One) For the return value option: It is usually bad coding practice to mix error codes with information the function returns. If a function returns an int, don't stuff an errno in there when things go wrong. Separate the data from the error code. I hate it when functions that are supposed to return a pointer use NULL as the error code. NULL doesn't tell you anything, and it very well may be a valid value to return anyway. Set errno, send a signal, return a separate error code, but don't put your noise (error code) in the signal.
Two) I want to see the errors. Don't hide them from me. Force me to deal with them, at least as far as generating a meaningful error message. (Meaningful!. that's a different rant.) I don't want the hardware, OS, compiler, library or whatever to take away from me the ability to see -- and handle -- the error myself. Feel free to offer me some boilerplate error code, but don't force me to use it. Half of elegant programming is in the error handling. If you think about it, a program seems "smart" when it handles error conditions well, instead of just crashing or quitting.
And the plus: It seems to me what the guy is complaining about is the aethestics of the code, not the actual error handling. Wouldn't a folding editor help with that? You just mark the error handling code and let the editor collapse it for you, until the time comes when you need to see it (and it will). Problem solved.
Demo this: open up a document in your favorite editor/word processor. Now, go in and change all the 'p's to 'q's, using search and replace. Easy right? Now change all the 'q's to 'p's. This does not put things back the way they were, does it?
No problem, just use "undo" a couple of times and you are back to the original, correct document, right? That's when you point out that without a version control system, you have no "undo". Without it, your only recourse is to go through that document one letter at a time and fix the p's and q's by hand.
Then draw the obvious parallels to source code bugs, emphasizing that finding bugs is much harder than finding misspellings.
One of the greatest learning experiences for a developer is to see things from the customer/user perspective. For that reason, I'm going to buck the trend here and say that developers should HAVE to do at least 1 customer install, just so they know what hell they are putting them through. There is often a big disconnect between what the developer thinks he's producing and what the field people actually have to do to get it to work. The way to fix that is to make the developer go through the experience.
That being said, I do agree that anyone (properly authorized) should be able to install the software. If you can't install it without the developers help, then it isn't ready for prime-time.
If you want to get a feel for whether or not programming can be learned by "anyone," try teaching it to a random group of people.
Before I tried to teach programming to some people, I was of the opinion that anyone could learn to program. If you could cook, or dress yourself in the morning or operate a VCR, surely programming would be within your grasp right? All it takes is someone to explain it clearly enough. That's because it seemed to obvious to me. Wasn't it obvious to everyone?
Not so much. There are some people that just do not get it. The sequential, logical reasoning involved does not come naturally to them. If you spent a few months at it, they might get some glimpse of the basic ideas. Or they could learn to parrot back rote pieces of code on demand. But the ability to write a program from scratch is not inherent. While it is partly a skill that can be learned, it also takes talent that not everyone has.
Of course, programming is not the be-all end-all of existence. Diversity of talent makes the world go 'round.
I just read "Rule 34" by Charles Stross. It has a law enforcement department in charge of internet policing. One of the things it addresses is this issue of what happens to the people who have to see this stuff.
All languages are equivalent in what they can do (See Turing Machine). However, you pick a language that makes what you want to do easy. For twiddling bits, for writing fast algorithms, for controlling hardware, for lots of common programming tasks, C is the simplest language that makes those tasks easy. There are things that are tedious to do in C (like doing complex things with strings), so in those cases you pick another language that is more appropriate. Something that might take up 5 lines of Perl could take pages of C code, but there's no point in writing a Perl script for something that can be easily done with a few lines of C. The C program will be smaller and faster, and probably easier to understand.
So there are lots of things to like about C, when it is the appropriate language for the task.
Slashdot Mirror
But can he do the job?
- Joe Vs the Volcano
Seriously, slashdot has been providing us a great site for how many years now? And at the first sign they are doing something we might not like everyone turns on them like a pack of rabid wolves. It's a bit disappointing.
Yeah, the beta site is ugly, and it lacks a bunch of features. it's *BETA*, as in NOT FINISHED YET. Can we give them a little room to work on it before leaving en-masse? "Release early, release often" is how you get software into shape. When they asked for feedback, they needed constructive criticism, not useless abuse. So they didn't instantly respond to everything you posted complaints about. THEY'RE BUSY. Give them a little time.
This avalanch of ranting, conspiracy theories and threats isn't helping any, and it's a poor way to repsond to people who have supported our community for so long.
I had various problems with email address collisions as well. Then when I had to change ISPs, I decided to get my own domain name. It's a little different when you own your own email address. If you register a domain, you can be firstname@lastname-variation.net or such. Then you just forward from your actual email host to the registered email address. It's only a few dollars a year. Then YOU decide who gets an email address for your domain, and you can have whatever policy you want to avoid collisions.
There are three methods of authentication: Something you know, something you have, something you are. Passwords are the first category. In the case of amnesia, you lose all that. Any method of reclaiming passwords that also requires you to know something will also fail with amnesia, so a device with a PIN or another layer of passwords or those stupid "security questions" won't work. You can transform case 1 into case 2 easily by putting your passwords in some type of lock box. However, if you have amnesia, how do you remember where you put it, and how to open it? If you do get into your safety deposit box and find a piece of paper with 'myxlplix' on it, how do you know what that means, or what it's for, if you can't remember? The third category is basically biometrics, which might work, unless the same accident that gave you amnesia also cut off your right hand, or put out your eye, or lost whatever body part is needed to authenticate you. And of course, you have to remember that you have biometric authentication, how to use it, and what it's for.
And then there's this: any method for storing or reclaiming passwords that is outside your head weakens the security of your passwords. If you can get your passwords back without needing to know something only you know, then someone else can as well.
I for one would love to have a smart license plate. Just think of the hacking opportunities!
Jailbreak your license plate and display snarky messages to the other drivers on the road. Change your state to "confusion". Temporarily change your plate number and see how many red light cameras you can trip in a row. "Borrow" your rude neighbor's id and run up their toll bill. Steal a smart plate and hack it so you don't have to pay to register your vehicle. The possibilities are endless.
Any "smart" whatever can and will be hacked. If the incentives are large enough, those hacks will get widely distributed and used. How many incidents of license plate hacking will it take before the police decide it's just an expensive way to enable smart criminals? Not too many, I'd guess.
I've been on both sides of this issue.
As a user, I am often frustrated by the terse, non-informative error messages I get when something goes worng. "Cannot open file" is typical. Which file? In which directory? Why couldn't it be opened? What is the file for? What is supposed to be in it? What part of the program was trying to open the file?
The available on-line help is mostly not helpful in these cases, and FAQ's written by the developers, not the users are useless. Even finding out where the log is kept, much less actually seeing useful information in it? Good luck with that.
How can I as a user file an informative bug report with such scarce information?
So first suggestion: build into your programs meaningful error messages, along with enough information to accurately diagnose the problem. Include options to turn on debug output. When an error is detected, log complete information about it into the log file (the location and format of which should be documented). That way the user has a chance of making a good bug report. And be sure to ask for that information when the bug is filed, with specific directions about how to find and include it. "Append log file" isn't enough, you have to tell them where and how to find the log file.
As a developer, I know the frustration of vague bug reports, that leave out vital information. Simple things like which version of the program was being used, or the configuration settings. You have to make it clear to the reporter that you cannot solve the problem if you don't have enough information. One company I worked for actually had a bug state named "Not Enough Information." The only cure for this is to engage with the end user who reported the bug. And the biggest incentive for that person to engage with you, is the prospect of getting his bug fixed, soon.
So second suggestion: be very reactive to people who report bugs. Get back to them, tell them what's going on, ask questions, and let them test the fix. There is nothing that kills the enthusiasm for bug reporting like going through the process, waiting weeks to get a response, and then be told "Yeah, OK, it'll be fixed in the next version, due out in about 9 months. Thanksbye." And don't underestimate the effect of some user saying to his peers "I reported this bug, and they fixed it for me" to encourage others to report bugs, and make good bug reports.
Of course, there will always be lame bug reports, no matter how you do it. But you can at least encourage good ones, raising the signal to noise ratio.
What is your hardware background? 0 electronics experience? Can wire a bread board? Can Solder? Make your own PCBs?
How much do you want to spend? A couple of paychecks? A couple hundred bucks? Coffee money? Pocket change?
What tools do you have available? Machine shop? 3-D printer? Garage full of power tools? Dremel and a glue gun? Swiss army knife?
What aspect interests you the most? Mechanics? Electronics? Programming? Artistry?
The answers to these questions will determine how you approach the field of robotics. You are getting in at a good time: there are tons of options. Here are a few to get you thinking:
And of course, you can combine any of those options. Lots of people start out with Mindstorms or a BOEbot and end up building custom parts for them, or using salvaged parts to add on to a pre-built robot like a Roomba.
Two suggestions. First, you will need a support group to talk out problems and ideas. Online is fine, in person is more inspiring. Second, find a good book on what you want to do. There are several mindstorms books, there's several arduino books, and of course there is The Robot Builders Bonanza for the DIYer.
Hope this is helpful,
When I was in grad school the local ACM/IEEE chapter sponsored a programming contest for several local high-schools. This is a fun way to get kids interested in programming and computers in general. Competitive games are a draw. Contact the ACM, IEEE or your closest university and see if they have any contests in your area. If not, maybe they will help YOU host one. Your kids will get to meet students from other schools with the same interests, polish their programming skills and have some fun. Cool prizes help.
Another area with some cool factor to it is robotics. There are FIRST and BEAM leagues all over the place. Check them out. You could spend a few months getting a contest entry together, involving not just programmers, but budding engineers as well. Even without a contest, having a school robot is cool. And they have something tangible to show off to the rest of the school.
I first learned to code by reading the BASIC manual of my Sinclair ZX-81 and laboriously typing out programs one keyword at a time on that little keypad (after assembling it myself). It's amazing what you can do with 1K of RAM.
> Imagine the power of being able to hire a recent college graduate who has been taught how to develop system diagrams,
Using which tool?
> build complex SQL,
For which implementation?
> run log analysis,
On which platform?
> set up a cloud test environment,
On who's cloud stack?
> and write automation scripts.
In which language?
Sure, it would be great to hire someone who could do all that right out of college. But 5 years later, he'd be unemployable because all the specific skills he learned will be obsolete. What is he supposed to do then, go back and get another BS in software QA?
Hire people who know the fundamentals. Choose people who can learn new skills. Train them.
Sure, they won't know the specific tools and environment your particular company uses. But you have to invest in people to get the most out of them. The more highly specialized the job, the more time and money you need to invest in training them. If you concentrate on hiring those who can learn, rather than those who happen to match your particular requirements at the moment, then they can do more than just the one job on the current project. Imagine not having to fire people when the project is over, but instead just move them to something else, even if it requires a different skill set.
> No more crossing your fingers that this eager young face in front of you can really pick up those skills,
> and no more investing so much time and money in training them on the job. We ask no less from
> Technical Writing and Development. Why do we have such different expectations for one of the most
> important functions on the team?"
If you can't tell whether or not the person you are hiring can learn the skills needed to do the job, you need to revise your interview process. Sure, there's no 100% way to tell the gems from the lemons, but you should be able to consistently identify applicants who can do the job.
The fact that development jobs often demand a high degree of specialization is, IMHO, a bug, not a feature.
It's true that even an obsolete smart phone has lots of integrated features that you would be hard pressed to find or add to a micro-controller or tiny PC ( like the PI). There are even a few models that have some primitive IO capability, and lots of them at least have a serial port. So you can, with some effort, get some IO going.
But.
The huge advantage of the PI (and Arduino et al) is the development environment. It's free. It comes with the device. You can roll your own OS, drivers, libraries, programs and interfaces. Or build on the work of others via the community of developers who share their code. In other words, it's an open platform (yeah, yeah, quit nit picking).
A smart phone, on the other hand, is going to be much more difficult to develop for, unless you just want to make apps like everyone else. Many of those neat pieces of highly integrated hardware are not documented, proprietary, and don't give you the source code you need to made modifications. Yes, there's Android, but even there doing low-level things like single pin IO, or even just using the components to their full capabilities, is going to be hard, if not nearly impossible.
So for example if you want to make a robot controller, and you have an old iphone 3 lying around, and compare it to a Ras Pi. The Pi isn't going to have built-in screen, wifi, accelerometers, audio, battery and charger. But the Pi is going to be much easier to use for this application. The number of hoops you'd have to jump through to get the iphone working would make it a much harder prospect to use. By the time you finish getting, or custom making, the connectors/cables/circuits needed to hook it up, you'll have spent as much as a Pi or arduino costs. And that doesn't even address the development environment you'd need. Android phones have it much better off, but it's still not as easy as hooking up and programming a Pi or arduino.
Yes, you have a perfectly good cell phone that could, with some work, be used instead of a Pi. The problem is that the cell phone is going to take a lot more time and effort to hack than the Pi.
That's so wrong. Imagine you are on the other end of this process, trying to use that code. You'll never be certain which combination of features exist and are supported and which have either been deleted or not implemented. If you have a logically orthogonal set of features, removing or not implementing a random subset just leaves gaping holes where your users are going to be very frustrated on the day they try to do something you thought was of "zero value".
Just -In-Case development prevents problems in the future, which is what good programming does. Just-In-Time development is a shortcut and leads to incomplete code.
Take something he wrote several months ago, that he's not likely to have on the top of his brain. Then ask him to debug, add to, modify or analyze his own code. Or just ask him to give you an explanation of how it works. It might dawn on him that his own code is unreadable and hard to maintain, if you do it right.
I'd also push back on your manager, to make it policy that until this guy gets his code in shape, he is the one who has to maintain it. Bad code is bad even to those who wrote it. Make him work on his own code.
One)
For the return value option: It is usually bad coding practice to mix error codes with information the function returns. If a function returns an int, don't stuff an errno in there when things go wrong. Separate the data from the error code. I hate it when functions that are supposed to return a pointer use NULL as the error code. NULL doesn't tell you anything, and it very well may be a valid value to return anyway. Set errno, send a signal, return a separate error code, but don't put your noise (error code) in the signal.
Two)
I want to see the errors. Don't hide them from me. Force me to deal with them, at least as far as generating a meaningful error message. (Meaningful!. that's a different rant.) I don't want the hardware, OS, compiler, library or whatever to take away from me the ability to see -- and handle -- the error myself. Feel free to offer me some boilerplate error code, but don't force me to use it. Half of elegant programming is in the error handling. If you think about it, a program seems "smart" when it handles error conditions well, instead of just crashing or quitting.
And the plus:
It seems to me what the guy is complaining about is the aethestics of the code, not the actual error handling. Wouldn't a folding editor help with that? You just mark the error handling code and let the editor collapse it for you, until the time comes when you need to see it (and it will). Problem solved.
Demo this: open up a document in your favorite editor/word processor. Now, go in and change all the 'p's to 'q's, using search and replace. Easy right? Now change all the 'q's to 'p's. This does not put things back the way they were, does it?
No problem, just use "undo" a couple of times and you are back to the original, correct document, right?
That's when you point out that without a version control system, you have no "undo". Without it, your only recourse is to go through that document one letter at a time and fix the p's and q's by hand.
Then draw the obvious parallels to source code bugs, emphasizing that finding bugs is much harder than finding misspellings.
QED.
One of the greatest learning experiences for a developer is to see things from the customer/user perspective. For that reason, I'm going to buck the trend here and say that developers should HAVE to do at least 1 customer install, just so they know what hell they are putting them through. There is often a big disconnect between what the developer thinks he's producing and what the field people actually have to do to get it to work. The way to fix that is to make the developer go through the experience.
That being said, I do agree that anyone (properly authorized) should be able to install the software. If you can't install it without the developers help, then it isn't ready for prime-time.
If you want to get a feel for whether or not programming can be learned by "anyone," try teaching it to a random group of people.
Before I tried to teach programming to some people, I was of the opinion that anyone could learn to program. If you could cook, or dress yourself in the morning or operate a VCR, surely programming would be within your grasp right? All it takes is someone to explain it clearly enough. That's because it seemed to obvious to me. Wasn't it obvious to everyone?
Not so much. There are some people that just do not get it. The sequential, logical reasoning involved does not come naturally to them. If you spent a few months at it, they might get some glimpse of the basic ideas. Or they could learn to parrot back rote pieces of code on demand. But the ability to write a program from scratch is not inherent. While it is partly a skill that can be learned, it also takes talent that not everyone has.
Of course, programming is not the be-all end-all of existence. Diversity of talent makes the world go 'round.
"If you can imagine it, there is porn of it [on the internet]"
http://xkcd.com/305/
I just read "Rule 34" by Charles Stross. It has a law enforcement department in charge of internet policing. One of the things it addresses is this issue of what happens to the people who have to see this stuff.
All languages are equivalent in what they can do (See Turing Machine). However, you pick a language that makes what you want to do easy. For twiddling bits, for writing fast algorithms, for controlling hardware, for lots of common programming tasks, C is the simplest language that makes those tasks easy. There are things that are tedious to do in C (like doing complex things with strings), so in those cases you pick another language that is more appropriate. Something that might take up 5 lines of Perl could take pages of C code, but there's no point in writing a Perl script for something that can be easily done with a few lines of C. The C program will be smaller and faster, and probably easier to understand.
So there are lots of things to like about C, when it is the appropriate language for the task.
Second!
This is a freaking brilliant business idea. Those guys are going to make a fortune. Wish I'd thought of it.
No it wouldn't.
Building codes.
And construction companies HATE to change materials.
The ice cap is farting?
I don't like you.
As everybody knows....
It's not easy being green.