Will and BJ first met in college and have been friends ever since. You can tell this through their dynamic conversations. Will bring a wide knowledge base to the conversation through his years of experience as a senior developer and aspiring software architect. Whereas BJ being a journeyman developer is learning as he works in the field. He shares those lessons and more each week. Because of their varied experiences topics range from the technical to the every day life of a software developer. Whether you are just starting out or in the twilight of your career you'll find something useful and informative on Complete Developer Podcast.
There are plenty of podcasts out there focused on languages and coding. What we are doing with the Complete Developer Podcast is to also cover the other areas of life as a developer.
Logical Fallacies: Omission and Ambiguity
Logical fallacies are errors in reasoning that can invalidate an otherwise good discussion, formal argument, or debate.
The fallacies discussed here have to do with misdirection or misinformation. Fallacies of Omission occur when important or even necessary information is left out of an argument. Fallacies of Ambiguity create confusion by using unclear or poorly defined words or phrases in order to misdirect the argument from the evidence supporting the other side.
This is the final part in a series of episodes on logical fallacies. Already we have discussed Fallacies of Relevance and Component Fallacies. There are a lot of logical fallacies out there, enough to have entire college classes on them. These episodes only covered a few of the more common ones in each category.
This concludes the series on logical fallacies. At first glance these appear overwhelming and overly academic. However as you learn them you will start to see people using them. This will help you to better understand the reasons for certain decisions or how management has been influenced to keep using a deprecated technology that hasn’t been supported in years. Study them, re-listen to the series if need, so that you will not only be able to recognize when you or others are using them but also know how to defend against fallacious arguments.
Fallacies of Omission
Fallacies of Omission are logical errors where necessary information is omitted. It often results in the argument being directed away from the missing information.
Argumentum Ad Ignorantium
Literally translated it means “Argument from Ignorance” or it can be called the Appeal to a Lack of Evidence. This is the idea that because the other person cannot disprove a premise or idea that it must be true. You will run into the lack of evidence fallacy a lot when trying to get older managers or leads to try newer technology, they will come up with something that the newer tech was never designed to do or that there is no information about. The tricky part of overcoming this fallacy is that the burden of proof lies with the person making the claim so if they something isn’t possible the burden is on them to prove it, not on you. This is why scientific research uses a null hypothesis (opposite of what they are trying to prove) because the lack of evidence doesn’t disprove their hypothesis it only fails to disprove the null hypothesis.
Argumentum Ad Speculum
Also known as Hypothesis Contrary to Fact, this fallacy tries to proves something in reality using examples from a fantasy or made up world. The idea is that hypothetically if A happened, then B would be the result of it. The problem is that all of the examples and evidence supporting the argument are hypothetical, or based on accepting a hypothetical premise. This is the other side of the “What if this happens” of the previous fallacy, instead you’ll see this happen after the fact, “Well if we’d changed platforms back when I suggested we wouldn’t have these problems”. While fun to play time-travel/butterfly effect mental games, these hypotheses are typically irrelevant and do not actually provide evidence for or against an argument in the real world. To overcome this you have to politely point out that talking about what could be doesn’t solve the problem a hand, also you don’t know what issues you would have faced had a different decision been made.
Stacking the Deck
The name comes from cheating in card games where a person will place cards in the deck while shuffling to benefit them in the game. In this fallacy, the person making the argument ignores evidence or examples that disagree or disprove their conclusion and only provide evidence in support of their case. The ‘No True Scotsman’ Fallacy is a specific type of Stack...
By its nature, software is subject to frequent change. In general, software isn’t particularly static and can be rapidly reconfigured to adapt quickly to changing circumstances in the market, security landscape, and whatever industry it serves. This is one of the main reasons that software is eating the world right now – it’s because of its rapid ability to change.
However, this adaptability can also be a weakness if you aren’t careful. Most software these days includes integration points of various sorts so that other software can work with it. If the people integrating with your software happen to be paying you, then it’s crucial that you control the way your software interfaces change so that you disrupt your users as little as possible. To make things more complicated, not everyone always interacts with your software in the way you expect. You may find, for instance, that people directly interact with an underlying database, use web automation to push data into your system, or even automate your user interface as a sort of “back door” integration method.
If you want to try and ensure backward compatibility to the degree possible, there are a few practices you can use that will make this easier. While we are planning to have more episodes discussing backward compatibility in various contexts, there are some general rules that you should follow regardless of how other software is interacting with your software. In particular, these rules are focused around the idea of limiting disruption to your users while still allowing as much flexibility as possible for your development team. Disrupting your users a little bit will irritate them, while disrupting them a lot makes it more likely that they will flee your platform for that of your competitors.
Keeping backward compatibility is a royal pain at best. As your software gets more mature and has more people integrating with it, don’t be surprised when you find that you have to spend significant effort keeping your code from breaking other people’s integrations with your product. Once your software is stable and in use, you no longer have the ability to change things at the edge as quickly as you could when you were starting out. However, if you are careful and plan ahead, you can often significantly reduce the amount of time and effort that are required to be able to make changes to your software that impact other people. Best of all, these best practices can often result in your integration points being more useful to your own team as well.
Use Semver religiously.
If you can’t communicate version changes in a clear and widely understood manner, then everything else we are about to suggest will be impossible. Semantic versioning is a good way to do this. With Semver, versions are expressed in three segments (Major, Minor, Patch). Major version numbers are incremented when you make breaking changes. Minor versions are incremented when you add functionality in a backwards compatible manner. Patch versions are incremented when you add bug fixes in a backwards compatible manner. Semver is a great way to communicate changes to your users in a way that makes it easy for them to see how much trouble an upgrade will be. This doesn’t mean that you don’t need to include release notes, however.
Keep on top of YOUR dependencies.
Nothing can force you to implement breaking changes on your users faster than having one of your dependencies force you to quickly make sweeping changes in your code. While some vendors really seem to love to make sudden sweeping changes that cause major problems among their users, most vendors at least attempt to handle breaking changes in a sensible manner. If they don’t, you should reconsider your integration with them, because they are hurting your users in a way that causes yo...
Your Most Effective Work Times
How much actual work do you get done in a given work day? Some of us don’t think much about this. We clock in, work, then go home. Interruptions, meetings, and pointless tasks are just part of the daily routine. For others tracking productivity is almost a hobby or second job. They use tools and spreadsheets to track how much time they spend on tasks and even demark the value of those tasks.
Several different research studies suggest that people are only productive for 2.5 to 3 hours in an 8 hour work day. Everyone has a most effective or peak performance time which typically lasts 3-4 hours. This is when the majority of people get their productive work done during the day. Factor in meetings and other interruptions and you get your average of 2.5 to 3 hours of productivity per day.
However, the way you organize your schedule has a huge impact on your productivity. Knowing when you are at your most effective time means you can actively work to reduce distractions. Also, just because you are not at your peak doesn’t mean you can’t get productive work done during the down times.
Unfortunately we don’t have full control over our work schedules. There are meetings we can’t control or required business hours when we have to be online or at the office. In these cases we have to know where we are in our productivity cycle and use that to make the best of the situation until it can be changed. Understanding when you are at your best performance and how to maximize it will help you not only in the work place but in your life outside of work as well. Whether you are a lion, a wolf, a bear, or even a dolphin you can learn to use your natural tendencies to get the most out of not only your peak times but also your troughs.
Using Time Wisely
Mono-task Instead of Multitask
Multitasking may seem like a way to get more done in less time, but it leads to more mistakes and less creativity in thinking. As humans we have limited cognitive bandwidth, therefore our ability to accomplish things is dependant on our ability to focus on one task at a time. Unless used for the same task, reduce yourself to one screen when you are mono-tasking. The pomodoro technique, or interval work helps to stay focused on a task for a set amount of time. Distraction is a primal instinct. It was necessary for early humans to respond quickly to predators.
Find the Prioritization That Works for You
Prioritizing basically means figuring out which tasks you are going to get done in a limited amount of time. It doesn’t always mean one task is more important than the other, though that makes the process easier. Spend some time experimenting with different techniques to prioritize your schedule. Some people spend the first part of their day deciding which tasks to accomplish and prioritizing them. Whereas others will prioritize and entire week, or set up for the following day at the end of their workday. There is also the difference between starting with an easy task to get going or “eating the frog” and doing the most difficult thing first. This depends on personality and what you have to do that day.
Stop Going to Meetings
Meetings are typically time consuming wastes of time that are unproductive and foster disengagement of workers. Look at teams distributed across continents for inspiration on ways to avoid meetings. They are not able to all be in the same room or even online at the same time. Only attend meetings with agendas, especially if the items cannot be discussed or resolved without having synchronous communication. If you must go to meetings try to schedule them in blocks of time, or around blocks of focused work time.
Experienced developers understand the cost of interruptions, especially during their most effective work time,
Leveraging Legacy Technology
Most of us want to work on the latest tech. In addition to being more fun in general, newer tech also comes with less baggage, more job opportunities, and often solves emerging problems. However, beggars can’t be choosers. Eventually, either due to a surprise job loss, major economic turmoil, or a bad job situation that you have to get out of, you’ll eventually be stuck working with legacy technology in some capacity. In tech, the tip of the iceberg is comprised of organizations using the latest and greatest, and beneath that is a substantially larger number of environments that are using something developed between 5 and 40 (or more…) years ago.
At some point in the future, whether it is in the next couple of months, or the next 20 years, the economy will crash and burn to some degree, taking many jobs with it. It’s simple mathematics. While you might typically avoid older technology, you’ll find that there are situations where you have to deal with it, simply to get the bills paid. Your approach to this problem will determine your level of success once things recover enough to get a better job.
In effect, it’s like someone just showed up at your door with a dump truck full of manure. You either have to deal with a load of crap, or you have to figure out the right place to put it so it can become fertilizer. The willingness and ability to do this can often be a career changer.
You can effectively leverage working on a legacy system, provided that you know what you want to get out of it, other than a paycheck. A lot of developers tend to look down on work positions that use legacy technologies. This is excellent, because if you are any good, you can often have your pick of the jobs. Better yet, if you pick the right jobs, you can quickly build up non-tech skills and expertise that will help you compete with people whose technical resumes are more current.
Experience With Older Tech
The most obvious benefit to legacy tech projects is the opportunity to learn legacy tech. While this may not seem like much, if you can still get a job in an older technology stack, that means people are still using it. As stacks get older and there are fewer people using them, the price per hour for getting development help often goes up. This is especially true of stacks that are more than 10-15 years old. Additionally, experience with older tech is often very useful even in jobs with newer technology, simply because you may have to integrate with it.
People that work with older tech also tend to be older. In addition to often being good mentors, they tend to know a ton of other people in the tech community. While you might not think that the mentoring aspect is too valuable when you are dealing with older tech, the fact is that you can often bounce ideas off of people who are used to an older way of doing things and gain surprising insights. Many times, people who are using legacy technology are very good advisors on how to deal with non-technical problems in your career, such as office politics. If they’ve survived in one position for a while, there’s probably a reason for it. Additionally, you might serve as a mentor to THEM on some of the newer stuff. This can be advantageous to both of you.
Experience Converting To Newer Tech
If you end up on a legacy project, learn well, and have experience in new technology, you can often be heavily involved in porting that technology to a newer platform. This will give you more experience in BOTH technologies, as well as a ton of other useful non-technical experience. As it gets harder to find developers of legacy technology, you might a useful (and lucrative) niche in converting business systems from an older technology to a newer one. Lots of people do this and make a lot of money with it.
Logical Fallacies: Component Fallacies
Component fallacies are considered formal fallacies because they have to do with the form of the argument. You may be correct in what you say but it is out of order and therefore sounds like nonsense. This group of fallacies have to do with errors in reasoning. This may be inductive or deductive reasoning.
This part two in a series of episode on logical fallacies. A few weeks ago we discussed Fallacies of Relevance. There are a lot of logical fallacies out there, enough to have entire college classes on them. These episodes will only cover a few of the more common ones in each category.
You are going to run into logical fallacies all the time, especially in informal conversations with friends or on social media. It’s important to understand that fallacies are faults in the logic of an argument. Because what someone says contains fallacies, that does not mean they are not correct, it just means their particular argument didn’t prove them correct. Keep that in mind and be lenient on those who may commit the fallacies. Use the knowledge here to better your own use of logic when arguing your point.
The Fallacy of Presumption or Begging the Question is also known as assuming the conclusion. This happens when the conclusion to the argument is used as part of the premise for that same argument. Sometimes the term “begging the question” is used in ways other than in relation to the Fallacy of Presumption such as when someone means “raising the question”. Circular Reasoning is a form of Begging the Question where the argument repeats what has already been assumed instead of arriving at a conclusion. These are really not arguments but instead restatements of the same thing to look like a logical argument.
Hasty Generalization are also known as “Jumping to Conclusions” and “Converse Accident”. This is a failure of inductive reasoning where there are not enough samples to prove a point. It’s normal and natural to generalize, the problem comes when there is an insignificant amount of evidence for the generalization or it is take beyond the constraints of the evidence. Many times you’ll see this in the “we tried that a few years ago and it didn’t work” argument. This can be a difficult one to overcome because what is considered sufficient varies depending on the circumstances.
Non Causa Pro Causa
Literally translated meaning “not the cause, for a cause”, the False Cause Fallacy occurs when the conclusion comes before there is enough evidence for the conclusion. This tends to happen when the person making this fallacy wants the conclusion to come from a particular cause because it fits into their own narrative or argument. Post Hoc, Ergo Propter Hoc (Post Hoc for short) means “after this,
Generally speaking, repeating the same actions under the same conditions should create the same results (or close enough that the results aren’t a surprise, at least). This tendency is at the root of all scientific pursuits, our development of technology, our understanding of economics (such as it is), and forms a core belief in a big chunk of the population. This is especially true for software developers, because we literally rely on functions at a deep level. In fact, the mathematical definition of a function is “a relation from a set of inputs to a set of possible outputs where each input is related to exactly one output” (mathinsight.org). When examined, this statement simply says that doing the same thing should produce the same result with the same inputs, albeit with a bit more mathematical rigor.
However, if you’ve ever had the experience of getting burned by caching, you are more likely to describe the experience as being more like Schrödinger’s cat. This is a concept from a thought experiment posed by Erwin Schrödinger during discussions with Albert Einstein while expressing his objections to the Copenhagen interpretation of quantum mechanics. While a full discussion of this principle is beyond the scope of this podcast, the gist of it, per Schrödinger was that if you put a cat in a box with something that would kill it (in this case, a radioactive particle), that if you couldn’t perceive what was in the box, that one could model that cat as either being “alive” or “dead”. While a somewhat gruesome notion, if you’ve ever dealt with cache invalidation of unknown length, this probably sounds familiar.
So, if you suspect a cache issue, because things are behaving in a way that indicates Schrödinger’s Cache might be your issue, you probably need a reasonable way to think about your troubleshooting efforts. Troubleshooting cache issues without a plan is not only unlikely to succeed, but you may find that you have difficulty proving that you actually fixed an intermittent issue. In effect, you need to figure out how to let the cat out of the box so that it is in a provable state.
Dealing with caching issues is very frustrating. One of the biggest problems is that caching problems often manifest in a very unpredictable manner, often driven by load or by user behavior. Because of this, troubleshooting caching problems often requires that you first prove that caching is a factor in the problem, before attempting to correct it. Once you have proved that the cache is involved in the problem, you can manipulate your cache in order to make the problem easier to reproduce, which will greatly aid you in troubleshooting and debugging.
Basics of caching
A cache is a higher speed (or lower cost) data storage layer, which stores a subset of data, typically transient in nature so that future requests for this data are faster/cheaper and create less load on the system. When a cache is in use an incoming request will be examined and a cache key generated. This key will be used to look up the result in the cache. If the result is there, it will be returned. If it isn’t, it will be retrieved, stored in cache, and then returned.
Items in cache will have a cache window, that is, a period of time that will elapse before the item is removed from cache. Accesses of data subsequent to cache invalidation will cause the data to be reloaded and recached. Sometimes caches have sliding expiration, that is, the item will remain in cache for a certain amount of time since it was last accessed. This lets the cache perform better under load, while possibly reducing accuracy. Most caching systems also let you manually invalidate an item in cache. This is handy if the thing you are caching sometimes exhibits more volatility more frequent than the length of your cache window.
Customer ReviewsSee All
Keeps interest in the craft
Great podcast to keep current in the dev world and prompt ideas. I've been a software engineer for 20+ years and I'm still learning :)
Very informative and has helped me identify my blind spots
All your podcasts have helped me become a better engineer.
There are several aspects of programming like documentation and collaboration that I have learned from you folks.
Informative and funny
Very fun to listen and at the same time learning new stuff that I am not even know off. Wish you guys can talk about dev ops and over engineering codes