apaitch

I dunno, either you will reformat using some kind of automated tool before you check in or you won't.

If you will, then why not do it before the review and spare everyone the trouble? In a codebase that conforms to certain standards steps away from the standard stick out and distract from the content.

If you won't, then maybe it's good that people point it out so that you can fix it manually?

Of course there is a difference between a comment saying: "Nit: Trailing whitespace" and "According to Section V, Subsection VII of the Coding Manual you should never add trailing whitespace. Please see that you don't." or some stuff like that. The latter is a passive-aggressive potshot, the former IMO is just a quick reminder.

Thanks a lot! I'll definitely check some of these out!

I don't seem like a good fit for any of these positions (Java/C++ engineer >.<), but I'd love to learn more about database internals and how things work and how to make them better. Is there much to do in that area, or is it pretty much complete? Should I just pick a bug and try to fix it, or is there some process to follow >.<

Let's say I'm lazy. Sure, maybe I "haven't found what I'm meant to do" quite yet, but if I'm lazy AND armed with the "I don't want to do it - the universe is telling me not to!" rhetoric then how will I ever find something I love? You have to be willing to invest effort into things that hold your interest, but until you've done something for a while the aspect that holds your interest is the result and not the process. For example, I didn't get into programming because I loved programming. I got into programming because I didn't know what to do and I thought making video games would be cool. After a couple of semesters (yes, this was late in my life >.<) I realized that hey, programming is actually quite enjoyable! Now I try to invest in opportunities for self-improvement in the programming space (among others).

"Self-help books and workshops arm us with ways to trick ourselves into doing things we perhaps should, but generally don’t want, to do."

That seems like quite a generalization. I get that it's hard to create a catchy title without making some form of generalization, but... really? I guess the author is talking about workshops like "How to write and sell your awesome novel in 7 days", but what comes to my mind when hearing "self-improvement" is something like the 7 habits. I hardly saw the latter as an attempt to trick myself into doing things I don't want to do.

That's part of the reason I put visionary in quotations. It's a slippery term. In this case, when you think Steve Jobs = visionary you don't think "he made Apple a great place to work." Since Steve Jobs seems to be one of the paragons of "visionary" leadership in the valley, all I meant to say was that Marissa is not in the same mold.

As I said, I barely know her/of her so my opinion is based on superficial things like reputation. The main point I was trying to make is not that she's not a "visionary" but that the things she's doing to help Yahoo are admirable and worthy of praise >.>

That's actually what I'm trying to say - she doesn't come off as a visionary (in my opinion) but if she is able to set up a good and healthy work environment then she won't need to be the one coming up with all the ideas.

I know almost nothing about her, but Marissa Mayer doesn't come off as a Steve Jobs or Elon Musk-like "visionary" who will drive Yahoo to unexplored and unexpected market openings. Her approach seems to be to make Yahoo a great place to work, attract and empower talent, and let said talent churn out great products. Some would say that she should focus on changing the market direction of the company, and that's certainly one of her responsibilities. At the same time, I think what she's doing is admirable and valuable. It's certainly putting Yahoo on the map in the communities that matter. Let's hope Yahoo can ride this momentum and make something of it!

Commuting does kind of suck if you're trying to roll in during rush hour. But without super-heavy traffic I find driving to be rather enjoyable in itself. Even more so if you're riding a motorcycle :) Perhaps the problem is not commuting, but the fact that many companies want their employees at work at 9:00 and out of work at 5:00?

Most people want to get the promotions and the money, but I think it's not only to buy the materialistic stuff they want. For many white-collar workers it's about the prestige, the status, the self-validation, and the respect these things tend to bring about. I think the thesis of this article applies to these "emotional" indulgences as well. I'd say if you respect yourself and have a sense of inner peace AND you acknowledge that you don't NEED to go from $75,000 to $175,000 (though of course it'd be nice) it gives you a kind of freedom from the shackles of what goes on at many a workplace. You can develop your skills because you enjoy getting better, do good work because you like what you do, and often get a promotion and more money as a byproduct without having to focus on it. That's one of the good things about the programming field :)

With regard to the "giving", I wonder what theories there are about why many people feel good when giving things up to benefit others. Is it just a societal/cultural thing, influenced by religions?

I think that spending 4-6 years doing research in an area you love is something anyone would be interested in. In addition, going into it with the decision that you don't want to have a career in academia would free you up from much (though of course not all) of the "game." The OP echoed this sentiment in the memoir. You can go to conferences without worrying about proper "networking" and just talk to people. You can focus on research that interests you even if it's not a "hot" or "prestigious" field among academics, as long as your results are publishable. You still have to bend to the system in some regards if you want to graduate, but I think not having to worry about securing a professorship would really take a lot of the weight off. In fact, I would consider doing a PhD under these conditions :)

I didn't mean to get into the debate between natural talent and skills acquired by work - probably should've cut the "natural" part out of the definition to make that clear. I was thinking of the "potentiality" aspect of talent. I agree that employers want capable employees - preferably able to contribute from day one. I think investing in employees who have the potential to be great contributors but are not quite there yet is worthwhile, and is something that's under-emphasized in most recruitment strategies. To me, "talent" is when a master finds an apprentice he knows could be great with the right guidance. The job market demands masters (dubbed "talent"), but few are willing to help create masters by actualizing the potential of those who are less experienced.

Note: I'm not talking about on-the-job training from someone who doesn't know what a computer is to a master programmer. I'm talking about allowing people who are less immediately capable into the workplace and mentoring/growing them into strong contributors.

From the outside looking in, it certainly doesn't seem like everyone is eager to snatch up mediocre graduates. I can't say I've done much research on the subject or crunched numbers, but I noticed two things: 1) Complaints about "talent shortages" from top companies and startups in the Valley and otherwise. 2) Companies evaluating people based on experience, GitHub profiles, open source contributions, etc.

Not that it's wrong to evaluate based on that criteria. However, for people like the hypothetical John it's quite hard to keep up with a good CS program and manage to do impressive things on the side. So you end up with people with strong potential, much of it not yet actualized, who spend the first years of their careers in a job of questionable usefulness (excel macros?). I think there are more of those people than commonly assumed, and I do think they can contribute well in much better places. They may be slow at first, but give them 6 months and they will be strong members of the team. Granted, a startup may not have 6 months to give, but once you've got some resources under your belt a green-but-talented engineer can be a great investment.

It's totally understandable for a 10-man startup to not want to take in a relative newbie and have him/her drag down the team's productivity when they've got to ship in a month. However, for bigger companies (not necessarily giants like Google either) it may well be worth it to invest in a number of somewhat less experienced employees and grow them internally. The only problem, I suppose, would be selecting the right people.

What happens once a person encounters programming is a different story. I tried, with seemingly mixed success, to portray Jon as someone who is indeed interested in coding - enough to try stuff on his own, and certainly not on a "just to get by" basis - but who did not discover this interest until he picked his major (arbitrarily, perhaps) and actually tried it. Adjusted for age difference, Jon is about as excited about programming as Norman was, but encountered it much later. I think there are many reasons why one would or would not encounter programming at a younger age AND in a manner that excites him (parents, friend circle, alternative entertainment available, neighbourhood, school/teachers, etc). In aggregate, they come down to luck.

Are SF and Silicon Valley really that different? Isn't Palo Alto like a 30 minute drive from SF? I know of people who bike the distance as a daily commute. Sure, there are advantages and disadvantages to living in and outside the big city (SF), but "why SF and not Palo Alto" seems to me like a rather unimpressive and, perhaps, not terribly important question. Something like "Why Silicon Valley?" may spur a far more interesting discussion :)

Team Liquid is a rather popular professional gaming team, especially in Starcraft 2. I doubt anyone would end up on their website not knowing who they are (why would you go to teamliquid.com just for kicks?) so it's not that bad of a flaw.

What would people do if, as you say, everyone gets into it just for the money? Would enough people consider leaving somewhere else?

This kind of thing - not the exact events or people described, but the atmosphere conveyed - is exactly what's been turning me off from Silicon Valley. I've interned here twice, and I know that it's full of the top engineers in the world. Yet the underbelly seems to be full of these ridiculous cutthroat business practices and an atmosphere of self-indulgence, self-importance etc, most likely because Silicon Valley is where the money is. It seems like it's turning into the Hollywood of the tech industry, and not in a good way. T'would be a shame.

Open source software and free software are two different things, and Stallman is an advocate for the latter (as well as the former). I think that's an important point, and one which people tend to miss.

I learned Scheme in my intro to programming course and I loved it! It was very lean, simple and straightforward. No voodoo, everything is explainable, and an easy substitution-based "debugger" to step through your code.

On a side note, I don't think modern-day students will ever be exhilarated when they get "Hello World" to appear in command-line output. In the day of Pixar films, 3D games, etc the simple outputs are underwhelming. The exhilaration comes from making a program that solves a problem (real or artificial) and overcoming challenges along the way :)

A wise man learns from the mistakes of others, yes. But you don't have to be doing what everyone else is doing to learn from their mistakes (otherwise you wouldn't be learning from their mistakes, but from your own). Also, if, as you say, you follow others and do what they do it's not really based on data either until you get enough experience to know what works and what doesn't. After that your "data" will be the sum of past experience and observing the successes and failures of others. It's really the same process if you follow your intuition.

I think the misconception is that following your intuition HAS to mean NOT following the herd. That's only true in the sense of making up your mind and choosing what it is you want to do regardless of what other people are doing. If this happens to coincide with the herd's behaviour it doesn't make your behaviour herd-y (=P). The difference is the "why", not the "what". You're acting in a certain way because that's what you decided to do based on, say, intuition, or based on what other people are doing (or a mix of both). What it is you're doing may be exactly the same as what others are doing, but that's secondary. And I should say that living according to your inner voice really isn't that difficult/frustrating. In fact it's somewhat liberating to do what you want to do as figuring out the herd and convincing yourself to follow it takes more mental energy (in my opinion/experience, of course).

Lastly, when talking about "learning what works and what doesn't", it's unlikely that you'll learn about things that really work from those that follow the herd. It's more likely that you'll learn from those who lead the herd - and those people do it by following their inner voice.

I'm not sure I can fully agree with the idea that programmers are self-taught in the sense of writing good code. I'm a student at the University of Waterloo, and in the courses in 1st and 2nd year a sizeable chunk of the marks depends on readability/documentation and such. We have coding guidelines and we lose marks for not following them. Needless to say, this doesn't mean most students at Waterloo write good, well-documented, readable code. Most of them are focused on getting the program to work, sprinkling in obvious comments (i.e. "//setting width to 60" ) and debugging when the tests fail. When they get marks off for poor documentation/readability they either complain or brush it off, claiming that since their program worked the rest isn't a big deal.

Bottom line: in my experience, the reason most programmers are self-taught with regard to writing good code is not that no one tries to teach them. It's that most of them don't think they NEED to know (i.e. don't place enough importance on it) and are willing to lose marks for it until they get to a job and they have no to choice but to, you guessed it, teach themselves. There are people who try to make the best out of their education, and these can be very good coders who learned by making the best of their education.

(Note: obviously this is a generalization - there are plenty of students who try to write good code.)

I would like to think that there's a happy medium between these extremes, especially considering that cleverness is not necessarily equal to incomprehensibility. Choosing the best tool for the job and writing clean code can be just as satisfying as writing clever code, and the two are not self-exclusive. I think one can take joy in writing quality software - one that works, one that does its job, and one that other people can understand and extend.