My biggest failure, the FreeBASE console...

It’s been almost 10 years since the FreeBASE idea was initiated. However, it was a massive failure due to realizing that we were competing in the wrong field and honestly being afraid of our shadow.

The biggest problem that I didn’t understand back in my university days is that good ideas don’t make good products. I mean, how great of a proposition is it? A game and media console that would play free content with thousands of freeware and open-source games and popular online series that were viewable at no cost.

We had a great team each with their own speciality me being software, someone else doing research for the free content, a web developer, a DevOps (before the term was even coined) expert but still looking for more. Several times, we even had amateur investors meeting with us because they were interested in taking the idea even further though all of them, at the end of the day, were skeptical of the idea and threw us out of the window.

At the time, the landscape was shaping up to be a quite competitive one and I was slightly scared of them. I mean, the giants Sony, Microsoft and Nintendo had a foothold on the market and we realized that we could never compete with them. But we had a bit of hope because other players tried to enter the market such as Boxer8’s OUYA and Valve’s Steam Machine made us feel like we can squeeze into the market too.

However, in retrospect several years later, after the project was canned, we saw Boxer8 and Valve fall flat on their faces with disastrous results. We were naïve at the time and couldn’t see the faults in our ‘competitors’. But, just like us, they were short-sighted, and failed to understand the market. Julie Uhrman, the founder of the OUYA project, had no idea what she was doing. For example, she claimed that the OUYA controller was the first to have a touchpad while she was oblivious to the fact that Sony’s Dual Shock controller beat them to it. What an embarrassment!

Valve’s idea fell on it’s face after selling so few Steam Machines that many people ended up buying them because they were cheap computers installing Windows on them to get rid of the subpar SteamOS. OUYA was even more embarrassing. The best selling game was TowerFall, but the developers revealed that only 7000 copies were sold. It was ported to PC and become a massive hit there.

At this point, I have to give up on insulting the other projects because ours was a much bigger failure. I was so confident that we would get somewhere but I began to feel fear and the whole team got disillusioned and split apart shortly after. The only evidence left is an idiotic YouTube video that looked like a teaser, for a teaser.

Our proposition brought challenges that our much larger competitors didn’t have to face.

First, we couldn’t build or design our own hardware, we decided to use off-the-shelf components but building such a machine was very expensive. We tried to make tiers to create multiple markets but it was as confusing as Windows Vista’s swath of editions. Our projections showed that our systems would be at least twice as expensive of current consoles with much less horsepower.

Second, we had to make money on hardware, we couldn’t sell it at a loss like the others. Since the games were free, we couldn’t make the creators pay licensing fees to have their game featured on the console. We saw Microsoft try this business model with making money on the console but they had to take so much shortcuts that the rings of death became a meme. In other words, these companies had such deep pockets that they could recuperate their losses with licensing fees, and that made their products make millions and billions of dollars.

Third, we made no market analysis at all. We didn’t know if anyone was actually interested in playing shoddy indie games made by someone in their free time. The quality of the games didn’t even touch the ones made by AAA publishers.

My main partner, who was helping me with building the software, put it so elegantly that we hit emotional walls and still haven’t learned our lessons from the failed project. It became really obvious that we didn’t have our shit together.

To this day, I still ruminate about the project because I wish it would be alive and successful. I did consider turning the hardware idea into just a Linux distro. There are already some poorly polished ideas such as Lutris which handles pretty much everything up to even installing patched versions of Wine for better compatibility.

The project still left a legend or legacy behind it, so here’s some images that invoked what we thought the FreeBASE interface would be like.

Leave some notes in the comments sections on your opinions and ideas on this failed project, or similar ideas you had, or even if you want to bring it back again.

How to get a Software Engineering Job

The field of IT is incredibly competitive. People are attracted to the excellent pay and what they perceive as something easy, just sitting in a cubicle. However, it’s much more than that; it’s something that requires passion, dedication and care for your work. You need to constantly perform and any seems in your performance could be reason to take you out. Keep in mind that there’s hundreds of software engineers that applied for the same job and you need to be the cream of the crop.

I’ll go over the different aspects in creating a great image for yourself to make it more likely to get an offer. It’s more than your education that counts, but also your experience both at home and at work. You really need to look like a well-rounded person who has a life full of hobbies, volunteering and a big portfolio.

I hope this advice from someone who’s landed over 10 job experiences resonates with you a little bit and gets you through the narrow corridor of competitiveness.

Resume

This is the part where I struggled the most because everyone has a different take on what a good resume looks like. Rather than using my resume as an anecdote, I’ll suggest different styles that recruiters have suggested and the ones that have lead to me to an interview.

Even if you have a short two page resume, it’s unlikely that the hiring manager will go through more than the first one. I always recommend to have the first page to be a summary of your highlights including a description of you, your favourite experiences/job and a small list of your major skill sets. Then the resume can go into details over what you did. I noticed most interviewers only go through the first page of my resume.

In terms of length, some recruiters suggest between 2 and 4 pages while others say the longer the better. My resume is a length 20 pages but I doubt anyone reads the whole thing. From my experience, I noticed most only read the first page and zero in on some part of the resume. For example, I was hired at one company from my volunteering experience.

One thing, I beg you to avoid, is a terse one page resume. It just makes you look lazy and they won’t hire people who won’t take the effort to do proper work. I see it a lot but it seems unsuccessful in finding a job. Of course, you did more than one page of work in your life so don’t trivialize yourself.

Just remember that the first form of exposure to you when applying is your resume. They won’t meet you unless they’re happy with the contents of your resume.

Make your Resume stand out

Making your resume standout requires both subtle and obvious creative skills. One of the most subtle things I have done is exchange the Times New Roman font to Liberation Serif. That small difference makes the resume look more unique to the onslaught of Arial and Times New Roman resumes.

Word Processors comes with themes and layouts that you can use to make your resume look more different. Add your own touches to it and keep the styles function handy. So many resumes look the same and it’s your chance to make yours look different. This will increase the chance that a hiring manager will look at your resume.

I’ve seen very creative resumes with colourful graphics and even some interactivity. Those to me are really special and if you have the creativity for it, then go for it. Your resume will look different than everyone else’s.

What to make your Resume with

I’ve seen people make resumes with LaTeX and other complicated WYSIWYM systems and struggle with formatting and text placement. Yes, LaTeX produces the most beautiful documents but if you’re not a LaTeX veteran you’re spending way too time on something that could take you less time.

My secret, is Microsoft Word, although you could also use LibreOffice Write. If you’re creative with invisible tables and other tricks you can get a document formatted exactly the way you want. I have to admit some of the contortionist tricks can sometimes be buggy but at the end of the day you can generate a nice PDF file to present yourself. In my opinion, WYSIWYG is the way to go.

What to include in your Resume

If you look at my resume, you’ll notice a short one page summary but also a table of contents to whatever else the recruiter or hiring manager will want to take a look at. I suggest you include everything whether it’s volunteering work, your certifications, your education, your hobbies so on and so forth. Even if one experience is not directly related to your field, include it. It will make your look more polyvalent and as a result more well-rounded.

For each experience, separate the tasks into projects and rather than use paragraphs for each one, write bullet points. Not every job is project based so you’ll need a different presentation at the risk of making your resume look less consistent. Be creative here.

I recommend that for each job, you have a short list of technologies you work at for each companies. Sometimes, employers and recruiters only care about that so it will save them time pruning your resume.

Embolden key words in your descriptions which will help recruiters skim your resume rather than reading each line. They look for individual items and words that stand out make their job so much easier.

I heavily recommend creating a LinkedIn profile that is very similar to your resume. Recruiters often look at profiles for potential workers. In the tech world, LinkedIn is the most popular place for exposing yourself and finding jobs.

Portfolio

Although many employers require a diploma they often turn a blind eye to it. They’re looking for experience, both professional and personal. You might find it difficult to show off to their interviewers if they can’t find a GitHub account. Even if they are small, a few projects on GitHub can make a huge difference. However, make sure it’s your best code with the cleanest of comments and formatting.

Your portfolio doesn’t have to be only software you made, it could be anything else like essays you wrote. Like I said before, the more well-rounded you look, the higher chances of you landing an interview is. This is as important as they experience you had in your professional life. You’ll need to spend sleepless nights working on these and even one project can make a different. It doesn’t have to something fancy, even a web version of a Todo List can do.

Interviews

For most, this is the scariest part of acquiring a job. Interview styles change drastically from very technical ones to more laid back informal ones.

In preparing for informal interviews, get familiar with the technologies that the company is using for their projects. Learn them well so you can answer questions about them. It shouldn’t take more than a day but it will make all the difference in the selection process. Know about the company and their industries and exude curiosity during the interview. Remember, casual interviews tend to be more two way.

For technical interviews, it’s the same deal, learn the technologies behind their projects. Whether they make you go on the whiteboard to create a stack using lists or ask you questions from JSR-310, don’t be afraid. Remember, interviews are two ways and don’t be afraid to ask questions. They’d much have a curious employee than someone who just does what they’re told.

Keep in mind that once you got offered an interview, you’re really far in the job acquisition process. This is probably your last step before getting asked for references.

References

As for references, pick coworkers and managers who’ve had a good impression on you. Ask their permission of course and get their email and phone number. I highly recommend you get their personal contact information because they could have changed jobs two years down the line.

Some employers however skip this step entirely as it’s quite a cumbersome task to make phone calls and send emails. This is especially true for contracts in comparison to full-time jobs.

Contracts vs. Full-Time

Contracts give the most freedom in terms of how you’re going to work. You can negotiate the terms and the timelines and the possibility of renewal. You can finish projects early and end the contract before the end time. If you need to quit for health reasons, you can do so at any times.

However, the biggest problem is the lack of any benefits whatsoever. No health insurance, no life insurance, no RRSP matching and so on. You have to arrange that yourself and very often you’ll find yourself denied for some benefit.

I do however heavily recommend you get incorporated. It makes dealing with taxes so much easier and it adds to the flexibility. Finally, the pay is much better than full-time jobs but get ready to do a ton of paperwork.

Full-time jobs are for when you desire security and benefits. If you have health problems for example you don’t have to worry about paying in full for whatever you need. The pay is much less but it depends how much comfort you want during your employment. If you get hired by a recruiter, you have some of the flexibility of contracting but with the comfort of a full-time job.

How to Apply

There are several places to upload your resume including Indeed, Monster and LinkedIn. I found that Indeed and Monster provide really low quality jobs often away from where you live. Only use them if you’re desperate. LinkedIn allows recruiters to see your profile and you can easily apply to many jobs just by providing your resume.

If you’re just starting, apply to as many jobs as you can. You don’t have the luxury of being picky, just find anything that matches your skill set and apply. Don’t take too much into account how far it is from your place and the salary. You need something to start building your experience.

More experienced people can be more selective as higher paying jobs need a ton of experience which you likely have at this point.

From application to finding job, in my experience takes from one to three months. Again that depends on your country and specific industry you’re interested.

Accepting Offers

Once you get the offer letter, don’t rush to accept it. Even worse, don’t accept the offer during the interview, it will make you seem more desperate. Be clear with them that you need a day or two to sleep over the offer before making a decision.

Conclusion

Applying for any kind of job can be gruelling and soul-crushing requiring immense patience. However, I hope the above tips get you closer to get you to a workplace you enjoy and cherish, no matter how bad the weather is.

If you have any questions or additional advice, please post a comment.

Clever Code

I recently worked on a proof of concept mobile application for an insurance company. It was simply designed as a tool for sales to demonstrate how a potential concept could work.

The statement of work seemed to be reasonable, a week to improve some functionality and change some branding. It also included updating the dependencies of the project and upgrading it to work with latest tool set.

It really seemed like a reasonable project until I was given the source code. I realized that what I had in hand was production quality code with hundreds of libraries included. I could barely understand the workflow of how the code lead to functionality, it seemed like sorcery was being used to generate it. I've worked on a dozen of mobile applications and it was generally easy to understand how they worked.

Obviously, this 3 year old project wouldn't compile with the latest tool set. I thought it would be an easy task to simply bring up the libraries to their latest version, but a ton of compiler errors were thrown. Why? The code heavily relied on paradigms from the older libraries and the newer ones have changed workflows completely.

I realized that updating the application would require major refactoring which wouldn't fit within the tight deadline. I won't give too many details as work is supposed to be confidential, but it was a very simple app with a few screens and extremely basic functionality.

At that point, I decided that I would rewrite the application from scratch. What took a team several months to do I was confident that I could do it in one day. However, I wrote very simple and easy to understand code. It's a proof of concept, a prototype. The source code is supposed to be disposable once the company decides to turn the PoC into a production quality application.

In one day, I had the prototype working with the same functionality, actually more, than the original version. My goal was very different, it was a PoC, not production software, it's supposed to be a prototype. One day's worth of work is not costly to throw out, but spending on several employees to do the same thing, but with way more complicated code is way more costly and even more when it comes time to maintain it.

Even production applications can be overengineered. Code can be very clever but an impossible mess to actually understand. Most developers don't realize that code is easier to write than to read. In several years, a simple bug fix will break the application because you can't remember how the asynchronous event system worked when it could have been a simple method call in a seperate thread.

Code is supposed to be of the same scope of the application, not more. Annotations, lambda expressions and so on are tools to help you write more readable code but only when it stays reasonable. A super clever implementation of lambda expression that spans the entire screen is much worse than a simple for loop which is what you really needed.

New developers want to show how clever they are with complicated code, however it doesn't impress anyone because no one understands it. As I progressed throughout my career, I realized that very simple code is way more elegant than clever black magic. As a result, I ended up with more maintainable code that I could come back to years later when it needed a simple bug fix and I was confident that it wouldn't break anything else.

My belief is that code should be as simple as reading an English article. Only a one pass reading should give you an idea on what's going on. If you need to reread the code several times to understand it, it's a bad sign.

When you do need to be clever because it's the only choice, it better be documented with plentiful of comments, that explain why and not how the code was designed that way. Whatever is needed whether it's diagrams, a separate document or even a video. The point is that the next developer understands it right away.

If you can recite the code and it sounds like English sentences, you're on the right track.

How to Program and Make Software

Learning software development is one of the most frustrating endavours you can partake in. You see these sophisticated web apps and advanced operating systems and you want to do like them. You want to make a great triple-A game with your own amazing story. However, few realize the amount of effort into making these. These pieces of software are built by big teams with dozens of members who spent the past 5 years churning out code.

On top of that, it's not just about writing and understand code, but it's about writing it in a way that it can be re-used, easy to read and understand years down the line and easy to fix and maintain. Yes, you can make something work by copying code you don't understand and having a big giant mess of spaghetti, but it's not something that you call software engineering. At best, you're a script kiddie.

Like in any field, you need to start really small. Writing command line applications that add two numbers. Understanding the very fundamentals of how computing actually works, how code is converted into something the CPU understands.

Many want to become computer scientists and software engineers, but I honestly don't believe that academia is the best route for this. The knowledge they offer is often out-dated and doesn't really apply to the real world. In school, you get these lab exercises with perfectly commented code but when you start your job, things are really different and way more messy. Yes, you might need a degree for you next job, but an Arts or Math degree will get you far enough. To build software, you need to be passionate about it and teach yourself. You need to get deep into the books and learn by reading other people's cryptic code. Unlike other fields that have been the same for centuries, software changes every day. Just look how often your phone apps get updated and changed. It's not just about trends, it's about constant improvements.

Don't be discouraged when something doesn't work, keep trying until you get the results you want. Keep re-inventing the wheel until it is a well-oiled machine. You won't get there in a few days but trust me the ramp up will be quicker than you think.

You need to pick a path before you start on your adventure. Do you want to write games, cool web apps for budgeting or how about an advanced modeling and simulation library? Just like any other field, there are specializations and you can be good on as many as you want. The secret is time.

When someone asks me about where to start, I usually throw this list of resources with books and websites. Somewhere in there, you'll find something that tickles your fancy and will get you started on your programming adventure.

No Excuse List

http://noexcuselist.com/

There's a lot of free programming courses in there if you prefer lectures and interactive exercises instead of reading. Codeacademy and O’Reilly are really popular.

Freely available programming books

https://ebookfoundation.github.io/free-programming-books/books/free-programming-books.html

Basically anything related to computer science can be found here. There's even some IT related books in the list. Updated all the time.

Awesome Awesomeness

https://github.com/bayandin/awesome-awesomeness

A meta-list of useful libraries for different programming languages. Before trying to code something on your own, see if there's a library that does it already.

Pick your preferred method of learning and you'll on your way to make whatever you want. The sky is the limit, or perhaps your imagination.

The Million Dollar App Idea

If you're a mobile developer, this almost certainly happened to you. A friend or relative makes you swear to secrecy about what he's going to tell you next. His secret idea will change the world and make millions. He comes up with the idea (usually like Uber but for X) and you do all the development work, split share 50/50.

Most people think that coming with an idea is hard, but it isn't. Everyone has a ton of ideas all day long, many of them ridiculous and some few genius. However, execution is the difficult part: development, marketing, building a company and so on. That sucks in every available time slot in your day as you try to make your idea into reality.

What's worse however is most of these ideas fail. Startups get a ton of investment money that is sunk into nothing. People quit their jobs hoping their new business will let them retire early. None of this really happens.

People are mesmerized by what they see in the media. A teenager who made a soundboard app makes millions and buys a mansion at age 17. Another makes thousands of dollars in ads from his YouTube videos or Twitch streams. However, all of this is a form of survivorship bias.

How many Twitch streams are watched by virtually nobody compared to the few famous ones. Pennies are made from most YouTubers who put ads up. The reality is that these successful people are the exception not the norm, they can almost attribute their success to luck.

I've seen people with no fame make excellent content and vice-versa. Producing good work isn't guaranteeing success. Not the best product is always the one that makes it to market. If we can call it that, fate, results in success.

However, to succeed, one must play the lottery game and hope to make it there. You can't beat the odds if you don't try. But don't approach the idea with naivety, but actually study what people want. Notice how informercials sell mundane things you never thought of and they sometimes make great success even if their products are garbage.

Think of a problem that you actually experience day to day. Something that bothers you and perhaps others. Maybe finding a solution to that would increase your success. Don't just imitate another streamer or blogger, because they succeeded out luck mostly. You need to do something novel that no one has ever thought of yet, and maybe, just maybe, you'll be making a few bucks.

When working on a project, your goal shouldn't be fame or money, but rather passion and learning. That growth is so much more valuable as the new skills you learn can be put into use somewhere else, maybe in a job that actually makes money.