Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Imposter's Handbook

impostershandbook.com

Post reply on HN
Print view View original

91–100 of 237 posts

Re: The Imposter's Handbook

#91

Post by kchoudhu »

ThePawnBreak wrote: post #55
kchoudhu wrote: post #46

Earlier quoted context omitted.

I have libraries that make sure I don't do stupid shit.

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 effi…

Next question: how often would this kind of malprogramming actually lead to deal-breaking performance issues in a project? After a decade in the industry, countless projects delivered and much shit code witnessed, I can empirically answer this question, and the the answer is -- even at places that are known for their technical excellence -- not often.

Look, I'm not advocating illiterate programming, nor am I a proponent of unprofessional work. I took my share of CS classes, and I can talk about algorithms and how to analyze them. The number of times I have had to do so on the job, however, can be counted on my bodily digits, without taking off my shoes.

This is probably not an original observation, but a big part of why these unproductive conversations keep on happening here has to do with how young HN demographic skews. When the biggest achievement in your life is getting that new degree you spent $BIGNUMBER $$/years on, you're going to want to belittle workmanlike programmers who don't measure up to your own standards. It takes a while for people to move on and grow up.

Re: The Imposter's Handbook

#92

Post by collyw »

marcosdumay wrote: post #41
eksemplar wrote: post #13

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 cove…

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

I learned big-o around 15 years ago, and have never used it professionally. (I forgot what it meant when I had a phone interview with Google).

I do know that some algorithms are more efficient than others, and some sorts depend on whether you expect the list to be random, sorted or partially sorted. If I find myself in a situation needing to choose between libraries. I would guess that half an hours reading would refresh what I need to know.

Re: The Imposter's Handbook

#93

Post by lorenzhs »

drak3 wrote: post #32

The excerpt on the Boolean Satisfiability Problem reads > The basic concept that people have figured out, so far, is that a number of NP-complete problems can likely be solved if we crack the Boolean Satisfiability problem. And > If NP-Complete problems get resolved, it is likely (though nobody knows for sure) that we'll crack every NP-Problem Isn't the definition of a NP-Complete problem exactly that it is in NP _an…

Yes, you're absolutely right. The other excerpt paragraph right next to it is correct but terribly misleading:

> That "undecidable" part is what makes this problem [the Halting Problem] NP-hard.

I mean, that's true - but it's very misleading. The most common context in which NP-hardness is discussed is when talking about NP-complete problems - those that are NP-hard and in NP. The way you go about showing that a problem X is NP-complete is showing that it's in NP (most of the time, this is the easy bit) and then showing that it's at least as hard as some NP-complete problem Y. This is usually done by transforming an arbitrary instance of Y into an instance of X in (deterministic) polynomial time, and showing that the X-instance is satisfiable iff () the Y-instance is.

Then there are problems for which NP-hardness has been shown but it's unclear whether they're in NP. Those are often of a continuous nature. I think deciding whether a level of Super Mario World is doable falls into this category.

Re: The Imposter's Handbook

#94

Post by softawre »

hibikir wrote: post #79
sotojuan wrote: post #30

Earlier quoted context omitted.

That's the case for some elite finance institutions, but does it happen with programming?

Oh yes. While this might not be a hard, publicly facing requirement, I have seen resume review processes that took into account things like school or whether you have worked for a hip, big name tech employer. If your sensible resume with 10 years of experience doing work on an in demand field doesn't even get a recruiter call back, it might be because you did it for an enterprise company the recruiting team doesn't r…

Sounds like a good movie in the making (Coderball?)

Re: The Imposter's Handbook

#96

Post by collyw »

softawre wrote: post #90
EliRivers wrote: post #71

Earlier quoted context omitted.

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

There are many software engineering jobs where Big-O is relevant.

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.

Re: The Imposter's Handbook

#97

Post by jacobsenscott »

eksemplar wrote: post #13

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 cove…

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.

Re: The Imposter's Handbook

#98

Post by cmrdporcupine »

nostrebored wrote: post #86
cmrdporcupine wrote: post #34

Earlier quoted context omitted.

Having a CS degree gets you through a Google-style interview -- where they will hammer you for hours on your ability to recall the skills you needed to pass your algorithms classes in university, and grade you almost solely on that. And then you will start working there and almost never use those skills again, because you'll be using a vast library of datastructures and algorithms in the language of your choice, and…

Implementation is only a portion of what's important in an interview. The thing you will not get anywhere without is a knowledge of what algorithms exist and when to use them.

You will not get through a Google style interview knowing what algorithms exist. You will be expected to implement them. On a whiteboard. Almost perfectly. Without access to a computer.

Re: The Imposter's Handbook

#99

Post by teekert »

haylem wrote: post #31
teekert wrote: post #20

Earlier quoted context omitted.

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.

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

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.

Re: The Imposter's Handbook

#100

Post by kchoudhu »

riskable wrote: post #78
ThePawnBreak wrote: post #55

Earlier quoted context omitted.

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 effi…

What's funny about your example is that using a set in that situation would be an example of premature optimization. If your entire list of receipts fits into memory users won't notice a difference between a list and a set. Also, if you used a list in Python (or other similar dynamic languages) swapping a list out for a set is a trivial operation... receipts = [] # ...becomes: receipts = set() ...and it would require…

Not to mention that most of the kids today would have stowed their entire population of receipts in whatever the datastore flavor-of-the-week is. At that point, the lookup would effectively be a SELECT -- which the DBMS would optimize away for you.
Post reply on HN