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

171–180 of 237 posts

Re: The Imposter's Handbook

#171

Post by haddr »

Yep, people are really forgetting that most of the time it's just being clever rather than having (or using) in-depth knowledge is what allows to bring some good solution to the table.

An example from today: we have a very slow pattern matching code, that starts to be a bottleneck for the application. What can you consider? Well you can dive into sexy bloom filters, experiment with some Trie-based structures. But then when you analyse the problem it results that simple word lookup with a simple hashtable is the fastest solution for given constraints. No big deal, no rocket science.

Probably the same goes for rocket scientists, but one level higher ;)

Re: The Imposter's Handbook

#172

Post by chadclan »

ryandrake wrote: post #123
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.

Preach it. This is EXACTLY my experience. CS degree or not a person's proficiency depends on that person. One of the biggest hurdles I personally face is that so many programmers just don't care about #3. It's often not a competency issue, it's an apathy issue.

Re: The Imposter's Handbook

#173

Post by nikmobi »

BinaryIdiot wrote: post #158
jacobsenscott wrote: post #97

Earlier quoted context omitted.

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…

> A CS degree prevent you from making a lot of obvious (if you have a CS degree) and costly mistakes. I couldn't disagree more. I do not have a CS degree and have lead many teams of folks with a combination of having and not having them. It's a huge mixed bag and I'm not confident you can make a general statement in either direction. Yes CS can prepare you by knowing some of the basics but I've run into countless peo…

I agree with you for the most part, but I think if his sentence read:

> A CS degree can prevent you from making a lot of obvious (if you have a CS degree) and costly mistakes.

I think most people can agree that it doesn't provide any guarantee, but it definitely gives you a boost in the right direction.

(For the record, I don't have a CS degree)

Re: The Imposter's Handbook

#174

Post by GFK_of_xmaspast »

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…

This is a case where a little knowledge can be a dangerous thing, because "regexes" are often strictly stronger than just "regular expressions".

(That said, the moral of this story is still correct, i.e. use a parser, but mostly because html-in-the-wild is uniformly awful and it's better to let someone else worry about that).

Re: The Imposter's Handbook

#175

Post by [deleted] »

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…

[deleted]

Re: The Imposter's Handbook

#176

Post by [deleted] »

riskable wrote: post #78
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…

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…

[deleted]

Re: The Imposter's Handbook

#177

Post by GFK_of_xmaspast »

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…

Perhaps you just aren't taking/finding the more challenging jobs?

Re: The Imposter's Handbook

#178

Post by vonmoltke »

emodendroket wrote: post #169
vonmoltke wrote: post #156

Earlier quoted context omitted.

How does it change what you do, though? I did signal processing with massive data streams rather than bioinformatics, but I assume the situation is similar. The algorithms are what they are. They are complex mathematical equations or transformations that need to be run on data and are often optimized without being able to change their asymptotic complexity.

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.

Re: The Imposter's Handbook

#179

Post by scaleout1 »

when I was college I thought all the data structure and algorithm courses were complete waste of time. Primarily because I was working as an intern on the side, making crud applications, slinging xml, writing DAOs etc.

For first five years of my career I never had to touch any of the stuff I learned in school and I was particuarly happy that I mostly mailed it in in those classes. Eventually my career evovled into dealing with data at massive scale and working on some of biggest services on the planet and the way I have taught myself to program completely changed. No longer it was possible to just sling code and hope that it will just scale to million of users. All the stuff that I slept around in class was relevant again and I had to go back to coursera and take those classes all over again. So moral of story, if you will be slinging webapps rest of your life you probably dont need to know Big O, different search algo, linear algebra and statistics etc but if you think you will be working on stuff thats coming around like automanous cars, IoT, augmented reality etc, you should definitely read up on it

Re: The Imposter's Handbook

#180

Post by rayiner »

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…

> A CS degree prevent you from making a lot of obvious (if you have a CS degree) and costly mistakes.

This. Many years ago, our code was shitting the bed, a month before a major milestone deadline. Turns out that someone wrote an N^2 algorithm and only tested with N=5.

I don't have a CS degree--just a few semesters of combinatorics and graph theory. When I was programming, I always felt that was a huge liability. I'd confront a problem, and I knew just enough to know it could probably be reduced to some graph problem and solved using a known algorithm, but I didn't know what that was.

Post reply on HN