4 ms·

As a self-taught software developer (with a degree in physics) I have a bigger problem with project-based learning (which is how I taught myself): completeness.

by cjs_ac 3y ago

As a self-taught software developer (with a degree in physics) I have a bigger problem with project-based learning (which is how I taught myself): completeness. Learning on my own meant I avoided the trap of only learning part of how to complete the project (because I had to do all the parts) but I only learnt enough to complete the project I was working on. I didn't learn any data structures or algorithms fundamentals until I started playing with C (in fact, my algorithms knowledge is still rubbish, and I've never implemented a hash map, I just use tries), and there's so much I pick up on just from listening to my CS-qualified colleagues in the office. To make guided project-based learning achieve this, the projects have to be so finely structured that they end up forming a traditional curriculum anyway.

2143 3y ago
> hash map, I just use tries That's how I messed up my <big-company>-Luxembourg-office interview many years ago. At least, that's one way, out of the possibly many ways I messed up. The interviewer asked what was in retrospect a trivial question whose obvious and straightforward solution involved using a hash table, but me being clever proposed a ridiculous solution involving tries. Didn't get the job :)
- cinntaile 3y ago
  Amazon I presume.
- sshine 3y ago
  Sometimes landing a job requires several tries.
dgb23 3y ago
Since you're self taught as well: there's an exceptionally great book (available online for free) Crafting Interpreters. It's entirely project based, but you learn so much from it because it explains the concepts along the way. As for A&D, there are a couple of data structures that are interesting and generally applicable. But I found that there are diminishing returns here. If you know a reasonable set of them, you _can_ stop there and pick up new ones when you actually need them for something.
- PartiallyTyped 3y ago
  Crafting Interpreters is an easy recommendation! Very well written, and gets straight to the point!
matwood 3y ago
> to complete the project I was working on. Which is itself an important skill. I was working at a small startup while in undergrad. During the day I was being taught theory and 'correctness', while at night I was coding with my boss trying to get features built so the client would give us another check to stay in business. Sometimes you just have to get things done - "Real artists ship." - SJ
kerblang 3y ago
Yes, completeness is exactly right, but not just for computer science. It's true for learning a programming language, a protocol, a database, really anything. Learning just enough to push over the finish line by the seat of your pants inevitably leaves gaps, and often leads to deficiencies causing unexpected breakdowns in the future. It's a widespread problem. The value in doing projects is learning to do... projects - not a trivial thing, actually.
scarface_74 3y ago
I’ve been developing professionally for 25+ years and by the time I graduated college in 1996, I had been a hobbyist assembly language developer on four architectures - 65C02, 68K, PPC and x86. I spent my first 12 years doing at least some C on mainframes, x86 PCs and later maintaining a proprietary development stack written in C for Windows CE devices. I think in my entire career, the only algorithmic complex things I had to do were some recursive programming and the “Shunting Yard” algorithm. I did some real hairy C and assembly language optimizations back in the day that I haven’t needed in over a decade. But nothing that was taught in algorithms classes. I would venture to say that a great majority of your developers doing enterprise CRUD development - which most are - would need to know any algorithms to get their job done.
aidenn0 3y ago
> in fact, my algorithms knowledge is still rubbish, and I've never implemented a hash map, I just use tries If you need to write an associative data structure, write a trie. There are too many pitfalls when implementing a hash-table. e.g. It's really hard to accidentally write a trie with linear lookup performance or quadratic space usage, but it's really easy to accidentally write a hash-table that does one of those. A well implemented hash-table will beat a well-implemented trie for pretty much all unordered operations, but a quick and dirty trie will usually be far more robust to corner cases than a quick and dirty hash-table.

by cjs_ac 3y ago

2143 3y ago

> hash map, I just use tries That's how I messed up my <big-company>-Luxembourg-office interview many years ago. At least, that's one way, out of the possibly many ways I messed up. The interviewer asked what was in retrospect a trivial question whose obvious and straightforward solution involved using a hash table, but me being clever proposed a ridiculous solution involving tries. Didn't get the job :)

cinntaile 3y ago
Amazon I presume.
sshine 3y ago
Sometimes landing a job requires several tries.

dgb23 3y ago

Since you're self taught as well: there's an exceptionally great book (available online for free) Crafting Interpreters. It's entirely project based, but you learn so much from it because it explains the concepts along the way. As for A&D, there are a couple of data structures that are interesting and generally applicable. But I found that there are diminishing returns here. If you know a reasonable set of them, you _can_ stop there and pick up new ones when you actually need them for something.

PartiallyTyped 3y ago
Crafting Interpreters is an easy recommendation! Very well written, and gets straight to the point!

matwood 3y ago

> to complete the project I was working on. Which is itself an important skill. I was working at a small startup while in undergrad. During the day I was being taught theory and 'correctness', while at night I was coding with my boss trying to get features built so the client would give us another check to stay in business. Sometimes you just have to get things done - "Real artists ship." - SJ

kerblang 3y ago

Yes, completeness is exactly right, but not just for computer science. It's true for learning a programming language, a protocol, a database, really anything. Learning just enough to push over the finish line by the seat of your pants inevitably leaves gaps, and often leads to deficiencies causing unexpected breakdowns in the future. It's a widespread problem. The value in doing projects is learning to do... projects - not a trivial thing, actually.

scarface_74 3y ago

I’ve been developing professionally for 25+ years and by the time I graduated college in 1996, I had been a hobbyist assembly language developer on four architectures - 65C02, 68K, PPC and x86. I spent my first 12 years doing at least some C on mainframes, x86 PCs and later maintaining a proprietary development stack written in C for Windows CE devices. I think in my entire career, the only algorithmic complex things I had to do were some recursive programming and the “Shunting Yard” algorithm. I did some real hairy C and assembly language optimizations back in the day that I haven’t needed in over a decade. But nothing that was taught in algorithms classes. I would venture to say that a great majority of your developers doing enterprise CRUD development - which most are - would need to know any algorithms to get their job done.

aidenn0 3y ago

> in fact, my algorithms knowledge is still rubbish, and I've never implemented a hash map, I just use tries If you need to write an associative data structure, write a trie. There are too many pitfalls when implementing a hash-table. e.g. It's really hard to accidentally write a trie with linear lookup performance or quadratic space usage, but it's really easy to accidentally write a hash-table that does one of those. A well implemented hash-table will beat a well-implemented trie for pretty much all unordered operations, but a quick and dirty trie will usually be far more robust to corner cases than a quick and dirty hash-table.