12 ms·

I have a degree in CS and I've never found myself in a situation where anyone would discuss bouble sort vs merge sort. Neither have I been in a situation where

I have a degree in CS and I've never found myself in a situation where anyone would discuss bouble sort vs merge sort. Neither have I been in a situation where big-o was relevant beyond the basic concept of not doing obviously stupid shit. What you've really missed is things like best practices, design patterns and concepts like SOLID, but a lot of people with CS degrees missed some of those as well. If the book covers this, excellent, but why wouldn't it sell itself on valid points?

teekert 10y ago
I have no degree in CS and I see these terms (Big O, np vs p, etc) regularly, mostly here on HN. No idea what they mean, this books sounds great to me.
- haylem 10y ago
  > mostly here on HN Which may or may not be an accurate depiction (as we read personal accounts and thoughts of the commenters) of a quite marginal subset of real-life IT-professionals. I wouldn't worry too much about what's being said or not said on HN. There are great ideas and topics to be covered here for sure, but they're sprinkled on top of a giant cake made with 1-part self-loathing, 2-parts day-dreaming, and 1-part regular huff-and-puffing. It makes for good entertainment and procrastination. > No idea what they mean, this books sounds great to me That being said, not knowing Big-O while doing CS or IT work seems worrying. Sure, it's not absolutely necessary for most of the grunt work. But you should definitely have the same understanding of performance issues without knowing the fancy notation and terminology. Big-O is just a notation and a formalization of these concepts, and it helps with communication. I'd say it's still better to know it. So, indeed the book probably doesn't hurt.
  - teekert 10y ago
    I'm just a biologist that switched to Python because Excel and Origin weren't dealing very well with my ever increasing pile of data (Typical data: Every row is cell in a Tissue sample, every column is a quantified parameter (size, marker intensity, ...) of that cell, typically I deal with 10s to 100s of tissues samples) Pandas is great, I spend my time turning DataFrames into histograms, scatter plots and ROC curves in Jupyter Notebooks. I have the feeling knowing Big-O is not very relevant. Still, learning new languages, new words and new abstractions is almost guaranteed to influence ones way of working and thinking at some level. So, indeed indeed the book probably doesn't hurt ;) Edit: Just glanced over the link in Practicality's comment about big-O and sure enough I think it may actually be useful as my ever increasing pile of data increases even further! I have to admit; as the parameters increase I find myself doing over night calculations more and more.
    - emodendroket 10y ago
      Asymptotic complexity comes up pretty frequently in bioinformatics contexts because the volumes of data can be huge.
      - vonmoltke 10y ago
        How does it change what you do, though? I did signal processing with massive data streams rather than bioinformatics, but I assume the situation is similar. The algorithms are what they are. They are complex mathematical equations or transformations that need to be run on data and are often optimized without being able to change their asymptotic complexity.
        emodendroket 10y ago
        Skiena's Algorithm Design Manual mentions him being brought in as an algorithmic consultant to modify some genetics analysis software so that it'd actually finish but I don't really remember the details or know enough about the field to give you plausible examples.
        vonmoltke 10y ago
        I can see that; I did a lot of similar work with signal processing algorithms. None of what I did affected asymptotic complexity at all, though. The asymptotic complexity was tied to the algorithms chosen, and changing those was an issue of trading computational performance for system performance.
        deleted 10y ago
        [deleted]
        emodendroket 10y ago
        I pulled it up and found it; the problem involved modeling genome sequences as strings and finding possible substrings.
    - 10y ago
  - lafay 10y ago
    This is the best description of HN I've ever read: > There are great ideas and topics to be covered here for sure, but they're sprinkled on top of a giant cake made with 1-part self-loathing, 2-parts day-dreaming, and 1-part regular huff-and-puffing.
  - dineshp2 10y ago
    > I wouldn't worry too much about what's being said or not said on HN. There are great ideas and topics to be covered here for sure, but they're sprinkled on top of a giant cake made with 1-part self-loathing, 2-parts day-dreaming, and 1-part regular huff-and-puffing. I don't understand your argument regarding why you would not pay much attention to what is being said on HN. Could you explain?
    - blowski 10y ago
      Probably because there is a noisy minority who voice dogmatic opinions without understanding the constraints of the problem at hand. They are lilliputians, spouting wonderful ideas that collapse in the face of deadlines and budgets. For those of us that have to live in reality, they can be very annoying and disheartening, so it's essential to take their opinions with a fistful of salt.
      - haylem 10y ago
        That, yes. But also because a significant amount of even the day's top popular topics have in the end very little relevance and impact to most businesses. Which doesn't mean it's not interesting, though.
- Practicality 10y ago
  Ironically, big-O describes things that are very easy to understand, in a notation that looks complicated. If you have a lot of experience, you probably already understand the concepts. The notation just gives a clear way to describe them: https://rob-bell.net/2009/06/a-beginners-guide-to-big-o-notation/ https://rob-bell.net/2009/06/a-beginners-guide-to-big-o-nota...,
  - chris11 10y ago
    True, but studying the theory gives a better intuition for big-O. And theory is helpful for some of the edge cases that can be more complicated. For instance, I wouldn't want to try to determine the run-time of a recursive algorithm with just the info in that article.
    - Practicality 10y ago
      Indeed, and if you did learn these things through experience, as I supposed, then you probably did so by writing something O(2^n) and suffering when you had to process >100,000 records. (Why does it take 100 ms for 10,000 records and 50 minutes for 100,000? ... hmm) Learning these concepts through the theory is definitely more efficient.
- jredwards 10y ago
  I have no degree in CS and I see these terms regularly. So I google them and read about them.
  - mattmanser 10y ago
    You don't know what you don't know. The point of a book like this is that some who knows what you don't know from being asked questions about things he didn't know by people who did know, he now knows what you don't know and can tell you what you need to know. The only knowledge you have now is of known unknowns without knowing anything at all about the unknowns unknowns. Know what I mean?
    - steve_g 10y ago
      You should have ended with "You know?"
    - retro64 10y ago
      I realize you are joking, but this is why I was in frantic mode in my early years. I do not have a degree in CS, so I had no idea what I was missing. Consequently I read up on everything. I still have a bookshelf filled with books on algorithms, "gotchas", Gang of Four wisdom, database design, you name it. I was forced to learn coding on the side and still have the habit today. I always have a side project going (which has fueled my career, but has also unfortunately cost me my marriage). I now have a son going through the proper steps of receiving a degree, and I have book to supplement him for every class (except for the higher math).
  - AMHOL 10y ago
    https://www.youtube.com/watch?v=QnZ0Y4rvz6E&feature=youtu.be&t=196 https://www.youtube.com/watch?v=QnZ0Y4rvz6E&feature=youtu.be...
  - manifestsilence 10y ago
    Exactly. Music major here. I spent a lot of time on Wikipedia, the programming sub-Reddits, and now on here. Making the code run is one thing, but knowing how to communicate with other programmers is important. Speaking the language around programming rather than just the programming languages themselves.
- gthtjtkt 10y ago
  Just throwing my anecdote in the ring: I work with a small team (4 devs) in at a non-tech company. The other devs all have 10+ years experience and none even know what SOLID is. I've never asked, but I'm guessing they don't know about any of the other things you mentioned either. There's an ocean of small/medium businesses who just need to get shit done and don't need it optimized so it can scale to serve 7 billion people every day while running on a 1997 microwave. HN seems to overlook that market entirely. Not hip/trendy enough, I suppose. Consultants are billing $250/hr just to write CRUD apps or reports, and they're completely booked.
  - DanHulton 10y ago
    I mean... which consultants? In which industry? And who else works in that industry? And do you have phone numbers? Just... asking. You know, for reasons.
    - gthtjtkt 10y ago
      Legal industry, in a branch of the law that's very high volume. We were paying a consultant $175/hr just to create basic SSRS reports until I learned to do it. I'm sure plenty of other firms are still hiring outside devs at exorbitant rates. And when I explain what I do (mostly automating clerical or data entry/retrieval processes) to friends in other fields, a lot of them have said "Wow, we could use a lot of that at our company. We do X and Y and Z over and over and it's a huge waste of time." Small companies often force highly-skilled workers to complete their own repetitive clerical tasks, and medium companies seem to hire teams of $10/hr drones. They never think "At what point is this worth automating?" or they don't know where to look for a dev who can do it for them. I think the small/medium business CRUD app market is extremely neglected because it's not as glamorous as machine learning or whatever else all the MIT grads are doing these days.
frobozz 10y ago
I disagree. The things that come up every day in practical, real-world professional software development, such as design patterns and SOLID are the things that professional autodidacts normally have plenty of experience in and knowledge of. The things that they have missed by not taking a Computer Science degree are precisely those things that don't tend to come up, such as big-O and the behaviour of various sorting algorithms. Anyway, here are two paragraphs on the linked page that you might like to see: "More than just theory, this book covers many practical areas of the industry as well, such as: Database design, SOLID, How a compiler works, sorting and searching algorithms, Big-O notation, Lambda Calculus, TDD and BDD." "One of the more subjective parts of the book, but I was asked by many people to write about these things. Specifically: SOLID, structural design, TDD, BDD, and design patterns."
deleted 10y ago
[deleted]
sailfast 10y ago
I don't have a CS degree, and while I know not to write ten nested loops it's nice to know the actual reasons behind why it's a problem. Understanding the core principles allows for a deeper understanding of what you're doing, and as a result might lead to some novel use of something. Not saying novel use or innovative stuff requires a CS degree, merely that improved understanding of the basics of computing will likely improve the way you fully consider engineering problems. This one's definitely on my reading list for that reason (also MIT / Stanford open courses on the topic of algorithms, etc are super helpful for this kind of background)
- kamaal 10y ago
  Any body who spends any amount of decent time with a problem, eventually know hows to optimize it. This isn't just with software, its with every task on earth. Humans have an in built ability to think about saving the effort required to achieve any task X.
chris11 10y ago
Do you think that your intuition for not doing something stupid came from studying the theoretical side of cs? Sure, you should be able to get a good idea of the runtime of code without spending much time looking at it, but I'd say personally that spending a couple semesters in classes that specifically covered big-o really helped my intuition. It just seems to me that not doing stupid shit can really depend on your intuitive grasp of theoretical cs. For instance, trying to find the optimal solution to an np problem might be a really bad idea, depending on the instance. But recognizing np problems doesn't really explicitly come up that often outside of theoretical cs.
marcosdumay 10y ago
> Neither have I been in a situation where big-o was relevant beyond the basic concept of not doing obviously stupid shit. How do you know you are doing stupid shit if you don't know about complexity and don't know your algorithms? Really, I do work on CRUD applications from time to time, and I often have to select algorithms based on complexity. Yeah, didn't have to implement one of them for ages¹, but I do have to tell coworkers things like "here you use a set", "here you use a list", "this sorting algorithm isn't stable", or "nah, just use brute force and get done" once in a while. 1 - Or, better, did implement a B-tree for a side project just a couple of months ago. Ended up just throwing it away, but I didn't know I wouldn't use it at the beginning.
- kchoudhu 10y ago
  I have libraries that make sure I don't do stupid shit.
  - kevhito 10y ago
    And my students have calculators so there is no need for them to know basic arithmetic.
    - collyw 10y ago
      My friend is a Maths teacher and can barely do mental arithmetic.
  - ThePawnBreak 10y ago
    That's the point, there is no magic library that can do this for you. For example, let's say you're writing Python and have a list of receipt numbers. When you get a new receipt, you want to check if it's already in the list, so you do the pythonic thing: "if receipt_nr in receipts", assuming that the standard implementation of this operation in the library is efficient. The problem is, a set would be a lot more efficient here, but the standard library doesn't know you'll be checking if a number is in the list many times, so it cannot use the appropriate data structure. So, in a way, the time and space complexity of each operation is part of the interface: maybe you don't really need to know how the internals are implemented, but at the very least you need to know the time and space complexity of the data structures you're using, and how to analyse the complexity of your code.
lanna 10y ago
http://www.joelonsoftware.com/articles/fog0000000319.html http://www.joelonsoftware.com/articles/fog0000000319.html
- philippeback 10y ago
  Ah, these articles are worth their weight in gold. Not related directly but from the good old days: The Ars Digita Systems Journal. http://www.eveandersson.com/arsdigita/asj/ http://www.eveandersson.com/arsdigita/asj/
kabdib 10y ago
These things come up regularly. Well, bubble sort is usually the punch-line to a geeky joke. But I've spent an unreasonable amount of time on data structures that fell apart at scale because of O(N) issues. Had to look up SOLID. Makes sense, follows the principles I've soaked up from books and a couple O-O courses. That acronym was apparently invented 20 years after I dropped out of college :-) Just keep learning. No drama. Just improve.
- qwertyuiop924 10y ago
  Yeah, and most of SOLID are just good ideas in general in software design, regardless of whether you're using OO. Write objects/programs/functions/libraries/interfaces that do one thing. Depend on an interface, not an implementation. That's the S and the D. L becomes irrelevent outside OO, and the sorts of things you would do with L you can do by instead loading a different library for D, or passing in the correct implementation for the situation, in a manner akin to DI. I is really just a more specific restatement of S, and O falls out of D easily, so long as you design your functions and libraries well. So in short, the idea of SOLID is to write units that have a single, small responsibility, split large units into smaller ones, make the interface abstracted from the implementation, and ensure that it is easy to write alternate implementations of a given interface as necessary. Those aren't OO ideas, those are just good design ideas.
qwertyuiop924 10y ago
The problem with design patterns and SOLID is that they're sometimes followed in a cargo-cult like manner. You don't necessarily get good code just following a set of instructions. You have to apply common sense, and know the tradeoffs of various approaches. Experience is the most important think to have, and it's something I lack, admittedly. CS is no substitute for that, but it's still an important part of getting it. It gives you a set of tools and a lexicon for understanding what's going on, and understanding some kinds of tradeoffs. As somebody who is just trying to figure all this stuff out, this is invaluable.
- RealityVoid 10y ago
  Experience is good, but I find some people have a "knack"... they intuitively understand when something is good and when not. How do you instill that? Priming from good logical and mathematical education help. Nudges to think for yourself and thins of the reason things are done a certain way sort of help. What more?
  - qwertyuiop924 10y ago
    That's actually kind of what I was trying to say... CS is no substitute for experience, but it helps.
  - ryandrake 10y ago
    Lots of practice and experience. Calling it a "knack" kind of downplays the years (decades) of study, work, and effort people put into refining their craft. You could also say Michael Phelps has a "knack" for swimming, but he also did nothing but workout, train, practice and compete for years.
    - qwertyuiop924 10y ago
      I keep trying to explain this to my non-programmer friends: No, I'm not some genius, I read lots of information, and worked hard to get to where I was, and from a programming perspective, I'm barely competant and know just enough to be dangerous. Yes, you could probably do it too, although the difficulty varies depending on how well you can handle the kind of abstractions and logic you'll be dealing with.
wpietri 10y ago
Your basic complaint here seems to be, "I am not in the audience for this book. I don't like what it covers." Maybe the problem isn't the book, but your expectation that a book that isn't for you should cover what you want, not what it's readers want. As a person who has been programming for a long time without a CS degree, my guess to why it doesn't have "best practices, design patterns and concepts like SOLID" is because working programmers without CS degrees know that stuff already. I sure do. Things like "best practices" and "design patterns" are distillations of experience. (And I'll note that he explicitly mentions covering SOLID, so maybe double-check your complaints before posting them.) The parts easiest for to miss, though, are the most theoretical ones. I had an intuitive grasp of algorithmic complexity from my teens, but going back and learning big-O notation was helpful in talking with theory-oriented approaches. I still don't really get lambda calculus because I've never had a practical problem where learning it would help me ship things. I wouldn't mind learning it, but it's just never gotten to the top of the to-read pile. I love the idea of a book like this because it strips out the 90% of a CS curriculum that I know and gives me only the pieces that I don't.
EliRivers 10y ago
"I've never found myself in a situation where anyone would discuss bouble sort vs merge sort. Neither have I been in a situation where big-o was relevant..." How about in job interviews? Obviously never on the actual job, but how about interviews? They ask all sorts of crazy crap. I suspect because they've got no idea what to ask.
- softawre 10y ago
  There are many software engineering jobs where Big-O is relevant.
  - collyw 10y ago
    And many many more where it isn't. My current work, the problem isn't the algorithms that make the thing run slowly, its because the people who wrote it don't know how to use Django efficiently. Lots of loops in the application making database calls each time (our main page is making over 1000 database calls). A bit more thought in the database design, knowing a bit more about how Django's ORM works and you could do all that work in the database in less than 10 calls and make it a lot faster. A couple of extra database indexes in the right places, and a bit of caching and it should run even faster. Thats the sort of knowledge that is relevant to (most of) our jobs, not big-o.
    - IMTDb 10y ago
      "Lots of loops making database calls each time" improved by "a bit more thought in the design" and "a bit of caching" sounds an awful lot like Big O analysis, and algorithmic optimisation even if it is on top on Django ORM.
      - lucasnemeth 10y ago
        Sometimes only. big O cuts all the constants and they are really important in actual software development. A lot of actual work involve improving the speed from a 10N to a 2N, it is a big difference for the costumer, but they are all O(N).
jacobsenscott 10y ago
I have a CS degree, and while nobody sits around talking about data structures and complexity that's not the point. It gives you a foundation of knowledge that you automatically and subconsciously apply to every job you do. A CS degree prevent you from making a lot of obvious (if you have a CS degree) and costly mistakes. It sort of gives you a crystal ball. You can see that some code isn't going to work when a db table gets to 100,000 records, or that some code is making the wrong space/time tradeoff, or that some code is using the wrong data structure from the standard library. When your performance monitoring tool is telling you something is slow or leaking memory you have the foundational knowledge to understand why and fix it, rather than spending money on 10 more dynos or whatever. Computers are so fast and cheap today a lot of this doesn't matter most of the time. The naive solution does just fine. But when the core dump hits the fan you better have one or two CS grads on staff.
- eksemplar 10y ago
  The thing is though that you don't really deal with this in your day to day life, and when you do, even with a few CS candidates on staff, you're going to hire a consultant with a Ph.D. in the field. Of course I may be environmentally damaged from never having worked with someone who was self taught.
  - jacobsenscott 10y ago
    I deal with this stuff regularly, but not daily. I'm sort of the go to guy on the team when things start to feel CS'y. It isn't PhD level stuff.
  - schrodinger 10y ago
    I don't think that's entirely true. It comes up pretty often. You may not be doing formal proofs but it's helpful to have a thorough understanding as it helps guide intuition around scaling your product (e.g. how a database query will scale with more users). It should influence your design early on rather than be something requiring a PHD consultant later on
- emodendroket 10y ago
philippeback 10y ago
When you deal with large data sets (e.g. Hadoop/Spark...), BigO starts to hit badly. Dynamic Programming also requires you to have a clue about it. See https://www.youtube.com/watch?v=OQ5jsbhAv_M https://www.youtube.com/watch?v=OQ5jsbhAv_M for some cool explanations.
Periodic 10y ago
What I find most illuminating about the deep software theory is it helps me understand why things are best practices. There are a lot of things that are good to do, but understanding deeply how the compiler things and how the languages are designed gives me insight into why we choose to do the things we do. The best example is taking a few options someone has for their function interfaces and reframing it in terms of type algebras which helps expose where it's overly complicated. The two best examples I have are making IO and mutations of input explicit and localized in single a location so the user doesn't have to guess which functions are changing things and which ones aren't. Once you have a good framework for describing these abstract boundaries a lot of other principles of design fall out from keeping it simple and readable.
ryandrake 10y ago
There are 1. "I get it to compile" programmers, 2. "I get it to work" programmers, and 3. "I make it great" programmers. A solid computer science foundation, knowledge of the literature, and experience can (but not necessarily will) get you from 2 to 3. Sadly, I've encountered quite a few professional programmers, complete with CS degrees, who year after year barely scrape by at 1, so it's not a given.
- chadclan 10y ago
  Preach it. This is EXACTLY my experience. CS degree or not a person's proficiency depends on that person. One of the biggest hurdles I personally face is that so many programmers just don't care about #3. It's often not a competency issue, it's an apathy issue.
mbostleman 10y ago
Then you've apparently never been in a technical interview with ALOT of companies.
codingdave 10y ago
"beyond the basic concept of not doing obviously stupid shit." Isn't that exactly the point? Based on one's knowledge, something that is obviously stupid to you could be a completely new concept to someone without that same knowledge or experience. Describing anything as "obviously stupid shit" is exactly the kind of thing that makes new self-taught programmers afraid to engage with others. It is better to give people a break, help them learn, and give them a positive environment in which to do so. This book sure seems like a good step in that direction, whether or not its topic comes up in everyday conversation.
iandanforth 10y ago
Here's another perspective. Let's say the company you joined has a culture that is big on sports, specifically American football. A lot of the people on the team care about the sport, make jokes about it, and make passing references to the current events in the game. If you're the kind of person who cares about fitting in, you might just read up on the game and perhaps browse the sports page headlines so the comments and jokes don't go totally over your head. You know when to laugh. This type of book can help with the cultural roadblocks non CS degree wielding programmers may have. There are many cultural code words that CS degree holders use and being up on those can make an "impostor's" life easier.
- vonmoltke 10y ago
  > Here's another perspective. Let's say the company you joined has a culture that is big on sports, specifically American football. A lot of the people on the team care about the sport, make jokes about it, and make passing references to the current events in the game. If you're the kind of person who cares about fitting in, you might just read up on the game and perhaps browse the sports page headlines so the comments and jokes don't go totally over your head. You know when to laugh. Personally, I wouldn't want to work at a place where I felt like I needed to "fit in".
  - magic_beans 10y ago
    I work in fashion because it was the best job I could get before I ran out of money. I have zero interest in fashion. I don't fit in with my colleagues because I have zero interest in fashion. It is not very fun to work in an environment where I have so little in common with my colleagues, but I didn't have much of a choice in the matter. Alls I'm saying is... sometimes the circumstances of life dictate where we find ourselves employed.
kamaal 10y ago
>>I have a degree in CS and I've never found myself in a situation where anyone would discuss bouble sort vs merge sort. Yeah everyone knows stuff like that isn't helpful in your everyday work. But that is what they ask you in the interviews. The tragedy is you have to do this ritual every now and then just to get a job, and that knowledge is largely useless everywhere else.
munificent 10y ago
> the basic concept of not doing obviously stupid shit I find that the more CS fundamentals I learn, the higher the bar on my definition of "obviously stupid shit" becomes. It turns out lots of things become obviously stupid as you learn more about algorithm analysis, more about how compilers work, more about how CPU caching effects performance, etc.
noelwelsh 10y ago
Just got back from a meeting where we discussed on-disk data structures, in-memory data structures, and design of a query language for a time-series database with the goal of achieving <1s response time for queries on TBs of data. For comparison I worked on a project some time ago (arriving well after the original developers) that tried to store an event log in a relational database and ran into severe performance problems. Knowing a bit of theory sure helps avoid a lot of mistakes, and it's super interesting as well. There's lots of good stuff in the front-end and web dev space as well. I know enough about UX to understand there is a lot of depth there. If you understand functional programming you'll go a long way with React and friends (and perhaps be able to innovate in this area as well.) Not all of this is in the typical CS curriculum but that doesn't invalidate the usefulness of what is.
GFK_of_xmaspast 10y ago
Perhaps you just aren't taking/finding the more challenging jobs?
jna_sh 10y ago
It has chapters on those things, including a chapter specifically on SOLID.
jna_sh 10y ago
It has chapters on those things, including a chapter specifically on SOLID.
barrkel 10y ago
I work on a product that does reconciliation for finance: that basically means comparing two lists. Each list could have a hundred items, or ten million. When there's that much variance in n, it matters what the O(n) is for any code that has to touch this data. Worst-case list comparison for two lists of length m and n respectively, is O(mn). For 10 million in each list, that's a bigger number than you can reasonably expect to iterate through using brute force. So brute force won't do: it is imperative that you understand how everything that touches all the data scales. "Not doing obviously stupid shit" means understanding the implementation of data structures and how they scale, understanding how nested loops multiply runtime, how recursion levels multiply runtime. It turns out there's actually a 1:1 correspondence between knowing big-Oh and not doing obviously stupid shit. That's why it's one of our in-person coding questions: after the candidate has written up a solution to the problem, they need to be able to analyze what they wrote and understand how it scales to different n. If they don't have an intuitive understanding of the performance of code, the chances are they'll do obviously stupid shit. (Personally, I learned about big-Oh long before I went to college, and I believe it's probably the single most useful thing to learn in CS, right up there with compiler theory (my previous job was a compiler engineer, so I may be biased). With best practices / design patterns etc., it's extremely hard to substitute for experience; I see juniors misapplying software design concepts on a weekly basis.)

teekert 10y ago

I have no degree in CS and I see these terms (Big O, np vs p, etc) regularly, mostly here on HN. No idea what they mean, this books sounds great to me.

haylem 10y ago
> mostly here on HN Which may or may not be an accurate depiction (as we read personal accounts and thoughts of the commenters) of a quite marginal subset of real-life IT-professionals. I wouldn't worry too much about what's being said or not said on HN. There are great ideas and topics to be covered here for sure, but they're sprinkled on top of a giant cake made with 1-part self-loathing, 2-parts day-dreaming, and 1-part regular huff-and-puffing. It makes for good entertainment and procrastination. > No idea what they mean, this books sounds great to me That being said, not knowing Big-O while doing CS or IT work seems worrying. Sure, it's not absolutely necessary for most of the grunt work. But you should definitely have the same understanding of performance issues without knowing the fancy notation and terminology. Big-O is just a notation and a formalization of these concepts, and it helps with communication. I'd say it's still better to know it. So, indeed the book probably doesn't hurt.
- teekert 10y ago
  I'm just a biologist that switched to Python because Excel and Origin weren't dealing very well with my ever increasing pile of data (Typical data: Every row is cell in a Tissue sample, every column is a quantified parameter (size, marker intensity, ...) of that cell, typically I deal with 10s to 100s of tissues samples) Pandas is great, I spend my time turning DataFrames into histograms, scatter plots and ROC curves in Jupyter Notebooks. I have the feeling knowing Big-O is not very relevant. Still, learning new languages, new words and new abstractions is almost guaranteed to influence ones way of working and thinking at some level. So, indeed indeed the book probably doesn't hurt ;) Edit: Just glanced over the link in Practicality's comment about big-O and sure enough I think it may actually be useful as my ever increasing pile of data increases even further! I have to admit; as the parameters increase I find myself doing over night calculations more and more.
  - emodendroket 10y ago
    Asymptotic complexity comes up pretty frequently in bioinformatics contexts because the volumes of data can be huge.
    - vonmoltke 10y ago
      How does it change what you do, though? I did signal processing with massive data streams rather than bioinformatics, but I assume the situation is similar. The algorithms are what they are. They are complex mathematical equations or transformations that need to be run on data and are often optimized without being able to change their asymptotic complexity.
      - emodendroket 10y ago
        Skiena's Algorithm Design Manual mentions him being brought in as an algorithmic consultant to modify some genetics analysis software so that it'd actually finish but I don't really remember the details or know enough about the field to give you plausible examples.
        vonmoltke 10y ago
        I can see that; I did a lot of similar work with signal processing algorithms. None of what I did affected asymptotic complexity at all, though. The asymptotic complexity was tied to the algorithms chosen, and changing those was an issue of trading computational performance for system performance.
        deleted 10y ago
        [deleted]
        emodendroket 10y ago
        I pulled it up and found it; the problem involved modeling genome sequences as strings and finding possible substrings.
  - 10y ago
- lafay 10y ago
  This is the best description of HN I've ever read: > There are great ideas and topics to be covered here for sure, but they're sprinkled on top of a giant cake made with 1-part self-loathing, 2-parts day-dreaming, and 1-part regular huff-and-puffing.
- dineshp2 10y ago
  > I wouldn't worry too much about what's being said or not said on HN. There are great ideas and topics to be covered here for sure, but they're sprinkled on top of a giant cake made with 1-part self-loathing, 2-parts day-dreaming, and 1-part regular huff-and-puffing. I don't understand your argument regarding why you would not pay much attention to what is being said on HN. Could you explain?
  - blowski 10y ago
    Probably because there is a noisy minority who voice dogmatic opinions without understanding the constraints of the problem at hand. They are lilliputians, spouting wonderful ideas that collapse in the face of deadlines and budgets. For those of us that have to live in reality, they can be very annoying and disheartening, so it's essential to take their opinions with a fistful of salt.
    - haylem 10y ago
      That, yes. But also because a significant amount of even the day's top popular topics have in the end very little relevance and impact to most businesses. Which doesn't mean it's not interesting, though.
Practicality 10y ago
Ironically, big-O describes things that are very easy to understand, in a notation that looks complicated. If you have a lot of experience, you probably already understand the concepts. The notation just gives a clear way to describe them: https://rob-bell.net/2009/06/a-beginners-guide-to-big-o-notation/ https://rob-bell.net/2009/06/a-beginners-guide-to-big-o-nota...,
- chris11 10y ago
  True, but studying the theory gives a better intuition for big-O. And theory is helpful for some of the edge cases that can be more complicated. For instance, I wouldn't want to try to determine the run-time of a recursive algorithm with just the info in that article.
  - Practicality 10y ago
    Indeed, and if you did learn these things through experience, as I supposed, then you probably did so by writing something O(2^n) and suffering when you had to process >100,000 records. (Why does it take 100 ms for 10,000 records and 50 minutes for 100,000? ... hmm) Learning these concepts through the theory is definitely more efficient.
jredwards 10y ago
I have no degree in CS and I see these terms regularly. So I google them and read about them.
- mattmanser 10y ago
  You don't know what you don't know. The point of a book like this is that some who knows what you don't know from being asked questions about things he didn't know by people who did know, he now knows what you don't know and can tell you what you need to know. The only knowledge you have now is of known unknowns without knowing anything at all about the unknowns unknowns. Know what I mean?
  - steve_g 10y ago
    You should have ended with "You know?"
  - retro64 10y ago
    I realize you are joking, but this is why I was in frantic mode in my early years. I do not have a degree in CS, so I had no idea what I was missing. Consequently I read up on everything. I still have a bookshelf filled with books on algorithms, "gotchas", Gang of Four wisdom, database design, you name it. I was forced to learn coding on the side and still have the habit today. I always have a side project going (which has fueled my career, but has also unfortunately cost me my marriage). I now have a son going through the proper steps of receiving a degree, and I have book to supplement him for every class (except for the higher math).
- AMHOL 10y ago
  https://www.youtube.com/watch?v=QnZ0Y4rvz6E&feature=youtu.be&t=196 https://www.youtube.com/watch?v=QnZ0Y4rvz6E&feature=youtu.be...
- manifestsilence 10y ago
  Exactly. Music major here. I spent a lot of time on Wikipedia, the programming sub-Reddits, and now on here. Making the code run is one thing, but knowing how to communicate with other programmers is important. Speaking the language around programming rather than just the programming languages themselves.
gthtjtkt 10y ago
Just throwing my anecdote in the ring: I work with a small team (4 devs) in at a non-tech company. The other devs all have 10+ years experience and none even know what SOLID is. I've never asked, but I'm guessing they don't know about any of the other things you mentioned either. There's an ocean of small/medium businesses who just need to get shit done and don't need it optimized so it can scale to serve 7 billion people every day while running on a 1997 microwave. HN seems to overlook that market entirely. Not hip/trendy enough, I suppose. Consultants are billing $250/hr just to write CRUD apps or reports, and they're completely booked.
- DanHulton 10y ago
  I mean... which consultants? In which industry? And who else works in that industry? And do you have phone numbers? Just... asking. You know, for reasons.
  - gthtjtkt 10y ago
    Legal industry, in a branch of the law that's very high volume. We were paying a consultant $175/hr just to create basic SSRS reports until I learned to do it. I'm sure plenty of other firms are still hiring outside devs at exorbitant rates. And when I explain what I do (mostly automating clerical or data entry/retrieval processes) to friends in other fields, a lot of them have said "Wow, we could use a lot of that at our company. We do X and Y and Z over and over and it's a huge waste of time." Small companies often force highly-skilled workers to complete their own repetitive clerical tasks, and medium companies seem to hire teams of $10/hr drones. They never think "At what point is this worth automating?" or they don't know where to look for a dev who can do it for them. I think the small/medium business CRUD app market is extremely neglected because it's not as glamorous as machine learning or whatever else all the MIT grads are doing these days.

frobozz 10y ago

I disagree. The things that come up every day in practical, real-world professional software development, such as design patterns and SOLID are the things that professional autodidacts normally have plenty of experience in and knowledge of. The things that they have missed by not taking a Computer Science degree are precisely those things that don't tend to come up, such as big-O and the behaviour of various sorting algorithms. Anyway, here are two paragraphs on the linked page that you might like to see: "More than just theory, this book covers many practical areas of the industry as well, such as: Database design, SOLID, How a compiler works, sorting and searching algorithms, Big-O notation, Lambda Calculus, TDD and BDD." "One of the more subjective parts of the book, but I was asked by many people to write about these things. Specifically: SOLID, structural design, TDD, BDD, and design patterns."

deleted 10y ago

[deleted]

sailfast 10y ago

I don't have a CS degree, and while I know not to write ten nested loops it's nice to know the actual reasons behind why it's a problem. Understanding the core principles allows for a deeper understanding of what you're doing, and as a result might lead to some novel use of something. Not saying novel use or innovative stuff requires a CS degree, merely that improved understanding of the basics of computing will likely improve the way you fully consider engineering problems. This one's definitely on my reading list for that reason (also MIT / Stanford open courses on the topic of algorithms, etc are super helpful for this kind of background)

kamaal 10y ago
Any body who spends any amount of decent time with a problem, eventually know hows to optimize it. This isn't just with software, its with every task on earth. Humans have an in built ability to think about saving the effort required to achieve any task X.

chris11 10y ago

Do you think that your intuition for not doing something stupid came from studying the theoretical side of cs? Sure, you should be able to get a good idea of the runtime of code without spending much time looking at it, but I'd say personally that spending a couple semesters in classes that specifically covered big-o really helped my intuition. It just seems to me that not doing stupid shit can really depend on your intuitive grasp of theoretical cs. For instance, trying to find the optimal solution to an np problem might be a really bad idea, depending on the instance. But recognizing np problems doesn't really explicitly come up that often outside of theoretical cs.

marcosdumay 10y ago

> Neither have I been in a situation where big-o was relevant beyond the basic concept of not doing obviously stupid shit. How do you know you are doing stupid shit if you don't know about complexity and don't know your algorithms? Really, I do work on CRUD applications from time to time, and I often have to select algorithms based on complexity. Yeah, didn't have to implement one of them for ages¹, but I do have to tell coworkers things like "here you use a set", "here you use a list", "this sorting algorithm isn't stable", or "nah, just use brute force and get done" once in a while. 1 - Or, better, did implement a B-tree for a side project just a couple of months ago. Ended up just throwing it away, but I didn't know I wouldn't use it at the beginning.

kchoudhu 10y ago
I have libraries that make sure I don't do stupid shit.
- kevhito 10y ago
  And my students have calculators so there is no need for them to know basic arithmetic.
  - collyw 10y ago
    My friend is a Maths teacher and can barely do mental arithmetic.
- ThePawnBreak 10y ago
  That's the point, there is no magic library that can do this for you. For example, let's say you're writing Python and have a list of receipt numbers. When you get a new receipt, you want to check if it's already in the list, so you do the pythonic thing: "if receipt_nr in receipts", assuming that the standard implementation of this operation in the library is efficient. The problem is, a set would be a lot more efficient here, but the standard library doesn't know you'll be checking if a number is in the list many times, so it cannot use the appropriate data structure. So, in a way, the time and space complexity of each operation is part of the interface: maybe you don't really need to know how the internals are implemented, but at the very least you need to know the time and space complexity of the data structures you're using, and how to analyse the complexity of your code.

lanna 10y ago

http://www.joelonsoftware.com/articles/fog0000000319.html http://www.joelonsoftware.com/articles/fog0000000319.html

philippeback 10y ago
Ah, these articles are worth their weight in gold. Not related directly but from the good old days: The Ars Digita Systems Journal. http://www.eveandersson.com/arsdigita/asj/ http://www.eveandersson.com/arsdigita/asj/

kabdib 10y ago

These things come up regularly. Well, bubble sort is usually the punch-line to a geeky joke. But I've spent an unreasonable amount of time on data structures that fell apart at scale because of O(N) issues. Had to look up SOLID. Makes sense, follows the principles I've soaked up from books and a couple O-O courses. That acronym was apparently invented 20 years after I dropped out of college :-) Just keep learning. No drama. Just improve.

qwertyuiop924 10y ago
Yeah, and most of SOLID are just good ideas in general in software design, regardless of whether you're using OO. Write objects/programs/functions/libraries/interfaces that do one thing. Depend on an interface, not an implementation. That's the S and the D. L becomes irrelevent outside OO, and the sorts of things you would do with L you can do by instead loading a different library for D, or passing in the correct implementation for the situation, in a manner akin to DI. I is really just a more specific restatement of S, and O falls out of D easily, so long as you design your functions and libraries well. So in short, the idea of SOLID is to write units that have a single, small responsibility, split large units into smaller ones, make the interface abstracted from the implementation, and ensure that it is easy to write alternate implementations of a given interface as necessary. Those aren't OO ideas, those are just good design ideas.

qwertyuiop924 10y ago

The problem with design patterns and SOLID is that they're sometimes followed in a cargo-cult like manner. You don't necessarily get good code just following a set of instructions. You have to apply common sense, and know the tradeoffs of various approaches. Experience is the most important think to have, and it's something I lack, admittedly. CS is no substitute for that, but it's still an important part of getting it. It gives you a set of tools and a lexicon for understanding what's going on, and understanding some kinds of tradeoffs. As somebody who is just trying to figure all this stuff out, this is invaluable.

RealityVoid 10y ago
Experience is good, but I find some people have a "knack"... they intuitively understand when something is good and when not. How do you instill that? Priming from good logical and mathematical education help. Nudges to think for yourself and thins of the reason things are done a certain way sort of help. What more?
- qwertyuiop924 10y ago
  That's actually kind of what I was trying to say... CS is no substitute for experience, but it helps.
- ryandrake 10y ago
  Lots of practice and experience. Calling it a "knack" kind of downplays the years (decades) of study, work, and effort people put into refining their craft. You could also say Michael Phelps has a "knack" for swimming, but he also did nothing but workout, train, practice and compete for years.
  - qwertyuiop924 10y ago
    I keep trying to explain this to my non-programmer friends: No, I'm not some genius, I read lots of information, and worked hard to get to where I was, and from a programming perspective, I'm barely competant and know just enough to be dangerous. Yes, you could probably do it too, although the difficulty varies depending on how well you can handle the kind of abstractions and logic you'll be dealing with.

wpietri 10y ago

Your basic complaint here seems to be, "I am not in the audience for this book. I don't like what it covers." Maybe the problem isn't the book, but your expectation that a book that isn't for you should cover what you want, not what it's readers want. As a person who has been programming for a long time without a CS degree, my guess to why it doesn't have "best practices, design patterns and concepts like SOLID" is because working programmers without CS degrees know that stuff already. I sure do. Things like "best practices" and "design patterns" are distillations of experience. (And I'll note that he explicitly mentions covering SOLID, so maybe double-check your complaints before posting them.) The parts easiest for to miss, though, are the most theoretical ones. I had an intuitive grasp of algorithmic complexity from my teens, but going back and learning big-O notation was helpful in talking with theory-oriented approaches. I still don't really get lambda calculus because I've never had a practical problem where learning it would help me ship things. I wouldn't mind learning it, but it's just never gotten to the top of the to-read pile. I love the idea of a book like this because it strips out the 90% of a CS curriculum that I know and gives me only the pieces that I don't.

EliRivers 10y ago

"I've never found myself in a situation where anyone would discuss bouble sort vs merge sort. Neither have I been in a situation where big-o was relevant..." How about in job interviews? Obviously never on the actual job, but how about interviews? They ask all sorts of crazy crap. I suspect because they've got no idea what to ask.

softawre 10y ago
There are many software engineering jobs where Big-O is relevant.
- collyw 10y ago
  And many many more where it isn't. My current work, the problem isn't the algorithms that make the thing run slowly, its because the people who wrote it don't know how to use Django efficiently. Lots of loops in the application making database calls each time (our main page is making over 1000 database calls). A bit more thought in the database design, knowing a bit more about how Django's ORM works and you could do all that work in the database in less than 10 calls and make it a lot faster. A couple of extra database indexes in the right places, and a bit of caching and it should run even faster. Thats the sort of knowledge that is relevant to (most of) our jobs, not big-o.
  - IMTDb 10y ago
    "Lots of loops making database calls each time" improved by "a bit more thought in the design" and "a bit of caching" sounds an awful lot like Big O analysis, and algorithmic optimisation even if it is on top on Django ORM.
    - lucasnemeth 10y ago
      Sometimes only. big O cuts all the constants and they are really important in actual software development. A lot of actual work involve improving the speed from a 10N to a 2N, it is a big difference for the costumer, but they are all O(N).

jacobsenscott 10y ago

I have a CS degree, and while nobody sits around talking about data structures and complexity that's not the point. It gives you a foundation of knowledge that you automatically and subconsciously apply to every job you do. A CS degree prevent you from making a lot of obvious (if you have a CS degree) and costly mistakes. It sort of gives you a crystal ball. You can see that some code isn't going to work when a db table gets to 100,000 records, or that some code is making the wrong space/time tradeoff, or that some code is using the wrong data structure from the standard library. When your performance monitoring tool is telling you something is slow or leaking memory you have the foundational knowledge to understand why and fix it, rather than spending money on 10 more dynos or whatever. Computers are so fast and cheap today a lot of this doesn't matter most of the time. The naive solution does just fine. But when the core dump hits the fan you better have one or two CS grads on staff.

eksemplar 10y ago
The thing is though that you don't really deal with this in your day to day life, and when you do, even with a few CS candidates on staff, you're going to hire a consultant with a Ph.D. in the field. Of course I may be environmentally damaged from never having worked with someone who was self taught.
- jacobsenscott 10y ago
  I deal with this stuff regularly, but not daily. I'm sort of the go to guy on the team when things start to feel CS'y. It isn't PhD level stuff.
- schrodinger 10y ago
  I don't think that's entirely true. It comes up pretty often. You may not be doing formal proofs but it's helpful to have a thorough understanding as it helps guide intuition around scaling your product (e.g. how a database query will scale with more users). It should influence your design early on rather than be something requiring a PHD consultant later on
emodendroket 10y ago

philippeback 10y ago

When you deal with large data sets (e.g. Hadoop/Spark...), BigO starts to hit badly. Dynamic Programming also requires you to have a clue about it. See https://www.youtube.com/watch?v=OQ5jsbhAv_M https://www.youtube.com/watch?v=OQ5jsbhAv_M for some cool explanations.

Periodic 10y ago

What I find most illuminating about the deep software theory is it helps me understand why things are best practices. There are a lot of things that are good to do, but understanding deeply how the compiler things and how the languages are designed gives me insight into why we choose to do the things we do. The best example is taking a few options someone has for their function interfaces and reframing it in terms of type algebras which helps expose where it's overly complicated. The two best examples I have are making IO and mutations of input explicit and localized in single a location so the user doesn't have to guess which functions are changing things and which ones aren't. Once you have a good framework for describing these abstract boundaries a lot of other principles of design fall out from keeping it simple and readable.

ryandrake 10y ago

There are 1. "I get it to compile" programmers, 2. "I get it to work" programmers, and 3. "I make it great" programmers. A solid computer science foundation, knowledge of the literature, and experience can (but not necessarily will) get you from 2 to 3. Sadly, I've encountered quite a few professional programmers, complete with CS degrees, who year after year barely scrape by at 1, so it's not a given.

chadclan 10y ago
Preach it. This is EXACTLY my experience. CS degree or not a person's proficiency depends on that person. One of the biggest hurdles I personally face is that so many programmers just don't care about #3. It's often not a competency issue, it's an apathy issue.

mbostleman 10y ago

Then you've apparently never been in a technical interview with ALOT of companies.

codingdave 10y ago

"beyond the basic concept of not doing obviously stupid shit." Isn't that exactly the point? Based on one's knowledge, something that is obviously stupid to you could be a completely new concept to someone without that same knowledge or experience. Describing anything as "obviously stupid shit" is exactly the kind of thing that makes new self-taught programmers afraid to engage with others. It is better to give people a break, help them learn, and give them a positive environment in which to do so. This book sure seems like a good step in that direction, whether or not its topic comes up in everyday conversation.

iandanforth 10y ago

Here's another perspective. Let's say the company you joined has a culture that is big on sports, specifically American football. A lot of the people on the team care about the sport, make jokes about it, and make passing references to the current events in the game. If you're the kind of person who cares about fitting in, you might just read up on the game and perhaps browse the sports page headlines so the comments and jokes don't go totally over your head. You know when to laugh. This type of book can help with the cultural roadblocks non CS degree wielding programmers may have. There are many cultural code words that CS degree holders use and being up on those can make an "impostor's" life easier.

vonmoltke 10y ago
> Here's another perspective. Let's say the company you joined has a culture that is big on sports, specifically American football. A lot of the people on the team care about the sport, make jokes about it, and make passing references to the current events in the game. If you're the kind of person who cares about fitting in, you might just read up on the game and perhaps browse the sports page headlines so the comments and jokes don't go totally over your head. You know when to laugh. Personally, I wouldn't want to work at a place where I felt like I needed to "fit in".
- magic_beans 10y ago
  I work in fashion because it was the best job I could get before I ran out of money. I have zero interest in fashion. I don't fit in with my colleagues because I have zero interest in fashion. It is not very fun to work in an environment where I have so little in common with my colleagues, but I didn't have much of a choice in the matter. Alls I'm saying is... sometimes the circumstances of life dictate where we find ourselves employed.

kamaal 10y ago

>>I have a degree in CS and I've never found myself in a situation where anyone would discuss bouble sort vs merge sort. Yeah everyone knows stuff like that isn't helpful in your everyday work. But that is what they ask you in the interviews. The tragedy is you have to do this ritual every now and then just to get a job, and that knowledge is largely useless everywhere else.

munificent 10y ago

> the basic concept of not doing obviously stupid shit I find that the more CS fundamentals I learn, the higher the bar on my definition of "obviously stupid shit" becomes. It turns out lots of things become obviously stupid as you learn more about algorithm analysis, more about how compilers work, more about how CPU caching effects performance, etc.

noelwelsh 10y ago

Just got back from a meeting where we discussed on-disk data structures, in-memory data structures, and design of a query language for a time-series database with the goal of achieving <1s response time for queries on TBs of data. For comparison I worked on a project some time ago (arriving well after the original developers) that tried to store an event log in a relational database and ran into severe performance problems. Knowing a bit of theory sure helps avoid a lot of mistakes, and it's super interesting as well. There's lots of good stuff in the front-end and web dev space as well. I know enough about UX to understand there is a lot of depth there. If you understand functional programming you'll go a long way with React and friends (and perhaps be able to innovate in this area as well.) Not all of this is in the typical CS curriculum but that doesn't invalidate the usefulness of what is.

GFK_of_xmaspast 10y ago

Perhaps you just aren't taking/finding the more challenging jobs?

jna_sh 10y ago

It has chapters on those things, including a chapter specifically on SOLID.

jna_sh 10y ago

It has chapters on those things, including a chapter specifically on SOLID.

barrkel 10y ago

I work on a product that does reconciliation for finance: that basically means comparing two lists. Each list could have a hundred items, or ten million. When there's that much variance in n, it matters what the O(n) is for any code that has to touch this data. Worst-case list comparison for two lists of length m and n respectively, is O(mn). For 10 million in each list, that's a bigger number than you can reasonably expect to iterate through using brute force. So brute force won't do: it is imperative that you understand how everything that touches all the data scales. "Not doing obviously stupid shit" means understanding the implementation of data structures and how they scale, understanding how nested loops multiply runtime, how recursion levels multiply runtime. It turns out there's actually a 1:1 correspondence between knowing big-Oh and not doing obviously stupid shit. That's why it's one of our in-person coding questions: after the candidate has written up a solution to the problem, they need to be able to analyze what they wrote and understand how it scales to different n. If they don't have an intuitive understanding of the performance of code, the chances are they'll do obviously stupid shit. (Personally, I learned about big-Oh long before I went to college, and I believe it's probably the single most useful thing to learn in CS, right up there with compiler theory (my previous job was a compiler engineer, so I may be biased). With best practices / design patterns etc., it's extremely hard to substitute for experience; I see juniors misapplying software design concepts on a weekly basis.)