3 ms·

Ad A) Most of that I 101'ed at the university. There are elements that I would never have learned on the job. Ad B) Quite a bit, actually. I am assuming the Sa

Ad A) Most of that I 101'ed at the university. There are elements that I would never have learned on the job. Ad B) Quite a bit, actually. I am assuming the SaaS CRUD developer is facing a high number of users (>50 req./s). - Space-time complexity of algorithms. Needed when reasoning about caching, cache-coherency, in-memory searches, CPU/Core allocation - Statistics. Very useful to understand the QoS the SaaS application is delivering to the end-users. 101 Stats is enough, but very useful in the toolkit. - Management. Not just to manage yourself, but to be able to understand the needs of the managers, the structure of the company and the long-term goals and strategy. - Parallel and concurrent programming. This depends. In SaaS applications I've seen some simple concurrent programming when it comes to request pipelining. - Formal reasoning and logic. Not really needed. - Linear algebra. Not needed. - Machine and operating system architecture. Could be very useful for high-throughput applications. What is the effect of the scheduler? The paging system? The L1/L2 cache? - Communication theory. Could be useful, not needed. - History of computer science. Personally, I think this one is really needed for CRUD developers. They'd stop repeating the same stupid traps all the time. - Database implementation. Although you don't need to implement a database, understanding how a database works and its query optimizer, is gold. - Quality assurance. When dealing with a programmer + PO team only, the devs need to do the QA as well. It's a learned skill, but easier to master after a 101. - Technology assessment (impact on society). Maybe not needed, unless you are into ethics. - Effective team work. Very useful. - Multi-disciplinary design and architecture. Could be very useful when developing SaaS applications for different domains. Understanding and working together with stakeholders from your target domain is a strong advantage. - Presentation skills. Could be useful. - Research skills. Not very useful.

scarface74 7y ago
So I’m going to start off by admitting all of my biases. I was a hobbyist Basic, 65C02 assembly language in middle/high school, graduated undergrad with a degree in CS from an unknown state school, MBA drop out (but I did learn a lot). I also spent my first 12 years professionally as a cross platform C bit twiddler, became your standard “enterprise developer” and then moved into development+cloud architecture. - space time complexity of algorithms. True that was a big deal when I was writing C programs that churned through what was then a lot of data, but, how many “Enterprise developers/architects” are writing code that is algorithmically complex and not just translating complex business rules into code? Even then when I’m determining why a system is slow, it could involve many layers of the stack from a too heavy payload going over the network, bad caching, incorrectly size servers, incorrectly placed servers, bad sql queries, etc. Machine and operating system architecture. Could be very useful for high-throughput applications. What is the effect of the scheduler? The paging system? The L1/L2 cache? I have some understanding about architecture and OS. But how useful is that from a CS level? Can’t you just look at your various metrics and see where your bottlenecks are? Again my degree was over 20 years ago. I would have had to learn that on the job. My operating system class was taught on some SUN Sparc workstations. My first job was writing FORTRAN and C on DEC VAX and Stratus mainframes. I’ve had to learn each operating system and platform on the job. Database implementation. Redshift (a columnar OLAP database), optimizes differently than a regular OLTP RDMS, which is different than something like ElasticSearch. Would you have learned any of that in college a decade ago? Technology assessment (impact on society). Maybe not needed, unless you are into ethics. Is that really taught in undergrad? I had a few classes like that in grad school. Multi-disciplinary design and architecture. Is that taught in undergrad? That was taught a little bit in grad school. But I’ve learned a lot more from working at 5 companies in 10 years (or 7 in 20). Presentation Skills I struggled for years with presenting ideas to non technical leadership but I am passable now. But that came more just by seeing how managers did it.
- edejong 7y ago
  I also started with GWBASIC, QBasic, Turbo Pascal, x86 assembler as a hobbyist. Followed during undergrad by C, C++, PHP, early Python, LISP/CLOS, Clean, Haskell and some Smalltalk. I started my full-time career as a Java programmer, but did part-time jobs in C and Perl during my grad years. Now I am mostly act as a tech lead / architect, but enjoy some Scala programming and fiddling with types and category theory. Erik Meijer is my hero ;) Many programmers indeed just copy whatever business rule they see into Java / C# code. However, on occasion they write an optimizer or a system churning through large amounts of data. Having that background sets the engineer apart from the coder. > Even then when I’m determining why a system is slow, it could involve many layers of the stack from a too heavy payload going over the network, bad caching, incorrectly size servers, incorrectly placed servers, bad sql queries, etc. Well, each of these are studied at grad school: networking, caching systems, SQL optimizers. It really gives a head start and I'm grateful for that. Re OSes. Most OSes have the same paradigms. I've been taught from the book Operating System Concepts by Silberschatz, Galvin and Gagne. It details the many concepts adopted by the various OSes over time. OS specific is not really interesting afterwards. Re Redshift / ElasticSearch. Columnar DBs were still new, so yes, you do need to learn at the job. Still gives you a tremendous head-start though, understanding row-based DBs. Technology Assessment and multi-disciplinary design was part of my Bachelors program, albeit 101. Presentation skills: I am very happy we were taught these skills extensively. Proved absolutely valuable, even though I constantly improved on them during my career. Overall, the skills are not so much to understand why a system does what it does, but to quickly understand a new technology from its basic functions. So when Rust comes along, I can quickly assess that it will be useful in a microservices setting due to not having a run-time, predictable behaviour and fast startup times. When MongoDB is pushed, I am not one of the many followers blindly believing its marketing lies.

scarface74 7y ago

So I’m going to start off by admitting all of my biases. I was a hobbyist Basic, 65C02 assembly language in middle/high school, graduated undergrad with a degree in CS from an unknown state school, MBA drop out (but I did learn a lot). I also spent my first 12 years professionally as a cross platform C bit twiddler, became your standard “enterprise developer” and then moved into development+cloud architecture. - space time complexity of algorithms. True that was a big deal when I was writing C programs that churned through what was then a lot of data, but, how many “Enterprise developers/architects” are writing code that is algorithmically complex and not just translating complex business rules into code? Even then when I’m determining why a system is slow, it could involve many layers of the stack from a too heavy payload going over the network, bad caching, incorrectly size servers, incorrectly placed servers, bad sql queries, etc. Machine and operating system architecture. Could be very useful for high-throughput applications. What is the effect of the scheduler? The paging system? The L1/L2 cache? I have some understanding about architecture and OS. But how useful is that from a CS level? Can’t you just look at your various metrics and see where your bottlenecks are? Again my degree was over 20 years ago. I would have had to learn that on the job. My operating system class was taught on some SUN Sparc workstations. My first job was writing FORTRAN and C on DEC VAX and Stratus mainframes. I’ve had to learn each operating system and platform on the job. Database implementation. Redshift (a columnar OLAP database), optimizes differently than a regular OLTP RDMS, which is different than something like ElasticSearch. Would you have learned any of that in college a decade ago? Technology assessment (impact on society). Maybe not needed, unless you are into ethics. Is that really taught in undergrad? I had a few classes like that in grad school. Multi-disciplinary design and architecture. Is that taught in undergrad? That was taught a little bit in grad school. But I’ve learned a lot more from working at 5 companies in 10 years (or 7 in 20). Presentation Skills I struggled for years with presenting ideas to non technical leadership but I am passable now. But that came more just by seeing how managers did it.

edejong 7y ago
I also started with GWBASIC, QBasic, Turbo Pascal, x86 assembler as a hobbyist. Followed during undergrad by C, C++, PHP, early Python, LISP/CLOS, Clean, Haskell and some Smalltalk. I started my full-time career as a Java programmer, but did part-time jobs in C and Perl during my grad years. Now I am mostly act as a tech lead / architect, but enjoy some Scala programming and fiddling with types and category theory. Erik Meijer is my hero ;) Many programmers indeed just copy whatever business rule they see into Java / C# code. However, on occasion they write an optimizer or a system churning through large amounts of data. Having that background sets the engineer apart from the coder. > Even then when I’m determining why a system is slow, it could involve many layers of the stack from a too heavy payload going over the network, bad caching, incorrectly size servers, incorrectly placed servers, bad sql queries, etc. Well, each of these are studied at grad school: networking, caching systems, SQL optimizers. It really gives a head start and I'm grateful for that. Re OSes. Most OSes have the same paradigms. I've been taught from the book Operating System Concepts by Silberschatz, Galvin and Gagne. It details the many concepts adopted by the various OSes over time. OS specific is not really interesting afterwards. Re Redshift / ElasticSearch. Columnar DBs were still new, so yes, you do need to learn at the job. Still gives you a tremendous head-start though, understanding row-based DBs. Technology Assessment and multi-disciplinary design was part of my Bachelors program, albeit 101. Presentation skills: I am very happy we were taught these skills extensively. Proved absolutely valuable, even though I constantly improved on them during my career. Overall, the skills are not so much to understand why a system does what it does, but to quickly understand a new technology from its basic functions. So when Rust comes along, I can quickly assess that it will be useful in a microservices setting due to not having a run-time, predictable behaviour and fast startup times. When MongoDB is pushed, I am not one of the many followers blindly believing its marketing lies.