Comment by Neywiny | Hacker News Reader

Comment by Neywiny | Hacker News Reader

Parent Full thread

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.

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?

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.

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.

> 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.

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.

I haven't looked at leetcode in a long time but if the problems require e.g. rebalancing a tree, I honestly don't remember how to do it and might not be able to reason it out on the spot either. I have no problems with concepts like recursion or computational complexity though.

It sounds like leetcode problems require either memorization of a significant number of algorithm design patterns or seriously sharp algorithmic problem solving skills.

> Off the top of my head, possible problems here might be:

> 1. To handle trees easily you have to understand recursion.

Well that's the point of the exercises I suggest - to learn recursion :-/

> No Big-O notation. Interviewers usually ask questions about time/space complexity

Well, that's the other half of the interview, I only promised that my method will cover half the questions :-)

> Well that's the point of the exercises I suggest - to learn recursion :-/

Then we must have been talking past each other. We are considering this problem here:

>> I never took affinity to computer science/math, but I love building real world products with software. [...] I am struggling with all the interviews that have these leetcode problems.

Then your advice to these interview problem is to learn some CS - the useful parts of it? E.g. recursion is CS.

>>>but I love building real world products with software.

> Then your advice to these interview problem is to learn some CS - the useful parts of it?

Theory was not my advice.

My advice was to do practical things with trees; I felt it would fit his love of building real things.

I mean, I didn't recommend doing problems out of a textbook, did I?

> 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.

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.

For what it's worth, my computer science degree also had courses and projects that included requirements analysis, breaking down the problem, and elements of software engineering methodology and project management. (I believe we had a course titled "software engineering" even though the university doesn't award engineering degrees.)

I suppose in some schools computer science programmes might be fairly distinct from engineering ones. However, it seems that in lots of places a bachelor's in computer science is rather an generalist degree that covers lots of (mostly software) tech topics and some CS theory.

I'd still have trouble calling myself a software engineer, though, since I don't technically have an engineering degree, even though in lots of places my job might be described as such.

I also don't know a single programmer/developer whose job is distinct from field 2.

I agree with this. As someone who took 3 degrees in computer science, one called "systems developer" and another called "software engineer", I can confidently say we have a taxonomy problem in computer science education.

It makes me crazy that companies labels there entire programmer workforce as "software engineers" when there are no engineering concepts involved at all. Other fields (medical, mechanical, civil engineering) are a lot more mature in this area and have solved this issue long ago.

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.

> 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.

Is code monkey derogatory here?

How about "Software Simian"?

https://ia601605.us.archive.org/view_archive.php?archive=/23...

No. As somebody who lives in the trenches, I'm not too far behind. I've met people who say they can only do theory and can't do the practical side of this area. I think they might use it derogatorily but anybody who does clearly doesn't understand that both sides are necessary. So if anybody says it in that tone, just walk away.

Reply on news.ycombinator.com