A week ago I blogged about creating a tool to let people make accessible résumés. During the following week, just ended, I got an appointment for a telephone interview with one of the organizations I was thinking about working for. My interviewer was going to be a blind person. That’s an example of a situation in which it’s useful to have a résumé that is accessible—i.e. designed to be consumed by people with various abilities and disabilities and who use assistive devices.
Although my application was already able to output a reasonably accessible résumé, its code was ugly.
One flaw was the commingling and dispersion of code serving different purposes. To use my application, you write your résumé in a standard format called “JSON”, complying with the rules of the
jsonresume project. We can call the file you save your résumé in its “source code”. Then you run my application (called a
jsonresume “theme”), and it does 2 things to your source code:
Parsing is making sense of your source code and deciding on the logical structure and layout of the document that will be produced from it.
Rendering is producing that document according to a particular technology. The output technology I started with is HTML, i.e. the usual technology of web pages. But in the future one might want to add the ability to create résumé documents for other technologies, such as PDF, “markdown”, RTF, and plain text.
In order to facilitate the future multiplicity of rendering options, I needed to carefully segregate the parts of my software that do rendering from the rest. That’s a good idea anyway. But I had not done that. One of the professional advisors at Learners Guild, where I’m retooling, had pointed that defect out. As I worked to remediate it, I either discovered or introduced additional problems. I have lost count of the number of times I have re-architected this application. See a problem; correct it; see another one caused by the correction; correct that one; and so on.
By the end of a whole week of “refactoring”, I had finally arrived at an architecture that I no longer felt ashamed of. Parsing and rendering were neatly separated. I had consolidated repetitious code into reusable functions. I had named things so another software developer could make sense of my code. I had given end-users much more power to make decisions about their résumés than other
jsonresume themes do, but I had not forced them to make such decisions. There was still debugging, documenting, and publishing to do, but the hard part seemed to be done.
This was my 38th week at the Guild, out of 40, and it has been getting obvious that this programming environment is a luxury. Nobody is giving me deadlines. I’m not at risk of crashing anybody’s system. I don’t have to agonize over the unconscionable amount of money a customer is paying me for repeatedly changing my mind. I get to be a perfectionist without guilt.
In 2 more weeks the Guild will become my ex-environment. If and when I thereafter start a regular job, I can’t expect this permissiveness to last, so I’m reveling in it for now.