The silliness of the paper is that there is no reason at all to keep previously submitted chunks in memory, and it's like somebody discovered that naive string appends are quadratic in memory allocation. On day 2 of everybody's first job, they learn to just append strings to a list and either flatten them to the one big string you need at the end, or evict the head of the list out somewhere (disk?) when a reasonable chunk size (optimize for block size) or amount of time (optimize for latency) has passed. I would imagine that in this case, you should simply queue up writes in memory into a constant-sized and pre-allocated buffer, and flush to disk as soon as it is the size of a disk block.

Holding the string in memory serves no purpose at all if you are just appending to it. Frankly, this += of strings issue is the most common "Smart but Green Self-Taught" versus "Computer Sci grad" problem you will see with new hires. Appending strings can be O(n^2) when the strings are immutable, and it applies to most high level environments. Even Metasploit had this issue at one point, and it was written by some very smart people. So everybody learns to keep appending to a list, and then flatten it to a string at the end. But this tie in with disk just makes the paper totally dumb. If you won't be reading the queue of string chunks, just flush them to disk immediately so that the code runs in constant space - relieving the memory allocator.

By what technical means do you prevent data leakage though? You need to specify what the system (and its users) will NOT do. Defending against bad input (and bad state transitions) is the foundation for everything else, because there is no technical means of enforcing any other security property otherwise. The game of the attacker is to reach and exploit states that are undefined or explicitly forbidden. Think of the Heartbleed bug as an example of a failure in 5 mooting 6. Bad input causes a web server to cough up arbitrary secrets, which is used to violate every other security constraint. For 5 mooting everything, including data leakage protections: SQL injections can be used to extract sensitive data out of web sites (ie: SilkRoad user lists presented back to the administrator with ransom demands). I work on a data leakage protection system, and it's based on earlier intrusion detection and prevention systems for a reason. I regard Intrusion Detection and Intrusion Prevention systems as essentially trying to force a fix of number 5 over a zoo of applications that didn't get it right; amounting to taking action on a connection that looks like it's not safely following protocol.

Number 5 is the most important. It is about defending against bad input. When an object (some collection of functions and a mutable state) has a method invoked, the preconditions must be met, including message validation and current state. A lot of code has no well defined interfaces (global states). Some code has state isolated behind functions, but no documented (let alone enforced) preconditions. The recommendation implies a common practice in strongly typed languages: stop using raw ints and strings. Consume input to construct types whose existence proves that they passed validation (ex: a type "@NotNull PositiveEvenInteger" as an argument to a function, etc). DependentTypes (types that depend on values) and DesignByContract are related concepts. With strong enough preconditions, illegal calling sequences can be rejected by the compiler and runtime as well. If secure code is ever going to start being produced on a large scale, people have to get serious about using languages that can express and enforce logical consistency.

Bad algorithms are the major difference between a totally self-taught programmer and a programmer who has learned some actual computer science. Yes, "1000x speedup" is not ridiculous at all. Use the wrong algorithm, and you can make this speedup number as large as you want by feeding it a larger data set.

This is only an issue because of unchecked pointer arithmetic. For garbage collected and range checked items, you can't take advantage of co-location of data. In a JVM, if you try to cast an address to a reference to a Foo, it will throw an exception at the VM level. Indexing arrays? Push index and array on the stack, and it throws an exception if index isn't in range when it gets an instruction to index it. In these cases, pointer arithmetic isn't used. In some contexts, you MUST use pointer arithmetic. But if the pointer type system is rich enough (See Rust) then the compiler will have no trouble rejecting wrong references, and even avoiding races involving them. In C, an "int*" is not a pointer to an int. It is really a UNION of three things until compiler proves otherwise: "ptr|null|junk". If the compiler is satisfied that it can't be "junk", its type is then a union of "ptr|null". You can't dereference this type, as you must have a switch that matches it to one or the other. The benefit of this is that you can never actually deref a null pointer, and you end up having exceptions at the point where the non-null assumption began, rather than deep inside of some code at some random usage of that nullable variable. As for arrays, if an array "int[] y" is claimed, than that means that y[n] points to an int in the same array as y[0] does. Attempts to dereference should be proven by the compiler or rejected; even if that means that like the nullable deref, you end up having to explicitly handle the branch where the assumption doesn't hold. You can't prove the correctness of anything in the presence of unlimited pointer arithmetic. You can set a local variable to true, and it can be false on the next line before you ever mention it because some thread scribbled over it. Pointers are ok. Pointer arithmetic is not ok except in the limited cases where the compiler can prove that it's correct. If the compiler can't prove it, then you should rewrite your code; or in the worst case annotate that area of code with an assumption that doubles as an assert; so that you can go find this place right away when your program crashes.

Yes, that is what I meant. You will be parsing data almost every day. If you are not good at this, then you will be responsible for the creation of a huge number of security holes, and never-ending quality issues. Complexity theory (ie: algorithms), Probability (ie: measuring), and a basic understanding of language theory (the core of compiler writing) are the key CS specific skills that excellent developers share. You do need to be good at math, but not necessarily the kind of math that is emphasized in the academic world.

If you already have a couple of good developers on a team and put on a guy who can't be trusted to edit the code without breaking its performance, correctness, or usability; he will both cause the good developers to leave and start creating maintenance burdens. That's why I say that the minimum competence bar to get into a programming team is actually pretty high.

Now if you have a job which isn't primarily programming, but are writing code to *automate* a tedious process that you would otherwise have to do manually; then go ahead and write horrible code. Maybe you have nothing to lose in that situation, or the consequences of maintenance fall on somebody else.

Security correct input reading is a compiler problem. Almost all security holes result from haphazard file and socket reading. In any case, people who can only do simple things are not your 10x developers. Due to the maintenance costs of having bad code in the first place, a lot of places will do without a developer than have one that writes code that is just ok.

Self-taught developers do need to pick up enough math to stop writing code that dies under its first realistic load (complexity theory). You can't write a good compiler without being able to learn the math. Computer graphics and Statistical programming require absurd amounts of math to do well (to be the 10x developer). I agree that the academic background isn't necessarily useful, and we see good people who went from high school to military to industry. Computer Science as it now stands has serious rigor problems. Which is why it is undergoing a serious security crisis, and the only light at the tunnel is languages that will reject logically inconsistent input that wont follow a specification. That means that at some point, programming is going to look a bit more like Haskell, and require some ability to write code that meets it's spec the first time; rather than quickly building something that undergoes haphazard maintenance for years on end.

Even when you get good programmers, projects are often managed to push as many amps through a developer as possible. When that happens to a team, more difficult things do get accomplished, but the code often still looks like it was written by an amateur. Bad code ends up being like credit card charges that never get paid off, while the owed amount continues to climb until bankruptcy occurs. This is because the bad code wastes a percentage of everybody's time every day, and the mess compounds as everybody works around it. So, it is often better to just not hire a developer that isn't "the one" (who is often worth about 10 normal people). We used to do interviews including the entire office, and generally require unanimous approval. Maybe 50 to 100 people between phone screens and actual interviews were done to get one person. I think there is an oversupply of people trying to specialize in programming; and most people should be learning programming as a supplemental skill to a specific business.

This! I had to reload my psmouse module half way through the album. Apparently this is not so uncommon on Dell laptops. I read the source code, and it was trivial. But the very large byte array size makes this something that's generally inadvisable, precisely because you could jump somewhere into it where the audio happens to be specific byte code. I also discovered it from tweets coming out of thegrugq, etc.

C is a perfect language for back-dooring code. Without good tools - even for the sake of code reviewers that are trying to defend the code base against good malicious programmers - we won't be able to keep up. Most C code is going to be full of accidental back doors, and possibly a few intentional ones. Something has to be done about machine assisted proof of memory safety, and about ensuring that parse code either follows a spec or stops parsing the input. High level languages with memory safe semantics are essentially constructive proof of memory safety at the cost of performance. You can also go the route of fixing the defaults of what is going to be allowed in important C files, and force programmers to #pragma their way out of violating the constraints so that potential bugs are easy to spot. Or better yet, stop using read() in the raw to ingest input; and force the code to parse input with a well defined grammar (and fail to compile otherwise). You don't necessarily need an abstract garbage collected language that prevents you from cutting yourself. What you really need is by any means necessary to limit security critical code to constructs that the compiler can prove the consistency of. Code review should essentially amount to the reviewer making a list of proof demands, with the review process failing until there are machine checkable proofs of these facts. Every exception to these rules (Supress warnings, or accepting a hand proof, or proof by authority) need to be documented at the line where they happen. That way, when the next back door is discovered, we can easily search for the place that introduced it. This is not theoretical at all. I worked with a guy who was publicly accused of back dooring a Unix. No amount of code review will clear anyone of suspicion; because we use the crappiest tools for proving correctness of even small things.

You have to calculate it as: (Sales + JobOpportunities - (Taxes + Hardware + Software + Books + TheJobYouCantTakeWhileYouDoDev)) .... If you really are good enough to make a profitable app that covers all of your costs, then TheJobYouCantTakeWhileYouDoDev is about $100000. I put my well paid day job at risk doing part time mobile app development for a few years. My partner did in fact quit to do it full time (and eventually got tired of making $30k a year for 60hr workweeks doing work at about the $130k/year level - and found a remote development gig through the connections that app development gave him.) I calculate that had I quit the job to do it full time, it would be roughly competitive with my day job; but with very large variables for both risk and future opportunities. I consider it roughly equivalent to getting a Masters Degree. I learned a lot about the business side of development.

There are other ways, like the military. I work at a place that is full of kernel developers. Most of our people have college degrees, but it seems that our best people went straight into tech work in the Israeli military and didn't stop to go to college when their mandatory service was up. It's different from the US because everybody does 3 years of military before they are able to go to college; but it seems to effectively provide a nationalized trade school that precedes college.

For mobile apps, this is actually not a bad idea if you can afford to fail; because you are still unattached enough that nobody depends on your income in a critical way. If nobody is going to pay your way through college, then you have nothing to lose. Get your failures and experience in before you have a house and a kid. LinkedIn will light up for you as a side-effect. A lot of my friends are the top developers in the iOS music app space; and I was in the mosh pit trying to make it happen along with them (while working a good full-time job - contemplating full time app dev). A small number of them make a healthy living doing little more than occasional maintenance on long-shipped apps while using the rest of their time learning the craft and having a life. 90% of them fail badly, with improved job prospects. The 30% Apple tax is high, but the mobile user mindset is what makes it hard. The large volume of users that can drive your asking price down nicely can also be a major support nightmare because you have to deal with them directly. You will deal with fads, gaming the review system (ie: send you an email that implies that if they don't get something for free in a few days that you will get a 1 star review, or requesting refunds while keeping the app and still sending support questions for months on end). The huge numbers of apps can make it hard to get a foothold on iOS/Android. On other platforms, even a well promoted and executed (even best and only for its category) app can still fail because there really are almost no users. Even given a *great* app and somebody that's good at the business, it's still far more of a gamble than showing up to a job and knowing how much you will make. But it's far better to do this while you are living with your mom than sitting around doing nothing or working an unskilled job for minimum wage.