Week 38 at an Unbootcamp

I may have discovered the thing that most makes me enjoy being a Learner at Learners Guild: It allows me to be a shameless perfectionist. I can “refactor” ad nauseam, and nobody complains.

Refactoring

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:

  1. Parse
  2. Render

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.

 

2 thoughts on “Week 38 at an Unbootcamp

  1. It is certainly the case that careful design work up front can reduce the amount of ugliness (such as duplicated code) in a programming project. However, nearly every large project, particularly with multiple contributors, will, gradually, likely develop inelegant or ugly sections of code. Cleaning up that ugliness is not simply a luxury, because – over time – there will be costs to be paid (in terms of buggier software or longer times required to develop new parts of the system, because the existing code is gnarly and hard to understand) in letting the ugly code remain. The managers of such projects need to do risk/reward evaluations, and will have to decide when (or whether) development resources would be better spent cleaning up older code, rather than developing new code for added functionality.

    1. Thanks for your observations. I could have mentioned that investments in refactoring are not always impossible in the outside world, because good managers can estimate when that investment will pay off sufficiently in the reduction of “technical debt”.

Leave a Reply

Your email address will not be published. Required fields are marked *

Edit translation
Machine translation (Google):
Loading...
Copy to editor
or Cancel