This is why we need faster and faster processors. Think of it as price support for Intel.

I wonder about the people who pay $20 for a $2 bill. They aren't that rare. Bill Clinton has already reserved the $3 bill. It was supposed to go to Hillary, but all did not go to plan....

Not sure what it's like in the UK but in the US it's difficult to get a good developer job without a degree. Those ads that say degree or 5 years? Don't believe it, they aren't treated the same. 5 years experience means any technical degree is okay, not just a CS degree, but when it comes to interviews the ones without degrees go to the bottom. Yes, still a chance but only if the top of the pile are too expensive or fail the interview. As someone who's been on both sides of the interview table I do agree with most of the points above. Experience counts, especially in senior positions. Junior positions it's less of a factor, so the only tangible data to go on is...degree and subjects in school. Bootcamps? Anyone who's been a programmer for some time knows you can't really learn to be a commercial developer in 12 weeks. Maybe, maybe an entry level position where the company expects to train for the job. Expect pay grade to be competitive with janitorial services. When you get to positions that ask for 10+ years experience degrees don't count for much as long as you have one in a technical field, unless it's a Ph.D. Problem with Ph.Ds is too much focus on academics, not enough on how to build code in an economical and profitable way. Good for a research position, not so much for engineering the deliverables. There are other aspects to development work besides coding. What makes a prospect stand out are the communications skills. Can you explain your work in a way others understand? You'll be on a team; they have to know what you are doing. Some day there will be "the next guy" working on your code, will they be able to follow your logic? Do you even comment your code? If you say "the code is self documenting" in an interview you might as well stand up and leave. Managers who have to worry about continuity and maintenance know first-hand that particular cliche is a myth. Consider some classes on writing, an articulate and well-written report or manual will demonstrate you are more than just a code monkey.

What happens when you start the second instance of the program? What happens when you run it as a service? How do you look at the log remotely, while the program is running locally? Windows already has event logging that work well, using WMI. Remotely accessible, fits in with enterprise operations management frameworks, no file droppings in local directories, no need to reinvent the wheel. Log4Net et al. are solutions that fit problems when logging expands to larger enterprise systems. Silly log files quickly break down when complexity increases.

My commute consists of descending into the basement to the luxurious Embedded Developer Office Suite. Maybe 30 seconds each way, and that makes this one of the best jobs I ever had, especially when it's -5 and snowing outside. I can work in a nice place to live (Nebraska) instead of some tech ghetto like California or Arizona. If an idea wakes me up at 3am I can head right to the keyboard to capture it, and if I'm brain dead at 2pm I can take a break to watch some awful TV show on Youtube (ever watch those Belarussian military TV mini-series?). My job is about 75% software, 25% hardware so I get a much-needed break from coding every now and then. Yes, I still like to code, but I also like designing the controller board I'g going to program. It's always a challenge to optimize the hardware layout to best advantage for the firmware. Only down side is testing for all those edge cases that show up in embedded designs, like batteries suddenly failing when it's only -40 outside, or the solar cell ices up and battery charger shuts down. I am isolated, no co-workers sitting next to me in cubicles, but that's equally good and bad. Skype and Slack takes up some of the, err, slack in socializing and talking out problems. The team is diverse and spread out across North America but we do have good communications and keep in touch daily. Management works hard to limit meetings to a minimum for those actually producing, and that's a big plus too. I can go all day in the coding zone without interruptions. After some 40+ years writing software and laying out circuit boards I would never do anything else. Not sure I'd feel the same way writing web pages to sell shoes, but even e-commerce websites have their place in improving society. Jack Peacock

20 years ago for embedded devs it was the shift from 8 bit controllers to 16 bit, DSPs and the exotic new 32 bit controllers. 20 years from now it'll be the shift from 32-bit ARM to 64-bit and virtual machines along with IPv6 for your IOT toaster....

Over Xmas vacation I'm reading a manual from NXP on a new multi-core embedded controller, Cortex A7 and M4 in one package. Something for the C++ Linux guys on the A7 end, and something for the C "bare iron" guys on the M4 end. Lot of programming challenges to manage power and how to best partition the design to split the requirements between a real-time front end and lots of store and forward data routing on the back end to multiple radios. Then there's the problem of a C# production tester at the assembly line. And on top of all that the security hypervisor to secure against IoT attacks.

In many organizations it's more important to do something rather than the right thing. With agile coding can start immediately, without a design. Since progress is measureed in lines of code, "something" is progressing well. After all, it's gonna be late anyway, put off the design till halfway through the project.

If you are writing a general ledger then no, it's not that relevant other than demonstrating a basic knowledge of boolean algebra and numerical anaysis (i.e. truncation and how it affects accuracy). If the job was embedded, especially bare iron, it's a core competency and if you missed it you better go back to selling shoes on a website. Any time you interface to a foreign app or device it's quite likely you'll come across situations like that. Even if it's C#, when you build that production line tester that interfaces to scales, spectrometers and time of flight sensors you'll have to know boolean operations. And if you don't understand boolean operations, how do you build SQL queries or LINQ statements?????

Tektronix or HP? That question once evoked religious wars comparable to Apple vs. Microsoft. Still have my decades old Tek 2235 analog 2 channel. Big and clumsy but good to 100MHz, without all those fancy DSO screen controls to mess it up.

The sad part in all the comments on this topic is that not one suggested writing some documentation for the project. Documentation is always someone else's responsibility. Two years ago I was handed 100KLOC of undocumented but production critical cowboy code. Programmer who wrote it was adamant that "the code is self documenting". It wasn't. It took 18 months to document it to the point where it could be maintained...barely. If you REALLY want to contribute to a project, write something other than code. "Everyone complains about the weather, but no one does anything about it."

The stringy tape concept had been around for a long time by then, and survived in QIC format for quite a while longer. Old time PDP programmers will remember the LINCtape and later DECtape drives on PDP-8s that go back to the 60s. They were bi-directional block replaceable tape drives, sort of a linear disk drive. DECtape was a vast imnprovement over paper tape. There were some QIC tape cartridge drives that used a floppy interface to implement a stringy floppy. QIC-40 was a common backup medium on early PCs. Just start the backup when you finished for the day to save an overnight copy of that huge 20MB disk drive.

Compared to paper tape 16KB was impressive and 1 minute extremely fast. Paper tape readers were manually seek (find label written on tape) and pull it through as fast as you can. If you were rich and had an ASR33 teletype with mechanical paper tape the transfer rate was a breathtaking 10 bytes per second.

One of the side benfits working for a Canadian company are the extra holidays every year. Even though I'm in the US I get Canadian Thanksgiving and Boxing Day off. And I still get 2 days for US Thanksgiving!

As others point out, working freelance is a long way from being a beginner. Figure on 5-10 years in a real job to give you the experience first. Try to freelance without the experience, you'll go broke after working 100 hour weeks till you're near collapse. Programming pays well although the locations may be limited. Some of the specialized jobs do quite well (I do 'bare iron' embedded programming, heavy on the electronics, circuit board design and how best to fit hardware with software). Web site programming is the highest demand, from what I see on job sites, which means more competition for the position. Embedded programmers are a rarity since you also need a lot of EE type skills, and I'm sure the same applies for advanced graphics/animation, avionics, medical and some other niche jobs. Books teach you some of the technical basics but virtualy nothing about commercial software development. A lot of non-technical skills like economics, project management and communications, go into the mix when you have to pitch a project to management. As for outsourcing, those website development projects are high profile targets for the Wipro outsourcing companies out of India, so yes, it's something you need to watch out for. Other types of programming jobs have little chance of being outsourced. Anything that needs local cultural fluency, or highly specialized knowledge, generally isn't economical to outsource. The particular (foreign) company I work for happens to outsource... to the US, since the foreign pool of senior level embedded guys is extremely small and just as expensive. Website stuff is your best chance for an entry level position. The IT experience won't impress anyone doing development ("those who can, program; those who can't, plug cables into routers"). Last place I worked for the first check mark was for a BS degree in a hard science, or a whole lot of solid programming experience. "I read a lot of books" won't make it past the HR filter. Might be unfair but there are so many applications HR has to come up with a base line, which for software development is a degree.

Thats an old technology, the Soundex code. Its a type of hashing to see if two words sound alike when spoken. It was a common way to look up names that may have been misspelled when first entered into a database.

I've used Git, Mercurial, SourceSafe and TFS, even (from the dark ages) DECset on VMS and an SCM on CDC Kronos systems (darn, can't remember the name, and yeah, SCMs have been around on mainframes since the 1960s). TFS gave me the least amount of trouble. I develop both C# and .NET alongside embedded "bare iron" ARM GCC using Eclipse. TFS worked fine for both. Working with embedded involves building boards as well as writing code. I used TFS to version schematics, PCB layouts and reference manuals, even field service work instructions, along with code. That's where the database method is handy; it stores binary BLOBs as wll as code deltas. What I like best is the lack of "file droppings" in source code directories. TFS puts everything in a SQL database. This is developing in a commercial enterprise environment where project management is critical. TFS has a very nice work item structure to track design, bugs, testing, even deployment, and it integrates well with both VS and Eclipse, along with MS Project. The type of programing is not quite the usual mix. What I need is a common pool of drivers and RTOS tasks that I pick and choose for different circuit boards, sort of an a la carte program design methodology. Code is added to individual files with conditional compiles for different variations, due to IC pinouts, but basically similar targets. Directory level commit gets in the way because individual files are shared across several target builds, not the entire directory. Sure, other SCMs can do file level check in/out, but TFS does it best. These days I have to use Github, management directives from on high, but I do miss the ease of use with TFS.

There's a micro-kernel for essential services, things like task scheduling and memory management. Essentially that's a standalone program since it's the lowest layer. Built on top of that are tasks that can be scheduled to implement the rest of the services. Task is a way to encapsulate a service. That has some security benefits by localizing references, it only runs as needed, can be swapped in a virtual system if not needed, and run multiple execution paths through the same code, important if there are several execution units (multi-core CPUs). So the upper layers, close to the end user, are usually process based, though there are some exceptions when you get to embedded RTOS design. Response time is everything in an RTOS, which is why they exist alongside a traditional OS like LInux or Windows. In an RTOS there may not be enough resources to work through multiple layers. Remember, we're talking about a microwave oven or a sprinkler controller, not an i7 and 16GB RAM. A low level RTOS does look more like a library of method calls to a small set of services.

As an american company Amazon is subject to FISA Court warrants. Unlike the public cases (Microsoft and Ireland) FISA warrants are secret and carry gag orders. If there's a way to get to the data from a US location then it doesn't matter where the disks drives reside. amazon cna be compelled, in secret, to deliver whatever the Court wants. And being a FISA warrant, you don't even know the data has been seized. Just to make it more interesting, the FISA court almost never turns down a warrant request from US security agancies. Don't count on checks or balances, but if you wan't any asurances from the US you have to "pay to play", which involves donations to special foundations and speaking contracts in the multi-millions USD. Your data would be safer in Russia. At least there you can just pay off a few people to leave you alone. It's a lot cheaper.

Something of an irony, I'm a US based embedded guy working for a foreign company, becasue of a skill shortage in that country (and most ironic of all, lower oeprating costs in the US). Fortunately I don't need a work visa since I work from home, but in principle I believe the H1-B was a good idea when it started. The US (and other First World countries) does benefit from a brain drain, pulling the best and brightest from other countries. And in a way it helps the newly graduated in those other countries since it puts pressure on foreign companies to improve conditions at home. The H-1B as it exists now is a joke. Companies like Wipro have destroyed it by grabbing every visa within minutes of issue, and using it to flood the outsourcing market. What I'd like to see is a quota, where any particualr company has a small limit on the number of available visa. Extend the quota to groups of related companies to block shell games. Wipro can't function in the US if all they can bring in is 100 bodies a year. Let companies bring in unique expertise, the way the H-1B was intended, but stop wholesale importation of inexperienced and cheap replacements. The counter argument is companies like Microsoft will move R & D overseas, but there's nothing to stop that now. The foreign talent pool for 20+ year experience engineers can't match what's available in the US.