3 ms·

Okay, I'll give you the "triage" presentation. It's a combination of "where to start" and "what I've actually used in industry." 1) Algorithmic complexity: Stu

Okay, I'll give you the "triage" presentation. It's a combination of "where to start" and "what I've actually used in industry." 1) Algorithmic complexity: Study why naively adding to the end of an array or the end of a string results in O(n^2), while doubling the size when you increase the storage results in O(n). That one tidbit has comprised some embarrassingly large fraction of the "consulting" I used to do working for a language/VM vendor. 2) Graph theory. Study BFS and DFS and implement them a few times to do things like solving a maze. Get comfortable with those until you can "run" them in your head when looking at a problem specified on paper containing a graph, and you can see uses/consequences. This will both keep you out of trouble and can be a starting point for further study. 3) Concurrency. Learn about race conditions and deadlock. Figure out some tools and patterns for dealing with them. Use them to write a chat server and figure out how to automatically QA it until you can break it. 4) Transactions. ACID. Read up on why you have ACID transations, and what can go wrong. That right there is good for some huge percentage of what could really get you into deep trouble.

leowoo91 8y ago
4th one should be elective :-P
- stcredzero 8y ago
  I disagree. I'm not asking for one to implement ACID transactions. Rather, just understand why people did it. I'm building a system which is relaxed down from ACID, which depends on idempotency and a single coordinator process to keep a cluster of servers from trampling on each other. You need to know the rules and the reasons behind them if you're going to start "breaking" them. Otherwise, you're just acting in ignorance.
dmux 8y ago
Could you explain why adding to the end of an array results in O(n^2)? From what I can find, it appears to be O(1). If you increase the size of the array by 1 each time and copy the old array elements over, wouldn't that be O(n) to copy the array plus the additional add, O(n+1) which is just O(n)?
- stcredzero 8y ago
  Could you explain why adding to the end of an array results in O(n^2)? If an operation does that n times, then it's O(n^2). It's very common for self taught programmers to write operations that do the naive addition many times. There have been entire consulting trips caused by basically that, including, so I heard, the one that brought a consultant into the Chrysler C3 project and sparked the invention of Extreme Programming.

leowoo91 8y ago

4th one should be elective :-P

stcredzero 8y ago
I disagree. I'm not asking for one to implement ACID transactions. Rather, just understand why people did it. I'm building a system which is relaxed down from ACID, which depends on idempotency and a single coordinator process to keep a cluster of servers from trampling on each other. You need to know the rules and the reasons behind them if you're going to start "breaking" them. Otherwise, you're just acting in ignorance.

dmux 8y ago

Could you explain why adding to the end of an array results in O(n^2)? From what I can find, it appears to be O(1). If you increase the size of the array by 1 each time and copy the old array elements over, wouldn't that be O(n) to copy the array plus the additional add, O(n+1) which is just O(n)?

stcredzero 8y ago
Could you explain why adding to the end of an array results in O(n^2)? If an operation does that n times, then it's O(n^2). It's very common for self taught programmers to write operations that do the naive addition many times. There have been entire consulting trips caused by basically that, including, so I heard, the one that brought a consultant into the Chrysler C3 project and sparked the invention of Extreme Programming.