For years, I made a decent living in a dayjob writing code for an ad agency back east.
Well, I say “writing code”, but that was only part of my job. I also had to do some fine-tuning of visual design elements and animations, which unfortunately is not one of my strengths. It’s a skill I’m interested in developing, to be sure, but at the moment, my focus is swatting up on programming skills. Between practicing meditation and mindfulness to combat bipolar symptoms, and investigating the neuroscience of plasticity to increase focus on and pleasure in writing, I’m teaching myself new languages and getting familiar with IDEs.
It’s been a busy time, despite any evidence to the contrary.
The thing is, many of the fundamentals of programming extend beyond the constraints of a single language. This is especially evident when it comes to object-oriented languages. My work experience back east was dominated by my skills in ActionScript, a “kissing cousin” of JavaScript. In working on an example of use and understanding of such a language (based on this book), it’s becoming more and more apparent that a good portion of my strengths in this area of productivity is in the fundamentals of good programming, with specifics able to be ironed out with practice and research.
It can be easy to focus on getting a job done as quickly as possible, as completely as possible, and move quickly onto the next assignment, project, or client. That, however, is not long-term thinking. One of the strengths of object-oriented programming is the ability to build your code in such a way that it is easy to maintain, extend, and revise the resulting functionality. It’s caused me no small amount of consternation to open a project and find a tangle of old code, clearly written in haste or before a new version of the language was available, and take precious time to sift through the lines to find where maintenance needs to take place. Often when bringing up these problems, the response has been “just fix it”, instead of giving the code an overhaul to make future revisions and maintenance easier and faster, and thus more profitable. I still believe that it’s possible to get a positive, long-term return on investment from taking time to make and keep code structures current, rather than ignoring obsolete and inefficient programming in the name of short-term expediency.
I’m talking mostly about higher-level stuff, rather than the nitty-gritty of the languages I’m studying. I’m working on taking more time to learn the Unity IDE and the inherent C# language within, as well as preparing to teach myself Python. It’s a lot to take in, but if I am to be an asset to a future employer, I want to ensure I have a good arsenal of tools to bring to the table. It’s one of the many ways I’m rebuilding myself from the ground up.
More on this as it develops, and as I develop.
It works on multiple levels.
Thursdays are for talking tech.
