Hiamalya-The podcast Player

4.8K Ratings
Open in app
title

Complete Developer Podcast

BJ Burns and Will Gant

13
Followers
12
Plays
Complete Developer Podcast

Complete Developer Podcast

BJ Burns and Will Gant

13
Followers
12
Plays
OVERVIEWEPISODESYOU MAY ALSO LIKE

Details

About Us

A podcast by coders for coders about all aspects of life as a developer.

Latest Episodes

Static Code Analysis

Static code analysis is a way of debugging that automatically examines source code before it compiles or is run. It does this by comparing the code code to a set of rules or standards. It is a way of automating code reviews and can be used in conjuncture with peer reviews. Yuri Minaev is working in the PVS-Studio company as one of developers of the C++ static analyzer. His primary responsibility is to keep low-level stuff in order and add new features to the core module. It’s been almost 2 years since he joined the team after about 12 years of IT experience. Apart from that, he periodically gives talks at various conferences – mainly on topics related to static analysis and C++. PVS-Studio is cross platform, working on Windows, Linux and MacOS 64-bit environments. It can analyze code designed for 32-bit and 64-bit systems as well as embedded ARM platforms. It generates reports that help developers to find and fix bugs before they become a problem. Keeping a codebase clean and detecting problems before they occur will make your life better as a developer. When you can avoid getting nailed by simple problems, you can think about your software at a higher level, vastly improving your effectiveness as a software developer. It’s not just about avoiding bugs, although that’s important, but about what you can do with the time, money, and attention you save. Book Club Remote Work: The Complete Guide. Will Gant Chapter 10 – The Ultimate List of Remote Work Resources. This last chapter of the book lists out a ton of resources for remote work. This includes tools for automation, books, blogs, podcasts, career resources, and other things that will help you on your remote work journey. While you can do it all the hard way, you’ll get a lot further a lot faster if you learn from other people and use what they know. This section will help you do that. Tricks of the Trade It can be hard to let things go. Especially when it’s a project you’ve been the primary developer on for a while. You don’t want to let other people in to mess with the patterns and paradigms you’ve set up. However, in order to move forward we have to move on from our old code. There are developers who spend years building a large intricate system, but don’t allow anyone else to touch it. This means they spend the next few decades maintaining it. If you don’t want to spend your career updating and maintaining something you wrote early on, then you have to allow others to make changes in your code. Links * PVS Studio * Yuri Minaev Remote Work Book * Why Work Remote * Will’s Profile on Simple Programmer Editor’s Notes: Yuri lives in Russia so the audio from the call is not the best.

68 MIN5 d ago
Comments
Static Code Analysis

Long Term Remote Work

Working remotely is a wonderful job perk and can make many developers more productive, happy, and less likely to leave for greener pastures. However, it’s no panacea, especially over the long term. The effectiveness of remote work over the short term is a result of your work ethic and your ability to think on your feet. Over the longer term, however, remote work is only successful if you have good habits for managing your remote work environment. In addition to easily forseeable problems, such as communication and productivity issues, there are a lot of hazards to remote work that you might not have considered until you’ve done it for a while. Lots of things are stable over the short term that are completely unsustainable over the long term. For instance, you might need to work an 80 hour week for a week or two to hit a critical deadline that takes your career or your company to the next level, completely destroying your work-life balance, sleep, and personal interactions over the short term to get a much better long term result. However, you can’t do that for very long. In fact, we would generally argue that you can’t (or shouldn’t) do it all, but some people do manage it reasonably well on occasion. If you do it for very long, you not only quickly hit a point of diminishing returns, but you often do damage that can’t be easily undone. The costs of not managing things for the long term are stark. Poor remote work habits can lead to job loss, degradation of skills, damage to your most important personal relationships, financial and health woes, and even chronic pain. We are in a unique period in history where it is not only technologically feasible to work from home, but where we are expected to do so while heavily collaborating with other people. However, if you really want to take advantage of this unique opportunity you need to plan ahead. Working remotely over time has some challenges. While these can be overcome as they occur, you are usually far better off if you address them BEFORE you have to. Not only is this approach more sustainable, it’s also a lot less stressful than trying to fix things after problems have already occurred. Episode Breakdown Ergonomics. The layout of your work area can hurt you a lot. Choosing good equipment and positioning of devices is a must. Simply sitting still for a long period of time is pretty bad for your health in general. Be extremely careful about how everything your office is positioned, and pay close attention to any aches, pains, or stiffness that starts developing. You need to be proactive. Socialization Social interactions happen incidentally when you go into the office. They have to happen intentionally when you work from home. While you aren’t going to get as bad as Tom Hanks’ character on Cast Away, isolation will “weird” you over time. A lot of people rely on work to provide them with socialization. The fix for this is to regularly meet with other people for lunch, or have a social life outside of work. You also need to set aside at least some time every week to have non-work conversations with your coworkers. Don’t let your rapport rot. Health (diet, exercise, mental health) It’s easier to ignore your health, physical appearance, and mental state when working from home where you can adjust a camera and not have people notice that you are putting on weight. There also tends to be a lot of snack food at most people’s houses and it can often be easier to eat that than it is to prepare real food (or to pick something up). If you had a routine of stopping by the gym on the way home, you’ll need to develop a routine oriented around either working out at home, or going to the gym at a certain point. You need to be working out,

76 MIN1 w ago
Comments
Long Term Remote Work

Types Of Programming: Coding Styles

As programmers, we tend to be a rather interesting bunch. Some might even call us peculiar. Developers tend to have our own culture and even subcultures within the development community. Attending a polyglot or regional conference will show many of the various subcultures within development getting together to grow, learn, and enjoy the company of like minded individuals. Within the community of developers are several archetypes that you will see. Rarely will you find someone who is completely a particular one but you’ll notice these traits, some stronger than others, in most of the developers you meet. The other two episodes are look at the developers personality and their knowledge base. While researching the different archetypes of developers we broke them down into three groupings: Coding Styles, Knowledge Expression, and General Personality. This is the first of three episodes talking about the types of programmers you’ll meet in your career. It focuses on the various coding styles you’ll encounter. This is not an exhaustive list of coding style archetypes. Instead it’s a group of the ones you are most likely to encounter within your career. While there are others out there you can use this list to better understand your coworkers, managers, and friends in the development community. To be truly introspective think about the times you have exhibited the traits of these and try to figure out which one you resemble most. Use that information to set yourself up for success at your current place of employment and when you are looking for work. Episode Breakdown The Cowboy/girl Coder Cowboy coders are a force or nature who can code two to three times faster than anyone else. They typically have a degree in computer science and believe that clean code and best practices do not apply to them. Refactoring is a luxury for city slickers, the cowboy’s code is spaghetti at best and smells like several nights on the trail eating only beans. Cowboy coders are best on projects where deadlines are more important than anything else. The Perfectionist The polar opposite to the cowboy coder, the perfectionist aim to write the best code ever. While the cowboy treats code like cattle, the perfectionist treats code like their pet or even worse like their own child. They can get confrontational and argumentative when asked to speed up the process or when told to build a less than optimal solution for the sake of time or money. When resources are limited, the perfectionist works best when told the limitations up front and asked to find “the best” solution given the current limitations. The Caretaker The caretakers has been with the company for years, maybe even decades so they know the codebase inside and out, especially the older, more arcane areas. Likely an older generation of developer, they are more comfortable with out dated technology and languages so spend most of their time maintaining legacy applications. The caretaker may have gotten stuck in a rut or be bound by golden handcuffs preventing them from trying new technologies. Tread carefully if putting a caretaker on a newer project as they may be riding out to retirement on their knowledge of the codebase. The Specialist The specialist is a developer who rather than becoming a ‘T’ shaped developer has become a lower case ‘l’ shape, diving too deep into one area at the cost of being well rounded. The data scientist is one particular type of specialist who only codes in python, tends to be very good with math, and enjoys statistics and image manipulation. The security expert is another common specialist you’ll encounter who knows everything about security, typically hacks into systems for fun, and has a different set of ethics than most.

62 MIN2 w ago
Comments
Types Of Programming: Coding Styles

Breaking The Relational Model

The rule: Normalize until it hurts; denormalize until it works. That’s what you typically get taught early on. While normalizing a database is a solid practice and something you should do when designing a system; it can jump up and bite you when you get under load. You probably won’t deal with most of these issues early on in a system (and shouldn’t), but the time will come where eventually some degree of denormalization is necessary to keep performance up to snuff. On average if you start suggesting denormalizing a system, you will have to be able to show that it improves performance significantly. There are good reasons that systems aren’t denormalized and people will typically balk at doing so. However, there are places where under some circumstances it’s worth considering. After all, CPU cycles on a database server are often some of the most expensive ones out there – go check your SQL Server or Oracle licensing fees for proof. Rules are made to be followed in general, but sometimes you have to bend them just to get by. This is especially in computer science, where many “rules” or more like “guidelines for most cases” at best. Episode Breakdown When additional join tables will hurt performance. Joins are not cheap or free. Complex joins are especially bad (for instance, a function call in a join). This is especially true when you are joining across a lot of tables and aggregating a lot of results on a regular basis for data that doesn’t frequently change. When you need to keep historical database records. Consider a system that manages invoices and products. You don’t want to mess up historical data on invoices from last year when a product price changed today. Typically historical tables are also going to be used mostly for reads, so you want to cut down the number of joins just to make that faster. Tables with historical data can often be more heavily indexed than you might see in transactional tables that are used in online transaction processing that has to be fast. When data needs to be structured for reporting purposes. Reporting systems generally have a lot of data duplication simply so that more interesting trends can be spotted with the data at hand. You’ll also have very different indexing requirements for reporting tables. The way the tables are accessed is also very different for reporting. They tend to be read heavy and are going to need different levels of locking depending on what you’re doing. When the data itself is hierarchical in structure. Hierarchical data is difficult to represent efficiently in a relational model. This is especially true when you need to rearrange a tree, or determine if something is an ancestor of something else, especially if the structure has an arbitrary depth. It’s also very difficult to write logic for tree structures stored in a relational model such that you don’t accidentally create cycles in the data. When the data is a graph structure. It’s even more fun when it’s a graph, because cycles are actually possible. While storing nodes and edges is easy enough, doing things like finding the shortest path will be difficult. You’ll also have a difficult time proving that any two nodes are connected without a serious risk of major performance problems. When you have very large records. Relational database have issues with large records, whether you query them or not. They aren’t really designed for holding things like images and huge chunks of text. This is especially true if you want to index and search through this content, as a lot of the search capabilities of a relational database are not really built for this purpose. If you are storing large records,

64 MIN3 w ago
Comments
Breaking The Relational Model

Impostor Syndrome When Getting Promoted

Impostor syndrome is a feeling of inadequacy. It is the sense that you are not qualified or talented enough to do your job. In many cases it’s a feeling that you can’t live up to the expectations of a job because you are a fraud. It was first identified by Pauline Rose Clance and Suzanne Imes in a paper in 1978. At first they thought it only affected women but further research indicates it affects people no matter their gender. While affecting everyone slightly differently, Valerie Young has identified a few patterns that people tend to fall into with impostor syndrome. The perfectionist sets very high standards for themselves and if they don’t meet them feels like a failure. The expert feels like they should know every little thing before being competent. A person who is naturally gifted will feel inadequate if they struggle to learn or do something. The soloist feel that they have to do everything on their own, they are a fraud for asking for help. Finally the superhuman will push themselves harder than their coworkers to prove they are not an impostor. Typically impostor syndrome rears itself when a person is put into novel situations or given more difficult tasks than normal. For most of us some of the most stressful times in our careers comes with celebration. We get promoted then have to take on new duties and responsibilities. This can lead to stress, anxiety, and impostor syndrome. Impostor syndrome is something that we all face at one time or another in our careers. Many of us face it several times as we move up the ladder. This is not a comprehensive list of fears or concerns. They are the ones that we have heard about from others or have faced during our careers. If you have other concerns or questions about moving up in your career leave us a comment or send us an email about it. Episode Breakdown Common Impostor Syndrome Concerns When Getting Promoted * What if I don’t find a good role model or mentor? * I’m not good enough, what I do isn’t perfect. * I like being “in the weeds” on a project, but moving up means I’ll have to take a more general focus. * I’m not good a taking on new responsibilities. Impostor Syndrome Concerns with Starting As A Junior * I do not know enough about coding or the business to be useful. * I don’t really know where I want to focus my career or how I want to brand myself as a developer. * I’m afraid I’ll mess up the existing codebase because I’ve only ever worked on my own code. * Coding is fun, but what if I don’t like doing it as a career? Impostor Syndrome Concerns with Moving to Mid-Level * I’m not going to get as much mentoring or support. * What if I am overwhelmed by the amount of work. * How will I keep up with changes in technology? * Am I trying to make changes or move up too quickly? Impostor Syndrome Concerns with Moving to Senior * What if I’m not ready to be a mentor? * I’m not longer the learner, I don’t know enough to be an expert. * I’m afraid to ask questions or appear unknowledgeable. Impostor Syndrome Concerns with Moving to Management * I’m an expert, not a manager. * How do I manage others while still actually working? * Now I’m managing friends and former peers. * I don’t know how to give direct feedback. Book Club Remote Work – The Complete Guide Will Gant

66 MINAPR 30
Comments
Impostor Syndrome When Getting Promoted

Red Flags In The Hiring Process

When you are looking for a new job, it’s easy to take the first job that comes along. And it might even turn out ok. However, it’s also possible that you’ll end up in a job that is absolutely miserable, burning you out and making you hate software development. Worse still, when you finally get to the point where you are exhausted enough with your job that you end up quitting (or worse, getting fired), the damage has been done. A bad enough job can completely ruin software development for you, to the point where you dread working on code at all. This has happened several times to Will over the course of his career and it’s really hard to recover from. A new job can make huge changes in your career, for good or ill. You want to make sure that any new job you take is going to help you improve your career, without burning you out. While not every bad job gives obvious warning signs before you start, most of the worst ones will at least give you some warning of what to expect. Episode Breakdown Job Posting Verbiage that indicates that the company over-estimates themselves, and you’ve never heard of them. “We only hire the top 5% of developers”. Is your payscale in the top 5%, are you deliberately ripping off the top 5% of devs and hoping they won’t catch you, or are you full of crap? This tends to mean that they have a byzantine, awful interview process of which they are very proud, that probably is designed to help them hire yes men who feel lucky to be there. We are looking for a very specific type of developer and have a thorough set of interviews to find them. Sometimes this is true. Sometimes they need a developer with a very specific set of skills. However, most of the time, what they are looking for is a “yes man” or someone who is compliant. If you can’t tell why your specific set of skills are exactly what they need, then one of you will be disappointed. Lack of clarity about what you’ll be doing. Some companies hire before they have a clue what they are doing. This can often mean that you have to pivot repeatedly during your tenure at an organization. If you don’t know what you want out of your career, this can be a wonderful opportunity to try new things. If you do know what you want, this can be an unbelievable waste of time. If they are being especially vague, it can indicate something even worse. For instance, they may be doing something that is borderline illegal, immoral, or just sketchy in general. Companies running low-budget pornographic operations, or quasi-legal investment schemes may approach you in this way. You would be surprised how many people are involved in extremely sketchy ventures who will approach you if you know the right people. Asking for too much experience for what they are willing to pay. If they are paying a junior developer salary, but expecting five years of experience, there is a reason for it. This could be anything from not having a clue about the market value of a developer, to simply making the job posting so that they are free to outsource. Sometimes companies will post an oddly specific set of criteria for a developer position not because they are looking for someone, but because they’ve found someone they want to hire and are otherwise constrained. This is a common trick some sketchy companies used to hire H1Bs at a lower price, whom they usually later mistreat. Initial Contact Can’t pin them down on a time for initial contact, or the time changes repeatedly. Some companies have really messed up, slow, or confusing hiring processes.

77 MINAPR 23
Comments
Red Flags In The Hiring Process

You Are The Problem

We all experience some drama and confrontations in life. Typically, when these are the rare occurrence, they are out of our control. However, if they seem to be happening all the time or in almost every relationship, friendship, or job then the problem is not likely to be external. A corollary to the Dealing with Difficult People episode, when the difficulty follows you around no matter where you go then you need to look at yourself for the source of the problem. It is difficult to admit that you are the problem. A lot of introspection is required just to recognize that it is not external. Then humility to accept that you are the problem. Finally courage is necessary to tackle the challenge of overcoming yourself and improving. When you recognize that you are the problem and are able to accept it then you are able to make the changes necessary to fix it. Don’t think of this so much as you being broken and needing fixing but more as you have developed a pattern of maladaptive behaviors that need to be adjusted and changed. The focus here is on self-care and improving your life by improving your relationships and the way you treat others. Next time you find yourself in a heated debate or in the middle of some drama step back and look at your own actions that lead to where you are. Ask yourself what you can do to change. Look back on these tools to help you find where and how to make those changes. Episode Breakdown Knowing the Problem is You Unhealthy patterns of behavior can indicate that you are the problem in a situation. At various times in our lives we are likely to experience or express some of these. One or two every now and then isn’t an issue. It’s when they form a pervasive pattern that you know you might be the problem. Unhealthy View Of Self You do not take responsibility for your own problems and faults. You are never to blame or never at fault for anything. There’s always a way to find someone else to take responsibility. You alienate other by never taking responsibility for yourself. This drives a wedge in friendships and relationships. Friends and coworkers are afraid to be honest with you. People in your life are not able to say anything without you losing control. They do not feel they can be honest with you without getting yelled at about it. Likely they will hide things from you because they don’t want to deal with your rage. You see problems as external to yourself. You are not part of the problem or issue in a relationship or friendship. No one is completely guiltless when it comes to relationship problems. You however don’t see yourself as part of the problem but the victim of circumstances. You sabotage yourself and your relationships. This occurs mostly from overthinking or overdramatizing conversations, especially confrontations. Self-sabotage causes problems in otherwise healthy relationships. You create self-fulfilling prophesies where you place a negative motive on a normal behavior. Then when the other person is defensive about their normal behavior you “know” it is for other reasons. You self-loath or are not happy with yourself. You despise yourself or aspects of yourself but can’t admit that you feel this way. A lot of times this leads to being intolerant of similar flaws in others. It is normal to have aspects of yourself you want to improve or change. Self-loathing is taking it to the extreme and feeling emotionally sick when you think about it. Unhealthy Relationships You have a lot acquaintances but few or no real or close friends. People like to hang out with you but not get into deeper conversations.

72 MINAPR 16
Comments
You Are The Problem

Inversion of Control in Legacy Applications

When you get dropped into a legacy project, one of the main things you’ll miss is the use of more modern development practices, such as testing, inversion of control, proper object models, and configuration management. However, you probably can’t simply stop active development for six months to re-architect your entire application. This is especially risky if you don’t have a proven track record of reworking applications in this fashion. The code is never the most important aspect of a business, no matter how important it is to the developers. While working on old crappy systems is generally stressful and doesn’t help your career much, it’s really hard to get the business people to care. However, you can usually get away with making incremental system improvements. If you plan these improvements well, refactoring can make your work easier, giving you time for further improvements. Adding dependency injection and inversion of control is one of the first things you’ll probably do as you refactor a legacy application to make it more maintainable. Cleaning up code in older applications is a lot of work, and you simply cannot do it all in a short period of time. There is a bit of art and science to the process of cleaning up legacy systems to make them more maintainable. You have to be smart about the way you handle this work, both because of the risk of breaking things and because of the way office politics tend to work. However, if you do it well, you can drastically improve the functioning of nearly any old crusty app that you run across. Episode Breakdown Why you would want to do this. Improved ability to quickly change the app. When components are pluggable, it’s easier to switch implementations across the application as needed. You can even control this configuration dynamically from settings, which simplifies your code. This can also be a critical component of your strategy if you plan to support a plugin architecture. Improved object lifecycle management. Your app may not be properly managing things like network sockets, database connections, etc. A lot of this stuff is encapsulated in objects that you use and getting rid of those objects gets rid of the underlying resource. Sloppy development practices tend to mean that these objects hang around longer than they should, especially in garbage collected languages. This is also a good way to manage lifetimes of objects using policies to make sure that they are kept around for the length of a logical unit of work. Easier testing. Because you can switch the implementation being used, it’s easier to use mocks and stubs. This tends to simplify testing code, because instead of fully implementing the object you are trying to mock, you only really need to mock the methods that you are actually using. It’s also nice to be able to mock some of the slower objects with faster code that returns more quickly. This makes tests run faster. Necessary precursor for modern application development. Most modern object-oriented development frameworks make fairly heavy use of dependency injection and inversion of control. Additionally most modern frameworks can be configured to use IOC in a relatively transparent fashion when communicating with your application components. Prerequisites to this process. Data access layer While you certainly can proceed without having a data access layer, having one makes this process easier because you can abstract those calls away. Database calls, network calls, interactions with the file system, and interactions with other APIs often add a lot of complexity that you really don’t want to deal with just yet.

68 MINAPR 9
Comments
Inversion of Control in Legacy Applications

Batch Processing

Even though most developers prefer to build applications that respond to user input directly, in most applications there are usually at least a few processes that happen out of band or even overnight. These processes require a different way of thinking about your code, and about the processes that support that code. You might use offline batch processing for a variety of purposes within your application. Whether it is used for things like sending emails in bulk, importing large amounts of data from external systems (or pushing data to external systems), or for managing outages and latency in external services. Handling interactions with unstable, slow, or limited third-party systems is often best handled with a batch process. In addition, many industries have a tendency to prefer batch processing to processing-as-needed. Banking is one example of an older industry that tends to process things in this manner, and many other older and heavily regulated industries. Batch processing is common in older industries and is often used to shift system workloads into time periods where utilization is lower. At some point in your career, you’ll probably be tasked with writing a batch process to handle off-hours data processing. We hope that the set of suggestions and questions offered here will make it easier for you to successfully build batch processes when that day comes. Episode Breakdown Start up How often and where does this thing run? The physical execution environment is important, especially if the process has to have completed successfully in a short time frame. It’s very common for really crappy companies to try to run batch processes off of developer workstations, or even older computers stuffed in a closet somewhere. This tends to slowly get worse over time and fail suddenly. All it takes is for the cleaning staff to unplug a machine, or for a power surge to hit the building and you’ll have a mess on your hands. You also need to think about the digital environment you are running in. Are all your servers available at the time of execution? Are they running intense batch processes themselves? What about the databases you are using? Is maintenance being performed on them during this time window? What about time zone issues? Could your application’s scheduled run time be missed during a shift to day light savings time? Could a forced system update occur during your startup window? What resources are available during the run? How much memory, disk, and network I/O are available? Just because there is a lot of any of these things available when you are writing the process doesn’t mean that they will be available when it starts up. This could impact how long your process takes to start up or whether it can even start at all. Sometimes systems are turned off or otherwise unavailable after hours. A lot of times, work systems will be turned off entirely after hours, especially if you are using a cloud environment. Third party systems may be under similar constraints. Services you are depending on on the system itself may also be off during this time period. How do we handle failure to start up? Just because you schedule a process to run at a certain time, doesn’t mean it actually happens. Sometimes the task scheduler chokes and crashes. Permissions can also change, which could stop your program from running. Your application might start loading and then fail before actually starting processing. This could result from anything to not having all of its dependencies available, to simply not being able to contact the system that it uses to determine what work needs to be done.

67 MINAPR 2
Comments
Batch Processing

Wizard’s Rules

The Sword of Truth is a series of high fantasy adventure novels by Terry Goodkind. It follows the lives of wizards, sorceresses, and other magic and non magic people as they battle for their very existence against several enemies. After the series Goodkind wrote several other books taking place in the same fantasy world. One smaller series of books follows the main characters after the events of the main books. In the series and beyond it Goodkind lists out several Wizard’s Rules. These are guidelines and rules to live by for the characters, specifically the wizards, in the series. While they claim to be secretive the characters in the series seem to dispense them freely giving about one per book in the Sword of Truth series. The first eleven rules are numbered and associated with a book in the main Sword of Truth series. The final three are found in the books written after the series and are not given a specific number associated with the rule. These rules are based on a series of fantasy novels, so take them for what they are; one way to go about living and an interesting April 1st episode topic to get you thinking differently. Read through them, write them down, and try applying them to your life. Take a scientific approach and see if applying these rules makes a difference in your life. Episode Breakdown People are stupid. We are all people. “People are stupid. They can be made to believe any lie because either they want to believe it’s true or because they are afraid it’s true.” ~ Wizard’s First Rule People will believe something because they want it to be true. Desire for a lie to be true gives it validation. We can start to believe a lie because we want to believe it is true. Just because you want something to be a certain way, doesn’t mean that it will be that way. People will believe something because they are afraid of it or afraid it is true. Fear of a lie gives validation to that lie. Being afraid that something might be true means that you admit the possibility of it being true. You have to objectively look at the facts and not be ruled by fear. This describes tactics used in sales all the time. The Jones Effect plays on the fear of missing out (FOMO) or not having what your neighbor’s have. Look at advertising to see this play to peoples desires. This can be used for manipulation or freedom. In the books this rule is shown to be used as a way to manipulate people. It is also used as a self assessment tool to keep the characters from falling prey to a lie. The intention is to free yourself of biases based on desire or fear. The greatest harm can result from the best intentions. Sometimes doing what seems right at the time actually causes more harm than good. The full effects of an action may be unknown or unclear to you. There will likely not be any obvious signs that what you are doing could cause harm. You may not see the harm at first because you are still reaping the benefits or not looking at it. The harm may be something much further down the line. You may not even be around for when the actual harm hits. To avoid causing harm you must know the effects and long term outcomes of your actions. This involves a bit of wisdom that may only be earned by making mistakes. It also means not falling victim to the first rule. The key is to have forethought about what you are doing to do the right thing and avoid harm. This rule comes into play a lot when making changes to existing or legacy code. Your changes may solve the problem that you are having. However, it may break other areas or have long term consequences.

68 MINAPR 1
Comments
Wizard’s Rules

Latest Episodes

Static Code Analysis

Static code analysis is a way of debugging that automatically examines source code before it compiles or is run. It does this by comparing the code code to a set of rules or standards. It is a way of automating code reviews and can be used in conjuncture with peer reviews. Yuri Minaev is working in the PVS-Studio company as one of developers of the C++ static analyzer. His primary responsibility is to keep low-level stuff in order and add new features to the core module. It’s been almost 2 years since he joined the team after about 12 years of IT experience. Apart from that, he periodically gives talks at various conferences – mainly on topics related to static analysis and C++. PVS-Studio is cross platform, working on Windows, Linux and MacOS 64-bit environments. It can analyze code designed for 32-bit and 64-bit systems as well as embedded ARM platforms. It generates reports that help developers to find and fix bugs before they become a problem. Keeping a codebase clean and detecting problems before they occur will make your life better as a developer. When you can avoid getting nailed by simple problems, you can think about your software at a higher level, vastly improving your effectiveness as a software developer. It’s not just about avoiding bugs, although that’s important, but about what you can do with the time, money, and attention you save. Book Club Remote Work: The Complete Guide. Will Gant Chapter 10 – The Ultimate List of Remote Work Resources. This last chapter of the book lists out a ton of resources for remote work. This includes tools for automation, books, blogs, podcasts, career resources, and other things that will help you on your remote work journey. While you can do it all the hard way, you’ll get a lot further a lot faster if you learn from other people and use what they know. This section will help you do that. Tricks of the Trade It can be hard to let things go. Especially when it’s a project you’ve been the primary developer on for a while. You don’t want to let other people in to mess with the patterns and paradigms you’ve set up. However, in order to move forward we have to move on from our old code. There are developers who spend years building a large intricate system, but don’t allow anyone else to touch it. This means they spend the next few decades maintaining it. If you don’t want to spend your career updating and maintaining something you wrote early on, then you have to allow others to make changes in your code. Links * PVS Studio * Yuri Minaev Remote Work Book * Why Work Remote * Will’s Profile on Simple Programmer Editor’s Notes: Yuri lives in Russia so the audio from the call is not the best.

68 MIN5 d ago
Comments
Static Code Analysis

Long Term Remote Work

Working remotely is a wonderful job perk and can make many developers more productive, happy, and less likely to leave for greener pastures. However, it’s no panacea, especially over the long term. The effectiveness of remote work over the short term is a result of your work ethic and your ability to think on your feet. Over the longer term, however, remote work is only successful if you have good habits for managing your remote work environment. In addition to easily forseeable problems, such as communication and productivity issues, there are a lot of hazards to remote work that you might not have considered until you’ve done it for a while. Lots of things are stable over the short term that are completely unsustainable over the long term. For instance, you might need to work an 80 hour week for a week or two to hit a critical deadline that takes your career or your company to the next level, completely destroying your work-life balance, sleep, and personal interactions over the short term to get a much better long term result. However, you can’t do that for very long. In fact, we would generally argue that you can’t (or shouldn’t) do it all, but some people do manage it reasonably well on occasion. If you do it for very long, you not only quickly hit a point of diminishing returns, but you often do damage that can’t be easily undone. The costs of not managing things for the long term are stark. Poor remote work habits can lead to job loss, degradation of skills, damage to your most important personal relationships, financial and health woes, and even chronic pain. We are in a unique period in history where it is not only technologically feasible to work from home, but where we are expected to do so while heavily collaborating with other people. However, if you really want to take advantage of this unique opportunity you need to plan ahead. Working remotely over time has some challenges. While these can be overcome as they occur, you are usually far better off if you address them BEFORE you have to. Not only is this approach more sustainable, it’s also a lot less stressful than trying to fix things after problems have already occurred. Episode Breakdown Ergonomics. The layout of your work area can hurt you a lot. Choosing good equipment and positioning of devices is a must. Simply sitting still for a long period of time is pretty bad for your health in general. Be extremely careful about how everything your office is positioned, and pay close attention to any aches, pains, or stiffness that starts developing. You need to be proactive. Socialization Social interactions happen incidentally when you go into the office. They have to happen intentionally when you work from home. While you aren’t going to get as bad as Tom Hanks’ character on Cast Away, isolation will “weird” you over time. A lot of people rely on work to provide them with socialization. The fix for this is to regularly meet with other people for lunch, or have a social life outside of work. You also need to set aside at least some time every week to have non-work conversations with your coworkers. Don’t let your rapport rot. Health (diet, exercise, mental health) It’s easier to ignore your health, physical appearance, and mental state when working from home where you can adjust a camera and not have people notice that you are putting on weight. There also tends to be a lot of snack food at most people’s houses and it can often be easier to eat that than it is to prepare real food (or to pick something up). If you had a routine of stopping by the gym on the way home, you’ll need to develop a routine oriented around either working out at home, or going to the gym at a certain point. You need to be working out,

76 MIN1 w ago
Comments
Long Term Remote Work

Types Of Programming: Coding Styles

As programmers, we tend to be a rather interesting bunch. Some might even call us peculiar. Developers tend to have our own culture and even subcultures within the development community. Attending a polyglot or regional conference will show many of the various subcultures within development getting together to grow, learn, and enjoy the company of like minded individuals. Within the community of developers are several archetypes that you will see. Rarely will you find someone who is completely a particular one but you’ll notice these traits, some stronger than others, in most of the developers you meet. The other two episodes are look at the developers personality and their knowledge base. While researching the different archetypes of developers we broke them down into three groupings: Coding Styles, Knowledge Expression, and General Personality. This is the first of three episodes talking about the types of programmers you’ll meet in your career. It focuses on the various coding styles you’ll encounter. This is not an exhaustive list of coding style archetypes. Instead it’s a group of the ones you are most likely to encounter within your career. While there are others out there you can use this list to better understand your coworkers, managers, and friends in the development community. To be truly introspective think about the times you have exhibited the traits of these and try to figure out which one you resemble most. Use that information to set yourself up for success at your current place of employment and when you are looking for work. Episode Breakdown The Cowboy/girl Coder Cowboy coders are a force or nature who can code two to three times faster than anyone else. They typically have a degree in computer science and believe that clean code and best practices do not apply to them. Refactoring is a luxury for city slickers, the cowboy’s code is spaghetti at best and smells like several nights on the trail eating only beans. Cowboy coders are best on projects where deadlines are more important than anything else. The Perfectionist The polar opposite to the cowboy coder, the perfectionist aim to write the best code ever. While the cowboy treats code like cattle, the perfectionist treats code like their pet or even worse like their own child. They can get confrontational and argumentative when asked to speed up the process or when told to build a less than optimal solution for the sake of time or money. When resources are limited, the perfectionist works best when told the limitations up front and asked to find “the best” solution given the current limitations. The Caretaker The caretakers has been with the company for years, maybe even decades so they know the codebase inside and out, especially the older, more arcane areas. Likely an older generation of developer, they are more comfortable with out dated technology and languages so spend most of their time maintaining legacy applications. The caretaker may have gotten stuck in a rut or be bound by golden handcuffs preventing them from trying new technologies. Tread carefully if putting a caretaker on a newer project as they may be riding out to retirement on their knowledge of the codebase. The Specialist The specialist is a developer who rather than becoming a ‘T’ shaped developer has become a lower case ‘l’ shape, diving too deep into one area at the cost of being well rounded. The data scientist is one particular type of specialist who only codes in python, tends to be very good with math, and enjoys statistics and image manipulation. The security expert is another common specialist you’ll encounter who knows everything about security, typically hacks into systems for fun, and has a different set of ethics than most.

62 MIN2 w ago
Comments
Types Of Programming: Coding Styles

Breaking The Relational Model

The rule: Normalize until it hurts; denormalize until it works. That’s what you typically get taught early on. While normalizing a database is a solid practice and something you should do when designing a system; it can jump up and bite you when you get under load. You probably won’t deal with most of these issues early on in a system (and shouldn’t), but the time will come where eventually some degree of denormalization is necessary to keep performance up to snuff. On average if you start suggesting denormalizing a system, you will have to be able to show that it improves performance significantly. There are good reasons that systems aren’t denormalized and people will typically balk at doing so. However, there are places where under some circumstances it’s worth considering. After all, CPU cycles on a database server are often some of the most expensive ones out there – go check your SQL Server or Oracle licensing fees for proof. Rules are made to be followed in general, but sometimes you have to bend them just to get by. This is especially in computer science, where many “rules” or more like “guidelines for most cases” at best. Episode Breakdown When additional join tables will hurt performance. Joins are not cheap or free. Complex joins are especially bad (for instance, a function call in a join). This is especially true when you are joining across a lot of tables and aggregating a lot of results on a regular basis for data that doesn’t frequently change. When you need to keep historical database records. Consider a system that manages invoices and products. You don’t want to mess up historical data on invoices from last year when a product price changed today. Typically historical tables are also going to be used mostly for reads, so you want to cut down the number of joins just to make that faster. Tables with historical data can often be more heavily indexed than you might see in transactional tables that are used in online transaction processing that has to be fast. When data needs to be structured for reporting purposes. Reporting systems generally have a lot of data duplication simply so that more interesting trends can be spotted with the data at hand. You’ll also have very different indexing requirements for reporting tables. The way the tables are accessed is also very different for reporting. They tend to be read heavy and are going to need different levels of locking depending on what you’re doing. When the data itself is hierarchical in structure. Hierarchical data is difficult to represent efficiently in a relational model. This is especially true when you need to rearrange a tree, or determine if something is an ancestor of something else, especially if the structure has an arbitrary depth. It’s also very difficult to write logic for tree structures stored in a relational model such that you don’t accidentally create cycles in the data. When the data is a graph structure. It’s even more fun when it’s a graph, because cycles are actually possible. While storing nodes and edges is easy enough, doing things like finding the shortest path will be difficult. You’ll also have a difficult time proving that any two nodes are connected without a serious risk of major performance problems. When you have very large records. Relational database have issues with large records, whether you query them or not. They aren’t really designed for holding things like images and huge chunks of text. This is especially true if you want to index and search through this content, as a lot of the search capabilities of a relational database are not really built for this purpose. If you are storing large records,

64 MIN3 w ago
Comments
Breaking The Relational Model

Impostor Syndrome When Getting Promoted

Impostor syndrome is a feeling of inadequacy. It is the sense that you are not qualified or talented enough to do your job. In many cases it’s a feeling that you can’t live up to the expectations of a job because you are a fraud. It was first identified by Pauline Rose Clance and Suzanne Imes in a paper in 1978. At first they thought it only affected women but further research indicates it affects people no matter their gender. While affecting everyone slightly differently, Valerie Young has identified a few patterns that people tend to fall into with impostor syndrome. The perfectionist sets very high standards for themselves and if they don’t meet them feels like a failure. The expert feels like they should know every little thing before being competent. A person who is naturally gifted will feel inadequate if they struggle to learn or do something. The soloist feel that they have to do everything on their own, they are a fraud for asking for help. Finally the superhuman will push themselves harder than their coworkers to prove they are not an impostor. Typically impostor syndrome rears itself when a person is put into novel situations or given more difficult tasks than normal. For most of us some of the most stressful times in our careers comes with celebration. We get promoted then have to take on new duties and responsibilities. This can lead to stress, anxiety, and impostor syndrome. Impostor syndrome is something that we all face at one time or another in our careers. Many of us face it several times as we move up the ladder. This is not a comprehensive list of fears or concerns. They are the ones that we have heard about from others or have faced during our careers. If you have other concerns or questions about moving up in your career leave us a comment or send us an email about it. Episode Breakdown Common Impostor Syndrome Concerns When Getting Promoted * What if I don’t find a good role model or mentor? * I’m not good enough, what I do isn’t perfect. * I like being “in the weeds” on a project, but moving up means I’ll have to take a more general focus. * I’m not good a taking on new responsibilities. Impostor Syndrome Concerns with Starting As A Junior * I do not know enough about coding or the business to be useful. * I don’t really know where I want to focus my career or how I want to brand myself as a developer. * I’m afraid I’ll mess up the existing codebase because I’ve only ever worked on my own code. * Coding is fun, but what if I don’t like doing it as a career? Impostor Syndrome Concerns with Moving to Mid-Level * I’m not going to get as much mentoring or support. * What if I am overwhelmed by the amount of work. * How will I keep up with changes in technology? * Am I trying to make changes or move up too quickly? Impostor Syndrome Concerns with Moving to Senior * What if I’m not ready to be a mentor? * I’m not longer the learner, I don’t know enough to be an expert. * I’m afraid to ask questions or appear unknowledgeable. Impostor Syndrome Concerns with Moving to Management * I’m an expert, not a manager. * How do I manage others while still actually working? * Now I’m managing friends and former peers. * I don’t know how to give direct feedback. Book Club Remote Work – The Complete Guide Will Gant

66 MINAPR 30
Comments
Impostor Syndrome When Getting Promoted

Red Flags In The Hiring Process

When you are looking for a new job, it’s easy to take the first job that comes along. And it might even turn out ok. However, it’s also possible that you’ll end up in a job that is absolutely miserable, burning you out and making you hate software development. Worse still, when you finally get to the point where you are exhausted enough with your job that you end up quitting (or worse, getting fired), the damage has been done. A bad enough job can completely ruin software development for you, to the point where you dread working on code at all. This has happened several times to Will over the course of his career and it’s really hard to recover from. A new job can make huge changes in your career, for good or ill. You want to make sure that any new job you take is going to help you improve your career, without burning you out. While not every bad job gives obvious warning signs before you start, most of the worst ones will at least give you some warning of what to expect. Episode Breakdown Job Posting Verbiage that indicates that the company over-estimates themselves, and you’ve never heard of them. “We only hire the top 5% of developers”. Is your payscale in the top 5%, are you deliberately ripping off the top 5% of devs and hoping they won’t catch you, or are you full of crap? This tends to mean that they have a byzantine, awful interview process of which they are very proud, that probably is designed to help them hire yes men who feel lucky to be there. We are looking for a very specific type of developer and have a thorough set of interviews to find them. Sometimes this is true. Sometimes they need a developer with a very specific set of skills. However, most of the time, what they are looking for is a “yes man” or someone who is compliant. If you can’t tell why your specific set of skills are exactly what they need, then one of you will be disappointed. Lack of clarity about what you’ll be doing. Some companies hire before they have a clue what they are doing. This can often mean that you have to pivot repeatedly during your tenure at an organization. If you don’t know what you want out of your career, this can be a wonderful opportunity to try new things. If you do know what you want, this can be an unbelievable waste of time. If they are being especially vague, it can indicate something even worse. For instance, they may be doing something that is borderline illegal, immoral, or just sketchy in general. Companies running low-budget pornographic operations, or quasi-legal investment schemes may approach you in this way. You would be surprised how many people are involved in extremely sketchy ventures who will approach you if you know the right people. Asking for too much experience for what they are willing to pay. If they are paying a junior developer salary, but expecting five years of experience, there is a reason for it. This could be anything from not having a clue about the market value of a developer, to simply making the job posting so that they are free to outsource. Sometimes companies will post an oddly specific set of criteria for a developer position not because they are looking for someone, but because they’ve found someone they want to hire and are otherwise constrained. This is a common trick some sketchy companies used to hire H1Bs at a lower price, whom they usually later mistreat. Initial Contact Can’t pin them down on a time for initial contact, or the time changes repeatedly. Some companies have really messed up, slow, or confusing hiring processes.

77 MINAPR 23
Comments
Red Flags In The Hiring Process

You Are The Problem

We all experience some drama and confrontations in life. Typically, when these are the rare occurrence, they are out of our control. However, if they seem to be happening all the time or in almost every relationship, friendship, or job then the problem is not likely to be external. A corollary to the Dealing with Difficult People episode, when the difficulty follows you around no matter where you go then you need to look at yourself for the source of the problem. It is difficult to admit that you are the problem. A lot of introspection is required just to recognize that it is not external. Then humility to accept that you are the problem. Finally courage is necessary to tackle the challenge of overcoming yourself and improving. When you recognize that you are the problem and are able to accept it then you are able to make the changes necessary to fix it. Don’t think of this so much as you being broken and needing fixing but more as you have developed a pattern of maladaptive behaviors that need to be adjusted and changed. The focus here is on self-care and improving your life by improving your relationships and the way you treat others. Next time you find yourself in a heated debate or in the middle of some drama step back and look at your own actions that lead to where you are. Ask yourself what you can do to change. Look back on these tools to help you find where and how to make those changes. Episode Breakdown Knowing the Problem is You Unhealthy patterns of behavior can indicate that you are the problem in a situation. At various times in our lives we are likely to experience or express some of these. One or two every now and then isn’t an issue. It’s when they form a pervasive pattern that you know you might be the problem. Unhealthy View Of Self You do not take responsibility for your own problems and faults. You are never to blame or never at fault for anything. There’s always a way to find someone else to take responsibility. You alienate other by never taking responsibility for yourself. This drives a wedge in friendships and relationships. Friends and coworkers are afraid to be honest with you. People in your life are not able to say anything without you losing control. They do not feel they can be honest with you without getting yelled at about it. Likely they will hide things from you because they don’t want to deal with your rage. You see problems as external to yourself. You are not part of the problem or issue in a relationship or friendship. No one is completely guiltless when it comes to relationship problems. You however don’t see yourself as part of the problem but the victim of circumstances. You sabotage yourself and your relationships. This occurs mostly from overthinking or overdramatizing conversations, especially confrontations. Self-sabotage causes problems in otherwise healthy relationships. You create self-fulfilling prophesies where you place a negative motive on a normal behavior. Then when the other person is defensive about their normal behavior you “know” it is for other reasons. You self-loath or are not happy with yourself. You despise yourself or aspects of yourself but can’t admit that you feel this way. A lot of times this leads to being intolerant of similar flaws in others. It is normal to have aspects of yourself you want to improve or change. Self-loathing is taking it to the extreme and feeling emotionally sick when you think about it. Unhealthy Relationships You have a lot acquaintances but few or no real or close friends. People like to hang out with you but not get into deeper conversations.

72 MINAPR 16
Comments
You Are The Problem

Inversion of Control in Legacy Applications

When you get dropped into a legacy project, one of the main things you’ll miss is the use of more modern development practices, such as testing, inversion of control, proper object models, and configuration management. However, you probably can’t simply stop active development for six months to re-architect your entire application. This is especially risky if you don’t have a proven track record of reworking applications in this fashion. The code is never the most important aspect of a business, no matter how important it is to the developers. While working on old crappy systems is generally stressful and doesn’t help your career much, it’s really hard to get the business people to care. However, you can usually get away with making incremental system improvements. If you plan these improvements well, refactoring can make your work easier, giving you time for further improvements. Adding dependency injection and inversion of control is one of the first things you’ll probably do as you refactor a legacy application to make it more maintainable. Cleaning up code in older applications is a lot of work, and you simply cannot do it all in a short period of time. There is a bit of art and science to the process of cleaning up legacy systems to make them more maintainable. You have to be smart about the way you handle this work, both because of the risk of breaking things and because of the way office politics tend to work. However, if you do it well, you can drastically improve the functioning of nearly any old crusty app that you run across. Episode Breakdown Why you would want to do this. Improved ability to quickly change the app. When components are pluggable, it’s easier to switch implementations across the application as needed. You can even control this configuration dynamically from settings, which simplifies your code. This can also be a critical component of your strategy if you plan to support a plugin architecture. Improved object lifecycle management. Your app may not be properly managing things like network sockets, database connections, etc. A lot of this stuff is encapsulated in objects that you use and getting rid of those objects gets rid of the underlying resource. Sloppy development practices tend to mean that these objects hang around longer than they should, especially in garbage collected languages. This is also a good way to manage lifetimes of objects using policies to make sure that they are kept around for the length of a logical unit of work. Easier testing. Because you can switch the implementation being used, it’s easier to use mocks and stubs. This tends to simplify testing code, because instead of fully implementing the object you are trying to mock, you only really need to mock the methods that you are actually using. It’s also nice to be able to mock some of the slower objects with faster code that returns more quickly. This makes tests run faster. Necessary precursor for modern application development. Most modern object-oriented development frameworks make fairly heavy use of dependency injection and inversion of control. Additionally most modern frameworks can be configured to use IOC in a relatively transparent fashion when communicating with your application components. Prerequisites to this process. Data access layer While you certainly can proceed without having a data access layer, having one makes this process easier because you can abstract those calls away. Database calls, network calls, interactions with the file system, and interactions with other APIs often add a lot of complexity that you really don’t want to deal with just yet.

68 MINAPR 9
Comments
Inversion of Control in Legacy Applications

Batch Processing

Even though most developers prefer to build applications that respond to user input directly, in most applications there are usually at least a few processes that happen out of band or even overnight. These processes require a different way of thinking about your code, and about the processes that support that code. You might use offline batch processing for a variety of purposes within your application. Whether it is used for things like sending emails in bulk, importing large amounts of data from external systems (or pushing data to external systems), or for managing outages and latency in external services. Handling interactions with unstable, slow, or limited third-party systems is often best handled with a batch process. In addition, many industries have a tendency to prefer batch processing to processing-as-needed. Banking is one example of an older industry that tends to process things in this manner, and many other older and heavily regulated industries. Batch processing is common in older industries and is often used to shift system workloads into time periods where utilization is lower. At some point in your career, you’ll probably be tasked with writing a batch process to handle off-hours data processing. We hope that the set of suggestions and questions offered here will make it easier for you to successfully build batch processes when that day comes. Episode Breakdown Start up How often and where does this thing run? The physical execution environment is important, especially if the process has to have completed successfully in a short time frame. It’s very common for really crappy companies to try to run batch processes off of developer workstations, or even older computers stuffed in a closet somewhere. This tends to slowly get worse over time and fail suddenly. All it takes is for the cleaning staff to unplug a machine, or for a power surge to hit the building and you’ll have a mess on your hands. You also need to think about the digital environment you are running in. Are all your servers available at the time of execution? Are they running intense batch processes themselves? What about the databases you are using? Is maintenance being performed on them during this time window? What about time zone issues? Could your application’s scheduled run time be missed during a shift to day light savings time? Could a forced system update occur during your startup window? What resources are available during the run? How much memory, disk, and network I/O are available? Just because there is a lot of any of these things available when you are writing the process doesn’t mean that they will be available when it starts up. This could impact how long your process takes to start up or whether it can even start at all. Sometimes systems are turned off or otherwise unavailable after hours. A lot of times, work systems will be turned off entirely after hours, especially if you are using a cloud environment. Third party systems may be under similar constraints. Services you are depending on on the system itself may also be off during this time period. How do we handle failure to start up? Just because you schedule a process to run at a certain time, doesn’t mean it actually happens. Sometimes the task scheduler chokes and crashes. Permissions can also change, which could stop your program from running. Your application might start loading and then fail before actually starting processing. This could result from anything to not having all of its dependencies available, to simply not being able to contact the system that it uses to determine what work needs to be done.

67 MINAPR 2
Comments
Batch Processing

Wizard’s Rules

The Sword of Truth is a series of high fantasy adventure novels by Terry Goodkind. It follows the lives of wizards, sorceresses, and other magic and non magic people as they battle for their very existence against several enemies. After the series Goodkind wrote several other books taking place in the same fantasy world. One smaller series of books follows the main characters after the events of the main books. In the series and beyond it Goodkind lists out several Wizard’s Rules. These are guidelines and rules to live by for the characters, specifically the wizards, in the series. While they claim to be secretive the characters in the series seem to dispense them freely giving about one per book in the Sword of Truth series. The first eleven rules are numbered and associated with a book in the main Sword of Truth series. The final three are found in the books written after the series and are not given a specific number associated with the rule. These rules are based on a series of fantasy novels, so take them for what they are; one way to go about living and an interesting April 1st episode topic to get you thinking differently. Read through them, write them down, and try applying them to your life. Take a scientific approach and see if applying these rules makes a difference in your life. Episode Breakdown People are stupid. We are all people. “People are stupid. They can be made to believe any lie because either they want to believe it’s true or because they are afraid it’s true.” ~ Wizard’s First Rule People will believe something because they want it to be true. Desire for a lie to be true gives it validation. We can start to believe a lie because we want to believe it is true. Just because you want something to be a certain way, doesn’t mean that it will be that way. People will believe something because they are afraid of it or afraid it is true. Fear of a lie gives validation to that lie. Being afraid that something might be true means that you admit the possibility of it being true. You have to objectively look at the facts and not be ruled by fear. This describes tactics used in sales all the time. The Jones Effect plays on the fear of missing out (FOMO) or not having what your neighbor’s have. Look at advertising to see this play to peoples desires. This can be used for manipulation or freedom. In the books this rule is shown to be used as a way to manipulate people. It is also used as a self assessment tool to keep the characters from falling prey to a lie. The intention is to free yourself of biases based on desire or fear. The greatest harm can result from the best intentions. Sometimes doing what seems right at the time actually causes more harm than good. The full effects of an action may be unknown or unclear to you. There will likely not be any obvious signs that what you are doing could cause harm. You may not see the harm at first because you are still reaping the benefits or not looking at it. The harm may be something much further down the line. You may not even be around for when the actual harm hits. To avoid causing harm you must know the effects and long term outcomes of your actions. This involves a bit of wisdom that may only be earned by making mistakes. It also means not falling victim to the first rule. The key is to have forethought about what you are doing to do the right thing and avoid harm. This rule comes into play a lot when making changes to existing or legacy code. Your changes may solve the problem that you are having. However, it may break other areas or have long term consequences.

68 MINAPR 1
Comments
Wizard’s Rules
hmly
Welcome to Himalaya Premium