Google App Engine – Final Thoughts and Comments
So now that I’ve officially finished my Google App Engine series (which I hope you will all find useful and applicable), I just wanted to share some final thoughts I had on application development, and provide a little motivation for why I decided to move away from a purely-Android-focused blog.
My school of thought for software engineering goes along the lines with this (in my opinion) spot on Techcrunch post:
In it, the author talks about how “a great coder can easily be 50 times more productive than a mediocre one, while bad ones ultimately have negative productivity” and I think this is a sentiment that’s shared across many recruiters and start-up founders in the bay. So now the question is, what does it take to be a great software engineer, and for recruiters, how do you find these great software engineers?
For those of you who have interviewed with tech companies you’ll know that the typical tech interview consists of maybe one or two brain teasers followed by a slew of algorithm-based questions (how do you reverse a string? what’s the run time? etc) and random one-liner language-specific based questions. However, is this really the best way to pick out a great programmer?
I would argue no.
“So what should a real interview consist of? Let me offer a humble proposal: don’t interview anyone who hasn’t accomplished anything. Ever. Certificates and degrees are not accomplishments; I mean real-world projects with real-world users. There is no excuse for software developers who don’t have a site, app, or service they can point to and say, “I did this, all by myself!” in a world where Google App Engine and Amazon Web Services have free service tiers, and it costs all of $25 to register as an Android developer and publish an app on the Android Market.”
Sure, every competent programmer should have a strong understanding of algorithms, run-time complexities, data structures, etc. But more importantly, every great programmer should be a great problem solver.
Sometimes this might mean knowing what the most efficient algorithm is, or what the most natural data structure is. But many other times, this may mean knowing what the best platform is for your back end or front end: being able to think ahead, and see the application from a macro-perspective. Many times this may mean knowing when the best solution is an ad-hoc solution, and when the best solution is a well-thought out, efficient solution: when it’s okay to ignore the ugly double for loop and push on for the sake of application as a whole.
At the end of the day, a great programmer is a great problem solver – and problem solving isn’t limited to algorithms.
And so I encourage you all to leverage the plethora of tools available to you today and build, build, build! Build until you can see and think about an application, not just as a back-end engineer, or a front-end engineer, or even a product manager, but as someone who can traverse the roles and see the entire application from above: where it is right now and where it needs to be 1 week from now, 1 month from now, 1 year from now.
Think like a problem solver, and love the journey along the way.
Until next time, happy coding and happy holidays.