Internship or Apprenticeship?

What’s the difference between an internship and an apprenticeship?

Internship

An intern is someone who:

• usually wants to explore many options for their next job, or career in general
• may be unpaid
• is probably in school

A company who hires interns:

• often has special project work that is a good fit for part-time employees
• knows it’s very likely the intern will work or study elsewhere after their internship

Apprenticeship

An apprentice is someone who:

• knows what type of job they want next, or what kind of career they want
• is almost always paid
• is probably not in school

A company who hires apprentices:

• has apprentices work side-by-side with expert employees on typical project work
• usually hires them for craft work, such as software development
• expects that the apprentice will probably work for them as a full-time employee after the apprenticeship

No value judgements

Neither an internship nor an apprenticeship is bad and the other good. I believe they’re intended for different people and companies.

Someone who isn’t sure they really want to be a web developer might feel overwhelmed in a rigorous apprenticeship. Someone who craves pair-programming with an expert may feel frustrated in an internship.

Similarly, not every company is able to provide the kind of one-on-one relationships that are necessary in an apprenticeship.

Who cares?

Well, I might be alone, but I do.

Lately, I’ve seen many many many interesting variations on the themes of internship and apprenticeship in web design and web development, probably driven by demand.

Setting expectations for everyone involved never hurts.

Written by Dan Croak.

Keep your privates close

A problem with the way we declare private methods in Ruby is the fact that when a class gets larger and more private methods are added to it, we lose sight of whether we are looking at a private, protected or public method. This is because the private declaration is a few hundred lines above the method you are looking at. Some people use another level of indentation on private methods to loudly proclaim their privateness, but this just doesn’t do it for me. About half of us here at thoughtbot (ok, just a couple of us) prefer setting private methods explicitly by providing a symbol to the private call:

class Archive
  def import
    download
    decompress
    cleanup
  end

  def download
    # ...
  end
  private :download

  def decompress
    # ...
  end
  private :decompress

  def cleanup
    # ...
  end
  private :cleanup

  def another_public_method
    # doing really cool stuff
  end
end

The main advantage of this approach is that you always know the method’s visibility, not that it really matters in Ruby, but I digress. Some may say that it’s tedious to write, or that it clutters your class. If you believe that it is tedious to write, we have $EDITORs at our disposal.

Help me help you

Here’s what I did to make vim mark a method as private. Just place your cursor below a method, and type <Leader>p to privatize it:

function! Privatize()
  let priorMethod = PriorMethodDefinition()
  exec "normal iprivate :" . priorMethod  . "\<Esc>=="
endfunction

function! PriorMethodDefinition()
  let lineNumber = search('def', 'bn')
  let line       = getline(lineNumber)
  if line == 0
    echo "No prior method definition found"
  endif
  return matchlist(line, 'def \(\w\+\).*')[1]
endfunction

map <Leader>p :call Privatize()<CR>

But the advantages are twofold. For one, you always know if a method is private. It also helps clean up your code because it affords you the opportunity to decrease the vertical separation between the private method and the first time it is invoked. When you are reading a method that calls the private method, it is much easier to scroll a few lines down to see its definition (or just zt in vim) than it is to do a search for the method name, read the definition, and then come back to the context where it was called.

A familiar pattern

Vertical distance in code is not a new concept. For example, it is good form to always declare local variables as close as possible to their first use, increasing legibility and decreasing ambiguity. Similarly, when we write unit tests it is important to keep any setup or fixtures close to where you exercise the code, so that your assertions or examples have a clear context. If we follow this pattern elsewhere, sometimes unconsciously, why not follow it for private methods as well?