4 ms·

Well, what you could learn at a four year degree program: - Space-time complexity of algorithms - Statistics - Management - Parallel and concurrent programm

Well, what you could learn at a four year degree program: - Space-time complexity of algorithms - Statistics - Management - Parallel and concurrent programming - Formal reasoning and logic - Linear algebra - Machine and operating system architecture - Communication theory - History of computer science - Database implementation - Quality assurance - Technology assessment (impact on society) - Effective team work - Multi-disciplinary design and architecture - Presentation skills - Research skills Could go on, just a few of the things I learned during my degree program. All of which I value of myself and others, although they don’t always come up. Coding is just a tool in a large toolkit. Unfortunately it is undervalued to do it right, badly taught and reinvented hundreds of times.

scarface74 7y ago
How much of that A) couldn’t be learned on a job B) is relevant for your typical yet another software as a service CRUD developer or the typical “dark matter development” that will never see the light of day outside of a company. I have a 20+ year old degree and most of what you list. I learned on the job.
- xiphias2 7y ago
  For me the hardest and most interesting part working at Google was statistics, although I have a Masters degree in CS, and I was very good at math in high school. A lot of the really interesting work at Google is data mining and modelling, and for that you need some level of statistics understanding. Of course for developing an app, it's not needed (could be a counteractive skill as well in iterating fast).
  - scarface74 7y ago
    Well seeing that most developers don’t work at Google, on the west coast or even for a tech company...,
    - xiphias2 7y ago
      Sure, I'm more commenting on the general feeling on the whole thread that having a CS degree should be dropped as a (soft) requirement for working at Apple/Google/Amazon, and coding can be learned from coding / working with colleagues. This is all true, but math has to be learned by getting a deep understanding of concepts that build upon eachother over many years, and understanding it is an important skill with large scale systems, so they can't be treated equally with other coding jobs.
  - edejong 7y ago
    Yes, statistics is a corner stone. I've come to appreciate it during my career as a software engineer as well. It's not just at Google but across many (competitive) companies. Developing an app... How is one going to be competitive doing that? It's dime a dozen, unless it provides something algorithmically interesting. And that is generally only possible when you have large amounts of data. In my opinion, the real skill is not in coding, but in data. Understanding the flow, the quality, the entropy, the structure, the meaning, the value, the meta. And code is data, and as such subject to the same understanding.
    - xiphias2 7y ago
      > Developing an app... How is one going to be competitive doing that? I tried to do it with a friend and failed. With apps looks are the more important than UX, and I was mainly working on usability features. Also market research and understanding your target audience without data is really important. At Google, understanding the user / customer was really easy, it doesn't need that much empathy: just give the user more quality clicks by changing the ranking and give the advertiser more conversions per dollar spent.
    - rland 7y ago
      Easier to teach an engineer how to program than to teach a programmer how to engineer.
      - scarface74 7y ago
        By the time I graduated from college, I had been a hobbyist for a decade. I was a good programmer and created a C based data entry system that double the size of the company six months out of college. But, after changing jobs and staying at a company too long, I became an “expert beginner” and in hindsight was a horrible engineer. Learning how to engineer happened on the job working with more experienced architects and managers, changing jobs 5 times, and by reading and studying a lot. There is nothing magical about college that you couldn’t learn on the job.
- edejong 7y ago
  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.

scarface74 7y ago

How much of that A) couldn’t be learned on a job B) is relevant for your typical yet another software as a service CRUD developer or the typical “dark matter development” that will never see the light of day outside of a company. I have a 20+ year old degree and most of what you list. I learned on the job.

xiphias2 7y ago
For me the hardest and most interesting part working at Google was statistics, although I have a Masters degree in CS, and I was very good at math in high school. A lot of the really interesting work at Google is data mining and modelling, and for that you need some level of statistics understanding. Of course for developing an app, it's not needed (could be a counteractive skill as well in iterating fast).
- scarface74 7y ago
  Well seeing that most developers don’t work at Google, on the west coast or even for a tech company...,
  - xiphias2 7y ago
    Sure, I'm more commenting on the general feeling on the whole thread that having a CS degree should be dropped as a (soft) requirement for working at Apple/Google/Amazon, and coding can be learned from coding / working with colleagues. This is all true, but math has to be learned by getting a deep understanding of concepts that build upon eachother over many years, and understanding it is an important skill with large scale systems, so they can't be treated equally with other coding jobs.
- edejong 7y ago
  Yes, statistics is a corner stone. I've come to appreciate it during my career as a software engineer as well. It's not just at Google but across many (competitive) companies. Developing an app... How is one going to be competitive doing that? It's dime a dozen, unless it provides something algorithmically interesting. And that is generally only possible when you have large amounts of data. In my opinion, the real skill is not in coding, but in data. Understanding the flow, the quality, the entropy, the structure, the meaning, the value, the meta. And code is data, and as such subject to the same understanding.
  - xiphias2 7y ago
    > Developing an app... How is one going to be competitive doing that? I tried to do it with a friend and failed. With apps looks are the more important than UX, and I was mainly working on usability features. Also market research and understanding your target audience without data is really important. At Google, understanding the user / customer was really easy, it doesn't need that much empathy: just give the user more quality clicks by changing the ranking and give the advertiser more conversions per dollar spent.
  - rland 7y ago
    Easier to teach an engineer how to program than to teach a programmer how to engineer.
    - scarface74 7y ago
      By the time I graduated from college, I had been a hobbyist for a decade. I was a good programmer and created a C based data entry system that double the size of the company six months out of college. But, after changing jobs and staying at a company too long, I became an “expert beginner” and in hindsight was a horrible engineer. Learning how to engineer happened on the job working with more experienced architects and managers, changing jobs 5 times, and by reading and studying a lot. There is nothing magical about college that you couldn’t learn on the job.
edejong 7y ago
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.