halpme

I work there and today's been utter chaos. Lots of meetings with upper management and people wandering around confused. I came in to work in a new position in a new team with a new manager. They probably shifted all the people they didn't care about into roles where they would be unhappy and eventually quit, as opposed to outright laying people off. Meg's mentality is that basically any unit of HPE has a pricetag. I'm probably going to stick around for a few months and quit if I can't transfer back to my old team.

Sunnyvale, CA

Off-topic: but I'm really happy to see an increase in reverse engineering threads here on HN.

Why do you say that?

How do you identify people who "can't code their way out of a paper bag"? What is it about their skill level that makes them seemingly incompetent?

There's a lot of video content on a lot of topics, but their content is shallow. If you want to get a deep understanding of something, reading textbooks and official documentation is likely the way to go.

I have the best of both worlds: Eclipse IDE with a vim plugin (vrapper). Not sure why people choose strictly one of the two.

What makes you say that Apple is dying?

Software Engineer @ big old enterprise company doing security work.

Side projects: None. I believe in having a life outside of programming. I don't touch code after 5PM. Currently training to run a half-marathon and getting more serious about powerlifting.

Reproduce the bug. Reproduction steps/environments are usually provided by support engineers or QA. Look through log files for any specific error messages, and use grep to find where in the code the error is coming from if it's not specified in the exception stack trace or something like that. Look at the code and form a hypothesis about where the bug might be located (use a "binary chop algorithm" discussed in books such as Code Complete and Debug It). Create breakpoints and step through the code with a debugger and record your observations. If you still haven't found the bug, use the data you just collected to form a stronger hypothesis and repeat the process until you've identified the source of the bug. Then apply the fix, and run some unit (or integration?) tests to verify you didn't introduce a regression or that you actually treated the symptom instead of fixing the root of the problem.

This might not be the best approach, but it generally works for me. I highly suggest reading the following books: Debugging, Debug It! and parts of Code Complete.

To echo what everyone else has said, my feed is utter garbage and a lot of friends post stuff that makes me cringe. I've unsubscribed from the majority of my friends so now all I see are ads and sponsored posts.

Here's the thing, I get to see what events my friends are going to, which usually end up being really fun and not something I would have found out about otherwise. So nowadays I only use facebook to find and management events to attend.

I'm taking several classes via Coursera to brush up on algorithms/data structures for fun and personal interest, but find it really hard to stay focused on the video lectures. I much prefer to read textbooks when learning any new information. But that's beside the point. I've conducted an interview and the candidate had taken multiple MOOC's on Coursera and Udacity and that really impressed me. Showed that the candidate actually cared about learning and deepening their knowledge in some areas.

As a Java developer I rely heavily on using the debugger in Eclipse and using grep to search through files. I first try to have a solid understanding of what the program is supposed to do, reproduce the bug, and then step through the code with a debugger to understand why the bug is happening. Other times I just try to find where the bug is happening, and working backwards to the root of the cause of the problem just be reading the code. This works most of the time, but as a junior developer most of the issues I have to debug are not too complex.

No. What I mean to say is, if someone claims to work at Google/Apple/Facebook/Microsoft, or a "cool" start-up like Uber or whatever else is popular these days, then everyone all of a sudden becomes more interested in talking to that person. "Oh wow, that's so cool! What do you do? How's it like working there??". If you work at a boring old enterprise company, most people react with "Oh, I see" and move on a different topic.

Do you actually go out and talk to people? The first thing anyone asks is what you do, followed by which company you work for. Watch people's reactions change depending on the reputation of your company. The whole social scene here is centered around networking, not making meaningful relationships. No one cares if you're a chill person with cool hobbies, but if you work at <cool company> then you become one more inside connection when someone needs a new job and a reference. YMMV.

I went to UC Davis but would frequently visit Sac. It's such a beautiful and laid-back city, and the people are great. SF is only a one hour drive away and Lake Tahoe is relatively close too. I've been living in Mountain View for a couple months and I miss the Davis/Sac area more and more as time goes on. The atmosphere here is, I dunno, toxic. Too many people here size each other up based on where they work and where they live and people are way too obsessed with advancing their careers and chasing higher salaries, more luxurious cars, nicer apartments, etc. Everyone seems to have some sort of inferiority complex if they don't work for the "Big 4". People in Davis/Sac seemed less superficial and it was a lot easier for me to make friends. Also, yeah, the cost of living is so much cheaper. I'm paying $1700 for a tiny studio in MV. Back in Davis I was paying $1400 for a pretty nice 2-bedroom apartment. Meh.

I use a composition notebook at work. Every day I write down a list of things I'm going to discuss at the scrum meeting, a list of things to do that day, a list of goals for that week to remind myself what I'm supposed to be doing, and then take notes on the bugs I'm working on. I'm a huge fan of diagrams and mindmaps so I fill up the pages with those, as well as notes of ideas that pop into my head or something my coworkers/boss mention that might be useful information later. At the end of the day I write a summary of what I accomplished and make any quick list of things I want to get done the next day.

I can flip through pages and actually see how my progress with certain things evolves over time. Sometimes, as a self-esteem booster, I look at my notes on something I've been struggling with a few months ago, and compare it to my current state of knowledge. I also have a bad memory and get somewhat nervous during scrum, so having notes to reference when its my turn to speak is super helpful.

That sounds a lot like deliberate practice, which is an idea that's been around for a while.

How would this apply to learning a conceptual topic, as opposed to a physical skill?

Totally, that sound like a great environment.

I understand that you were joking, but I replied out of frustration because I genuinely want to find a group of people (outside of my coworkers) that I can make cool stuff with but its been difficult.

I already have job and want to learn things outside of what I do at work (enterprise security). Thanks for posting an utterly useless comment.

At the end of my junior year I was placed on academic probation, and later kicked out of college. At that point I considered quitting school for good, but ultimately begged my way back into school and completed that degree. Now I work at a reputable company making sweet money. Getting a degree was so worth it. Don't quit, just hang in there.

It seems like a lot of academics and hardcore computer science enthusiasts love CLRS. But I remember taking an algorithms course just a few months ago and that book was almost unreadable. A lot of my classmates shared the same sentiment. The math was dense and the explanations were unclear. Juggling several other CS classes that quarter, nobody had the time to work through it. Maybe I wasn't smart or patient enough to understand CLRS, but it just never made much sense to me, especially on more advanced topics of algorithm design.

I loved The Algorithm Design Manual. Used it for my class as well as preparing for technical interviews. Although looking back at it now, TADM is great for learning algorithms (quickly) for the very first time, while CLRS is a good reference manual once you already understand how they work.