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

201–210 of 237 posts

Re: The Imposter's Handbook

#201

Post by DanHulton »

gthtjtkt wrote: post #139
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.

Just throwing my anecdote in the ring: I work with a small team (4 devs) in at a non-tech company. The other devs all have 10+ years experience and none even know what SOLID is. I've never asked, but I'm guessing they don't know about any of the other things you mentioned either. There's an ocean of small/medium businesses who just need to get shit done and don't need it optimized so it can scale to serve 7 billion p…

I mean... which consultants? In which industry? And who else works in that industry? And do you have phone numbers?

Just... asking. You know, for reasons.

Re: The Imposter's Handbook

#202

Post by [deleted] »

vonmoltke wrote: post #178
emodendroket wrote: post #169

Earlier quoted context omitted.

Skiena's Algorithm Design Manual mentions him being brought in as an algorithmic consultant to modify some genetics analysis software so that it'd actually finish but I don't really remember the details or know enough about the field to give you plausible examples.

I can see that; I did a lot of similar work with signal processing algorithms. None of what I did affected asymptotic complexity at all, though. The asymptotic complexity was tied to the algorithms chosen, and changing those was an issue of trading computational performance for system performance.

[deleted]

Re: The Imposter's Handbook

#203

Post by ap22213 »

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…

It's extremely helpful if a team member has a CS degree, but it's not always essential.

The CS grad usually understands the whole stack from UI through CPU, I/O, and memory. They don't get the distant stare when they see code with a Red black tree or a graph algorithm. They may not know about skip lists and bloom filters, but they can figure it out quickly. They understand reference vs. object equality. They understand multi-threading and concurrency strategies. They understand how to implement a hash so that there are few map collisions.

That said, a lot of IT work, web development work, database work, API work, etc. doesn't require all of that. A lot of my work does, but if it doesn't, I hire based on passion, productivity, resourcefulness, and craftsmanship.

As an analogy, many small businesses are successfully run by self-taught entrepreneurs. But, running a $100M company requires different knowledge.

Re: The Imposter's Handbook

#204

Post by mamon »

vonmoltke wrote: post #147
muhmi wrote: post #129

Earlier quoted context omitted.

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

Why would it not?

In some countries (think "Europe") Bachelor degree is considered "incomplete", or just an intermediate step. Only Master of Science degree is regarded as true "higher education". There are even university programmes that take you straight to MSc degree, without stopping at BSc.

Re: The Imposter's Handbook

#205

Post by vonmoltke »

Jtsummers wrote: post #186
teekert wrote: post #99

Earlier quoted context omitted.

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…

EDIT: Misstated the big-O, in this particular case (should've found my coworkers actual code). Both are O(m x n), one just has a large constant. Here's a pattern I've noticed with code written for processing a data file by a lot of people (python-esque, using a function (match) that's "left as an exercise for the reader" to implement): def search(filename, value): with open(filename, "r") as f: for line in f: if matc…

I would have never written the first example in the first place, and I don't need Big O calculus to tell me it's a bad idea. Even with a single file it is obvious that the initial implementation is doing unnecessary work and that re-reading a file from disk every time is ridiculous (unless the file is too large for memory, in which case I would pass the list of search terms to the search function and check each line for all terms as the lines are read).

Re: The Imposter's Handbook

#206

Post by Ensorceled »

nspriego wrote: post #162
jasonjei wrote: post #141

I think one of things that "millennial" self-taught programmers have trouble understanding is OS. While the need to implement OS functionality is now a niche (like process scheduling), I have noticed that "millennial" self-taught programmers have gaps in knowledge with respect to threading, mutex/semaphore, consumer-producer pattern, synchronization vs. lock-free (blocking vs. non-blocking), concurrency and paralleli…

Just curious, why the "millennial" descriptor? Is having trouble understanding the OS something unique to only "millennial" self-taught programmers?

In my experience, Gen X and Boomer self taught programmers spent a lot of time hacking at the application or system level and have less holes in that area. They have other holes in their knowledge base, just not those ones.

Re: The Imposter's Handbook

#207

Post by Jtsummers »

vonmoltke wrote: post #205
Jtsummers wrote: post #186

Earlier quoted context omitted.

EDIT: Misstated the big-O, in this particular case (should've found my coworkers actual code). Both are O(m x n), one just has a large constant. Here's a pattern I've noticed with code written for processing a data file by a lot of people (python-esque, using a function (match) that's "left as an exercise for the reader" to implement): def search(filename, value): with open(filename, "r") as f: for line in f: if matc…

I would have never written the first example in the first place, and I don't need Big O calculus to tell me it's a bad idea. Even with a single file it is obvious that the initial implementation is doing unnecessary work and that re-reading a file from disk every time is ridiculous (unless the file is too large for memory, in which case I would pass the list of search terms to the search function and check each line…

It only looks like a bad idea because of the close proximity in my example. What I've seen normally is that it's grown into something mimicking this structure, but actually far more complex. The point where the file read happens isn't so near the top so that refactor is less obvious, and it's so deep that the person who puts it into that outer loop in main may not realize what's happening internally (fully, at least).

I'm trying to recall the structure of another case where this happened that with a more complex internal algorithm. The solution was far less obvious, but required similar refactorings. In that case it was both reading the file multiple times, and a several deep loop where one (which was by far the longest running) could be refactored to only happen once. Instead of 100 or so times, we flipped some of the loops around (moved it to be the outer loop, similar to the idea of moving the loop over all lines to be the outer loop in my other example). Big-O wasn't essential (for me), because I'd internalized that sort of thinking. But that explanation was essential for my colleagues (EEs, couple years out of school) who hadn't been exposed to that construct before (at least not enough to stick).

Re: The Imposter's Handbook

#209

Post by ultramancool »

legulere wrote: post #130
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…

This is one I've never quite understood. Having written many scrapers I will say - Scraping is always hard to maintain. I've written regex and parser based scrapers many times, but it's still a need for constant updates as the page changes.

HTML will change about as often (only slightly less in my experiences) than regexes will need to be changed and can take more time to test and develop on each update, especially if you don't have access to a very durable parser which can stand broken HTML, unlike most XML parsers. So if a regex does the job, use it IMO.

Re: The Imposter's Handbook

#210

Post by brassic »

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 had to scrape the comments out of a blog. As you might expect, there was a div for comments, with comments nested within it. This made it easy to grab the comments using an HTML parser with xpath support.

Unfortunately, the blog software had a bug and it was possible for markup to leak out of the comments. Sometimes a spurious would close the comments div and the scraper would miss comments that came after it. However, the HTML did contain helpful HTML comments, something like "comments start here" and "comments end here". The reliable solution was to use a literal string search on these HTML comments to pull out the entire comments section, and then to use regexes to pull out the comments' content.

The only unbreakable rule is that there are no unbreakable rules.

Post reply on HN