One Role Per Subroutine/Function - Best Practices Series

If I write the following code:

  call openFile "myFilename.dat"
  call writeDataToFile
  call closeFile

I have three different subroutines that I am calling.  The first call should open a file name named myFilename.dat.  It should not do anything unrelated to opening that file.  The writeData call should only write data to the file.  The closeFile call should only close the file.  These subroutines might have some related code that makes sense for dealing with files specific to the application, or some debug logging code or the like and that would probably be fine.

But if sub openFile also opens a graphics window, or if it reinitializes a bunch of variables, or anything else that is not directly related to opening the file, that code is probably in the wrong place.  Such code should be moved to its own subroutine.

Why is this important?

One important idea in software development is called the principle of least astonishment.  As much as possible when I read code I expect that it should do precisely what it appears to be doing.  Nothing more, and nothing less.  Trying to avoid "What the ..!?" moments is an important goal in programming.  It saves time and money and makes people's lives easier.  :-)

Sometimes code is initially written very clean and in a way that is compatible with this idea of one role per subroutine or function but over time it gets polluted and things get into the code which violate this principle.  This is especially common when debugging because it's easy to write code during a heavy debugging session that you would not normally be willing to write when you're not debugging.  Then once the bug seems to be gone we are less willing to move that 'debug quality code' to the place where it belongs, or we are not sure how to do it.

Of course if you write a program such that there are no named subroutines or functions then your program is in danger of being a Big ball of mud (see https://en.wikipedia.org/wiki/Big_ball_of_mud).  If you discover that this is the state of your work, your code can be greatly improved by beginning to identify sections of code that can be moved into named subroutines or functions.

As a counterpoint this idea if you find that all the programs that you write are small one page long games or utilities that you bang out in a few minutes, then your programs might only be a small ball of mud.  In this case you might not really benefit very much from trying to break everything down into small named subroutines.

No Software Degree? Don't Let It Stop You!

I saw a an article over on freecodecamp.org where the author tells his story about getting a development job without a degree.  I think it is so inspiring when people share their stories.

I also am an un-degreed software engineer and I’ve been working in the industry for more than 30 years.

I assume that if you are ready to jump in to software development without doing a 4 year program, that you are passionate about writing code! If that describes you, read on!

Here are some tips.

• Don’t let anyone tell you that you NEED a degree. You can go and get one, sure and if that’s what you want, great. Go do it, but it will take you years and a lot of money.
• Read a lot. Consume as much programming literature as you can. Read conference proceedings. Read code. Read the History of Programming Languages, read archives of Dr. Dobbs Journal. 
• Learn several programming languages in different paradigms. I’m familiar with BASIC, 6502 assembly, Forth, C, Objective-C, Java and Smalltalk. Don’t be a one trick pony.
• Make your own software. Participate in open source projects so you can learn team programming skills. Code with friends. Create your own applications. Write some video games. Try your hand at programming tools. I wrote Liberty BASIC (a popular programming language) in my spare time and now I sell it. If you have a dossier of interesting stuff that you’ve done, it will be easier to get hired. Haven’t done anything interesting? The degree may not be enough.
• Network like crazy. Almost every job I’ve landed I landed because of people I met at the store, at church, at conferences (that I paid to attend myself), etc.  Join some programming groups on Facebook and meet local people using meetup.com.  This can be really important.
• Be ready to explain what you know. When you do get that interview, who will hire you if you can’t show on the whiteboard what you learned from your work. Give them a post mortem on your own code. Be ready to say what you could have done better.

Good luck and please check out my Liberty BASIC product!  http://www.libertybasic.com

See you around!