Live data from Hacker News

The Imposter's Handbook

impostershandbook.com

61–70 of 237 posts

Re: The Imposter's Handbook

#61

The main thing people miss out on not having a degree is not getting past silly HR "must have degree" filtration. Never once found a CS degree a worthwhile indicator of ability. It may be a superb book, but not even giving a sample chapter out to judge writing style, quality of explanations, depth and so on?

Comments like these can only really have two causes: - You've bought into the anti-intellectualism wave that's going on in the US. - The universities near you are really poor. Is it really the case that you learn so little on these universities that you literally have no advantage over those who didn't attend?

I think it's more many people vastly underestimate just how much they and others got out of their education.

Sure,everything is a bell curve, but spending the majority of your time thinking of little else beyond software concepts for 4ish years will fundamentally change how you think and reason.

Re: The Imposter's Handbook

#62
I'm always pretty skeptical of anything that offers "Learn X Quick!". Is there any reason I should trust the author of this as a good source? They even state they only started learning this stuff a year ago. I wouldn't take a course or buy a book from anyone claiming only 1 year's study in any subject, why should CS be any different?

edit: It's also hard to find the author's name to find out who they are. It's not in text anywhere on the page, only in the image of the book cover.

Re: The Imposter's Handbook

#63

Proofreading error near the 'buy' button. > I've learned more in this last year since I started programming over 25 years ago. Should be '... this last year than since ...' Personally, I think '... th e p ast year than since ...' reads better also. Do I get a free copy of the book for pointing that out? ;)

There is a repo for posting feedback (such as proofreading errors) here: https://github.com/imposters-handbook/feedback/issues

Re: The Imposter's Handbook

#65

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…

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.

Re: The Imposter's Handbook

#66

The main thing people miss out on not having a degree is not getting past silly HR "must have degree" filtration. Never once found a CS degree a worthwhile indicator of ability. It may be a superb book, but not even giving a sample chapter out to judge writing style, quality of explanations, depth and so on?

I've interviewed somewhere around 200 people at this point and from my perspective, the degree, university or GPA have had no correlation with how well the candidate does. Now, I interview for Ops roles and not software engineering, so this might not apply across the board for other roles, but I have my doubts.

Ops is a pure experience job. A degree will never reflect how good an ops person is.

Re: The Imposter's Handbook

#67
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.

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?

Re: The Imposter's Handbook

#68
post #3

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

I think it's worth picking up, but I'm also a developer without a traditional CS degree.

The author also will give you your money back if you go through the book and think you haven't learned anything.

Re: The Imposter's Handbook

#69

The main thing people miss out on not having a degree is not getting past silly HR "must have degree" filtration. Never once found a CS degree a worthwhile indicator of ability. It may be a superb book, but not even giving a sample chapter out to judge writing style, quality of explanations, depth and so on?

Comments like these can only really have two causes: - You've bought into the anti-intellectualism wave that's going on in the US. - The universities near you are really poor. Is it really the case that you learn so little on these universities that you literally have no advantage over those who didn't attend?

I'm quite firmly against anti-intellectualism. Otherwise I think I'd then have to be anti myself!

In interviews, and across my 25 year career, I've met some excellent degree holders who brought some great skills to proceedings and a roughly similar number of excellent developers who didn't have the paper.

I've also come across occasional degree holders who I'd barely trust to make coffee let alone put near code.

In short, people are people.

Similar to other commenters I've found no correlation between degree on CV and later ability in employment, or it to be a useful indicator for prospective employees. In consequence I do find requiring a degree for applications silly.

Re: The Imposter's Handbook

#70
post #56

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…

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…

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.

Post reply on HN