johnkchow

I like the clear distinctions you've set between a manager and leader (very well written).

I'd like to push this further and claim that a manager in a company has two roles: one that fulfills the business needs of the company (keeping the machetes sharp), and the other to have vision and lead the people (climbing the tree). A good manager has to also be a good leader. The converse isn't always true, and I've seen many "good" managers (from a business sense) get resented by the people by the people they're supposed to manage.

Got to say this is hard to admit, but after reading everyone else's comments, I am indeed ignorant. Thanks for the reality check.

From my personal experience, the saving in development time is very much real.

I used to work on .NET, and you'd have to program against crazy, non-intuitive patterns in order to have your code "clean" (I hated IoC containers as well as writing all that boilerplate code for Attributes. And for Java, remember that hilarious post about Factory-Factory-Factory patterns http://discuss.joelonsoftware.com/default.asp?joel.3.219431?)

I'm not saying statically typed languages are bad. Type errors always bite me the ass in Ruby, but it's a small price to pay (IMO) for better maintainability.

EDIT: By the way, it sounds like I'm an ignorant dynamically-typed lover. I'm not, I still yearn for those type safety net, but I'm just speaking from a pragmatic perspective.

In retrospect, I too went through a short burnout period. I was the only server engineer in my startup, working 10-12 hours 6 days a week. On top of that, I was leading a personal project to help college student organizations stay more organized. It became too much, as all the little micro-failures just rolled up into a giant ball of frustration and stress.

My bosses at my startup immediately recognized it and told me to take several days off. Since then, I've consistently made personal time everyday to keep my perspective in check: read a book in the morning, workout in the afternoon, meditate for 5 minutes, and leave work promptly after the expected amount of hours.

To get myself back into "beast mode" (which others would call "the zone"), I've done what some other commentors suggested: learn something new. For me personally, I decided to take on essentially low priority micro-projects within my startup that are interesting problems (i.e. integrating DynamoDB within an EventMachine process). I've built up my confidence back to near what it was before, and I'm feeling damn good these days.

I have one thing to say: Finally.

To give some context, my first job out of college was in a small WebForms/MVC shop in LA. It was very progressive in that my managers always pushed me to question the conventional "MS" way of programming/architecting. However, what frustrated the hell out of me was all the other MS companies around us: they were so damn dependent on what MS gave them.

I've heard countless MS devs in local meetups screaming bloody murder when MVC first came out, "Microsoft, you HAVE to train us on MVC! It's a black box, we're effed!" This shocked me, because these people wanted to literally be force-fed with MVC. Microsoft (intentionally or not) encouraged this kind of behavior with their close-mindedness, and this dependency/babying was crippling to the MS dev community.

Accepting pull requests signifies a tremendous step on MS's side, because they're finally admitting that there are actually smart developers OUTSIDE OF MS BUILDING who can help out with the framework. Their closed-software drove me away from them to RoR. Now, I have some peace of mind knowing that the bleeding of good devs away from MS stack may finally slow down. I can't wait to see the next generations of Scott Hanselman and ScottGu pushing the envelope for MS.

I started my career in MS ASP.NET WebForms/MVC, and then recently switched to RoR, and it's obvious that they're mimicking the success of RoR development environment and, more importantly, the culture. Their Nuget packaging system is pretty much RubyGems + Bundler. Last year was the last time I touched MS stuff, and it was pretty raw and not ready for the masses yet. With people like Hanselman and ScottGu pushing the MS culture towards more open, I'm hopeful for the direction of MS's Web stack.

antirez, thanks for the objective look at Redis's internals. As a young engineer 2 years removed from college, I feel these articles serve more to us young'ns with lots of knowledge gaps.

While it's not Rails, one of my favorite DynamoDB articles was Twitter Streaming with EventMachine and DynamoDB (http://arfon.org/twitter-streaming-with-eventmachine-and-dyn...). I see one huge strength of DynamoDB is its flexibility for analytics drools

One of the very first things I learned almost immediately after college is that inheritance typically is a bad idea and that composition is a better strategy. With inheritance you have so much thinking overhead with parent to children relationships when most abstractions could easily be viewed as building it through small pieces. Its sad but during my 5 years in UCLA I have not heard the word "composition" once.

I agree that in Jack's specific examples you don't need the constructor: the constructor trivially saves the parameters into instance variables. However, one thing that hasn't been mention is when the setup of the class is non-trivial, which most likely requires breaking it down its helper methods that's only specific to that class. Exposing those helper methods outside of the class can potentially add as much unnecessary complexity to the code base (i.e. is this a helper method for another method or if this is standalone method, how does this fit into what I'm trying to achieve?). Yes, this could be mitigated with good documentation, but classes exist for this specific reason.

One concern I have with Jack Diederich's video is that he never addressed one benefit of classes: better testability. In his Muffin example, he took out the instance variable that stored the API URL and created a constant out of it. If I had an URL for my staging environment, and another for my production environment, I'd like to programatically set that instead of going back into the code, modifying the constant value, run the test, and then change the value back to the original. That's just a bug waiting to happen.

This isn't to say his underlying message is wrong (I 100% agree with Jack's message, too much classes create unnecessary complexity in your library/app), but I don't want people destroying their classes without fully understanding the consequences.

It really depends on what your end goal is. Building a quick prototype doesn't need documentation, but building a long-lasting app that's maintainable and scales well with a growing dev team, documentation is extremely important.

I've never had a production Rails project, but do you have any anecdotes or numbers to back up your statement? From initial glance, it looks like the win in processing speed outweights the complexity. So then you're implying that this win isn't required. I'm assuming that scaling out is cheaper than the complexity cost of implementing/maintaining such a caching solution?

People need to understand that decisions should be made based on the team's current skill set. If your team is comprised of Java developers, time shouldn't be wasted on researching node.js; rather they should focus on how to leverage their Java knowledge with Scala. It frustrates me to hear people falling for the hype machine and falling hard when they could have easily avoided by asking themselves two questions: what's the path of least resistance to shipping our product out the door, and what's the opportunity costs relative to alternative paths?

At my startup, we have talked about this issue several times about how we can fairly compensate employees for their contributions to the company. Our company is a bit different in that we have a lot of young employees who are eager to learn and believe in the vision rather than people who maximizes reward and minimizes risk. Because of our employee makeup, we're adopting a revenue sharing plan. In my eyes, that's as fair as you can get: getting a ton of experience with the latest technologies for a temporary cut in pay. As a lot of commenters have said, it really depends on your situation, but I believe the reward is potentially great if you're a young engineer who's seeking a long-term reputation as a good programmer.

(And for those of you who think I am mad, my company is great in that it's fun, the work is extremely challenging yet exciting, and the vision aligns with my own personal vision. It's my dream job.)

I now see the true potential with personalized search. Just gives me the goosebumps (in a good excited way). Thanks for sharing!

I have to agree that PP loses value when you have many senior level programmers on the team. The biggest value in PP, in my personal experience, is transfer of knowledge and experience. This applies mostly to teams with huge gaps in experience (juniors vs. seniors) or new team members that need to be caught up to speed with the codebase.

If the talent level is the same (and by talent I mean having the innate passion and ability to learn, not having actual knowledge) the knowledge of the collective team members will eventually equalize through the initial PP sessions.

Like the author said, the context of the team and the general strategy of the company (i.e. maintaining a project vs developing new features) are the most important signals when determining the programming tactics (i.e. PP and self-learning) to reach those goals.

P.S. The link at the bottom of the article (http://blog.jayfields.com/2011/08/life-after-pair-programmin...), provides two great team contexts for when pair programming succeeds and when it fails. Definitely take a read on that.

These ads serve a secondary purpose of reminding people that Wikipedia's wealth of information originates by public knowledge. A lot of people tend to take knowledge for granted, and I personally feel humbled and grateful for Wikipedia from their ads.

I know this isn't exactly answering your question, but if you deploy on an Amazon EC2 instance, you can use MongoHQ's shared hosting in conjunction to your pre-existing Node provider. MongoHQ runs on the AWS infrastructure, so the latency between your Node server and MongoHQ is insignificant (we use EngineYard with MongoHQ and the latency for a simple small read is anywhere between 1-5ms).

Make sure that the regions match up though! :D

It really depends on your work ethic and mentality towards doing extra work. In order to become fully prepared after college, you need to have a) a deep passion for programming (i.e. personal programming projects), b) great work ethic to continually learn new things (i.e. tools, languages, etc), and c) the ability to search out fellow programmers and get help. If you're confident in the things I've mentioned before, then regardless of what degree you graduate with you'll be fine.

However, if you're not sure which industry you want to work in, not mature enough to learn and program on your own, or even if you're unsure about whether you can handle the class workload, I say bite the bullet and take the 5th year. I graduated class of 2010 after 5 years, and I have to say that if it wasn't for that extra 5th year I wouldn't have matured enough and been prepared mentally or emotionally for those job interviews and the working lifestyle after college.

Additionally, all the classes definitely provide some value to you, even though it's not obvious at first. For example, I took a compiler class in my 5th year because I was interested in how a language is constructed and then broken down into low level code. Although I never work on low level programming (I do server engineering with Ruby on Rails), the exposure of compilers and language grammar helped me understand how Ruby conceptually differs from other languages and why Ruby is better (or worse) than other languages in certain situations.

So in conclusion, if you're determined and know where you want to be 3 years from now, don't worry about whether you graduate in 4 years or not. However, if you're unsure about the things mentioned above, consider the 5th year without worrying yourself about the money. As a programmer, you'll do just fine financially.