Yearly Archives: 2016

Review: Xenoblade Chronicles X

Just in time for the end of the year, I finally finished Xenoblade Chronicles X, which I started playing around the first week of August (5 months!), with 120+ hours of game time. The game doesn’t have the best graphics (WiiU, etc), but I really like how it looks and how the world is built and all the different environments and the weird and sometimes absurdly large beasts.

There’s a whole lot of stuff to do in-game. It plays mostly like a single-player MMO, with party members that act on their own and most skills on a cooldown. There’s a ridiculous number of quests and items to grind for, I’m even tempted to still continue with the post-game content (if only I didn’t have FFXV waiting for me!), as I’m only at around 70% completion.

The story was okay, at many points well-told and hitting a lot of emotional highs (although some of the characters felt a bit over-acted). The ending was… well, kind of sequel-baiting. A mixture of disappointment and confusion and hope haha. I don’t imagine that they’ll have a sequel set in the same universe/timeline, so it felt a bit like they made up a ridiculous explanation that would attempt to explain some of the nonsense that happens in the game.

Here’s an imgur album with some stuff I screen-grabbed along the way:

Cleaning up your Code

In one of my most recent projects, a large system that had gone through a relatively long and unstable period of many, many changes due to sales demonstrations, different clients and whatnot, one of the “fun buffer tasks” I always kept around for devs was code cleanup. Because of the unstable nature of the project, there was always a lot of duplication, unused/unnecessary/obsolete classes/functions/files and so on. Unnecessarily large CSS files where most of the selectors were no longer really needed or JS libraries that weren’t actually used. That kind of thing.

It’s one of those things that you’ll never get official approval from management to do, so you have to somehow sneak it in during your daily tasks. But it’s important for a couple of reasons:

  • Having too much cluttered code makes your system a lot harder to grok. That means new developers will have a much higher learning curve, and existing developers will find it difficult to be assigned tasks in modules and functions they’re not familiar with. Lower understanding means more bugs, lower quality and so on.
  • Having a lot of unused files, classes, functions, etc. bloats the build process (making build times longer, extending development cycles) and makes build files bigger (extending deployment times)

A lot of developers prefer not to throw away old code, for fear that “we might need it later”. They would prefer to just comment them out in large blocks (making the code a lot more unreadable) or just leaving dangling functions/classes unused. The reason is hogwash of course, since you should be using source control, and source control means never being afraid to delete old code. (Of course, you should make sure what you’re deleting is really no longer in use!)

 

Decluttering

I traditionally try to save some time on the week between Christmas and New Year’s Day to do some cleaning up and decluttering of my stuff. One would assume that having more time meant I would be better able to organize my stuff and all that, but one would be wrong. My room still has stacks of books, toys, Magic cards and other stuff in random places.

Or maybe I just have too much OCD that I want everything to be neat and organized, but I’m not industrious enough to make it happen. I’m sure there are people a lot more cluttered than me.

Towards the start of the year, I told myself I should throw out/get rid of/dispose of at least one thing a day. It’s one of those relatively easy things to do I haven’t been able to maintain.

Why do we keep around all this old stuff we don’t need?

Part of it may be from a mentality of scarcity – we don’t want to throw away stuff for fear of finding out that we may need it later. But reasonably, if you haven’t used a thing in years, maybe you’ll never use it and even if you had need of one, how difficult would it be to find one again? Some kind of pack rat mentality. I know a few of my friends who would be very familiar with this.

Other things we keep around for some sort of nostalgia or as keepsakes of other people and faraway places. That’s fine I suppose, but maybe one shouldn’t put too much value in things that don’t actually have them. Case in point: I have a bunch of rocks here from different countries I visited in Europe, haha. Pictures, letters, and other personal keepsakes one might consider digitizing and storing in the cloud.

Having a cluttered space has a cost, one that’s difficult to ascertain or quantify. Not only do things look messy, but things are harder to find when you need them most. There’s also a strange satisfaction that comes from achieving a fine, organized space (before it all falls back into chaos of course.)

 

Learning a New Programming Language

Related: Learning new skills

While many people working as programmers/software developers are happy enough specializing in a single programming language or platform, I generally consider it a better idea to have a wider toolset and the ability to easily pick up new programming languages as needed. The benefits should be obvious: when you have a wide variety of tools under your belt and are able to quickly learn to use a new tool, the number of work options you have increases greatly.

Happily, programming languages share a lot of similar constructs. Only your first programming language (when you first learn programming) should provide you with any difficulty – once you’ve cleared that hurdle, learning additional programming languages shouldn’t be too much of a concern.

You typically start with syntax, variable declarations, function declarations and program flow (loops, conditionals and so on). Some languages may have a strange syntax that don’t share much in common with other programming languages, but that’s pretty much not a concern as long as you have access to a modern-day compiler that will tell you when you stray from the desired syntax.

I find that learning a programming language is best done the same way you actually program – iteratively. Learn something new, try it out, modify it a bit, try it out, and so on. I once had to help someone prepare for a programming interview where he would be expected to know C++. He had learned it before in college, but hadn’t used it for a few years, but for some reason he stuck to reading up on it instead of taking my suggestion to install a compiler and actually try out all the suggestions. (He ended up passing the interview, but that was luckily because they didn’t ask too much about syntax.)

It also helps a lot to learn about theory and terms and whatnot. Like for object-oriented  programming, it helps to know and understand the concepts behind polymorphism, inheritance, abstract classes and so on. When studying different programming languages, you can then easily compare how they are done in one language vs another, making it easier for you to carry over design concepts to the new language you are learning. Being familiar with the terms and vocabulary also helps you communicate better with mentors, teachers, and fellow learners studying the same language.

Building small toy applications with the new programming language is a great way to learn too. Or maybe if you had a certain project in mind that you wanted to do, you could use the new language with it. Slightly related: When I was consulting with a startup on developing a new product, I asked the CTO whether he preferred to use a technology stack that the developers were more familiar with (to reduce learning costs) or whether he wanted to try this different language that neither of us had tried before, and he told me that one of the great things about being in a startup was that he could choose to do new projects with new technologies to expand their horizons and not have to listen to higher-ups shut it down for fear of increased costs.

For the longest time, I tried to learn at least one new programming language/platform a year. For 2016, it was Unity/C#, although I’ve also started studying Node.js in the past month or so. I hope it’s something I’m able to keep up, even as I’m trying to explore new skills other than programming.

Learning New Skills

When Hanamichi Sakuragi from the manga Slam Dunk tries to get into the basketball club, he insists he’s a genius who doesn’t need to practice the basics and instead wants to go immediately to doing spectacular things like Slam Dunks.

Sadly, the vast majority of us cannot claim to be geniuses at anything, and we are forced to undergo a bit of hard work if we want to learn a new skill. Malcolm Gladwell says one needs 10,000 hours of work at something to become proficient, but that probably only holds true if you’re using those hours “smartly” and not just trying to brute force your way to expertise.

I try to always keep myself on a learning path, trying to pick up new skills on a regular basis. Here are some things I’ve noted down about how to work smartly towards self-improvement in any given skill:

  • Start with the basics, and keep up with the basics. When Sakuragi joined the club, they first made him practice dribbling in the corner, and despite his complaints it paid off when he actually got to play because he had really smooth dribbling. It can suck and be boring to be stuck doing simple things or studying theory or background first when you want to skip ahead to the fun, complicated, show-off stuff, but having a solid foundation to work on will help you get a lot further later on.
  • Have a target. What’s your goal when studying this skill? Do you want to become the best in the world in a competitive sport? Do you want to be able to converse in a foreign language? How much time and effort are you willing to spend? Knowing the answers to these questions lets you understand when you are pushing yourself too hard or not putting in enough effort.
  • Practice, practice, practice. I sometimes answer questions on Quora, and one of the common questions I see there is of the form “How can I get better at X”? And my response is inevitably some form of “There is no substitute for regular practice, good old time and effort.” followed by specific suggestions for the particular X. I used to play competitive Magic the Gathering a lot, and used to place decently in local tournaments on a regular basis. But that was when I had a larger playgroup that I spent a lot of time with and when I was still playing a lot. These days I will only pop in for a tournament every so often, and predictably I seldom do so well anymore. Even if you’ve been doing something for a long time, regular practice makes a hell of a lot of difference.
  • Try to improve at least a little bit every time. Every practice session, every time. Even if you improve only 0.1% every time, the magic of compound interest means those gains will scale up quickly.
  • Study how other people do things and overcome challenges. I love fighting games like Street Fighter, and one of the great things about the modern age is that fighting game enthusiasts have access to a whole lot of replays of top-level competitive fighting that they can watch and study to help improve their own fighting games. (Sadly I do not yet have the execution skills necessary to become competitively good at it – not enough practice probably, see above.) Studying other people’s work gives you insight into different ways of doing things and can unlock different pathways in your brain, allowing you more opportunities to think outside your own box and find more chances for improvement.
  • Keep pushing the difficulty. Try not to settle for the same level of skill so you can keep improving. Take small steps to improve your game. Handicap yourself in different ways and see how you can compensate. Compete against people who are better than you, and study how they fight you.
  • Study different approaches. Try out new strategies or new ideas; even if you just discard them later you will have learned something. You might find that the most common approach to learning a skill is not necessarily the best one for you.
  • Know your weaknesses and shore them up. If you have a certain style or technique you have a hard time with, practice that more or study it more intensely. While studying Spanish on Duolingo, I know that I always have trouble constructing sentences that use object pronouns so I try to special attention when such sentences come up, and I try to review them more often.
  • Keep track of your progress. While not always practical or doable, being able to track your progress, even as a high-level estimate, allows you to measure the rate at which you improve. It gives you a good idea of when you are doing well and when you are having difficulty and helps you compensate accordingly.
  • Reward yourself when you do well, and take a break every so often. As with all things, balance is something to consider.

 

Generalists and Specialists in Dev Teams

In any reasonably large software project, the system will be so large that no one developer will have a good grasp of the details of every function in the codebase.

The tendency is for developers to specialize – that is, developers tend to focus only on certain parts of the codebase and become more familiar with that part, while not having much knowledge about the other parts. This tendency is self-reinforcing – once it becomes known that the developer is an “expert” in the given module, there is a tendency that he will be assigned the most difficult and urgent tasks or fixes related to that module, further cementing his expertise. Thus, the developer becomes a sort of specialist within the system.

In contrast to a specialist, you will also sometimes have developers who prefer to be generalists. That is, they are comfortable working with any part of the system, although their familiarity and knowledge are probably not as deep as the specialist for any given module.

Both generalists and specialists are valuable in different situations. If you need a complicated change done quickly on a particular module with minimum impact, it’s best to have a specialist who is very familiar with how everything works. On the other hand, generalists are very useful from a resource management perspective, since they can jump in to help at any time in any part of the codebase. Say, if your specialist is sick or out of town and you urgently need to do a small change, the generalist can probably take it on no problem.

Ideally, you train more than one specialist per module of interest in your system, through some sort of mentoring or maybe pair programming, but not all dev teams have that luxury (mostly due to schedule or resource constraints). It’s best for software dev teams to find the right mix of generalists and specialists that their particular development process entails.

Nine Ways to Work Around Mental Blocks

Often I have these days where I’m supposed to be writing something or drawing something or coding something and I just can’t get to it. Some kind of mental block makes it difficult. And you try to focus your mind and clear your thoughts, but it just doesn’t help. Here are some ideas for how to get past mental blocks.

  1. Toss out ideas that weren’t working and start over. One example is today’s blog post. I promised myself I would be posting regularly, so I had to have one today. But after a couple of failed attempts that just couldn’t come together, I had to stop and ask myself what was wrong. I just wasn’t in the mood for any of the other serious topics I wanted to write about so I said screw it, I’ll just write about mental blocks!
  2. Phone it in. If you’re unfamiliar, the expression means “just do the bare minimum you’re allowed to do.” Just power through the work with as little effort as possible. You can always go back and edit it later if you want! I often do this with the daily sketches – I try to stay on theme and at the same time find something interesting or clever to draw. But I’m not always successful, and I sometimes don’t have enough time. So I’ll just draw whatever that barely makes the theme and send it in.
  3. If you have some time, step away from the work for a bit. Take a shower. Poop. Argue with people over the internet. Watch some Brooklyn Nine Nine. Play some Skyrim. Just get your mind off the work. It gives your subconscious mind a chance to work on the problems in the background and later you can come back to the work with fresh eyes and hopefully better ideas.
  4. Cheat. Find someone who’s done something similar before and copy, er I mean, draw inspiration from her work!
  5. Make a long list of ideas. Just random, stupid, ideas, as many as you can think of, as soon as they pop into your head. You’re throwing spaghetti at the wall and trying to see what sticks!
  6. Do the easy stuff first, then get back to the hard stuff later. I did this during my Nanowrimo this year! Whenever I had too much difficulty writing a scene, I would set it aside for a while and choose some other scene that I had already mostly plotted out in my head. You might think “Doesn’t that just mean I’ll have more hard stuff to do later?” Yes, yes it does, but also means that hard stuff will have a whole lot of easy stuff already written to support it, which can make things easier.
  7. Use random content generators. There’s a bunch of them on the internet! For writing, I sometimes use random name generators to help me out. There’s also random plot generators and random dialogue generators and so on. Most of the time you’ll get nonsense, but just clicking through those nonsense options can give you an inspiration for your own creative needs.
  8. Change it up. If you’re drawing, try drawing in a different style than you usually do. If you’re writing a story, try to throw in a random scene that’s a completely different style and makes no sense. If you’re blogging, write a post about something you’ve never written about before, or in a style you’ve never used. Like a listicle!
  9. Ask for help. In software development, there’s a concept called “Rubber Duck Debugging”, or sometimes simply “Rubber Ducking”. The idea is that by asking other people for help, even if the other person is completely useless, the mere act of describing your problem helps you think through it and unlocks new ideas. As a bonus, sometimes the other person can actually be helpful!

 

 

Power Distance in Software Development

I was in a meeting once with my boss (literally the CEO, a Malaysian) and some representatives of another company (Americans) where we were discussing the technical details of a possible future partnership. At one point, one of the Americans said to my boss that he was pleasantly surprised that I was openly speaking up independently of my boss and willing to correct him on some points when he didn’t quite get the technical details right. It seems they were used to working with some Indian outsourcing firms, where due to cultural differences, the tendency was for the Indian guys to accept everything the Americans asked for without question and delivered it exactly as requested, even if there were obvious problems.

The concept is called Power Distance, where cultures with a higher power distance are more likely to just accept without question the authority of “higher-ups”. While in cultures with lower power distance, people feel less of a gap with people of “higher” status, and are thus more willing to speak up openly.

I believe that I live and work in a country with a high power distance. It is typical of workers here to have an exchange like:

“Why are we doing this, isn’t it kind of dumb?”

“Because the boss says so.”

“Oh, ok”

Not just with people in “higher” positions, but especially with foreigners. I witnessed this first hand when I first observed how other people behaved when they first had to work with our project managers who were based in another country; many would be hesitant to raise their concerns directly with the foreign counterparts.

In an industry where users and clients and management often do not really understand the finer technical details of what exactly they want to happen, being able and willing to raise concerns regardless of differences in position or status is not only a distinct advantage, it may very well be an important aspect of the job. All the best developers I’ve worked with are the ones who are willing to call out problems, and it’s a trait I personally encourage in anyone I work with.

Nanowrimo 2016 Post-Mortem

As I recall, today was at least my fifth Nanowrimo attempt; the first one was sometime before 2003 (I would guess it was in 2000 or 2001 before I graduated from college), the second one was in 2003, then 2006, then 2011, then finally the fifth one this year. My best prior attempt was back in 2011, when I made it up to 22,000+ words.

At just around 1am on the early morning of November 30th this year, I beat that record and have won Nanowrimo for the first time. I wrote more than 3,000 words from the last hours of the 29th up to the early hour of the 30th to push across the target count. According to the official word count tool on the site, I am at 50,135 words. The novel is terrible and it will never see the light of day as it is, but it has a start, it has a plot that it follows to the end, and it has an ending which while I’m not totally happy with, is good enough for a first draft.

Getting the obvious question out of the way first: no, I’m not going to release or publish the draft as it is. Way too many problems (more on that below), even though I tried to resolve things and tie them together best as I can. The nature of nanowrimo itself means that novels written for this purpose tend to be all kinds of messy, since you are not encouraged to rewrite previously written parts. At some point I will revisit this story and attempt to rework it into something better, but for now, I’m just happy to be done and will set it aside for now.

I think there are two reasons that this attempt succeeded where previous attempts had failed: First is that I came in significantly more prepared this time than my last attempts since I actually had a story idea and an outline for what I had in my head. Granted, I had to expand and add upon that outline multiple times, but at least I had something decent to start with. Second reason is that I believe I have significantly more self-discipline this time around, as a result of all of the daily habits I’ve taken up this year. I’m less likely to skip writing for a day due to laziness or being sad about world events or whatever, and more likely to drag myself out of bed to force myself to write some number of words for the day.

What struck me about the process is the number of parallels I could draw to software development:

  • In software development, you need some sort of specifications or requirements to get going, and work proceeds smoothly the more detailed those specs are. When writing, having your outline and a vision of what happens in the story makes writing go by faster and more smoothly; when I get to parts that I have not planned out in detail I tend to flounder about until I can figure it out.
  • Scope creep happens in writing too! My initial story idea was about a wandering sell-sword who passes by a small rural village and gets caught up in trying to resolve a “curse” that the villagers believe they are under. But at the outline stage I already knew it was too short (I couldn’t list enough scenes), so I expanded it a bit with a backstory that the protagonist was actually a fugitive and although he stops to help the villagers with good intentions, he draws them into his troubles when his pursuers chance upon him. As I wrote, I realized I needed even more details so I found myself weaving a more detailed plot about how he became a fugitive because he had unwittingly uncovered a political plot and had to escape with a certain artifact, which led to me detailing the back story of that artifact that turned into a mythos and history for the world the story was set in. Yup, it escalated pretty quickly.
  • There’s a famous quote in software development that mentions one of the difficult problems as naming, and in writing, the same applies! I made liberal use of online random name generators for characters, cities, continents, etc. Midway through, I had to rename a couple of the main characters (lots of find and replace) and three timesI even renamed the main continent on which the story takes place, and I’m still not happy with what I have now.
  • When writing large programs, I have a tendency to code the interesting bits first, then I’m left with a whole lot of drudgery such as boilerplate code or CRUD screens to do. Writing turns out to be the same, I wrote a lot of the interesting scenes first then deferred those I had trouble with or hadn’t figured out too well. It led to some problems; if you saw my draft you would notice some points where the story jumps forward abruptly leaving the reader to infer what had happened in between. Those were points where I had difficulty deciding how to get from point A to point B and just decided to write the other end first and try to work backwards, but never did figure it out completely.
  • When programming, you can get too engrossed in a particular part of the program such that you put too much work into it which turns out to be unnecessary. In this draft, I enjoyed writing the world’s mythos and back story a bit too much, I kind of set the framework for a series of stories in the same world, and some of the back story parts are better off told in succeeding books since they are not especially relevant to the plot of this one.

Some other non-programming related notes:

  • Towards the start, I felt like I was writing too much dialogue (might have been a result of reading too many Brian Michael Bendis comics) and later on I adjusted by writing more prose. This also helped for some difficult moments, for example I had two characters where I wanted to get them into a shouting match but had trouble writing the dialogue to develop it, so instead I just used prose to describe the increasing tension of their discussion.
  • I made a silly decision early on to give the main character a speech affectation – he spoke in an archaic formal speech that was unusual for people in that region. It wasn’t a big deal and there was a story reason for it and it made him feel more distinctive, but it also meant I had to be more careful later on when writing dialogue for the character.
  • Making up some elements on the fly kind of got in my way; about 70% through I suddenly had the bright idea that a “good” character I had alluded to in an earlier flashback would actually be the “big bad” who was behind the conspiracy all along. This was fine, but it led to some plot acrobatics where I had to engineer some complicated scenarios to justify my decision, and it meant my ending had to be a bit different from what I had previously wanted.

Having the daily quota was a strange experience. I was over quota most days, but also had some days where I was under quota. I found myself preferring to write in scenes, such that I won’t switch scenes within the same day, so some scenes felt like they were a bit too long because I was stretching them to fit in the writing quota for that day. And the quota also meant that whenever I was already over quota for a certain day but still had a clear idea of what to write, I had the option to stop and just “bank” those thoughts and continue the scene the next day. I never tried to pull too far ahead (except for the last two days); I figured I needed to get used to the rhythm of writing a set amount per day, instead of in bursts as I might have done in previous attempts.

I tracked my daily progress via a spreadsheet (word counts are using Google Docs’ built-in word count tool. The nano site’s word count tool had a different final count for some reason.)

Nanowrimo 2016 Daily Log
Nanowrimo 2016 Daily Log

All in all, I’m happy with the experience, despite not being entirely happy with my own output. I learned a lot and now have a better sense of how long fifty thousand words actually is and what size a novel-size story really should be. I now have some idea of how quickly I can write, and how much “writing energy” I can spare for a day (I was actually in danger of falling behind on regular blogging at one point because I spent all my “writing energy” on nanowrimo.) I say “writing energy” because I find that I draw from a different pool of energy as compared to say, when I’m sketching. It’s probably not super indicative – I could probably have been writing more each day if I spend more time in preparation and outlining.

will attempt to write more in 2017, but maybe not yet on revising this particular work. I have some other ideas I’m thinking of visiting, not necessarily for nanowrimo. I don’t know if this will lead anywhere – I still have no idea if I could really write fiction for a living for example – but I think at least trying to write more will be a worthy endeavor to explore.

Javascript: References to out-of-scope variables.

In JavaScript, referencing variables that are declared outside of a function’s scope can be tricky. If you have code like this:

<script>
  var btn = document.getElementById("BTN");
  var test = 1;
  btn.onclick = function() {
      alert(test);
  }
  test = 2;
</script>

The click handler above retains a reference to the test variable even though it falls out of scope as soon as the script block finishes execution. When you actually click the button, the alert will show the last value of the variable when the block finished execution (2) instead of the value at the time the function was initialized (1).

I thought about this because another developer raised a similar problem to me a few days ago. He had a loop that was initializing click handlers for an array of elements. Of course I can’t replicate his example here, but let’s say we wanted to add click handlers to an array of buttons that would show the result of multiplying an input value by different integers.

  <script>
    var btns = [];
    btns.push(document.getElementById("BTN1"));
    btns.push(document.getElementById("BTN2"));
    btns.push(document.getElementById("BTN3"));
    btns.push(document.getElementById("BTN4"));
    var input = document.getElementById("IN");
 
    for (var i=0; i<4; i++) {
      btns[i].onclick = function() {
        alert(input.value*(i+2));
      }
    }
  </script>

This is kind of an analogous example for the problem. In this case, the expected behavior is that the first button outputs the input value times 2, while the second button outputs the input value times 3, and so on. But because each of the click handlers retains a reference to the loop counter i, what they will remember on execution is the last value of i after the loop exits, that is, i==4. All the buttons will show the same output.

There are several ways to correct the behavior. One way would be to build the click handlers using a utility function, like so:

   <script>
    var btns = [];
    btns.push(document.getElementById("BTN1"));
    btns.push(document.getElementById("BTN2"));
    btns.push(document.getElementById("BTN3"));
    btns.push(document.getElementById("BTN4"));
    var input = document.getElementById("IN");
 
    function getClickHandler(counter) {
      return function() {
        alert(input.value*(counter+2));
      }
    }
 
    for (var i=0; i<4; i++) {
      btns[i].onclick = getClickHandler(i);
    }
  </script>

This way, the value for the local function variable “counter” is locked in once getClickHandler exits execution, and each returned function now has a reference to a different “counter”, and the buttons will behave as expected.