Hacker News Reader

Comment by jedberg | Hacker News Reader

I've worked with a bunch of people who don't have degrees. At the more junior level, you can tell the difference, because while they tend to be really smart and can pick things up quickly, they have funny holes in their knowledge -- CS theory that you'd only pick up from a CS textbook, stuff like Big O notation or A* search (ok maybe that one is a bit more common now, but in the early 00s you didn't really learn that without a textbook).

By the senior levels you can't really tell the difference between someone with or without a CS degree. Experience definitely beats textbook knowledge after a couple of years.

View on HN

Hiring manager here and I completely agree with this. In my experience there is almost zero difference between a junior engineer with a CS degree and a junior engineer who is self-taught or had a non-traditional CS education.

In actuality the things you learn in a 4 year CS program that you wouldn't get elsewhere (algorithm performance, theory, etc.) don't apply to all professional engineering jobs (especially at the junior level). Triplebyte has some great data on how bootcamp grads fair against CS grads (https://triplebyte.com/blog/bootcamps-vs-college) and my takeaway from this (and from personal experience) is that at the junior level it almost makes no practical difference.

I did Big O Notation in college and I still can't remember which notation is faster/slower.

After college/university you begin to forget a lot of the specific textbook stuff and begin to replace it with the put-food-on-your-table practical stuff.

Absolutely. But Big O still comes up in practical stuff depending on what you're doing. You can usually get by without it, but sometimes when you need to process a few 100 terabytes of log files, having a basic grasp on Big O comes in handy for reducing your processing time from days to hours by picking the right algorithm.

I think the point the parent was trying to make is that the concept is way more important than the specific notation. Someone that doesn't know Big O could still tell you why one algorithm would be better, it just might be slightly less succinct:

"The execution time of algorithm A scales up with the number of items, while algoritm B's is constant."

"The execution time of algorithm A is O(n), while algorithm B's is O(1)."

In practice I've always found avoiding premature optimization and then profiling better than worrying about Big O.

You save an awful lot of time when you know have an idea of what's going to be slow up front.

I've spent so much time trying to chase down bugs caused by junior programmers because something that worked fine with 100 rows in db, slows to a crawl when we move a feature out of beta and we suddenly have 1000 rows.

If they had some idea that the query they were writing was O(n^3) they could have done a quick estimate and saved us all the trouble.

As someone without a CS this is reassuring.

I really recommend trying to learn just the basics about big-O, because it is really the single most important thing that a CS degree teaches you.

Yeah, I agree.

You can learn it in like 30 minutes, and understanding the concept behind it (not just the notation) is the core of understanding why some algorithms work better than others.

Industry specific certifications can help ease the way into the job market along with a portfolio of (side) projects.

This is not something to "remember". If you don't know this, you don't understand it.

I don't think so, I think this is one of the easiest things to forget.

Even in school, Big-O is used almost exclusively, very rarely do you see Big-Omega, Big-Theta, Little-O, etc. Even though in algorithmic analysis these are all used to give a more accurate characterization of the algorithms behavior.

Its funny, too, because the professionals (that are admittedly very smart) that like to talk down about Big-O as if it was a waste of time, seem to not realize there is a whole taxonomy of tools for analyzing and characterizing algorithmic complexity...

Again you don't need to remember or forget this. Big O is worst case , theta is always guaranteed bound, Omega is minimum bound. My point is call them whatever, just know the concept to help you make design decisions.

This is something you need to know! What approach you use most definitely needs to keep in mind it's runtime. O(n^2) must be looked at with a skeptical eye and you better be sure there's no better answer when going higher. (I've hit O(n^8) in production code in a data verification routine and O(2^n) in a side project--the latter had to be scrapped in favor of an O(n^2) that wasn't guaranteed to find the best answer.)

The opposite is also true, for example, highly educated but still directly concatenating query parameters into SQL... "Oh yeah, the IDE provided warning was annoying, so I turned it off"

Yeah, I mean our field is so immensely broad (and deep!) that pretty much everyone you work with will have "funny holes" in their knowledge regardless of experience level.

I'm wondering where I'll be.

I did Chem engineering in college, but have been programming since I was 17.

Now I've moved to electrical design Engineering since it seems to be a hybrid of engineering and programming.

So far my job is understanding everything that goes into my complex system. I'm not sure if this or embedded programming is my future. What is more valuable?

I think there's also a large gap for people who only have a CS education and those with a traditional engineering background.

Traditional engineering skills are very undervalued in this industry and I've met very few "engineers" in this field who understand engineering basics like control systems. IMO that's very valuable for building the systems we build -- I can't tell you how many half-baked implementations of some of the parts of PID I've seen kicking around.

And I say that as a completely self-taught, college dropout senior developer.

I think you have a good point. With today's complex distributed systems, control theory should really be emphasized more. I didn't learn it in school, but I definitely studied it when I started being responsible for the uptime of complex systems!

Not going to lie, it's somewhat validating reading a +1 on this from you. It's usually one of my more unpopular opinions and I work in ops.

I mean my personal take on it is that if you don't have a most basic understanding of control theory, you won't understand what your monitoring system is telling you nor will you know how to programmatically react to it.

In fact, I have a perfect counter example. At reddit, to even out load on our databases, we built a system that would take into account current load on the database when choosing which read slave to select. As it turns out, this doesn't work well, because you overwhelm the slave with the lowest load because the the reaction time is too slow compared to the request time. We had to tweak it to account for this.

Had we known control theory, we would not have made this mistake. On the other hand, that mistake didn't cause us that much damage and we were able to devise a solution that ended up being right. :)

My experience of embedded is that it encapsulates needing to know everything about more complex systems. You can't make any assumptions about anything, which makes life fun. And often it's something totally unexpected which causes you grief.

I do a lot of embedded work without a CS degree. Every board and chip is different, so you learn by doing. But,at the same time a lot of hardware is basically the same. You have some low power cpu and a bunch of standard peripherals. Once you know how most of them work, it's just engineering to figure out what libraries you need.

There's lots of work in embedded that's for sure. There's also a huge amount of variety depending how close to the metal you want to be.

What stands out to me (at my current workplace), is that the guys with a CS degree, tend to spend much longer on building features than the guys without a degree. Mostly because they have really intense arguments about best practices, and have very strong opinions on almost everything.

While the guys without a degree are able to have a quick discussion, and come up with an approach they think is best.

> they have funny holes in their knowledge -- CS theory that you'd only pick up from a CS textbook, stuff like Big O notation or A* search

I don't have a degree but made it far enough in school to take algorithms and we didn't learn A*.. I think there will always be holes in someone's knowledge since schools have different requirements.

You probably wouldn't learn A* unless you took an AI related course. Or specifically studied graph traversal.

Or, had an interest in building video games.

I think you're less likely to run into those issues if all you're doing is building web apps and the like.

> By the senior levels you can't really tell the difference between someone with or without a CS degree. Experience definitely beats textbook knowledge after a couple of years.

Agreed. Absolutely correct!

You can't tell the difference because the senior non-degree people have picked up the useful CS theory or because CS theory doesn't come up anymore?

They've picked up the useful CS theory.

Yeah, that's interesting. I know a few senior people without degrees (or high school diplomas) and that chimes with what they say.

Exactly what I mentioned in my other comment in the thread.

And you can't read a book in teaching yourself?

Many self taught developers will focus on less theoretical skills related to programming and focus on what's practical.

They may read a textbook to teach themselves but it'll be different than the textbooks they make you read for a CS degree.

This typically is a benefit, many fresh CS grades I've seen are not as comfortable developing in their first job as a lot of self taught developers.

The self-taught guy probably has a lot more experience writing bigger things than the guy who only learned in school.

Well yes, but that's true of any degree - heck, that's true of nearly any education. There are a handful of exceptions like medical school that give you access to cadavers that you otherwise wouldn’t have or a robotics lab that has million dollar equipment that you can play around with, but in general you can (theoretically) learn anything by just reading books/practicing. College focuses you on things you might otherwise not come across and, in theory at least, sets a level expectation: anybody with a CS degree ought to understand elementary calculus, for example. If a CS education is “useless” then so is nearly all education.

Reply on news.ycombinator.com