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

141–150 of 237 posts

Re: The Imposter's Handbook

#141

Post by jasonjei »

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 parallelism. I still feel these are essential topics to understand since these issues often come up in most programming languages (JS, Ruby, Go, etc). When deciding between Nginx or Apache, for example, knowing the difference in philosophy is useful (asynchronous vs. thread-based). One of things that CS trained me very hard was to think about cost; when I programmed before my CS education, the old adage of everything looking like a hammer was particularly true for me. Also, many of the self-taught guys need to use fewer libraries/gems and more stdlib and primitives because every additional include is not always necessary and may unnecessarily increase complexity :)

Pipelining is another concept that I feel self-taught programmers have weaker foundations--many of whom I have worked with write code that waits for all results to become available, while an operation that's blocked by I/O doesn't necessarily mean we can't do stuff with the CPU while we're waiting for the next batch of I/O to come through.

I have also seen self-taught programmers accidentally write O(n!) or O(2* * n) functions and not realize it. I think data structures is definitely a good chapter to have. Especially when writing queries to a data store.

I think explaining how a hash table works would be excellent since it is such a useful and fast data structure. A lot of set-taught programmers sort of treat them like magical black boxes when it's not a very complex data structure yet it's practically O(1) for most insertion/reads/deletions.

Memory management is fortunately something we don't really need to worry as much about. With languages and interpreters that do a very good job of cleaning up after our code and now that memory is relatively cheap, we can afford to ignore it until we need to scale.

Of course, if you have a good product, you can get away with inefficiency and hire CS guys when you have built a unicorn. ;)

Re: The Imposter's Handbook

#142

Post by codingdave »

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…

"beyond the basic concept of not doing obviously stupid shit."

Isn't that exactly the point? Based on one's knowledge, something that is obviously stupid to you could be a completely new concept to someone without that same knowledge or experience. Describing anything as "obviously stupid shit" is exactly the kind of thing that makes new self-taught programmers afraid to engage with others. It is better to give people a break, help them learn, and give them a positive environment in which to do so. This book sure seems like a good step in that direction, whether or not its topic comes up in everyday conversation.

Re: The Imposter's Handbook

#143

Post by haylem »

blowski wrote: post #119
dineshp2 wrote: post #108

Earlier quoted context omitted.

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

That, yes.

But also because a significant amount of even the day's top popular topics have in the end very little relevance and impact to most businesses.

Which doesn't mean it's not interesting, though.

Re: The Imposter's Handbook

#144

Post by harperlee »

nulagrithom wrote: post #106
r0fl wrote: post #83

Earlier quoted context omitted.

It's a way to easily filter when you get 1000 applicants for 1 job posting. Not the fairest but it's quick.

And an even easier way to filter out the company.

There is bias in the risk of their decision: hiring someone given that (s)he is good is not important - the important thing is that (s)he is good given (s)he is hired. That's why they are conservative in their selection process.

Re: The Imposter's Handbook

#145

Post by jacobsenscott »

eksemplar wrote: post #120
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…

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.

I deal with this stuff regularly, but not daily. I'm sort of the go to guy on the team when things start to feel CS'y. It isn't PhD level stuff.

Re: The Imposter's Handbook

#146

Post by iandanforth »

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…

Here's another perspective. Let's say the company you joined has a culture that is big on sports, specifically American football. A lot of the people on the team care about the sport, make jokes about it, and make passing references to the current events in the game. If you're the kind of person who cares about fitting in, you might just read up on the game and perhaps browse the sports page headlines so the comments and jokes don't go totally over your head. You know when to laugh.

This type of book can help with the cultural roadblocks non CS degree wielding programmers may have. There are many cultural code words that CS degree holders use and being up on those can make an "impostor's" life easier.

Re: The Imposter's Handbook

#147

Post by vonmoltke »

muhmi wrote: post #129
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…

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

Why would it not?

Re: The Imposter's Handbook

#148

Post by sbov »

kchoudhu wrote: post #91
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…

Next question: how often would this kind of malprogramming actually lead to deal-breaking performance issues in a project? After a decade in the industry, countless projects delivered and much shit code witnessed, I can empirically answer this question, and the the answer is -- even at places that are known for their technical excellence -- not often. Look, I'm not advocating illiterate programming, nor am I a propon…

Performance will rarely be deal breaking. Instead people will toil away with slow systems and just accept it. It doesn't mean that they wouldn't be much happier with a faster system.

We recently replaced a system whose online store took about 900ms to respond, and their back end admin section on average around 1.7 seconds. It obviously wasn't deal breaking since they lived with it for 3 years but it still was still ridiculous, and definitely had an impact on both their productivity and bottom line.

Re: The Imposter's Handbook

#149

Post by emodendroket »

kchoudhu wrote: post #91
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…

Next question: how often would this kind of malprogramming actually lead to deal-breaking performance issues in a project? After a decade in the industry, countless projects delivered and much shit code witnessed, I can empirically answer this question, and the the answer is -- even at places that are known for their technical excellence -- not often. Look, I'm not advocating illiterate programming, nor am I a propon…

How big is the list we're talking about?

Re: The Imposter's Handbook

#150

Post by ryandrake »

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…

This is exactly true. Even at places where the primary money-making IP is a truly novel application of some algorithm, 99.5% of the code are "supporting actors": an API onto that algorithm, plumbing up through layers of middleware, bindings to other languages/frameworks, integration code to shim it through some legacy system, a CRUD interface, etc. My guess is that Google's search code is actually just tiny island of real computer science surrounded by a vast ocean of plumbing, frameworks and middleware, and that when you're hired there, chances are you're not going to be working on that island.
Post reply on HN