Saturday, January 30, 2021

Open Letter to Ubisoft

The Letter

To: [email protected]; [email protected]

Subject: Support nightmare


I know this is the kind of email you'd likely ignore but I am at my wits end with your support team. I have been jostled from tech to tech since 15 November 2020 over an issue launching both Assassin's Creed Origins and Odyssey on a computer which previously ran both perfectly well, including playing Origins to story completion. All other titles I own from Ubisoft, and all titles I have access to on Xbox Game Pass, including the extremely taxing Flight Simulator, run perfectly well. Yet, your support team continue to give me a handful of troubleshooting tips directly from your support website, ignoring any prior interactions which would alert them to knowing those steps have already been tried. Recently, they took a different tack stating that there is likely something wrong with my memory and, after running the recommended Memtest86+ fo4 24+ hours and passing 10 times with 0 errors, suggested it was low quality RAM or that 16GB wasn't enough.

Is there no escalation path from them to figure out this problem? It is a problem that has echoes reaching back to 2018 on Steam with people seeing issues with Uplay/Ubisoft Connect. I am at a point of never purchasing another Ubisoft title or signing up for a subscription due to this abysmal support experience. 


Jack Pines



I have been a long time fan of Assassin's Creed having played several on console and repurchased several on PC recently. I recently played through AC:Origins and was enjoying AC:Odyssey on my PC. The astute gamer will recognize that those aren't current titles. I have a serious game backlog to work through as I typically get a long weekend here or there to play games. Then COVID-19 happened and I have more shut-in time to put towards video games. 

So, having played through AC:Origins, I turned my sights on Odyssey. I'd begun the game forever ago when Google was beta testing Stadia. It was fun, Stadia worked well on an ethernet network, and I scored a free copy of AC:Odyssey. And then I got too busy to play it. Now I had no where to go and time to spare. So, I got to playing, had finished the area which culminated in killing my father (SPOILERS!), cleared the next area, and was tooling around the seas when I got busy again. A month later, I come back to the game, Ubisoft+ had been introduced to the public, and I was excited because it seemed a good value to subscribe and play the newest titles on launch. 

However, along with the new product came a rebranding of Uplay to Ubisoft Connect and at that moment AC:Odyssey stopped launching. It would show the static title image, not even the full screen title screen, and crash. Stymied, I then tried launching other titles in my library. Turned out that AC:Origins exhibited the exact same behavior. I'd scored a great deal on the original Assassin's Creed Directors Cut Edition so I fired it up. That worked great. So did Asssassin's Creed III Remastered, which I have been pleasantly suprised about given the reviews; no eye-popping moments so far. Even Watchdogs 2 runs perfectly. I'd love to try out newer titles to see if they have issues but I'm unwilling to spend any more money to only risk failure.

The Nightmare

I immediately searched Ubisoft's support documents for hints to what could cause this. Nothing did. So, I created a support ticket, as noted above on 15 November 2020. It has been 2.5 months of mostly frustration as I was bounced around no less than 24 support techs, listed for your entertainment.

Ubi-Ice Cream Cake

My favorite fake name was Ubi-UwU. There was no continuity of support so the same logs and steps were repeated many, many, MANY times. They even told me they escalated me twice. The first time, I believed them. The second time, I didn't because the first time didn't feel like an escalation after all and because they basically ghosted me for 3 weeks and then came back with their finding that I might have faulty memory. Mind you, no other game from any other source has issues but I was game. 

I downloaded the recommended Memtest86+ and ran it for over 24 hours. It passed 10 times and was on its way to an 11th, all with no errors. I reported this back to Ubisoft support and they suggested I buy new, higher quality memory to swap out and test with. My gaming rig is, admittedly, an aging Alienware Area-51 R2 but I don't think they'd sell me inferior memory when they support overclocking out the door, something I don't bother doing since it's never seemed worth the effort when everything ran fine as is. When I said as much back, they told me that it wasn't the quality they meant to challenge; it was the amount. Since when is 16GB, with 8GB free, not sufficient for gaming -- especially games which ran fine with that much RAM previously?!


Assassin's Creed has been a lot of fun to play through the years. I will enjoy playing through Watchdogs 2. However, unless some miracle happens and either support pulls their collective heads out their arses or I actually get one of the C-level dudes addressed on the email I sent and pasted above, I believe Watchdogs 2 will be the end of the line for my time playing Ubisoft games. It's a damned shame as the subscription really looked like it was going to be worth it for me.

Wednesday, December 30, 2020

How to become a Software Engineer, part 2 (or where have you been, Jack?)

Where have I been? Good question as clearly it hasn't been maintaining my blog or telling you the part 2 of becoming a software engineer. So, what have I been doing? 

Let's review

Almost 4.5 years ago I wrote that article which told my story of getting to Microsoft as a Software Engineer. That was at the bequest of a friend who kept prodding me to put it to digital ink. I hoped it would inspire folks who, like me, didn't have the good fortune to afford a degree, in computer science or otherwise, that they, too, could become software engineers. Honestly, I doubt it got enough traffic for anyone to be inspired but it's the thought that counts, right? Hello? Is this thing on? 

Ok, but where have you been?

The short answer, honing my craft. Since I wrote that post, I've held 4 roles, 2 at Microsoft, in between them I took one role at a company which closed their offices 3 months after I joined them, and now at a company writing Java micro-services from scratch, design to deployment, for the first time. I've had a lot of technologies to learn in the process, both internal tooling at the various companies and cloud services from Azure to AWS. For this guy with a bit of ADHD, between that and family my plate was full and I lost touch with the outside world a bit. That includes you, dear reader. 

That's all well and good, Jack...

So, why now am I suddenly posting? I have to admit to something I bet almost everyone has experienced, imposter syndrome. I had it pretty bad working with a bunch of young folk (I'm almost 53 now) with CS degrees, some of them advanced. I had my associates degree but no one really sees any value in it. 

Instead, the interviews are all about those CS fundamentals that most unschooled developers never have to think about. Do you know what a hashtable really is (dictionary in C#)? Most developers making a good living for their families, not software engineers, just know that it's a way to store values with a key and understand that it's efficient to do so. We don't know that it's useful in solving a bunch of problems in computer science that's mostly essotaric in real world, business logic development. Yet, we use hashtables all the time to great effect. But that doesn't matter when you are being interviewed. You need to know that esssoteric stuff. And that sets the stage for imposter syndrome, something I now know too many, possibly most, software engineers suffer from. 

The industry literally interviews in a way to make us question our ability, our very right, to hold the roles we just obtained. Oh, and then we don't use any of that CS fundamentals stuff again in the role unless we happen to write some poorly performing code and have to later figure out where we goofed up (or someone else did; same difference). 

Are you getting to a point?

The point is that I still struggle with imposter syndrome when confronted with a technology I've never worked with before, but the monster is much tinier now and I can squash it with a little effort. I've been at this software engineering stuff, in 2 languages now, for long enough that I trust myself to be able to figure it out. And that's the key. Get that under your belt sooner. Trust yourself. You got this far because you are capable of figuring things out. By luck of biology, you got the brains for this so stop doubting yourself just because the stage was set for you to do so. Ignore that demon. Like me, you may not have time (or attention span) to do much else but you've got this. 

And then?

Now that I'm finally being able to clear up a bit of mental clutter having put that demon behind me, I am working to getting back to my true passion, helping others hone their craft. I'm no expert in anything and will never claim to be but I do have knowledge. The thing about knowledge, its best use isn't in hording it. It's in sharing it. And that's what I aim to do now. I'll be looking for ways to share what I know, through mentoring using this medium and individually and out in the community, however that presents itself during and post COVID-19. Be well and be seeing you soon.

Saturday, April 16, 2016

How to become a Software Engineer (part 1)

It was the end of June 2014 when I accomplished the improbable. I'd become a Software Engineer at Microsoft. Me. The guy who had learned C# on the fly just slightly over 7 years earlier and VB.Net 6 months before that having never programmed on the Microsoft stack before. Today, after answering a question on Quora, I'm going to finally begin a short series of posts that Phil Hagerman requested of me when my career trajectory pitched moonward, starting with a brief history. I'll get more into the details of the hows and whats of what brought me this success in later posts.

The Early Years 

I started programming as a kid on Applesoft BASIC followed by Sinclair BASIC on a Timex/Sinclair 1000. That tiny, 4K beauty had neither a sound chip nor a traditional keyboard. So, it was the perfect, first, hacker platform. My dad and I did the easy thing, first, of upgrading to the massive 16K memory pack. We then cracked 'er open and soldered a ribbon cable between the motherboard and a real keyboard that we built from a kit. Finally, I pounded out and modified every BASIC program I could find, whether originally written for Apples or the TS1000. That culminated with the ultimate hackery that was playing the Star Spangled Banner on a device with no explicit support for sound by detuning the TV such that the video was distorted and, then, poking at video memory, causing said distortion to create consistent pitches. And, yet, I did NOT become a software developer at this point.

Programming? How mundane!

No, I figured I knew all I could about writing software at the ripe old age of 18 and decided that the more interesting subject was understanding the silicon that produced these marvelous things. I didn't get as far in my Electrical and Computer Engineering studies as I'd have liked when, due to financial pressures, I ended up dropping out of college. So, strike two on being a huge success in the software industry.

Gotta Pay the Bills 

I spent the next 20 years working in IT in various ways, from field tech fixing printers for lawyers offices to network admin work. When the company I was making my career with went under, I found myself relocating to central Florida where I discovered the headquarters for one of my favorite pieces of software. The software was Backup Exec and the company was Seagate Software.
Now, in the back of my mind I thought to myself that I could somehow get a job with them and change my career to software development. Mind you, I hadn't written much code in the intervening 15 years. It took me 3 years and a merger with Veritas Software before I could join the company. No programming during that time, either. Then it took another 6 years and completing my AA with a couple of programming courses (C++ and JAVA) under my belt before I tripped over an internal project, Phil Hagerman's brainchild, which I could contribute to. It's not that, before that, I couldn't have been contributing to some open source project (PRO TIP for building your resume) but my self-confidence was low. That internal project, though, was the tipping point I'd been looking for which proved to some folks that I should be doing software development. I was 39 and I was a software developer...barely.

I'm Finally a Developer!

I look back to that time and realize that one knack, that I could arrange my thoughts around a task that I needed the computer to do, allowed me to write really lousy code that got the work done. I had none of the discipline I have today. Like the meme says, "I rarely test[ed] my code, but when I [did], I test[ed] in Production." I had no idea about TDD, design patterns or SOLID principles, or the software development lifecycle (SDLC), or even C#, the language they used, but I was a software developer for a data analytics team in the Symantec tech support organization! (Symantec had acquired Veritas Software by then.) I am not one to go at something half-way, though, so I quickly learned about all those things. After 4 years working on that team, I was ready to stretch my wings and have a bigger impact. Not finding the right opportunity there, I started doing C# and SQL contract work and got a lot of exposure to various SDLCs, architectures, and problem spaces. What I discovered is that I could work on anything as long as I kept an open conversation with my peers and the stakeholders, things I learned well before I became a software developer.

Leaping Moonward

Then the improbable happened. I joined a successful startup that soon thereafter was acquired by Google. And, to my surprise, they kept me on! I was a Googler. Ok, I wasn't a Software Development Engineer but I was programming in Python, another language I'd never seen before, at Google. The interview process introduced me to more new concepts, algorithms and an explicit understanding of the data structures underlying all the work I'd done previously. To remain a Googler, as they were closing my office, I'd have to learn these things to be effective at interviewing so I spent the next year finding all the online courses I could take on the subjects.

Would You Like a Milkshake With That?

Getting Google on your resume brings all the recruiters to the yard. Looking at all the places where I could work for Google, New York, Pittsburgh, Chicago, and Mountain View were on the short list. I wanted to avoid the extreme cold and live somewhere cost effective. When Microsoft called for the 4th time, I decided I needed to practice interviewing and they invited me out to Redmond to interview for a role as a Software Engineer. Redmond in May is beautiful and, to my surprise, they gave me an offer a few days later and moved me, my family, and our menagerie of pets clear across the country a couple of months later. I was a Software Engineer at 46.
I have had successful interviews with Amazon, Microsoft, Google, NASA, and have had continuing offers for interviews at Google, Amazon, LinkedIn, Facebook, Starbucks, Wizards of the Coast (for my fellow geeks out there), and more start-ups than I can count. I am now officially a Software Engineer at 48 and I continue to learn something new every day. I also continue taking online courses to fill in the gaps in my knowledge a CS degree would have covered. I am enjoying this new career trajectory and see myself progressing in this industry for the next 20 years.

Shia LaBeouf Would Be Proud

So, you want to know how I became a Software Engineer? There's a part of me that wants to say it was luck. However, my wife reminds me that it was a lot of hard work, understanding which risks to take, and surrounding myself with supportive people to allow me to take those risks. I'll cover more on those topics in future posts. However, if you are a developer who has always wondered if you could ever work in the big leagues of software, not only do I know it's possible but you can grow well past that. Most extraordinarily as careers go, you can even do it with no formal education. There will be challenges along the way, some internal and some external. Isn't that always the case, though? Don't make excuses for yourself. Just do it!

Thursday, January 28, 2016

StackTrace Tool

Wow! Over a year since I last posted. I really need to find the overlap of time and motivation to bring some value to the few who stop by here. Here's something. I created this and hope you might find it useful. Go check it out on my GitHub repo.


Collects tools useful for working with Windows stack trace.

Inspiration & Initial Release

I often have to debug process failures where something unexpected happens. Even when the unexpected is handled through logging, the logged stack trace gets mangled a bit due to the newline character getting turned into escaped text, eg. '\r\n'. So, I'd often stare at this in the tiny message area in Event Viewer or the enterprise's logging mechanism and end up copy/pasting into my text editor of choice and replacing all the '\r\n's manually with actual newlines. My motto has always been, "Don't do any repetitive work if you can automate it."

It'd be easy enough to create a Python script, a console app, or a simple WinForms application. However, I've never built a Universal Windows Platform app and this was the perfect impetus to spin one up. Currently, the prompt is the only feature. However, I welcome input on ways this tool may be improved.

Monday, January 26, 2015

Redundancy in Learning

Did you know that you can learn how to learn? Sounds redundant to me, too, but taking the time to understand the learning process can actually increase your ability to learn. That is the premise of a course on Coursera titled "Learning How to Learn: Powerful mental tools to help you master tough subjects" taught by Barbara Oakley, Ph.D., and Terrence Sejnowski, Ph.D.. In this post, I will share a number of techniques that the course presents which have enhanced my learning aims. These techniques were either quite novel to me or reinforced habits I knew I needed to embrace but had never implemented.

First a quick note about Coursera

If you haven't utilized this free resource for learning then you're really missing out. Coursera is a MOOC, or Massively Open Online Course, site. That means you and hundreds, thousands, or more students simultaneously participate in the same set of online coursework. At Coursera, this coursework may be self-paced, with more of it becoming such all the time, giving you flexibility in when you participate. However, many of the courses are time-scoped. This comes with its own set of benefits, including that you know that your classmates are working on the same material at the same time as you. It also might be useful in preventing procrastination knowing that there is a deadline for the assignments.

Speaking of assignments, Coursera's coursework typically includes video lectures with interactive mini-quizzes embedded within to make sure you didn't doze off during the video. There are often weekly quizzes, which cover the lectures, along with assignments that help exercise what you've learned. Whether via book sites, references, or an actual textbook, there is often also weekly reading assignments to augment the lectures. This is a top-notch education Coursera offers so go avail yourself of their broad offerings.

Now, back to the course

In "Learning How to Learn," the running thread throughout the lectures was the topic of how our brain works and, understanding that, how to leverage what we know about that process. Sounds like it might be dry material but these Ph.D.s are no dummies; they used their techniques in the production of the material they covered. (I would love more instructors to do so.)

For example, did you know that you have an inner zombie? I had never thought about it that way but this was one clever bit of imagery which was used in the course to remind us that we have habits and it's up to you to corral your zombies for good or ill. One such zombie for me was the procrastination zombie. In approaching a new task, it is easier to feel overwhelmed by the task and find a more pleasant distraction. You might think that the answer is willpower but the instructors were clear that willpower is in short supply and best used sparingly. Rather, it's time to create better zombies. In the case of procrastination, understanding your cues and addressing them are the best approach. For me, that cue is feeling overwhelmed by a project. So, rather than focusing on the project, I now focus on the process. The project will resolve itself as long as I have good processes.

Another key learning from the course is the understanding of why you shouldn't cram for tests, whether they are academic or life tests. The imagery used was that of a wall of brick-and-mortar. You may lay a set of bricks with mortar only to a certain load. Beyond that, if you don't let the mortar set first, the bricks will collapse upon themselves. Similarly, it is important to let the new knowledge establish itself on your neural pathways as retrievable chunks before you build on top of that. In other words, study something, step away from it for a time to let it sink in, and then return to it to reinforce what you learned.

Speaking of neural pathways, I'm going to switch to a topic every developer has experienced. You've been pounding your head against a problem for an hour and can't seem to get that breakthrough moment culminating in a bug fix or elegant code. That's known as the Einstellung effect and very common in those of us who have to do a lot of structured thinking,  If you're experienced, you might know about Rubber Duck Debugging. If not, though, even the best of us have experienced a time when, frustrated with the problem at hand, you step away from your desk to share you misery with a peer and suddenly have that "Aha!" moment mid-explanation or, maybe, even before you got to their desk.

What's that have to do with neural pathways? Well, the metaphor the course used to explain these focused versus diffused thinking modes was that your brain is like a pinball machine and when you're focused it's as if there were so many bumpers active that the ball simply can't get to the bottom where the answer lies. Rather, it isn't until a number of those bumpers are dropped out of the field, the diffuse mode, that the ball can bounce around to light upon the bumper which has the right correlation to the solution. So, the next time you're stuck, back off the problem. Tell your rubber ducky what you're trying to do or, better yet, go for a walk. You know you could use the exercise and fresh air.

But back to the procrastination zombie once more before I wrap up because if there is one "killer app" I got out of this course, it's the easiest way to deal with him. As I mentioned, it had to do with focusing on process. As developers, I'd be surprised if you haven't heard of the Pomodoro Technique. However, I bet you either haven't tried it or, like me, gave it a half-hearted attempt and then decided it was ineffective. I'm here to tell you that you need to commit seriously to putting it to use. You don't need to buy the book or even the cute, tomato-shaped, kitchen timer. What you need to do is make a list of ToDo items then, focusing on the process rather than the product, start working on them in 25 minute sprints. Most importantly, make the blasted list!

Look, let's get this perfectly clear. If you aren't making a list right now then you might as well stop reading. Frankly, if you've read this far and aren't making a list then why did you read this far? We all have limited short-term memories. Some of you brilliant readers have far larger ones than I have but they're still limited. So, why are you wasting them on remembering the things you need to get done. Get those things on a list and then forget about them so you can use that space for actual thinking. Have you done that? Good. Go onto the next paragraph.

Get a timer. Use it. After each 25 minute sprint, and this is the hardest part, take a break. Believe it or not, you will be more productive if you do that one little trick. You're a creative person else you wouldn't be programming. Your mind likes to wander. So, let it! Just do so for short bursts. Oh, and if it should wander during the sprint, jot down that stray thought in the list to revisit so you can stay focused until the break.

Now, to wrap that up, let me give you a couple of tools I've found to be perfect for making this work. First, you need a list tool. There are many out there but, since you also need a timer, why not pick one tool that has both. While we're at it, let's pick one that works on any device you may carry with you. My solution is Trello with Trellodoro. You'll need an account with Trello but they're free. Then use that account in Trellodoro to be your timer. It will also let you add completed Pomodoro's (the cute name for a sprint) to your tasks. That part is really optional but if you do it then, after a while, you'll get the added benefit of being able to estimate how much effort a task requires.

You can see that what I learned most from this class was that learning takes time and is not something to do all in one sitting. I knew this. We all do. However, this course gave me an understanding of why this is true. These are just a sample of all "Learning How to Learn" teaches. You'll get test-preparation/taking tips, more detail on how memories are formed, interviews with prominent learners and instructors, and more. As with many classes I've taken, I'm sure I could gain something new from repeated sessions with this course. Besides, as they say in the course, spaced repetition is key to learning. Go check it out. Perhaps I'll see you there one day.

Hiatus Ended

Dear Stalwart Reader,

I, your irregular blogger, am finally returning to writing. It isn't that I haven't had anything to write about, though I'll lie to myself saying as much. It isn't even laziness, which I have my fair share of, which kept me from entertaining and educating you. It's been a whirlwind of change that has left me very preoccupied and wondering which of the many topics to write about.

No more! I have decided to write about every topic that is even tangentially related to software development. I will still try to bring you information unique to the web but I have come to realize that it may not be the details that are unique but my presentation of them. I hope that looking through my unique viewpoint, you may gain something you hadn't before and maybe even something elusive to you before transforms to enlightenment.

If not, I hope I at least entertain you from time to time.


Sunday, July 28, 2013

Java Memory Troubles? Tweak the GC

tl;dr version

Memory issues? Try -XX:+UseSerialGC -Xss8m in your Run Configuration or as command-line parameters.

The Problem

I'm guessing that, like myself, you have found yourself struggling with the following, two memory errors. I will share what I found as solutions to them.

java.lang.OutOfMemoryError: Java heap space

So, you've taken great pains to use only primitive data types, switching from using an ArrayList<ArrayList<Integer>> for your data type to  Integer[][] even though it's not nearly as easy to work with. You discovered, though, that this just delayed running out of heap space. I tried a solution stated in many other posts on the web and that did seem to help but I can tell you that it didn't fix the problem. Rather, it allowed me to get to the next error.


I encountered this error for the first time when working on a project with a lot of recursion. This was likely due to what data I was inadvertently putting onto the stack during recursion. However, I recently worked on another project where I couldn't optimize any further the data pushed onto the stack during recursion. Moral of the story is that you should take the time to profile your code and optimize the data which may end up on the stack during recursion. However, after doing your due diligence, you still may need help, though not as much as you might think.

A Likely Solution

After a lot of research, I found the following two posts which helped tremendously. First, the solution and then the links. Add the following to your command line when executing your class or add it to your Run Configuration in Eclipse:
-XX:+UseSerialGC -Xss8m


This first switch is the one that intelligent developers worry will be overused. The default for the stack is 512KB. Suggestions have been as high as 1024m for the number component of this parameter. That's 1GB or RAM! If you need that much RAM for your stack then you might be doing it wrong. Something to note is that I had used this on the highly recursive project I mentioned first with 16m as my value. That got things working. Then I went back and got rid of a bunch of Strings in my code which I'd been using for debugging and I no longer needed this flag at all. Moral of the story, don't use it unless you have to so that you are forced to optimize your code.


It turns out that the java.lang.OutOfMemoryError: Java heap space error isn't always what it appears to be. Sure, I was running out of heap space but increasing heap space just allowed bad behavior to continue. A flag which is commonly recommended to deal with this error is -Xmx1024m. Again, that's 1GB of RAM. Now, the heap is where your application runs and by default it is given 64MB to work with. So, you could have a valid argument that one day you'll create an application which needs more heap memory. Just not today. It turns out, and this is keyyou just might not need more memory at all!
See, the problem is that Java's garbage collection, while very useful in letting us not worry about destructors and generally functional, can be lazy. So, this is a hint to the GC on how to run. By using this flag, I made it completely unnecessary to use the -Xmx flag. Further, this flag meant that I didn't have to have the -Xss flag set very high, either. Sure, I'm not writing a 4KB demo but I'm pretty happy to have everything working in less than 9MB.

Final Words

I hope you find these flags useful. The key thought, though, is that before you put any of the flags on this page to use, inspect your code with careful attention to the data types used. You may just find that you can slim down a bit and use far less memory in doing so. Remember, one day you might be writing code for a mobile or embedded device smaller than a bracelet, i.e. FitBit, and memory costs money and takes up space.