I think I'll buy a copy for all the BRO-Grammers in my office.
Idiotic arrogance
The Imposter's Handbook
81–90 of 237 posts
Re: The Imposter's Handbook
#82I'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…
>I've learned more in this last year since I started programming over 25 years ago
From the OP link. The author spent a year "filling holes" in his knowledge.
Re: The Imposter's Handbook
#83The 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?
Even funnier, coming across companies that don't accept anyone who doesn't have a degree from xyz university.
It's a way to easily filter when you get 1000 applicants for 1 job posting. Not the fairest but it's quick.
Re: The Imposter's Handbook
#84Earlier 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…
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.
Re: The Imposter's Handbook
#85He also wrote another book http://www.redfour.io/ take off with elixir. Anyone have read that ?
Re: The Imposter's Handbook
#86The 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?
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.
Re: The Imposter's Handbook
#87Earlier 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…
> 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 actually matters. I think a charitable reading of what ThePawnBreak said should assume one has already determined this particular operation matters for performance.
Re: The Imposter's Handbook
#88I'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…
Agreed, it is hard to find the author's name. I noticed that it was by Rob Conery in one of the blurbs and that turned my skepticism to interest as I am familiar with Rob as a frequent guest and collaborator with Scott Hanselman.
As a self-taught programmer (English/Classics major), I am (or was) the target audience for this book, but with deliberation have returned to school (ultimately pursuing a master's in Computer Engineering).
Re: The Imposter's Handbook
#89Earlier quoted context omitted.
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.
This is a fair point but isn't software development (in general) trending towards this same reality? Consider a job where the plan is to write a straightforward web application that runs inside a custom-built Docker container. What sorts of skills are more important?
Someone with a CS degree but little experience is going to have a hell of a time writing a Dockerfile and the scripts necessary to safely and securely deploy their application. They may be great at writing web applications but "that's not the hard part." The hard part is getting the architecture right so that the app will stay up despite being deployed, rebuilt, and re-deployed constantly.
Someone who's self-taught probably picked up Linux experience along the way (because how else are you going to teach yourself web development these days?) and probably has experience with things like AWS and the realities of hosting a web application (as opposed to just writing a web application). They will have had to setup their own development environments, do their own Linux installs, and probably got used to figuring things out on their own.
The way I see it computer science is science. The point of a CS degree is to give someone a career path as a scientist. These are the sorts of people that should be figuring out the next great algorithm (for whatever), finding uses for quantum computing, and finding solutions to similar fundamental problems.
Software development isn't computer science. It's like the difference between the structural engineers that invented that hurricane-proof nail and the architects that decided to use it in their build.
Re: The Imposter's Handbook
#90I 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'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.