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

121–130 of 237 posts

Re: The Imposter's Handbook

#121

Post by pjc50 »

kchoudhu wrote: post #91
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…

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

> how often would this kind of malprogramming actually lead to deal-breaking performance issues in a project?

Depends very much on your projects. Web developers generally have it easy, as it's cheap to add more servers and free to burn CPU in the browser. Even so you can get into trouble with anything that's O(N) in the number of users. I do wonder how much use of nosql is from people who think SQL is slow because they've not got their indexes set up properly.

Game developers, of course, live and breathe performance. As do embedded and similar low-level environments. Or people working with this trendy "big" data.

Re: The Imposter's Handbook

#122

Post by buckbova »

MehdiHK wrote: post #19
Cozumel wrote: post #3

Can anyone personally recommend it? It looks like a good investment!

Bought it. Pretty basic stuffs: - Didn't learn anything new from Linux chapter. - Data Structures and Algorithms chapter is too basic. There is not even any implementation provided. I thought it didn't offer anything more than you could find on Wikipedia if you add some illustration done with Paper by 53 app. I'd recommend "Grokking Algorithms" by Aditya Bhargava for this topic if you want illustrated explanations wi…

If videos are your thing this set of data structures videos is pretty good.

https://www.youtube.com/playlist?list=PL2_aWCzGMAwI3W_JlcBbt...

Good database references here, guaranteed to learn something new.

https://github.com/rxin/db-readings

Re: The Imposter's Handbook

#123

Post by ryandrake »

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…

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.

Re: The Imposter's Handbook

#124

Post by pjc50 »

scott_s wrote: post #87
riskable wrote: post #78

Earlier quoted context omitted.

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…

> If your entire list of receipts fits into memory users won't notice a difference between a list and a set. If you had said "small enough", I would agree, but linear walks of data that can fit in memory can easily be noticed by users, for large enough lists. (Very large lists can fit in memory.) But, at a higher level, yes, this is always true when people talk about performance: make sure what you're optimizing actu…

Earlier this month I was looking at the question of "why does it take 160ms to scan a list of just 60,000 items?

The answer turned out to be "because they're not adjacent and on this embedded system every single cache miss costs you hundreds of nanoseconds".

I strongly agree that, like woodworkers, performance improvers should measure before they take out the power tools.

Re: The Imposter's Handbook

#125

Post by brians »

The example text about the y combinator looks mistaken to me. It says Y can "find" a fixpoint, and sketches an example of a fixpoint in a numerical function. It implies Y is doing something like convergence.

But that's not what Y is at all. It's called the fix point combinator, yes, but with the assumption you're going to use it in some curried lazy evaluation scheme with higher order functions.

All this on ycombinator.com, too!

Re: The Imposter's Handbook

#126

Post by emodendroket »

jacobsenscott wrote: post #97
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 ta…

I agree with the sentiment, but I would say people who are familiar with the CS principles and not necessarily people who have CS degrees.

Re: The Imposter's Handbook

#127

Post by bogomipz »

I am curious, do people actually pay $30 for an ebook without even being able to see a(propsed) table of contents of a sample of the writing?

This is unusua. With both Amazon and LeanPub you can at least gauge the writer's style or get a feel for writing quality by looking at a sample chapter and a table of contents.

I'm skeptical that all of those people praising the book bought the book site unseen.

Re: The Imposter's Handbook

#128

Post by pjc50 »

cookiecaper wrote: post #114

This thread is long and this will probably get buried, but I'll leave it here anyway. I'm really excited about this kind of thing and have sometimes thought of writing one myself, primarily as a means for me to hammer out all the theoretical areas that are still foggy for me as an autodidact. If this can make it easy to pass impractical textbook-style interview questions and give a good, reliable foundation of CS kno…

I like the approach of hammering out knowledge through writing it down. I taught myself to fill in a lot of knowledge gaps by answering questions on electronics.stackexchange.

Re: The Imposter's Handbook

#129

Post by muhmi »

jacobsenscott wrote: post #97
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 ta…

That sounds like very basic CS stuff, so I guess "CS degeee" here means B.Sc. level knowledge? ;)

Re: The Imposter's Handbook

#130

Post by legulere »

apeace wrote: post #103

I have a funny anecdote about CS. I am a CS dropout who has been working in startups for a few years. About once a year, I see another programmer making a common mistake, and I draw on my CS knowledge to help them out. The mistake is parsing HTML with regular expressions. It is so tempting to write a good ole' regex to grab that attribute value off of that element. And it works on the 5-6 samples you write your unit…

I think the HTML/XML/JSON is not a regular language story is a bad one, because subsets of them are indeed regular. Most of the time the data you're trying to parse doesn't contain arbitrarily deep nesting and could actually be parsed with a regex. Further regexes of languages like perl can parse a superset of regular languages.

The real problem with regexes is that they are hard to maintain and are extremely hard to get right to neither have false positives nor false negatives.

Post reply on HN