Being a developer or just a good Googler

Scott Hanselman posted a quick blog post about a question he got from a young developer asking “am I a developer or just a good Googler?”  I thought it would be fitting to post it here in my neglected blog.

It’s true that we find ourselves trying to Google an answer often.  In fact, my Google history is up to about 60,000 searches over a few years.  I think Scott has a couple of great points in how to better yourself as a developer.  I try to do project Euler on occasion and I also read as much as time will allow.

I would like to add one more suggestion though:  learn test driven development. I started to do this a couple of weeks ago, and it has really changed how I program.  Test driven development forces development to be more focused on specific problems and solutions to those problems by starting with a failed test. You then program until the test is successful.  Then you rinse and repeat.

It helps you become a better programmer because once you’ve learned how the tests work, there’s really nothing to Google; it’s just you and the specifics of the test.

The internet is a fantastic tool for helping developers do their job faster, but it does allow us to become more complacent. Learning how to actually develop instead of just “Googling” is the difference between good and great developers.

Programmers learning something new: a simple guide

I struggle a lot to learn new programming languages on my own.  It’s not that I’m not smart (I want to believe I am VERY smart) but it’s the combination of lack of time, lack of desire and having no answer to the question: “Great, I’ve learned X… now what?”

I’ve started to learn about Django, and I believe it will be DIFFERENT this time.  Why?  Because I have created a simple guide to learning something new from a programming perspective:

STEP 1: Accept that you may burn out and ask “why bother” and figure out the answer to it before starting

I had stated before:  It’s hard for me to learn something new when I expect to do precisely nothing with it.  This is what happened with me and Ruby on Rails.  Ruby is a cool language and Ruby on Rails was really awesome to build scaffolding with.  However, I didn’t really know what else I wanted to do with it.  I suppose I could have learned it’s cool AJAX capabilities that go with it, but really, it just didn’t appeal to me.  Therefore, it went on the infinite back-burner

Back when LINQ was new, I struggled to learn it as well, because even though I do .NET professionally, I was so knee-deep into what I was doing that it would have been almost a waste of time to really sufficiently learn it.  I finally got a project in which allowed me to utilize LINQ to SQL effectively and easily and since then I wouldn’t know what I’d do without it. Again, once purpose settled in, I was ready and very willing to learn.

Your ‘why bother’ may be different.  Your success may be dependent on how you handle it.

STEP 2: Do the tutorials

These days, it’s pretty hard to find popular frameworks which have no or incomplete tutorials (I’m sure anyone could find examples where this isn’t true, but in general, it’s true).  Also, framework creators know that a quick and simple tutorial is the best chance for a developer to get on board, especially in the framework’s early stages.  Django has a wonderful tutorial, split up into four parts building a poll system (I feel like poll systems are the hello world of the web development world).

Here are reasons why I don’t like to just “dive into the code”:

  • You cannot be guaranteed what you are looking at is the correct way to do it
  • Most of us are lazy, and there may be certain things hidden by shortcuts which obfuscate key basic techniques used by the framework/programming language
  • There is more impact in doing it yourself, seeing what works and what doesn’t, rather than just reading through it and trusting it works
  • It’s less fun!

Tutorials are the best way to get yourself acclimated, set up your environment, and ultimately help you decide “why bother?”

STEP 3: Research technology on StackOverflow

I am a HUGE fan of StackOverflow.  I’ve never met a bigger group of developers, all willing to write great questions and thorough yet quick responses.  The reputation system is awesome.  Any developer not utilizing StackOverflow is SERIOUSLY missing out.

StackOverflow is a great way to see what difficulties most users have, as well as to see how these user’s issues are resolved.  While it’s not immediately helpful, you will drill back into your head, and all of a sudden, you’ll come up to a problem where you say “wow, I remember this on StackOverflow!”

StackOverflow is a great place to see how a technology stacks (get it) up.  For example, a quick search of Django immediately show questions about scalability, whether a user should use Django or X and configuration questions. A few quick searches and research will give you a sense of what type of framework Django is.

STEP 4: Think Small

I picked Django because I had an idea for a website and needed a specific framework.  I discussed the idea with a buddy of mine, a developer who uses Django, and he sold me the benefits of using Django.  I owned hosting which could support Django but not .NET, so it looked like a good choice.  Also, I was in the ‘market’ to learn something new.

Unfortunately, I couldn’t just dive in because I needed to learn Python as well as the basics of the framework.  Therefore, I decided to table the original idea for now and decided to build a personal website for myself entirely in Django.  It took hours to do, I had to read up on a lot of how Django and Pyhton works, but the idea was simple enough to wrap my head around so I was successful.  You should see a site hopefully by the end of next week.  Because it’s my own personal website (and not a large, professional site), it’s okay if it has a few problems with it or if I did it incorrectly;  it’s all part of the learning process.

STEP 5: Have a buddy help you learn

It’s nice to be able to send code to someone, even if it is just a file or two, for them to kindly message you back and say “get out of your .NET world, here’s a better way to handle what you are trying to do.”  Having a human allows you to do a sanity check as well as to see if you’ve missed any nuances.  It’s also nice to have someone to ask for help on really simple yet bothersome problems.  It’s a lot harder to do this using the Internet.

STEP 6: Have fun!

Every blog post with steps needs a cop-out answer.  Here is mine.  Most of us are learning new languages because ultimately we want to.  You should have fun with your learning experience!


Sad dogIf you are an IT professional interacting with another department, you’ve probably been in a situation where they just weren’t getting your pitch.  “Why can’t they just understand the problem!” you probably say to yourself.   “They just don’t understand the benefits of the solution!”

How do you make your point and keep cool in the process? I’ve come up with two lists: one to facilitate why we get these responses and one to better facilitate the discussion.

What is going on:

It’s not about how smart you are.  You both have different expertise. Do you always trust your mechanic’s opinion? Have you ever second guessed your doctor?  Ignorance can invoke different reactions.  Some people will not trust an opinion until it has been explained in a way they understand. Let’s say you were buying a house for the first time.  You go and try to understand the process.  There’s so much information that it’s natural to get frustrated and question the process.

Don’t take it personally. We as human beings take things to heart more often than we should and we tend to read into criticisms as a personal attack.  According to You Can Be Happy no Matter What by Richard Carlson, we tend to interpret criticisms based on our thought systems, which is generally not the reality.  Accepting the actual reality of the opposition rather than interpreting its intent will allow the conversation to be more subjective and thus, more productive.  This not only works for IT professionals, but for any professional in a similar situation.

They may be insecure. Someone comes into your workspace, starts discussing a project and you just don’t know where they are coming from.  It makes you feel anxious, nervous, and sometimes, combative.  When you are on the giving end of these conversations, you tend to misread the confusion as either disinterest or anger.  Being IT professionals, it’s easy to be on the giving end of this exchange–  not because we are smarter, but because we have a more specialized position.

You may be insecure. Perhaps you are not 100% sure your solution is the best one for the problem, but it’s certainly the best for you.  You pray that you have an easy sell so that you can do it.  If you are that unsure of your solution, perhaps you should rethink it.

Just like you, they are trying to get their jobs done. This is especially important when everyone is under time constraints.  IT has a nasty stereotype of being that jerk IT guy from SNL or the policy police.  They don’t want an explanation of the reasons why you cannot do it, they want a solution.

What to do about it:

Prepare in advance for the conversation. Do anything to help prove your point.  Remember, you are trying to sell a car to someone who knows nothing about cars!  My suggestion is to quickly bullet out the points you believe would help you explain your point better.  Simplified diagrams and analogies also work, but be VERY careful to not insult their intelligence.  Remember it is a two-way street– picture yourself getting an oversimplified explanation about something you need to know about.  You’d feel insulted and silly.

Try to fully understand what their issue is first. Sometimes you can avoid having the “technical conversation” altogether if you can come up with a different and simpler solution to their issue.  It may not even be IT related.

Accept the fact that they may be right.  Perhaps it is you who have over-analyzed and over-complicated the problem.  Sometimes the “why don’t you just do x” is the answer.  Opening yourself to this possibility early on in discussion can prevent unnecessary arguments and wasted time later.

Only discuss alternatives if they are viable solutions. Keep in mind these discussions’ purpose are to move a project forward; not to prove to the other person you’ve done your homework.  Unless they’ve specifically asked you to look into a situation, don’t bring up solutions you think are not going to work.

Keeping these thoughts and tricks for you will yield a happier you, a happier them, and ultimately, a stronger work relationship and environment.