First, you're limiting yourself far too much. This seems like a 'narrow the parameters down so far that when I fail it's not my fault' question.
A good programmer can pick up any similar language in short order. I won't say it's easy for a C++ programmer to pick up one of the LISP-likes, or vice versa... it's not. But a C++ programmer such as myself has little problem with Java other than the API bloat. I prefer Python to Ruby or Perl but can work in any of those. And PHP is the retarded brother of C, $so $that's $doable $it's $just $syntax $issues.
You want to limit yourself to web backends? Fine, go Ruby and PHP, but what you really should be doing is just picking a language and learning the/algorithms/ and interfaces to actually solve real problems and learn how to work with third party things like PostgreSQL or memcached. And learn JavaScript. You can't do well on the backend if you don't understand what's going on with the frontend. It's all an ecosystem, and the interactions are far harder than the mere syntax of a language and its APIs.
That more or less matched what we saw - there were two marginally competent people I can think of in the outsourcing organizations. They disappeared after six months, off to better things.
Both of them were what I would consider intern level - I might trust them to expand a CGI, but not write an OS. But there could be extra levels of this we didn't see where they grind the weak into meal while the rest level up to become super-coders. That would take a hell of a lot of work on this weak material though.
It's cultural, so I'm sure they'll be kicking us to the curb in a few decades once they start valuing results over hierarchy.
Has India ever produced any decent software? No. Every time we've outsourced to them (against my fervent objections every time but the first) they've been unable to deliver something robust, secure, or even functional - it always consists of code snippets they've Googled (TM), pasted together then flailed on till it compiles and produces the exact same output as the specification calls for (hard coded).
There's no freaking way they could write anything as complex as Windows compatible from the ground up (this is a gargantuan task for anybody), so it's going to be WINE on top of Linux or BSD with some splash screens stuck on it. 50 Indian outsourcers sounds about the right amount of people for that.
Bought one of these when they first came out. It's great - it looks like it would eat your hand, but it's so smooth and comfy, especially the thumb and little finger rests - talk about debauched hedonism.
Three caveats:
- Be prepared to spend a couple days tweaking it till it fits perfectly. You can dial it in coarsely pretty fast of course. If you are a compulsive adjuster this mouse may not be for you.
- If you like to rest the base of your hand (the meaty bit) on the mouse, no go - it supports the front and middle. This is like most mice, but if you're used to one of those big tall Logitech brick mice it may take some getting used to.
- I still haven't found any use for that horizontal spinner control.
Pondering getting one for work, even though the DPI doesn't matter so much there.
To start with, the Blizzard downloader is a horrible piece of crap that has trouble working with NAT or firewalls and it's often faster to just turn off peer to peer. At least it/lets/ you. The FFXIV client is an even worse piece of steaming fecal matter that doesn't even let you do that and won't download anything successfully - stupid people in the beta, like me, eventually ended up having to go to third party torrents using real clients like uTorrent to be able to update even the most basic game downloads - only to find out that the game itself was just as bad.
I don't mind a torrent being an option for download as long as the client allows the following:
- port assignment
- upload/download speed limiting - it's okay if the DL speed is a multiple of UL speed, that's fair.
- upload/download # of connections limiting
- realizing you're behind a natted firewall
The Lord of the Rings Online client is not too bad except it installs the downloader as a service, so if you're not paying attention it runs all the time in the background sucking up gigabytes of transfer. Don't be abusive.
Really, just give us a damn torrent file and let us use uTorrent because it's better than anything you could come up with off the cuff. These things have years of dev time and problem solving.
Yes, I know there are still a few iconclasts who use Windows (or TeX for the hardcore) but all the published authors I personally know are Apple fanboys. MBPs, Mac Pros (for writing? I know, I know), iPhones, the works. I imagine they don't want to bite the hand that pets them... But I'll ask one why it's okay for Apple and not Amazon.
While I doubt the 3% for several reasons other people have mentioned, I have noticed just how freakishly evil it is for even otherwise competent admins I've dealt with to get SSL certs working properly. It seems like something that's so important yet so seemingly designed to thwart you at every turn is either a horribly bad and cobbled together design (it's certainly/fragile/) or specifically intended to increase Verisign's consulting and certificate generation revenues.
Unless you're lucky enough to have the dream boss, they are used to paying you $X and anything they pile on top is just part of what they perceive as part of your job. After all, it's just 40 hours a week, right? Even if it's not even 40 hours a week any more and the responsibilities are far more complex. You're trapped by perception.
So just use this to add to your resume and go looking for a new job. Asking for a raise once you have a new job offer is always bad. Even if you get one the well is completely poisoned. You could ask for a raise before you go looking for a job, but you run the risk they'll terminate you on the spot. That's your call.
I spent about two hours finishing a book on the iPad last night, shut it off, went right to sleep. Screen brightness is turned down from halogen floodlight intensity, of course.
But I've been doing my computer catch-up and late night gaming just before going to bed for decades now, so brain and circadian rhythms are thoroughly beaten into submission.
Others have suggested this would go well with a religion class, but I really wish everyone had a class at some point on why people are biased to believe dumb things because of our biological tendency to recognize patterns even if they're not there and how you can combat that tendency in yourself. Commercial advertising tactics would play a big part of this, as would religion/cult tactics, new age anything, 'audiophiles,' fan death, etc. UFOs fit right in.
Not saying that Unidentified Flying Objects don't exist (obviously they do), but rather what conclusions you choose to draw from that.
All these articles that say tablets are doomed because they're not laptops or desktops are completely missing the point. I don't want another laptop or desktop, I want a niche filled that nobody's filled yet.
I just want:
- Good ebook and comic book reader. Which means something like Pixel Qi's transflective screen at 9.7 inches. Must be low power and color. eInk color could be good enough.
- Open formats - having a kindle store would be fine as long as I could still read pdfs, epubs, and just directories full of jpgs/pngs loaded via usb or sd card.
- Web browsing. Wifi is good enough, I can use my phone as an access point. But I wouldn't spit at 3g/4g/wimax.
- Non crappy OS. Nothing designed for mouse and keyboard and just repurposed.
- Note taking. Nothing complex, but I need to be able to scribble down notes. They don't need to be OCRed or complex.
That's about it. I don't need to run all my desktop apps. Give me that and I'll buy it. Kindle is not it. iPad is not it. MS's foldout tablet looks interesting but I have no confidence on their ability to deliver. Luckily there's a lot of other stuff in the pipeline.
We run python on our embedded 125 MHz ARM systems. For most things it's just as fast as C - on tight loops, you can get 40% faster in C, though not as often as you might think. Sometimes the Python is even faster just because it's optimized for things you normally want to do. Really, most of the time is in the launch, so as long as there's already an instance of python in memory linux's shared pages takes care of that.
More to the point, you can develop 10x faster in Python than C++. Literally. And it's so much easier to learn and more intuitive. And I say that as someone who is considered the company expert on C++. There are times when I still use it, but for instances where speed of development is a big deal? Never. Rather we write in Python then if necessary do tiny sections in C and call them from the Python. For any kind of problem I can see being asked at a competition like this the speed of development and the freedom to work out a smart algorithm via rapid iteration (if you don't have the experience to know already) will swamp the CPU overhead. If you really want an ace in the hole give your smartest student the task of learning how to call C from Python (you don't need C++ at all if you know both of those).
I'd also say Ruby - you can crank out stuff in Ruby even faster than in Python (though it's not as maintainable thanks to all the perl-y syntax) but this doesn't seem to be on the list here. And Teaching Visual Basic or PHP to students who don't have a very specific need for either would just be a crime.
I did Apple and C64 BASIC (and 6502 assembly language) to death back in the day. You really can't get more 'oh no, gotos everywhere!' than those, but I seem to have survived it. Of course I realized the fragility that GOTOs and JMPs engendered. The key thing is that it nurtured my love for programming because it was so easy to slap things together. Now of course, I can see where it had flaws, but what was I going to use Back in the Day? Pascal? Please, I learned it. But Wirth and Dijkstra's beloved Pascal, while great in theory, was in practice crap for making neat stuff with the minimum amount of effort compared to BASIC + 6502 ASM. If you wanted to do the REAL stuff in Pascal instead of just masturbating for your professor you had to learn the pcode interpreted byte code stuff, which was just fancy assembly language (though it was neat as a precursor of modern VMs). I could (and did!) churn out an entire game in AppleSoft BASIC while the UCSD pascal system was chonking away on the floppy drive editing or compiling or whatever, and god help you if you didn't have two floppy drives. Meanwhile BASIC would happily run with just a tape drive or/nothing at all/. She was an easy whore but things got done. These days I use Python with the added advantage that I think it's the most maintainable language even if it doesn't have the purity of something like Scheme, but none of those were an option at the time.
So yeah, spaghetti code is bad, but I think any decent programmer learns that sooner or later anyhow. If BASIC got you going, more power to you.
More to the point, is coddling uninterested putzes with Java's strait jacketed purity so they can churn out more utter crap really a better alternative than BASIC's trial of fire? Because that's our current go-to plan. I apologize in advance to those excellent Java programmers I know who can really make Java sing, but you, even more than me, already hate that most of the people using Java are FactoryFactoryFactoryAbstractFactoryTools. Far better to flush them out earlier.
I think you're just out of date. See http://www.ibm.com/developerworks/websphere/library/techarticles/0402_able/0402_able.html for instance. When I worked for the state government on a creaky IBM mainframe writing COBOL the framework uber alles approach was extremely evident. You had all these accreted packages which were supposed to bundle and simplify the database lookups and reporting and just ended up making it worse than if you'd just written it outright in COBOL, which has pretty spiff flat file handling and reporting features. And policy was you didn't write any code (or JCL) until you'd scavenged what you could from existing queries. You couldn't Google in those days, so you had to cut and paste what other people in the same department had written.
It's just an Enterprisey Mindset because you're dealing with so many drones.
I've dealt with Chinese and Indian outsourced code before - it's rather interesting. They take fragments of code they find via Google, paste them together, and do the bare minimum of editing to make it compile and say 'okay, we've fulfilled our contract, ship it.' This is what suffices for 'programming'.
On the other hand, I am still solving interesting problems with real programming at my current company, so I still think it's a lot of fun. The key point is that the programming is part of the/problem solving/. Code pigs have no concept of problem solving, just making the program work (by which they mean compile, or matching the sample screens). Engineers are solving problems, and the program is just a part of that. At my present job they really don't care what language I do things in as long as the job gets done, because solving the problem in the most practical manner is the most important thing. In practice this means I use C for things that actually do require high performance and minimal memory usage (this is still an issue in embedded programming), Python for everything else that I can, and domain specific languages for things like servo controllers or FGPAs.
The 'pasting not quite compatible libraries together' approach is a Java/COBOL thing of minimizing the damage incompetent consultants can do. I've seen it time and time again - once an Enterprisey Java programmer encounters sufficient complexity, a hormone kicks in and they create a framework to simplify this complexity. It does so, initially, but eventually ends up being 2-10x as complex as the original problem they were trying to simplify. But they see this as a net positive because they have a new acronym to put on their resume.
So basically, like every single damn post I've seen on here lamenting the state of programming, and repeating every damn comment I've made again and again, it boils down to 'solve problems as efficiently as you can'. Absolute rules, in programming or religion, are for people who are too simple to handle complexity. This is the difference between an engineer and a code pig.
This has happened to me several times, and again just recently. I'm not sure how many lines of code it was this time (I don't really care), but several thousand files (I do care about the structure). 'This is your new project, we have some stuff we need done ASAP'. The big constraints are:
- They want you to start doing stuff right away. That's usually a given.
- Therefore you do not have time to fully understand this code. You do not have time to do a full dissection. Just give up the idea that you can even do so in the short term; that will just paralyze you.
- Very little useful documentation. Read it if there is any, but keep in mind that it is usually out of date and therefore a filthy lie.
What you need is a good understanding of the parts of this code that are important right now and some high level overview. If you knock off enough of the little things you will end up learning the whole thing. In this way you gain enough confidence to move forward. So, get cracking:
- Make a safe copy. If you're lucky it's already in version control. If not, do it yourself. Check in your test stuff fairly frequently (not in the main trunk!) because you will be breaking things often at first.
- Use cscope or any other tool you like that will let you hop around the code like hyperlinks. cscope lets you do the following very important things: find the definition for this thing (method, structure, #define, whatever). Find all places that are calling something. Find some text anywhere in the code base. Find a file anywhere in the code base. You need this integrated into your editor so you can do all this without thinking - you can be cruising along, hit a reference to an unfamiliar but important looking datatype or method and just hit a few keys and go to the definition, wherever it is. And then pop back. If you're using Visual Studio then this is already built in, as much as I hate VS otherwise. cscope is an easy addition to emacs, I imagine for vi too. As a last resort, stand alone cscope, but it is so much slower than having it in your chosen editor.
- Add plenty of debugging printfs in areas of code you're interested in. #define a macro for it so you can turn them on or off easily. You can run it under a debugger, but I usually find that takes much longer to step through unless you know exactly what you're looking for already. And with the printfs you will soon develop a feel for what's going on and what values you expect to see. Debugging printfs are like a heartbeat for the code.
- Take notes in a wiki or whatever you prefer the general structure of the program - mostly which areas of the code do critical things that you're interested in, like common/engine/pp.c contains the paper path motor and encoder logic. Or anything else important you find.
- Start solving problems. You won't learn the whole codebase at once by zeroing in on a specific issue to fix, but you will learn subsystems fairly well that way. There should be sufficient separation of logic unless the code is hopelessly broken (which is possible). That's the big thing. Don't worry and get paralyzed if you don't understand it all right away, just work on understanding the bits you need right now and eventually you'll build up a picture of the whole thing.
I realize there are people who are going to freak out at the idea that you would go in and poke at things before you fully understand everything, but unless you have the luxury of unlimited time, that's not an option. Someone up above suggested writing unit tests for existing code, which is good idea in general, but is probably far more time consuming than you have been given time for. Try writing unit tests for the area you are working on right now if you have the time. It's possible the codebase is so broken that the little changes you are making here are having adverse effects elsewhere, but all you can do is try. Eventually as you knock off issues you'll gain confidence and knowledge and before you know it people will be coming to you with questions about the codebase.
tl;dr version - your worth is your ability to solve problems.
There a huge specrum we just lump together under the term 'programmer'.
* Programmer: coder who churns out mostly boilerplate code in the depths of a team. You're basically given 'I need this' and crank out a specific solution. Turn design into code. The lowest form of this is the code pig - you're stuck in your little pen with no context, turning garbage into sludge. The term 'code pig,' while demeaning, is one I've heard used in the industry - one specific example was people working on the Windows Vista team. * Engineer: someone who you can give a problem, analyzes it in the context of the complete system, comes up with an optimal solution in light of the tradeoffs, delivers a working solution. Turns problems into solutions. Engineers usually have more interest in continuing education than the code pig - whatever solves the problem easier and faster.
There are all sorts of shades of this - for instance the skilled IT guy who's not even a 'programmer' but ends up doing a lot of scripting can be effectively doing engineering. And you get people trying to act as engineers who simply should not be. Or someone who's stuck in a code pig job can be a great engineer.
But in general if you can be easily replaced you're not worth a lot - especially if your boss thinks your job can be outsourced to India and he can get the same result cheaper (even if he's wrong). If you can consistently solve problems you're worth a lot.
One good way for programmers to make lots of money: specialization. If you're good at COBOL and huge companies desperately need people to maintain or upgrade their millions of lines of outdated but nominally functioning mission critical code, well then you're valuable. If you have the rare skills and engineering skills then you're extra valuable. Another good way to make money if you have little tech skill is contracting. Get in, screw things up, on to the next contract. I am not saying that all contractors are like this - just a subset I've encountered. In this case you're trading your contacts and people skills to make up for lack of technical talent, and it takes a non-trivial amount of con man talent.
The reason I'm using Firefox is the because the extensions are so much better than on any other browser. AdBlock, FlashBlock, DownloadStatusbar, RefControl, NoScript. You can half-ass these on other browsers like Chrome or Opera, and I've done it, but in the end the ease and simplicity of it wins out, especially when I have to explain to other people how to do it and the first thing you do on a new machine is install a decent browser and extensions. I do not want to have to locate the profile directory and hand edit or copy things on every machine, much less have to explain to my parents how to do this.
If you cripple this to the level of Opera UserJS, which is fairly powerful but also a pain in the butt, then I have no reason not to move to Opera or Chrome.
Now if they can somehow make this transition while preserving the addon manager functionality and allowing actual browser extensions like DownloadStatusbar or TabMixPlus to work, then I'm fine with that. It's the results that count, not how it's implemented.
I completely own my linux box at work (root and all), and I have admin privileges on my XP desktop. There are a couple company tools that IT pushes and updates (like antivirus), but I can install and run anything I want. It basically boils down to us wanting to get work done, and if I had to wait for IT to install everything I needed when I needed it we'd be a month behind on the latest project instead of two weeks ahead of schedule. This comes with the expectation that if I do something stupid like start torrenting porn from my work computers that I will get slapped hard, and that's fair enough.
So that seems the way to go: allow devs admin privileges and fire them if they're dumb enough they can't handle that. This is win-win for dev and IT, unless IT is primarily interested in empire building. Everything else is just a doomed hack around the fact that you hired bad people.
Well - one of the reasons we use Python. I'm sure some people will consider this a troll, but it's true. Some languages encourage readability, some don't. You can write horrible, awful, unreadable Python and you can write elegant, readable, maintainable Perl (Calcium was the best I've seen in a real product), but neither is encouraged and you know what you tend to get out of your programmers.
This means our code takes a bit longer to write up front than just banging it out in Ruby, but has the advantage that when we come back to it six months later it's still obvious what's going on (even if someone else wrote it) and it's easy to maintain.
Ruby's great (and a close match for Python in niche and functionality, which is why I'm using it specifically), but our Ruby guys can't do that because they love to make things as concise as possible - it allows them to show how clever they are. Perl-style magic variables and punctuation everywhere. They sometimes rewrite functionality from scratch because it's easier than deciphering their (own!) old stuff, which at least unit tests help with. On the other side, Python's indentation generally limits how much you can cram into one line without gross misuse of lambdas, which frees you from the need to even try it.
Perhaps this is self selection - maybe boring people like me who learned to value maintenance considerations (thanks to hard experience) gravitate towards easy maintenance languages, which exacerbates the effect. But I think still think your choice of language will strongly inform how maintainable your code will be; you can mandate code policies for any language, but how often (and for how long) are those actually enforced in practice?
Have you been in a Wal-mart? People will hump anything with a hole. It seems to me that if you can show that Neanderthals and Homo Sapiens/Erectus were in the same place at the same time that you'd need extraordinary proof that they didn't have sex.
I argue that all you people with ridiculously consuming agendas, on whatever side, are just engaging in mental masturbation by coming up with various amusing ways to bend things so they fit your world view. I know slashdot sometimes has trouble finding decent tech news, but if you just stick pure opinon up as news then you're on the horrible path to kuro5hin.
Good question. I'm doing it for my project team, being the lead software guy. The IT dept. is a small team and kept busy with other stuff - but they gave us hardware for a team Linux server when I asked for it and let me admin it, so I'm just grateful that they're helpful when so many would be obstructionist.
Rambling: I've also installed a wiki, which is getting rave reviews from the people using it; hoping to make that popular enough that IT will/want/ to take it over.
I had this same problem not too long ago - we have a shared documentation tree with tens of thousands of documents that I wanted to index. I tried dozens of search engines in my spare time, most of which were just horrible (Beagle), were a nightmare to install for someone like me who's not a full or even part time admin (Apache SOLR), wouldn't allow cross platform access (lots of Windows ones, obviously), store a complete separate copy of every document (Alfresco, which didn't seem to have an option to ) and especially ones that had trouble indexing pdfs and MS Office docs (which we have a lot of). I'm not the IT guy, and have no budget for this, so Google Appliance was right out.
What I eventually ended up with is Omega on top of Xapian - http://xapian.org/ - it's not too hairy to install, indexes pretty fast, points back to the original files (so it doesn't duplicate everything), and can handle multiple repositories. It will also detect dups and not show them twice, though similar files are treated as completely different (which is probably what you want in the absence of something more sophisticated).
Two downsides: It can't do incremental update (unless that's changed recently) so you have to rebuild the entire index nightly. And the search is really sparse and ugly, which turned off some of my users, but you can rewrite the templates if you want to.
Just look at that list of reviewers. BusinessWeek (Steve Wildstrom), CNET (Robert Vamosi), Forbes (Stephen Manes), The New York Times (David Pogue), PC Magazine (John Clyman), Paul Thurrott’s Windows Supersite, PC World (Preston Gralla and Richard Baguley), USA Today (Ed Baig), The Wall Street Journal (Walt Mossberg), and ZDNet (Ed Bott). These are all people I expect to eagerly whore out new versions of the OS so they can write more articles, books, and magazine covers on how to make it not suck. And by the time Vista came out, XP was looking mighty weak in that department because it generally ran quite well.
Then Vista got into the hands of the users, and right out the door it sucked. There's no softpedaling that unless you're a hardcore apologist. I burned it from my systems with fire and stocked up on XP licenses.
With Win7, the users have been able to try it in advance, and more to the point I have been able to try it in advance thanks to the extremely savvy beta/RC program. The Tech Journalists will go 'wow, this is great' but I just ignore them - that's what they'd say anyhow.
Slashdot Mirror
First, you're limiting yourself far too much. This seems like a 'narrow the parameters down so far that when I fail it's not my fault' question.
A good programmer can pick up any similar language in short order. I won't say it's easy for a C++ programmer to pick up one of the LISP-likes, or vice versa... it's not. But a C++ programmer such as myself has little problem with Java other than the API bloat. I prefer Python to Ruby or Perl but can work in any of those. And PHP is the retarded brother of C, $so $that's $doable $it's $just $syntax $issues.
You want to limit yourself to web backends? Fine, go Ruby and PHP, but what you really should be doing is just picking a language and learning the /algorithms/ and interfaces to actually solve real problems and learn how to work with third party things like PostgreSQL or memcached. And learn JavaScript. You can't do well on the backend if you don't understand what's going on with the frontend. It's all an ecosystem, and the interactions are far harder than the mere syntax of a language and its APIs.
That more or less matched what we saw - there were two marginally competent people I can think of in the outsourcing organizations. They disappeared after six months, off to better things.
Both of them were what I would consider intern level - I might trust them to expand a CGI, but not write an OS. But there could be extra levels of this we didn't see where they grind the weak into meal while the rest level up to become super-coders. That would take a hell of a lot of work on this weak material though.
It's cultural, so I'm sure they'll be kicking us to the curb in a few decades once they start valuing results over hierarchy.
Has India ever produced any decent software? No. Every time we've outsourced to them (against my fervent objections every time but the first) they've been unable to deliver something robust, secure, or even functional - it always consists of code snippets they've Googled (TM), pasted together then flailed on till it compiles and produces the exact same output as the specification calls for (hard coded).
There's no freaking way they could write anything as complex as Windows compatible from the ground up (this is a gargantuan task for anybody), so it's going to be WINE on top of Linux or BSD with some splash screens stuck on it. 50 Indian outsourcers sounds about the right amount of people for that.
Bought one of these when they first came out. It's great - it looks like it would eat your hand, but it's so smooth and comfy, especially the thumb and little finger rests - talk about debauched hedonism.
Three caveats:
- Be prepared to spend a couple days tweaking it till it fits perfectly. You can dial it in coarsely pretty fast of course. If you are a compulsive adjuster this mouse may not be for you.
- If you like to rest the base of your hand (the meaty bit) on the mouse, no go - it supports the front and middle. This is like most mice, but if you're used to one of those big tall Logitech brick mice it may take some getting used to.
- I still haven't found any use for that horizontal spinner control.
Pondering getting one for work, even though the DPI doesn't matter so much there.
To start with, the Blizzard downloader is a horrible piece of crap that has trouble working with NAT or firewalls and it's often faster to just turn off peer to peer. At least it /lets/ you. The FFXIV client is an even worse piece of steaming fecal matter that doesn't even let you do that and won't download anything successfully - stupid people in the beta, like me, eventually ended up having to go to third party torrents using real clients like uTorrent to be able to update even the most basic game downloads - only to find out that the game itself was just as bad.
I don't mind a torrent being an option for download as long as the client allows the following:
- port assignment
- upload/download speed limiting - it's okay if the DL speed is a multiple of UL speed, that's fair.
- upload/download # of connections limiting
- realizing you're behind a natted firewall
The Lord of the Rings Online client is not too bad except it installs the downloader as a service, so if you're not paying attention it runs all the time in the background sucking up gigabytes of transfer. Don't be abusive.
Really, just give us a damn torrent file and let us use uTorrent because it's better than anything you could come up with off the cuff. These things have years of dev time and problem solving.
Yes, I know there are still a few iconclasts who use Windows (or TeX for the hardcore) but all the published authors I personally know are Apple fanboys. MBPs, Mac Pros (for writing? I know, I know), iPhones, the works. I imagine they don't want to bite the hand that pets them... But I'll ask one why it's okay for Apple and not Amazon.
While I doubt the 3% for several reasons other people have mentioned, I have noticed just how freakishly evil it is for even otherwise competent admins I've dealt with to get SSL certs working properly. It seems like something that's so important yet so seemingly designed to thwart you at every turn is either a horribly bad and cobbled together design (it's certainly /fragile/) or specifically intended to increase Verisign's consulting and certificate generation revenues.
Unless you're lucky enough to have the dream boss, they are used to paying you $X and anything they pile on top is just part of what they perceive as part of your job. After all, it's just 40 hours a week, right? Even if it's not even 40 hours a week any more and the responsibilities are far more complex. You're trapped by perception.
So just use this to add to your resume and go looking for a new job. Asking for a raise once you have a new job offer is always bad. Even if you get one the well is completely poisoned. You could ask for a raise before you go looking for a job, but you run the risk they'll terminate you on the spot. That's your call.
I spent about two hours finishing a book on the iPad last night, shut it off, went right to sleep. Screen brightness is turned down from halogen floodlight intensity, of course.
But I've been doing my computer catch-up and late night gaming just before going to bed for decades now, so brain and circadian rhythms are thoroughly beaten into submission.
Others have suggested this would go well with a religion class, but I really wish everyone had a class at some point on why people are biased to believe dumb things because of our biological tendency to recognize patterns even if they're not there and how you can combat that tendency in yourself. Commercial advertising tactics would play a big part of this, as would religion/cult tactics, new age anything, 'audiophiles,' fan death, etc. UFOs fit right in.
Not saying that Unidentified Flying Objects don't exist (obviously they do), but rather what conclusions you choose to draw from that.
All these articles that say tablets are doomed because they're not laptops or desktops are completely missing the point. I don't want another laptop or desktop, I want a niche filled that nobody's filled yet.
I just want:
- Good ebook and comic book reader. Which means something like Pixel Qi's transflective screen at 9.7 inches. Must be low power and color. eInk color could be good enough.
- Open formats - having a kindle store would be fine as long as I could still read pdfs, epubs, and just directories full of jpgs/pngs loaded via usb or sd card.
- Web browsing. Wifi is good enough, I can use my phone as an access point. But I wouldn't spit at 3g/4g/wimax.
- Non crappy OS. Nothing designed for mouse and keyboard and just repurposed.
- Note taking. Nothing complex, but I need to be able to scribble down notes. They don't need to be OCRed or complex.
That's about it. I don't need to run all my desktop apps. Give me that and I'll buy it. Kindle is not it. iPad is not it. MS's foldout tablet looks interesting but I have no confidence on their ability to deliver. Luckily there's a lot of other stuff in the pipeline.
We run python on our embedded 125 MHz ARM systems. For most things it's just as fast as C - on tight loops, you can get 40% faster in C, though not as often as you might think. Sometimes the Python is even faster just because it's optimized for things you normally want to do. Really, most of the time is in the launch, so as long as there's already an instance of python in memory linux's shared pages takes care of that.
More to the point, you can develop 10x faster in Python than C++. Literally. And it's so much easier to learn and more intuitive. And I say that as someone who is considered the company expert on C++. There are times when I still use it, but for instances where speed of development is a big deal? Never. Rather we write in Python then if necessary do tiny sections in C and call them from the Python. For any kind of problem I can see being asked at a competition like this the speed of development and the freedom to work out a smart algorithm via rapid iteration (if you don't have the experience to know already) will swamp the CPU overhead. If you really want an ace in the hole give your smartest student the task of learning how to call C from Python (you don't need C++ at all if you know both of those).
I'd also say Ruby - you can crank out stuff in Ruby even faster than in Python (though it's not as maintainable thanks to all the perl-y syntax) but this doesn't seem to be on the list here. And Teaching Visual Basic or PHP to students who don't have a very specific need for either would just be a crime.
I did Apple and C64 BASIC (and 6502 assembly language) to death back in the day. You really can't get more 'oh no, gotos everywhere!' than those, but I seem to have survived it. Of course I realized the fragility that GOTOs and JMPs engendered. The key thing is that it nurtured my love for programming because it was so easy to slap things together. Now of course, I can see where it had flaws, but what was I going to use Back in the Day? Pascal? Please, I learned it. But Wirth and Dijkstra's beloved Pascal, while great in theory, was in practice crap for making neat stuff with the minimum amount of effort compared to BASIC + 6502 ASM. If you wanted to do the REAL stuff in Pascal instead of just masturbating for your professor you had to learn the pcode interpreted byte code stuff, which was just fancy assembly language (though it was neat as a precursor of modern VMs). I could (and did!) churn out an entire game in AppleSoft BASIC while the UCSD pascal system was chonking away on the floppy drive editing or compiling or whatever, and god help you if you didn't have two floppy drives. Meanwhile BASIC would happily run with just a tape drive or /nothing at all/. She was an easy whore but things got done. These days I use Python with the added advantage that I think it's the most maintainable language even if it doesn't have the purity of something like Scheme, but none of those were an option at the time.
So yeah, spaghetti code is bad, but I think any decent programmer learns that sooner or later anyhow. If BASIC got you going, more power to you.
More to the point, is coddling uninterested putzes with Java's strait jacketed purity so they can churn out more utter crap really a better alternative than BASIC's trial of fire? Because that's our current go-to plan. I apologize in advance to those excellent Java programmers I know who can really make Java sing, but you, even more than me, already hate that most of the people using Java are FactoryFactoryFactoryAbstractFactoryTools. Far better to flush them out earlier.
I think you're just out of date. See http://www.ibm.com/developerworks/websphere/library/techarticles/0402_able/0402_able.html for instance. When I worked for the state government on a creaky IBM mainframe writing COBOL the framework uber alles approach was extremely evident. You had all these accreted packages which were supposed to bundle and simplify the database lookups and reporting and just ended up making it worse than if you'd just written it outright in COBOL, which has pretty spiff flat file handling and reporting features.
And policy was you didn't write any code (or JCL) until you'd scavenged what you could from existing queries. You couldn't Google in those days, so you had to cut and paste what other people in the same department had written.
It's just an Enterprisey Mindset because you're dealing with so many drones.
I've dealt with Chinese and Indian outsourced code before - it's rather interesting. They take fragments of code they find via Google, paste them together, and do the bare minimum of editing to make it compile and say 'okay, we've fulfilled our contract, ship it.' This is what suffices for 'programming'.
On the other hand, I am still solving interesting problems with real programming at my current company, so I still think it's a lot of fun. The key point is that the programming is part of the /problem solving/. Code pigs have no concept of problem solving, just making the program work (by which they mean compile, or matching the sample screens). Engineers are solving problems, and the program is just a part of that. At my present job they really don't care what language I do things in as long as the job gets done, because solving the problem in the most practical manner is the most important thing. In practice this means I use C for things that actually do require high performance and minimal memory usage (this is still an issue in embedded programming), Python for everything else that I can, and domain specific languages for things like servo controllers or FGPAs.
The 'pasting not quite compatible libraries together' approach is a Java/COBOL thing of minimizing the damage incompetent consultants can do. I've seen it time and time again - once an Enterprisey Java programmer encounters sufficient complexity, a hormone kicks in and they create a framework to simplify this complexity. It does so, initially, but eventually ends up being 2-10x as complex as the original problem they were trying to simplify. But they see this as a net positive because they have a new acronym to put on their resume.
So basically, like every single damn post I've seen on here lamenting the state of programming, and repeating every damn comment I've made again and again, it boils down to 'solve problems as efficiently as you can'. Absolute rules, in programming or religion, are for people who are too simple to handle complexity. This is the difference between an engineer and a code pig.
This has happened to me several times, and again just recently. I'm not sure how many lines of code it was this time (I don't really care), but several thousand files (I do care about the structure). 'This is your new project, we have some stuff we need done ASAP'. The big constraints are:
- They want you to start doing stuff right away. That's usually a given.
- Therefore you do not have time to fully understand this code. You do not have time to do a full dissection. Just give up the idea that you can even do so in the short term; that will just paralyze you.
- Very little useful documentation. Read it if there is any, but keep in mind that it is usually out of date and therefore a filthy lie.
What you need is a good understanding of the parts of this code that are important right now and some high level overview. If you knock off enough of the little things you will end up learning the whole thing. In this way you gain enough confidence to move forward. So, get cracking:
- Make a safe copy. If you're lucky it's already in version control. If not, do it yourself. Check in your test stuff fairly frequently (not in the main trunk!) because you will be breaking things often at first.
- Use cscope or any other tool you like that will let you hop around the code like hyperlinks. cscope lets you do the following very important things: find the definition for this thing (method, structure, #define, whatever). Find all places that are calling something. Find some text anywhere in the code base. Find a file anywhere in the code base. You need this integrated into your editor so you can do all this without thinking - you can be cruising along, hit a reference to an unfamiliar but important looking datatype or method and just hit a few keys and go to the definition, wherever it is. And then pop back. If you're using Visual Studio then this is already built in, as much as I hate VS otherwise. cscope is an easy addition to emacs, I imagine for vi too. As a last resort, stand alone cscope, but it is so much slower than having it in your chosen editor.
- Add plenty of debugging printfs in areas of code you're interested in. #define a macro for it so you can turn them on or off easily. You can run it under a debugger, but I usually find that takes much longer to step through unless you know exactly what you're looking for already. And with the printfs you will soon develop a feel for what's going on and what values you expect to see. Debugging printfs are like a heartbeat for the code.
- Take notes in a wiki or whatever you prefer the general structure of the program - mostly which areas of the code do critical things that you're interested in, like common/engine/pp.c contains the paper path motor and encoder logic. Or anything else important you find.
- Start solving problems. You won't learn the whole codebase at once by zeroing in on a specific issue to fix, but you will learn subsystems fairly well that way. There should be sufficient separation of logic unless the code is hopelessly broken (which is possible). That's the big thing. Don't worry and get paralyzed if you don't understand it all right away, just work on understanding the bits you need right now and eventually you'll build up a picture of the whole thing.
I realize there are people who are going to freak out at the idea that you would go in and poke at things before you fully understand everything, but unless you have the luxury of unlimited time, that's not an option. Someone up above suggested writing unit tests for existing code, which is good idea in general, but is probably far more time consuming than you have been given time for. Try writing unit tests for the area you are working on right now if you have the time. It's possible the codebase is so broken that the little changes you are making here are having adverse effects elsewhere, but all you can do is try. Eventually as you knock off issues you'll gain confidence and knowledge and before you know it people will be coming to you with questions about the codebase.
tl;dr version - your worth is your ability to solve problems.
There a huge specrum we just lump together under the term 'programmer'.
* Programmer: coder who churns out mostly boilerplate code in the depths of a team. You're basically given 'I need this' and crank out a specific solution. Turn design into code. The lowest form of this is the code pig - you're stuck in your little pen with no context, turning garbage into sludge. The term 'code pig,' while demeaning, is one I've heard used in the industry - one specific example was people working on the Windows Vista team.
* Engineer: someone who you can give a problem, analyzes it in the context of the complete system, comes up with an optimal solution in light of the tradeoffs, delivers a working solution. Turns problems into solutions. Engineers usually have more interest in continuing education than the code pig - whatever solves the problem easier and faster.
There are all sorts of shades of this - for instance the skilled IT guy who's not even a 'programmer' but ends up doing a lot of scripting can be effectively doing engineering. And you get people trying to act as engineers who simply should not be. Or someone who's stuck in a code pig job can be a great engineer.
But in general if you can be easily replaced you're not worth a lot - especially if your boss thinks your job can be outsourced to India and he can get the same result cheaper (even if he's wrong). If you can consistently solve problems you're worth a lot.
One good way for programmers to make lots of money: specialization. If you're good at COBOL and huge companies desperately need people to maintain or upgrade their millions of lines of outdated but nominally functioning mission critical code, well then you're valuable. If you have the rare skills and engineering skills then you're extra valuable. Another good way to make money if you have little tech skill is contracting. Get in, screw things up, on to the next contract. I am not saying that all contractors are like this - just a subset I've encountered. In this case you're trading your contacts and people skills to make up for lack of technical talent, and it takes a non-trivial amount of con man talent.
The reason I'm using Firefox is the because the extensions are so much better than on any other browser. AdBlock, FlashBlock, DownloadStatusbar, RefControl, NoScript. You can half-ass these on other browsers like Chrome or Opera, and I've done it, but in the end the ease and simplicity of it wins out, especially when I have to explain to other people how to do it and the first thing you do on a new machine is install a decent browser and extensions. I do not want to have to locate the profile directory and hand edit or copy things on every machine, much less have to explain to my parents how to do this.
If you cripple this to the level of Opera UserJS, which is fairly powerful but also a pain in the butt, then I have no reason not to move to Opera or Chrome.
Now if they can somehow make this transition while preserving the addon manager functionality and allowing actual browser extensions like DownloadStatusbar or TabMixPlus to work, then I'm fine with that. It's the results that count, not how it's implemented.
I completely own my linux box at work (root and all), and I have admin privileges on my XP desktop. There are a couple company tools that IT pushes and updates (like antivirus), but I can install and run anything I want. It basically boils down to us wanting to get work done, and if I had to wait for IT to install everything I needed when I needed it we'd be a month behind on the latest project instead of two weeks ahead of schedule. This comes with the expectation that if I do something stupid like start torrenting porn from my work computers that I will get slapped hard, and that's fair enough.
So that seems the way to go: allow devs admin privileges and fire them if they're dumb enough they can't handle that. This is win-win for dev and IT, unless IT is primarily interested in empire building. Everything else is just a doomed hack around the fact that you hired bad people.
Well - one of the reasons we use Python. I'm sure some people will consider this a troll, but it's true. Some languages encourage readability, some don't. You can write horrible, awful, unreadable Python and you can write elegant, readable, maintainable Perl (Calcium was the best I've seen in a real product), but neither is encouraged and you know what you tend to get out of your programmers.
This means our code takes a bit longer to write up front than just banging it out in Ruby, but has the advantage that when we come back to it six months later it's still obvious what's going on (even if someone else wrote it) and it's easy to maintain.
Ruby's great (and a close match for Python in niche and functionality, which is why I'm using it specifically), but our Ruby guys can't do that because they love to make things as concise as possible - it allows them to show how clever they are. Perl-style magic variables and punctuation everywhere. They sometimes rewrite functionality from scratch because it's easier than deciphering their (own!) old stuff, which at least unit tests help with. On the other side, Python's indentation generally limits how much you can cram into one line without gross misuse of lambdas, which frees you from the need to even try it.
Perhaps this is self selection - maybe boring people like me who learned to value maintenance considerations (thanks to hard experience) gravitate towards easy maintenance languages, which exacerbates the effect. But I think still think your choice of language will strongly inform how maintainable your code will be; you can mandate code policies for any language, but how often (and for how long) are those actually enforced in practice?
Have you been in a Wal-mart? People will hump anything with a hole. It seems to me that if you can show that Neanderthals and Homo Sapiens/Erectus were in the same place at the same time that you'd need extraordinary proof that they didn't have sex.
Offspring's a much harder question.
I argue that all you people with ridiculously consuming agendas, on whatever side, are just engaging in mental masturbation by coming up with various amusing ways to bend things so they fit your world view. I know slashdot sometimes has trouble finding decent tech news, but if you just stick pure opinon up as news then you're on the horrible path to kuro5hin.
Good question. I'm doing it for my project team, being the lead software guy. The IT dept. is a small team and kept busy with other stuff - but they gave us hardware for a team Linux server when I asked for it and let me admin it, so I'm just grateful that they're helpful when so many would be obstructionist.
Rambling: I've also installed a wiki, which is getting rave reviews from the people using it; hoping to make that popular enough that IT will /want/ to take it over.
I had this same problem not too long ago - we have a shared documentation tree with tens of thousands of documents that I wanted to index. I tried dozens of search engines in my spare time, most of which were just horrible (Beagle), were a nightmare to install for someone like me who's not a full or even part time admin (Apache SOLR), wouldn't allow cross platform access (lots of Windows ones, obviously), store a complete separate copy of every document (Alfresco, which didn't seem to have an option to ) and especially ones that had trouble indexing pdfs and MS Office docs (which we have a lot of). I'm not the IT guy, and have no budget for this, so Google Appliance was right out.
What I eventually ended up with is Omega on top of Xapian - http://xapian.org/ - it's not too hairy to install, indexes pretty fast, points back to the original files (so it doesn't duplicate everything), and can handle multiple repositories. It will also detect dups and not show them twice, though similar files are treated as completely different (which is probably what you want in the absence of something more sophisticated).
Two downsides: It can't do incremental update (unless that's changed recently) so you have to rebuild the entire index nightly. And the search is really sparse and ugly, which turned off some of my users, but you can rewrite the templates if you want to.
Just look at that list of reviewers. BusinessWeek (Steve Wildstrom), CNET (Robert Vamosi), Forbes (Stephen Manes), The New York Times (David Pogue), PC Magazine (John Clyman), Paul Thurrott’s Windows Supersite, PC World (Preston Gralla and Richard Baguley), USA Today (Ed Baig), The Wall Street Journal (Walt Mossberg), and ZDNet (Ed Bott). These are all people I expect to eagerly whore out new versions of the OS so they can write more articles, books, and magazine covers on how to make it not suck. And by the time Vista came out, XP was looking mighty weak in that department because it generally ran quite well.
Then Vista got into the hands of the users, and right out the door it sucked. There's no softpedaling that unless you're a hardcore apologist. I burned it from my systems with fire and stocked up on XP licenses.
With Win7, the users have been able to try it in advance, and more to the point I have been able to try it in advance thanks to the extremely savvy beta/RC program. The Tech Journalists will go 'wow, this is great' but I just ignore them - that's what they'd say anyhow.