Hacker News new | past | comments | ask | show | jobs | submit | csnewb's comments login

I'm a Bay Area resident. I went to Costco today at 9:00 AM and it was an absolute shitshow.


Isn't that a normal Sunday at most Costcos? ;@) (That's why I go on a weekday.)

Hint: Costco (COST), Clorox (CLX) and Pfizer (PFE; makes Purell) stocks seem like very short-term value-investing strategies (unless they're losing money elsewhere) because of both the market dip and they're having crazy sales numbers. It's probably a good idea to buy some stocks in general during this temporary downturn, because the odds that it will turn into a recession are very low and it will most likely bounce back.


Good question, and that's the main reason I prefer to own physical books over Kindle books. I know that I own a physical book, but a Kindle book can disappear at any moment. Kindles are great while traveling though.


Do you often reread old books? I find that most books are only read once and then discarded, but it's hard to tell which ones are before buying.


I don’t even have a concept of an “old” book or of “reading” a book, I just keep them around for inspiration, going back for some quote, rereading, showing someone, etc. I mean I also almost never finish them, or even try to read them in linear order...


It really depends on the type of book. muzani might be thinking novels, while you could be thinking textbooks.


Yes, I do.


Go to the gym and lift weights or do some cardio.


Security


Problem Solving 101 by Ken Watanabe provides a toolbox of problem solving techniques. One method I've been using to decompose problems us to use a "logic tree". Start here: https://en.wikipedia.org/wiki/Issue_tree. Another technique is to first explain the problem and solution at a high level (pretend you're explaining it to a friend or coworkers), then write pseudocode for how you would solve it, and then convert that pseudocode to actual code.


Logic tree is a good direction to look into. I asked the question in a broader sense, not just coding.


If you're located in the Bay Area I'm up for it. Or even working together remotely. I'm somewhat junior (3 years of experience) but mentorship is something I've been looking for in my career.


Become a T-shaped developer. Have a broad range of skills with a deep expertise in one.


Oh look, a thread about my current company. I'm actually in a bug fixing team right now separate from the main product development team. It's an extremely difficult position because as someone else mentioned, you need an incredibly deep understanding of the system to truly resolve these bugs. Unfortunately I work on a 20+ year old legacy codebase with minimal documentation and poorly written code, and our dev team is unwilling to spend any time helping to resolve these issues. They're too occupied with churning our new features, while the bug team is abandoned to clean up the mess from all this new code without any sort of help whatsoever. Another perspective that many people don't discuss is that only doing bug fixing is soul crushing. With things constantly breaking, it can be very mentally draining having to fix them. That being, the attrition rate on the team is quite high because there's very little career growth or satisfaction in being a bug fixer. This experience could be exclusive to my company, and I can't say whether it's effective for the business to run things this way since I'm still really early in my career.


Should be titled "How to Ace the Technical Interview in the Bay Area". Even absolute shithole bottom tier companies or unknown startups are asking these questions. Write perfect code on the whiteboard or get rejected. You have to put in A LOT of time into preparation even if you don't want to work at Google, which is ridiculous.


The books that I've read that have helped me immensely: How To Solve It, Problem Solving 101, 5 Elements of Effective Thinking, and Peak: Secrets from the New Science of Expertise. Trying to improve my problem solving ability in coding forced me to look inwards and analyze my thought process to understand why I'm able to solve some problems and unable to solve others. Ultimately I've realized the root cause of my inability to solve hard problems was poor problem decomposition. Every hard problem can be broken down into subproblems, and those can be further broken down until they become easy enough to solve. Then you just connect all the pieces together. It takes a lot of deliberate practice with many problem types to be able to recognize how to decompose problems, however.


Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: