cerrelio's comments

I would put forth that Google isn't a search company anymore. They spend more resources filtering out all the junk on the web. Search is a secondary function for them. The end-user doesn't see the filtering; publishers and merchants trying to jockey for position do.

Cocaine makes you very vigilant.

I became a photographer because I had some friends who were socialites and had VIP access to clubs. Their various club owner friends liked my photography, so I just started showing up with my camera all the time and I'd get in free and drink all night.

Short answer: no.

Long answer: Yes, if you can find a PI/project that's solving the exact problem you want to solve.

The work doesn't have to make money, but it has to make papers. And if your publications aren't landing in high profile journals, your funding (and career) will dry up.

I was considering that. I don't have any sales background, but I can communicate what's good and bad about software/systems fairly easily. In my career I've also had to "sell" complex ideas to management, and I've had pretty good success in getting permission to execute those ideas. Interacting with people can tire me out though. Nevertheless, I can power through anything with the proper motivation.

I'm currently trying out management, but the management atmosphere at my company is pretty bleak. None of the managers seem genuinely interested in launching products. They just kind of kick cans down the road for a few years hoping to fail upward. Over the past two years I've seen effective managers leave the company while the mediocre ones stick around. I probably just need to explore companies whose work ethic suits me better. However, it's hard to know beforehand if the company/team you join is going to fit you.

The other option is starting/founding a company. To explore that I've been going to monthly alumni events to network. There's so much money being thrown around in the Bay Area, I might as well try to tug on the brass ring. And it's not entirely the money that's the attraction, but the opportunity to call the shots.

I took two breaks from tech. One was for grad school, which I dropped out of after 3 semesters. Like some others in the thread I found academia to be pretty bad. You're paid shit and treated like a peon. The work was actually interesting, but I knew I could just go back to private industry and make 5-10x as much doing the same type of work.

I took a break from "everything" at one point and became a nightlife photographer in a large urban area. It didn't pay much. It mostly involved drinking and doing drugs, on someone else's dime, until the early morning. It was a great time for the most part, and I met lots of interesting people. After about 6 months I got tired of it and went back to tech. Note: having a professional camera in a club is a great way to meet women.

I'm considering leaving tech again, or at least ending my engineering career. I no longer find it personally enjoyable to build systems. Building systems that other people want, instead of ones I'd want to build, has jaded me. I've worked at several companies, large and small, over the years. And I've found that as a tech shop matures, that exciting feeling of creating a product dulls. It dulls to the point of becoming anesthetic. The longer you stay, the worse it becomes. I wouldn't mind staying in the tech field. I just don't want to spend all day in front of a monitor anymore.

These are based off my current experience in transitioning to a management role. I'm still a dev, but my manager is "testing me out" for a management role.

- Keep current on technologies, what your team uses and wants to use, and also technologies that might be useful.

- Know your developers' strengths and weakness, both technical and interpersonal.

- Time management. (Can't stress this enough).

- Ask lots of thoughtful questions (informed by the first item in the list).

- Develop relationships with other managers, teams and executives. If you want to manager bigger things, those guys need to see you and know you can do it.

- Don't hold grudges. At the end of the day, go home and forget about any bullshit that occurred.

- Trust your developers.

- Don't be afraid to say no.

- Take risks. Accept responsibility when those risks turn into failures.

- Give genuine praise.

One sort of cultural thing to keep in mind. It may not apply to you though. After moving to the Bay Area several years ago I noticed that behavior with organizations often defaults to passive-aggressive, especially when there's disagreement. Avoid being passive-aggressive and correct others (in a professional manner) when they're being passive-aggressive. I used to deal with more aggressive people when I worked on the East Coast. You know where you stand at least. PA behavior allows bad sentiment to stew and kills progress of any sort. Being assertive most of the time will solve this.

I've taken sertraline, venlafaxine, bupropion and fluoxetine.

Fluoxetine is the only SSRI I experienced no withdrawal from. I was on a low dose (10-20mg) though, and it mostly worked (went from severe depression to mild/none). I have a standing prescription for this as a fallback, but haven't taken it in 3 years. I avoid taking it because of the sexual side effects. I like having orgasms.

Bupropion triggered a seizure after the first dose. Immediately discontinued.

Venlafaxine was mostly effective, but I went from depressed to robotic/apathetic. When I stopped taking it, I tapered off, but I had brain zaps and developed acute tinnitus for over a month, alternating in each ear. To this day, 15 years after treatment, I still experience moderate hearing loss in my ears several times a month for about 60-90 seconds at a time.

Sertraline was the worst. I got up to 150mg before the problems. It triggered a hypomanic episode that lasted for about a month. I didn't sleep at all for the first three days it manifested. The doctor stopped treatment immediately and put me on risperidone, which is a new level of awfulness. I just quit taking it after a month, and told my doctor I would never take any antipsychotic again.

I have a great doctor now. He's not even a psychiatrist, just a generalist, but he's treated many cases of depression over the past 20 years. He figured I didn't have unipolar depression, but bipolar, due to the hypomania. SSRIs are bad, and not recommended, as monotherapy for bipolar. So he put me on lamotrigine and I haven't had a depressive (or manic) episode for over two years. I've also experienced no noticeable side effects.

I've found the only thing that matters in the treatment of mental/behavioral disorders is your doctor's skill and knowledge. Don't be afraid to dump a mediocre doctor; it's your wellbeing on the line.

My company's style is a culture of consensus. No one really "gives orders," because that's too aggressive, and someone might feel hurt. I find it fucking awful. If there's disagreement about something, usually another person is brought into the mix for "input," ad infinitum. This happens until the issue becomes a non-issue or a disagreement over a new issue occurs.

I might disagree with someone if they ordered me to do something I think is wrong, but I actually admire them for making a decision. There's nothing worse than making no progress because no one has the balls or authority to say "there's contention over this issue, but I think X is the best course."

SF needs to worry about its own transit issues. MUNI stops at rush hour are poorly serviced. I can't get on most of the trains that pass through Civic Center, so I usually end up going inbound to Montgomery or Embarcadero so I can actually board.

These modifiers are always a touchy point with me. They aren't applied consistently and imply greater experience and ability, when they often signify time spent at a company or political acumen. Over my 15 years in engineering, I've seen several engineers without senior or lead titles who provide more value than those with the modifier.

I prefer "staff engineer" for engineers who are capable of producing useful, working systems with a team. "Lead" should not be a modifier to a title, just an indicator who makes final technical decisions on a team.

On my resume I only have "software engineer." If I have to negotiate a higher salary after an offer, I point to my accomplishments and not my title.

Only if computing power catches up to handle the rapidly increasing rate at which data is produced. But as computing power increases, that also affects the rate at which data is produced. So, I firmly believe most data will sit around unprocessed and eventually decay into uselessness.

It is. We were specifically dealing with ESL/second-language learning though. Long term retention is necessary for fluency. If you want to pass a driver's exam or material you don't really care about beyond passing a test, then cram. Although in most classes, you will probably want to retain knowledge beyond a month in order to do well on a final.

This is the subject I tackled in grad school. It was super interesting, because many people still believe that memorizing stuff is best if you cram for an extended period of time. Showing them that just a few minutes of review at properly spaced intervals leads to better memorization floored most of the participants.

My particular research was the quantify the effects of the variance in follow-up exposure times. I did this research 10 years ago before smartphones were available. The participants had to physically be in a classroom in front of a computer to get the treatment. So in our experiment's case, the effects of variance were non-negligible and needed to be investigated. If smartphones had been around then, we could have tested so many more hypotheses.

This is the reason why I don't fear government surveillance as much as corporate surveillance. The government simply can't process all the data they collect. And the value of obtaining information from the data can be highly variable.

Corporate data collection and analysis efforts are optimized for least cost/highest return. They really don't care about individuals as much as they do classes/tranches of people. However, the most concerning part is when corporations will pass on, willingly or unknowingly, their trade secrets to the government to improve the latter's techniques.

I can't find a closer image of the west Portland area, so I can't comment on the nature of those commutes.

I live in SF, and at work my team consists of ~16 people. Of those 16 people only 3 live in SF (city/county). The other 13 live in the East Bay or south of the city. Of those who live outside the city the majority doesn't get paid enough to live within city limits; the others get paid well but have families and couldn't reasonably afford a large enough home in the city.

People are very willing to convert time into savings (on housing). And sometimes they have no other choice.

> support vector machines and Bayesian learning have been around since the 70s/80s (ninja edit: SVM's since 1963! Markov Chains 1950s, Bayesian Learning/Pattern recognition sine the 1950's), but adoption has been slow due to the nature of business, which is now drooling over it since neural networks beat a few algorithms.

This is one of the things I find hardest about convincing managers and leads of. They think things like CRFs and Markov models are "new" methods and too risky. So they opt for explicit rule-based systems that use old search methods (e.g. A*, grid search), which hog tons of memory and processor. Those methods rarely ever work on interesting problems of the modern day.

They can understand the rule-based methods easily. They have a hard time leaping to "the problem is just a set of equations mapping inputs to outputs, and the mapping is found by an optimization method."

The important thing about the PhD is that you've become an expert in conducting experiments and research. It really doesn't matter what ML techniques you've done, as long as you know everything else associated with building those types of systems. Just hone your research and experimentation skills and you'll be fine.

I do have one suggestion: learn to handle dirty data.

I work with ML researchers and notice two things: they're pretty bad software engineers (no knowledge of software patterns, bugs galore), and they almost never know how to clean their data. The latter is because they do a lot of their research using pre-cleaned, standard data sets. You never get that in industry.

I've seen for rent signs up for over a month in some very desirable locations. That's a change from 2 years ago when I was looking for a place. But the rents are still pretty high for new buildings. The developments opening up in SoMa on 8th street from Harrison to Brannan are asking for $3000/$4000/$5000 (studio/1bd/2bd). I wonder if they're getting that considering those are significantly above median.

I want a 2bd place soon, so I'm hoping that all the young professionals who came in 5-6 years ago are lowering rents by moving to the suburbs to pump out babies.

My current team suffers from disgust of Taco Bell programming. I love it, and I push hard to use it for the projects I lead. I've even had other leads scoff at my use of Python because "the GIL will throttle your application!" Possibly, but I understand the performance requirements of my systems and GIL is the last thing I'm worrying about. I'm not going to write my own programming language, or use one that doesn't have a good ecosystem, because an existing language is deficient in some negligible aspect.

Engineers who build things from scratch do not understand a very profound fact about software engineering: a computer performs menial, repetitive tasks so you don't have to. Be lazy and use someone else's solution.

When I was 14 I remember writing bubble sort from scratch dozens of times, as well as input scrubbing methods and binary search trees. I didn't know about the concept of libraries. Granted the internet (sourceforge, github, etc) wasn't around and I was writing everything in BASIC or Pascal. By the time I graduated high school I understood that writing code was painful.

Consequently, it's sometimes alarming that most systems I build rely on thousands of lines of code that I didn't write and rarely ever inspect. But I have to trust other developers in order to get my work done in a reasonable amount of time. I don't even consider myself a good programmer, mostly because I hate writing code. Nevertheless I do deliver useful, valuable systems. I know my problem has already been solved by someone else. I like being lazy. It's my best quality.

This isn't addressed in the article, but avoidance of Taco Bell programming is a symptom of a disease. The disease is ignorance; mostly in managers who are out of touch with the technical landscape in which their teams work. Any time I hear of a team building their own tools or doing significant amounts of de-novo work, I try to limit my dependencies on that team. You're never going to ship that shit, buddy, but I solemnly admire you for trying.

Then that academic can make a company out of it, and charge $2000/hr. :)

The issue is academics cashing in on their research. I think this is fine in general. Having been through grad school I've worked with professors who I felt placed their entrepreneurial endeavors ahead of their educational requirements. This is an ugly practice. Ethical standards need to be in place to address this. If you're primarily conducting business using your academic credentials, then relinquish your chair to someone else, and take up some "fluff" title and pay your grad students out of your own kitty. Also, pay the university for the non-human resources you use, because it's like you're a hairstylist renting a chair in a salon to obtain and service clients.

I think this is primarily the reason why there's a generation of postdocs sitting on the sidelines waiting for a full professorship. They eventually get bored (and hungry) and move into the private sector, robbing academia of fresh blood and new ideas. So a de facto privatization of research emerges. We all lose when this gets out of hand.