Everyone will be a programmer one day

We are currently in the first evolution of computer programming.  But we are seeing the beginnings of the second.  The first evolution was based on humans learning to program. Many industries have been revolutionized by technology, many more than once.  But there are still many to go.  Part of the problem is that people in technology are not as heterogeneous as society and that leaves gaps in knowledge.  Over time those gaps grow smaller but it can take awhile.  Being able to program is powerful because it allows you to build solutions for yourself.  Every industry has problems which can be solved or improved by software.

When I was coaching/playing for the MIT Graduate Men’s soccer team I got to meet a lot of really bright people who had the opportunity to travel, study and innovate in important industries.  Many of the post grad students, especially in the science field, had learned to program out of necessity.  Their main response was similar to, “i am so much more productive and/or thorough with my work”.  Most of these guys had learned it very late in their academic career, but I realized that this type of training will make it into many more career tracks.  Steve Jobs once said in an interview that he believed everyone should learn to program.  He believed that programming should be a required skill to learn in school.

Everyone will not become a programmer.  But I believe many more people will have the ability and access to program.  There are many examples today and it is trending upward.  There are high level language frameworks being created to allow non-programmers to program systems.  Services like CodeSchool are enjoying a big bump in traffic from people wanting to learn to program.  It should become a core class in high schools if it hasn’t begun already.  Programming is a versatile tool.  It is not like a mathematical formula that you learn and apply in certain situations.  It is not a war that you learn about and recount later.

Programming is a tool to solve problems.

Don’t get me wrong.  Programming well is hard.  Especially when you are trying to architect large systems.  But in many circumstances that is not needed.  Small programs for repetitive tasks or calculations don’t need much design.  But they can be extremely useful.  Once people in various industries start to learn programming early in their careers, that is when we will see another step function in change in those industries.  The best problems to solve are the ones you have yourself.

Technology has always been about revolutionizing industries.  Many industries come later than others and some have been changed more than once already.  Once we can arm everyone with the proper tools to solve their own problems, is when we will see another large return on investment into programming.

Discuss on Hacker News.

Advertisement

Every Software Engineer Needs Rules To Code By

As software engineers, we make lots of decisions on a daily basis.  It is definitely a skill that you can develop and improve upon.  From my experience, you get much more practice at this skill in a startup.  You get to build a lot of new software with not much guidance.  Many times you need to pick the technology/library/etc before you even start developing a solution.  I feel my decision making has improved tremendously in the year that I have worked for a start-up.  There are many ways you can improve your decision making ability.  One helpful mechanism for decision making, is having a set of rules that you live (design/code/test/implement) by.

Every software engineer should have a set of rules they live by.  Most developers have 0 rules when they finish university and start their first job.  The main reason for this is that we “gather” new rules through experience of screwing things up.  And I am referring to those bugs or time wasters that really cost you or your company time and money.  In school, you usually aren’t working on large pieces of software or mission critical features.  You also don’t own code for a substantial period of time usually.  So you don’t carry the burden of bad code or see the result of bad decisions.

The typical scenario goes something like:

1. Create and release some feature
2. Something very bad happens. (e.g. bug costing thousands/millions, spend 3 days debugging a problem, spend 3 extra days refactoring, etc)
3. You fix it.
4. You think to yourself, how do I not let this happen again.

There are a ton of other ways it happens, but from personal experience this is the most common scenario.  So people amass rules depending on the experiences they have had.  Very rarely do we learn from someone else’s mistakes.  One of my favourite quotes:

“Smart people learn from their own mistakes.  Smarter people learn from other peoples mistake.”

I think these rules are important to have because they help prevent mistakes and make decisions easier.  The less questions you have to ask yourself, the less decision fatigue you will experience.  Leave your decision making power to the more difficult decisions.

Without further adieu, some rules off the top of my head.

1. No code change should go untested.  No matter how small or trivial.  I don’t mean unit test every single line of code, but see it work.  Too many times I decided not test something because it was too small or trivial.  Then subsequently it broke in testing or production and I looked really dumb for not performing a basic test.  I have seen this happen to other engineers as well.  It usually is painfully obvious that no testing was done.
2. Don’t try to predict the future.  I have spent too much time thinking of what might come next when developing certain features.  I have been burned implementing extra features (feature creep) and then throwing it all away anyway because the system was going to be used in the way I foresaw.  This is especially true for marketing oriented organizations as they tend to change their mind a lot.
3. When you can’t decide, just pick a route and go from there.  I used to spend a lot of time comparing 2 different approaches to a problem.  Often there wasn’t an obvious winner and I would spend too much time splitting hairs.  Now, when I realize that I am doing this, I pick a solution and go from there.
4. Have more than one solution.  I read somewhere that having only one idea is dangerous.  Too many times I have implemented a feature only to have a co-worker suggest a different (more logical) approach which had me scrap half my code.  Now I try to think of these before I start designing.
5. Behave as if things will go wrong.  I know this is on the “glass half-empty” side, but this sort of thinking has helped me.  How many times have you finished writing a piece of code and went to run/test it and it worked first try?  You will start to ask yourself valuable questions such as; how can this break? If it breaks, how will I know?  how will I debug it?

These are a few that I have learned and wanted to share.  I am still early in my career and I am sure this list will grow!

The Ruby Way == Idiomatic Ruby

Almost 1 year ago, I joined a great start-up Thinknear (acquired by Telenav).  From a software engineer’s standpoint I did a complete 180 in the direction I was heading (outside of the fact that I was dabbling in Project Management at my old company Vistaprint).  

My previous company, Vistaprint, was a .NET shop for the most part.  I worked with C#, VB.NET, ASP.NET, IIS and MS SQL Server.  When I joined Thinknear, it was completely different.  We used Java, Ruby on Rails, Heroku, Apache Tomcat, Memcached, etc (the list could go on for awhile).

Anyways, I took learning Ruby to heart.  It had be awhile since I learned a new language and it was quite different than anything I had done before.  As I mentioned in earlier posts, I started from the ground up with tryruby.org.  I had about 3 weeks between knowing I got the job and starting the new gig (mainly because I had to transfer my visa).

I remember my boss (if you can call him that on a 3 person dev team), told me you can always spot a new Ruby person who came from an OO language.  It was hard for me to understand at the time, but now I get it.  I feel I am in a position to help the Ruby new comers.  So I want to introduce you to the “The Ruby Way” (a.k.a “Idiomatic Ruby”).

When I first started at Thinknear my code reviews were painstaking.  My teammates didn’t let up in learning Ruby and they made sure I would do everything properly.

The one thing that helped me the most was writing done every non-idiomatic mistake I made on code reviews and made sure I looked over the list before I submitted to GitHub.  I made very few mistakes more than 3 times, which believe me…was a HUGE step up from where I was coming from.

I am only 1 year into Ruby, but I am loving it!  It is a very natural and concise language.  It also helps you focus on the core algorithms and problems instead of a lot of other nuances in other languages.  I will be soon be ready to read my Metaprogramming in Ruby book, which will be fun and probably mind bending.  But here are my list of Ruby/Rails Idioms that I learned early on (low hanging fruit):

1. Ruby Style Guide – essential if you want to contribute to projects
2. Your best friend which you will be using a lot: http://ruby-doc.com/
3. Your best friend which you can try anything: irb
4. Do not use for i = 0; i < array.size, i++ etc…. use iterators!
   • Iterate over each element array.each { |element| puts element }
   • Iterate over each element, but transform each item: array.map { |element| element + 1 }
   • So many cool iterators: select, reject, inject
5. Do not use array.length > 0 or array == nil
   • array.present? is the bomb! It checks for nil AND to see if there are any items in the list (Rails only) – this also works for hashes
   • Checking for nil on any object? Use object.nil?
   • Checking for emptiness? array.empty?
   • Opposite of empty? = array.any?
6. Worried that something might be nil? try is your friend! Especially useful for hashes: Instead of hash.has_key?('missing-key') && hash['missing-key'] == value you can use hash.try[:[], 'missingkey') == value). Try will return “nil” if it can’t return anything.
7. Need the opposite of a condition? Do not write if !condition ... end , but instead use unless! unless condition ... end
   • Bonus points for writing conditionals on single line: do_something if condition

That is all I can think of, but I wanted this to be short and sweet and introduce some glaring Ruby newbie mistakes.  There is so much to offer in the language and I hope you have as much fun as I do!