in reply to Job Questions
- Only the code that I write is Perfect, Pristine, and Timeless. (There are only so many Perfect Coders allowed per planet, and I’m it.) All the code you’re likely to encounter will be old-crap that’s barely hanging-on on life support. ;-)
- Seriously, most code is “already existing,” therefore “legacy.” The new code that you write, as soon as you write it, becomes part of that “legacy.”
- So, it is always an important skill to be able to assess the present-state of a piece of code, to fully understand the desired future-state, and then to be able to articulate and to estimate what it will take to move it forward ... and at what business-risk, and with what allowances for Sergeant SNAFU ... and how it will be testable and how it will be tested ... before you and/or your team starts to write it.
- Most of the time, you will find these practices are followed, because people really do need to write stuff that is more-or-less stable and that more-or-less stays that way. However, the code has been changed, many times and by many people over many years for many reasons. This is inherently de-stabilizing to software. The work practices are often most-important: how do they handle problem-reports and change requests? Do they use source-code control? What is their deployment procedure, and how do they recover from / roll back a deploy? How do they “mentor” new team members, such as you would be? These are things that you should ask during that same interview.
- Most programmer positions have little direct client contact. But you will still need to develop the ability to converse effectively with a non-technical person about a highly technical subject. You will need to be able to communicate effectively with members of your team, including those who know more and those who know less than you (about a particular subject area), and to work with them effectively as a team. Computer software is not the work of one person.
In Section
Seekers of Perl Wisdom