| ▲ | Neywiny 14 hours ago |
| This is computer science. My uni's course number wasn't too different and I remember 3 things worth sharing here:
1. Somebody asked the lecturer what practical application something had. He pondered for a bit, and said "I don't really care." And then gave an explanation of how it's a science/theory class.
2. A classmate threw fits in the group chat about how he'd never have to do this kind of work after graduating because he could hire people like our lecturer to do it for him.
3. The rush when I figured out how to prove something during the last problem of an exam. As the time ticked away and I'm just staring at the words over and over, before I can sink an ice pick in and finally start grabbing a foothold. Other things not really worth mentioning were that we had some useless digital logic section at the start where we made a full adder and called it a computer. As a CompE, it was weird. The CS students thought they knew all there was to how a computer worked from that. Also, he was only a lecturer because our processor got sick right before the class and they found a grad student to do it. He was ok but took shortcuts and our TA would be like "oh, he did this fast and loose, so now I have to teach you the real way it's done". It was a great class in retrospect and certainly pushed my boundary on theoretical computing but you could feel the code monkeys regretting their decisions each homework and exam. It's what radicalized me to believing we needed programming and computer science to be different majors. |
|
| ▲ | AdityaSanthosh 14 hours ago | parent | next [-] |
| Hi, I am one of those code monkey you mentioned. I never took affinity to computer science/math, but I love building real world products with software. I built some really hard and interesting products. Basically, I love playing with tools and building tools from programming paradigms I know. Right now, I am struggling with all the interviews that have these leetcode problems. What sort of career in IT do you think would be best fit for me? |
| |
| ▲ | Neywiny 14 hours ago | parent | next [-] | | Well what I'll say is this: my job never had leetcode. Embedded engineering, especially if you do FPGA work, is very different from what leetcode has. Honestly if recruiters are using it for jobs like mine, they really don't get it. But I don't know you nearly enough to know. There are so many different fields up and down the stack. Front end, backend, embedded, cloud, edge, consumer, IoT... The list goes on. I would cast a wider net, I guess. | |
| ▲ | whateverboat 13 hours ago | parent | prev | next [-] | | There are three parts of building products in software just like everywhere else: 1. understanding what product needs to be built 2. Having the technical expertise to build them 3. how much effort is needed to build it And all three things can be hard in themselves. The product can technically be just straightforward (even if somewhat tedious) but you should know what to build because you should know what the customers need. The product can be technically so challenging that without the theoretical background, you would not even know that such a product would be possible. (An example here would be something say that requires distributed and independent time clocks). Finally the product can be something that is technically simple, obvious in its customer demand but requires quite a bit of effort and therefore requires you to be good at procuring resources and managing them. You need to figure out which of these three things made you successfull with the product you call really hard and interesting and pursue that line of industry (even if it is not software!). And then slowly try to become good at other two things. | |
| ▲ | lelanthran 11 hours ago | parent | prev [-] | | > Right now, I am struggling with all the interviews that have these leetcode problems. There's no need to struggle with them. You'll cover fully half of them simply with experience with trees. Build them. Traverse them top-down. Then bottom-up. Search it, Balance it, then rebalance on modification. Invert it, prune it, Roundtrip it to JSON, etc. After mastering that, given a problem of "develop a flood-fill algorithm to this specification" should be a walk in the park. | | |
| ▲ | kubanczyk 13 minutes ago | parent [-] | | Off the top of my head, possible problems here might be: 1. To handle trees easily you have to understand recursion. Somebody with no CS experience (and no parser experience) might never ever used recursion in anger, even if they launched zillion commercial projects. 2. No Big-O notation. Interviewers usually ask questions about time/space complexity. And the elephant in the room is that leetcodes are getting trickier and trickier, that's LLM era for you. |
|
|
|
| ▲ | czhu12 10 hours ago | parent | prev | next [-] |
| I was one of those students initially but then came to appreciate the beauty in the science and nature of computation. I always tell people that computer science is not about programming -- its about studying the dynamics of problems in nature. Unfortunately, I realized this a little late, and it wasn't until towards the end of my final year when I started appreciating these courses. I long for a day I can return to studying these topics. |
|
| ▲ | skipants 8 hours ago | parent | prev | next [-] |
| > radicalized me to believing we needed programming and computer science to be different majors. Some universities offer Software Engineering as a BEng as well as CompSci as a BSc. At least in Canada. |
| |
| ▲ | Neywiny 3 hours ago | parent [-] | | But software engineering as a concept still isn't writing code. I'm a bit of a stickler about it as somebody who has an engineering degree, but when programmers with a CS degree say they're a software engineer, they're not. Software engineering as far as I understand it from the little bit I did in school is actually engineering. Requirements analysis, breaking down the problem, following methodology, etc. It's not just that they're writing somewhere. So really there should be 3 fields of study:
1. The theory - computer science
2. How to apply the theory - software engineering
3. How to turn those designs into reality - programmers It's like the mech engineering side. You have materials science and stuff, then mechanical engineers, then machinists. |
|
|
| ▲ | mallic 3 hours ago | parent | prev | next [-] |
| > we needed programming and computer science to be different majors. Neither are needed anymore if people will be able to tell a chatbot what to do. Instead you’ll need a Problem Solution Verification minor. |
|
| ▲ | suggeststrongid 3 hours ago | parent | prev [-] |
| Is code monkey derogatory here? |
| |
