Anna Filina

There is no such thing as a perfect employee match in programming. If you write a list of technologies in the job description and expect to find a candidate with the all right experiences, you will be strongly disappointed. You could spend months or years searching, while overlooking very good candidates just because they lack one or two skills.

New technologies are coming out each hour and it’s impossible to keep up with absolutely everything. Developers make choices based on what they think will become a trend in the near future or based on what seems most useful. They are also exposed to some technologies regardless of whether it’s a good or a bad choice, because they are often not the ones making these decisions in a project. Since each person’s journey is different, the permutations of skills are incalculable.

IT projects require a multitude of technologies. A project can require experience in a specific framework, ORM, CMS, caching tool, automated testing tool, database, continuous integration, deployment, messaging protocol, etc. Also, multiple programming languages are sometimes required. Now multiply languages by the number of language-specific tools. A developer is often expected to have over 20 skills. The possibility of a perfect match is virtually inexistant.

I’ll give you some examples from my own journey. I was once hired to work with the Flex framework. I worked with ActionScript once, language on which the framework was built. I had no direct experience with Flex, the main skill required. I was hired regardless, because there were simply no developers experienced with Flex in the entire province at the time. I read the documentation in two days, I built the software and my employer was happy with his investment.

A scenario like this happened to me over and over again. I did not need direct experience with any technology, because all programming languages are pretty much the same except for syntax and minor philosophical differences. All frameworks and tools follow pretty much the same principles. At the end of the day, you just need logic and willingness to work with new tools.

So what is the solution? Don’t try to hire developers based on a keyword match. That’s just silly. Humans are much more flexible and adaptable than this. Hire them based on their logic, which you can evaluate by discussing anything technical or even non-technical. Hire them based on feedback from past clients or employers. Hire them based on enthusiasm and attitude in general. Hire them because they can think.

Many developers claim that to achieve high quality software, developers must create automated tests that ensure that all possible execution routes have been covered. This is also known as full path coverage. I will argue that different types of software require different testing approaches and that full path coverage is impractical in almost every case. Too many tests simply create clutter. Read more…

Many people confuse the three concepts. For a business to grow or for a project to succeed, these need to be well understood. I will use a driving navigation system to explain them.

Before you set out, you need a destination, a goal. A goal needs to be measurable, that is, you need a way to confirm that you have achieved it. When driving, that usually means arriving at the specified coordinates. Additionally, you may want to get there within no more than 40 minutes.

Read more…

A montreal-based newspaper recently released a new mobile product to read news. It’s very nice, but it cost them 40 million and took 3 years to ship, with some 100 people on the team. My company has enough experience with news corporations and other industries to know that there was a lot of waste. My associate stated on social media that he could save them millions on their next project. It’s what we specialize in: generating millions in ROI for our clients.

Read more…

I have recently read a blog post claiming that functional tests are not “true” tests. The author also claims that unit testing shows you where the problem is occurring, while functional testing simply identifies that a problem exists. This argument is deceptive and the conclusion dangerous. Different kinds of tests are not mutually exclusive. One is not superior to the other. They have different goals and can happily coexist. Let me explain the kinds of tests so that you could make enlightened decisions.

Read more…