Podcast Episodes

Relational databases continue to be a huge part of modern systems design and the rules of relational databases should generally be followed. However, there are times that you need to break (or bend) normal database design rules in order to reach your goals.

Promotions can be exciting. You've worked hard and are now moving up. However, they can also lead to impostor syndrome the closer you get to management.

Many developers start out in the job search feeling relatively optimistic about their chances of getting a much better job. However, that optimism can often quickly turn to horror if they end up landing the WRONG job.

Do you find yourself unable to stay in a relationship or at a job? Maybe you get a new job and it's great but quickly becomes a nightmare. You may believe you are unlucky in love. When this happens over and over again the problem may not be a string of bad people or places, the problem may be you.

Not every app is built using best practices. Sometimes you have to try and fix an application that has been poorly maintained for years or even decades. Adding dependency injection and inversion of control is a great example of this kind of situation.

If you are like many developers, most of the time you are building systems that are intended to be used directly by users. However, eventually you will be tasked with building processes to process data out of band. And when you do, you'll quickly learn that such processing requires a very different thought process.

In the Sword of Truth series Terry Goodkind lists out several Wizard's Rules that are used to illustrate points and train the characters. Each one has a different but related message about life.

We all lose motivation or fall prey to distractions. Productivity, creativity, and quality suffer when we lack the self discipline of a strong work ethic.

We talk often on the show about software development methodologies such as Agile or Waterfall. However, we haven't gotten into the project management process or stages of software development underlying them.

There was a time you could write software for just the English speaking market and expect your company to do well. That time has long passed, and to be truly successful, your software has to be able to work for people speaking a variety of languages and dialects.