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

221–230 of 237 posts

Re: The Imposter's Handbook

#221

Post by jasonjei »

nikmobi wrote: post #173
BinaryIdiot wrote: post #158

Earlier quoted context omitted.

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

I think in many ways, though, the self-taught guys are going to be very adaptive and resourceful to learn new things. The difference in knowledge can often be compared to a self-taught home cook and a formally-trained cook.

I once had an intern that was a CS master degree student and while he was tackling neural networks in school, I showed him how to link to a DLL 3-times in C++ and he still couldn't figure it out on his own. It also shows you having a CS degree doesn't mean anything.

I think CS though will tell you how it works.

Re: The Imposter's Handbook

#222

Post by xenihn »

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…

I appreciate this post. I definitely lack knowledge on the stuff you described, sadly...

Re: The Imposter's Handbook

#223

Post by vonmoltke »

Jtsummers wrote: post #207
vonmoltke wrote: post #205

Earlier quoted context omitted.

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)…

> 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 don't see how Big O calculus helps here. If you have enough understanding to run that analysis you have enough understanding to see it is trivially a dumb idea.

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

What's funny is that I am an EE, and the way I internalized complexity analysis and optimization was to look at the number of operations being performed, along with the cost of those operations, and design the code such that it used the fewest resources. Only later did I learn this "Big O" thing and it seemed stupid because it seemed overly complex and was telling me to throw out significant factors that I spent my career worrying about. I still don't really see the value of it over more detailed methods that seem trivially easy to me, like simply deriving an approximation of the complete polynomial describing the runtime, memory usage, or what have you. I am a systems engineer and have a bias towards modeling things, though.

Re: The Imposter's Handbook

#224

Post by emodendroket »

kchoudhu wrote: post #100
riskable wrote: post #78

Earlier quoted context omitted.

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…

Not to mention that most of the kids today would have stowed their entire population of receipts in whatever the datastore flavor-of-the-week is. At that point, the lookup would effectively be a SELECT -- which the DBMS would optimize away for you.

A very simple example that I think is "real-world" enough is recursively descending the fields of some object which has cycles. If you use a list instead of a set this can be quite slow.

Re: The Imposter's Handbook

#225

Post by cholantesh »

JoeAltmaier wrote: post #170
BurningFrog wrote: post #168

Earlier quoted context omitted.

Spending 4 years to get a CS degree gives you a lot of skills and knowledge. But so does writing software outside of college for 4 years. Which one is better? That's an empirical question.

Usually here is where we observe Dell, Gates and Jobs didn't finish college. But that's more about business than engineering.

And even if it wasn't, one could retort that Brin, Page, Musk, Nadella, etc. did, and in fact, did graduate level studies. It's a complex question.

Re: The Imposter's Handbook

#226

Post by BinaryIdiot »

jacobsenscott wrote: post #217
BinaryIdiot wrote: post #193

Earlier quoted context omitted.

Yeah a simple word and I would have taken the post entirely differently :)

I must have thought the word 'can' and didn't type it because it doesn't read right as it is. I do that sometimes.

Fair enough. I to do that quite frequently :)

Re: The Imposter's Handbook

#227

Post by gthtjtkt »

DanHulton wrote: post #201
gthtjtkt wrote: post #139

Earlier quoted context omitted.

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.

Legal industry, in a branch of the law that's very high volume. We were paying a consultant $175/hr just to create basic SSRS reports until I learned to do it. I'm sure plenty of other firms are still hiring outside devs at exorbitant rates.

And when I explain what I do (mostly automating clerical or data entry/retrieval processes) to friends in other fields, a lot of them have said "Wow, we could use a lot of that at our company. We do X and Y and Z over and over and it's a huge waste of time." Small companies often force highly-skilled workers to complete their own repetitive clerical tasks, and medium companies seem to hire teams of $10/hr drones. They never think "At what point is this worth automating?" or they don't know where to look for a dev who can do it for them.

I think the small/medium business CRUD app market is extremely neglected because it's not as glamorous as machine learning or whatever else all the MIT grads are doing these days.

Re: The Imposter's Handbook

#228

Post by qwertyuiop924 »

ryandrake wrote: post #136
RealityVoid wrote: post #74

Earlier quoted context omitted.

Experience is good, but I find some people have a "knack"... they intuitively understand when something is good and when not. How do you instill that? Priming from good logical and mathematical education help. Nudges to think for yourself and thins of the reason things are done a certain way sort of help. What more?

Lots of practice and experience. Calling it a "knack" kind of downplays the years (decades) of study, work, and effort people put into refining their craft. You could also say Michael Phelps has a "knack" for swimming, but he also did nothing but workout, train, practice and compete for years.

I keep trying to explain this to my non-programmer friends: No, I'm not some genius, I read lots of information, and worked hard to get to where I was, and from a programming perspective, I'm barely competant and know just enough to be dangerous. Yes, you could probably do it too, although the difficulty varies depending on how well you can handle the kind of abstractions and logic you'll be dealing with.

Re: The Imposter's Handbook

#229

Post by rianjs »

chris11 wrote: post #45
sotojuan wrote: post #30

Earlier quoted context omitted.

That's the case for some elite finance institutions, but does it happen with programming?

I once got a rejection from an internship application late one night a few hours after I applied. I wouldn't be really surprised if I had been automatically rejected. And my rejection might have been because the state university I went to was not specifically mentioned in the drop down list of schools, it was in the "other" category. I think I might have not gotten a rejection so quickly if I had been going to a targ…

More likely their internship program was full already.

Re: The Imposter's Handbook

#230

Post by manigandham »

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…

Interesting comments but both are saying the same thing: it's all knowledge in the end.

Either you know or you dont. CS degrees just means you learned it in a more standardized/formalized setting and have some proof to show you did it, but ultimately it's the knowledge itself that makes the difference, not how you gained it.

Post reply on HN