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

111–120 of 237 posts

Re: The Imposter's Handbook

#111

Post by Periodic »

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…

Just a year ago I was on a project that involved building a tree of data and we wanted the ability to try adding a few things and backtrack to multiple different points if it didn't work out, so there was a lot of shared data in the tree. Performance was critical and we had various operations that had to be performed regularly, so I did a lot of implementations and tested them directly.

My CS degree (which I got late in my career) was invaluable. I got it precisely because I had no idea what I was missing and if I hadn't I wouldn't have investigated half the options I did and would not have had a good framework for thinking about them. I would have gotten the job done without it, but it wouldn't have been as good a job and I wouldn't have known what I was missing.

Re: The Imposter's Handbook

#112

Post by philippeback »

lanna wrote: post #42
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…

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

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/

Re: The Imposter's Handbook

#113

Post by lorenzhs »

chrisseaton wrote: post #39
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…

In my opinion there are also serious errors with the description of currying. https://github.com/imposters-handbook/feedback/issues/50

The lambda calculus excerpt on the site has some issues as well. It says:

> Lambda Calculus is reduced from left to right, which is very important

No, you can do feasible reductions in any order. The problem is that you need to define β-conversion and normal forms (β normal from is obtained by repeatedly applying β-conversion to the leftmost redex).

Also, the example reduction is just wrong. You cannot transform (λx. x x) (λx. x x) into x x (λx. x x) - that's just not how β-reduction works. Applying a β-reduction to that term yields the same term, because you substitute the second expression for x in the first, thus obtaining the input all over.

Re: The Imposter's Handbook

#114

Post by cookiecaper »

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 knowledge that won't go away ten seconds after closing the Wikipedia page, I'd love to buy it (and I still may write my own some day just for good measure :P). I think autodidact programmers is a rapidly-growing and under-served market (though, unfortunately, I don't think it'll be allowed to go on much longer; I expect professional licensing organizations similar to the ABA to show up on the horizon soon).

Re: The Imposter's Handbook

#115

Post by acs5 »

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…

Also, the description of the boolean satisfiability problem isn't the boolean satisfiability problem at all, but just what we might call the boolean evaluation problem, or a version of the circuit value problem, which is certainly in P.

I have no idea what's going on in the lambda calculus excerpt further down the page, in particular substituting (λx.x x) with (x x)? There seems to be a fairly big misunderstanding here. And lambda calculus isn't reduced in any particular order -- there are many ways to reduce the same term.

Re: The Imposter's Handbook

#116

Post by IMTDb »

collyw wrote: post #96
softawre wrote: post #90

Earlier quoted context omitted.

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…

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

Re: The Imposter's Handbook

#117

Post by AMHOL »

jredwards wrote: post #52
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.

I have no degree in CS and I see these terms regularly. So I google them and read about them.

https://www.youtube.com/watch?v=QnZ0Y4rvz6E&feature=youtu.be...

Re: The Imposter's Handbook

#118

Post by Periodic »

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…

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.

Re: The Imposter's Handbook

#119

Post by blowski »

dineshp2 wrote: post #108
haylem wrote: post #31

Earlier quoted context omitted.

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

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.

Re: The Imposter's Handbook

#120

Post by eksemplar »

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…

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.

Post reply on HN