Organizing Code for Boston I have worked with many new software engineers. I have interviewed and hired new engineers at my old job. Often times the challenge is not coding, but rather the process of writing software applications is tough.
Computers are Different
If we all started with the same computers and software on them a large number of frustrations with coding could be remediated. I spend a large amount of time helping people setup their machines to run applications. For every single problem to solve there are a a large number of options and few standards. From text editors to managing programming language versions trying to help get someone’s computer prepared to work on code can feel like getting into a rental car.
Programming Languages Rapidly Change
With the introduction of changes to a language, documentation spoils faster than milk. Solutions posted a year or two ago do not work because they do not incorporate new features or syntax changes to a language. You might find a solution to your specific problem and then spend days having to adopt it to modern practices. Instead of abstracting away complexity, you are forced to learn it all before you can make progress.
Too Many Options
There are more decisions to make between wanting to write an application and creating it than you would expect. Which programming language is best? Vi or EMACS? Do we deploy with AWS or Heroku? Tutorials and classes spend lots of effort trying to hide these decisions or make them for you, but the real world hits back when you try and apply what you thought you learned and realize you’re in unfamiliar territory.
Software engineers are strangely allergic to writing documentation. When they do it is often terse and fails to add the context you need to understand the code. This means the effort to understand it is really high, and comfort in changing or manipulating an existing code base is low.