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.
Audit Trail Anti-Patterns
While the typical user of your application probably won’t be interested in your audit trails, that doesn’t mean that you can get by without them. Whether it is due to regulatory compliance issues, security policies, or simply because you need to troubleshoot something in production, you’ll have to deal with setting up and managing application audit trails at some point. Audit trails suffer from many of the same problems that logging does; while a simple implementation can be set up easily by a junior developer, you’ll often find that these implementations do not work well over time, at scale, or for making quick diagnostic decisions under pressure in production.
When you start talking to people about audit trails, you’ll also find that there are some persistent misunderstandings that are common. When we discuss audit trails, we really need to spend some time at the beginning breaking down what we are auditing, how we are auditing it, and what we are looking for (and how we expect to find it). Most of the time, when a business leader starts talking about audit trails, they have no idea about what they really want. “Audit trails” have been a corporate buzzword for years.
“An audit trail (also called audit log) is a security-relevant chronological record, set of records, and/or destination and source of records that provide documentary evidence of the sequence of activities that have affected at any time a specific operation, procedure, event, or device. Audit records typically result from activities such as financial transactions, scientific research and health care data transactions, or communications by individual people, systems, accounts, or other entities.” ~ Wikipedia
Basically, the idea here is to have a way of listing out the sequence of events (and other relevant information, such as who caused the event) that resulted in a system state. This information needs to be comprehensive, comprehensable, and secured in a way that prevents tampering. It’s essentially evidence and is often a critical feature of applications that touch healthcare information, online transactions, personal information, or financial data. Audit trails are also part of an organization’s security and compliance requirements. They are often required both by governmental regulation (such as HIPAA) and by industry standards (such as PCI). There are usually data retention requirements here as well. Audit trails are also useful for catching security issues, for providing evidence in courtroom proceedings involving computer systems, and can be very helpful when debugging complex and rare system issues.
Audit trails help you track when things happen in a large application or system of applications. You’re able to follow the path that a user or tester took when they found the issue. The concept is not only useful for computing but can also be applied in your own life. Tracking is often the first step in making changes, for example if you want to lose weight you could start by tracking the foods you eat, when you eat them, and your mood or state when eating. That will give you a baseline to start making changes. You can apply this same concept to any area of your life where you want to make a change. Need to save up for a new car or PS5? Start tracking your finances to see where and why you are spending your money. Need to stop smoking, or chewing, start tracking when you smoke, what’s going on around the event, and what your mood is before and after. The idea is that you can apply this concept to your own life to help identify ways to make positive changes.
Anti-pattern #1: Audit trails controlled at the application level by only tracking property changes.
This is an antipattern because your data is likely in a database that is controlled from outside the application, or could be.
Learning To Say No
Far too often when faced with a personal request that we don’t want to do or don’t have capacity, we will acquiesce, or (according to the dictionary) “accept something reluctantly but without protest.” We don’t want to disappoint others or we want to maintain a relationship so we say yes when we really want to say no.
For some people the image of being a helpful, can-do, person is more important than their own health. They will give up sleep, family time, or other hobbies to maintain that image of the helpful person. Unfortunately saying yes too often corrodes relationships and damages our ability to actually be helpful. It leads to resentment toward the person asking of us and prevents us from being able to do the things that we want or need to do for our own self-care.
Learning to say no, when appropriate, can be difficult for someone who has spent their life trying to please people or who sees themselves as the can-do helper who is always willing to put in the extra work. For them saying no is not only foreign, but it is worse than cursing. However, by learning to say no they will begin setting boundaries that will allow them to have healthier relationships. They will also gain a better sense of themselves and what it takes for them to recharge and be most productive and helpful.
Learning to say no is a valuable life skill that translates to the business world and development. It is important to being able to take care of yourself and establishing boundaries with those around you. While you are learning to say no, remember to respect when others say no to you. It can be frustrating, but remember to put yourself in their place and think about how you want to be treated when you say no to someone. They may be following the example you set by saying no and how you respond will greatly influence their future efforts to say no. A little bit of respect for others boundaries goes a very long way toward better relationships at work or in your personal life.
Importance of Saying No
You are NOT a terrible, horrible, evil person for saying “no”.
Many people have the misinformed belief that they are being rude or selfish if they say no to someone. They believe saying “no” is impolite and people will not like them if they don’t acquiesce to others. A lot of times this stems from childhood, because it was considered rude or impolite to say no to parents, teachers, etc. This can grow into a belief that you cannot say no, even when you want to do so. In childhood you were expected to acquiesce to higher authority because they were looking out for your best interests. As an adult, you are capable of making your own choices and saying no to things that you do not want or have capacity to do is one of those choices. In order to grow as a person you’ll need to disassociate the act of saying “no” with being disagreeable or selfish.
When you say “no” you are showing respect to yourself and the other person.
By saying “no” when you don’t want to do something you are showing the other person that you respect yourself and them enough to be honest. Acquiescence, even on minor issues, eventually leads to resentment. Over time this will destroy relationships whether they are romantic, friendships, or work related. Saying “no”, when appropriate, is also the first step in defining healthy relationship boundaries. You will start a process that will lead to healthier relationships in your life. This respect and appropriate boundaries will not only affect you, but it will set an example for others in your life to model and build healthier relationships.
If you’re unable to care for yourself, then you won’t be able to care for others.
In order to be able to provide the best for others in your ...
You’ll often hear about developers (including both of us) who regularly use pair programming. The practice of pair programming can be very helpful for sharing knowledge across the team, working through a difficult chunk of code, or simply showing how your team approaches their daily workflow (especially when working with a new hire). Pair programming also helps team members get to know each other (and each other’s thought processes), which is very important in our current COVID age where people are working remotely.
It can be hard to convince management and other developers to allow pair programming. Your typical corporate bean counter will see the practice as simply doubling the cost of the same piece of work. Project managers will often view the practice as something that jeopardizes project timelines for dubious benefit. Other developers might balk at the idea as well, both because they are self-conscious about the way they write code and because many find it boring. Furthermore, to nearly everyone involved, it sounds like yet another meeting that will chew up part of a day (most meetings stink and most people don’t like them).
Pair programming is a useful way to improve code quality, cross train team members, and on-board new developers quickly without boring training. In addition to making it easier to solve more difficult problems, it also helps with team cohesion and helps people understand how other team members think. Best of all, if done properly, it may not negatively impact your team’s throughput – it could even improve it.
Basics Of Pair Programming
What is it and why do it?
Pair programming requires two programmers (if more, it’s called a mob) to use a single computer. One developer will work, while discussing what they are doing with the other. The second developer might also have a computer or other device and use it to take notes, look up things for the first developer, review specifications, etc.
Basically, the idea is that with two developers working on a piece of code, you avoid creating knowledge silos, improve the quality of the code you are writing, and increase team cohesion by having people actually work together. Team cohesion from pair programming is often an undervalued result, but is especially important when dealing with remote and distributed teams.
Even in organizations where pair programming is not common, it does often happen during onboarding a new team member. The larger practice of pair programming can be viewed as a long term extension of this onboarding practice.
When to pair program?
You are probably not going to want to pair program all the time, since it can be exhausting. Instead you should be more strategic about when you do it. Ideally, you will only pair program when it actually provides value. Pair programming works well when you are trying to show another developer something they haven’t seen before.
It also works well when you need two people’s expertise to actually complete a task. This happens a lot when porting an old system to a new framework, or when trying to migrate data between systems. It’s also good for onboarding new developers and getting them used to your company’s processes. Pair programming is very effective when you need another developer’s help to get unstuck.
When not to pair program
It’s very difficult to pair program when the two developers involved don’t get along, have a major language barrier, or don’t use similar technologies to do their job (unless one of them is trying to learn the technology used by the other). When you don’t have a clean way to share a screen and to give control to the other party (some security setups make this difficult, especially when you are remote).
Quickly Learning New Technology
No matter how hard you work, you will not be able to keep up with the rate of change in technology. Or at the very least, you won’t be able to keep up with most of it. The best you can do is to keep up with the stuff that you actually need to do your job. However, even then, your job is probably also changing quickly, so it can be tricky to determine what you need to learn before you need it. Instead, you are going to find yourself constantly adapting to changing circumstances and having to make quick decisions about what to learn.
Constant, life-long learning is absolutely required for a career in technology. At no point in the near future will you be able to get by in tech without learning how to adapt to constant change. Instead, you are going to have to embrace change and learn to deal with it. Best of all, if you do this well, it will eventually become a competitive advantage for you. Best of all, if you are smart about it, it won’t be nearly as difficult to keep up with technological changes as you might think.
Accept that you can’t keep things from changing.
One common response to sudden change is to try to avoid or bargain with the change. While you can do this for a while (or even for a very long time in the case of some platforms), it eventually catches up with you.
The longer you wait to deal with change, the more it costs you. Consider how many businesses resisted getting a domain name and a website when these first became available. While they could have brought the perfect domain for less than $50 back in the day, it might cost thousands of dollars today, if it is even available at all.
While you probably don’t want to immediately learn the newest technology as soon as it arrives, you will want to learn relevant technology soon enough that it gives you an advantage. This also means that you need to make sure that you are aware of change that is about to happen. You can’t take advantage of change if you don’t catch it early enough.
Look for the opportunities in change
While change is disruptive, sometimes that disruption can work to your advantage. Major technology changes mean lots of new jobs, jobs where you can be ahead of the pack with far less effort than might be required for older technology.
New technology can also give you the opportunity to change your career to work in a different area. Say a new single page application framework starts becoming popular – if you can quickly build expertise in that, you can get ahead of other candidates in getting a development in an industry you...
Enneagram Type 4: The Individualist
The Enneagram of Personality, or just the Enneagram, is a representation of personalities using a geometric figure, also called an enneagram (little e), to express nine interconnected personality types. While each type is unique it is related to other types through the circle connecting the type to each of it’s wings and the lines or arrows in the center connecting the type to the ones it imitates in times of stress or growth. The Enneagram is used in business management training to better understand interpersonal dynamics in the workplace.
Types Two, Three, and Four constitute the Heart Triad. This triad is primarily motivated by their feelings. Those in the Heart Triad are do not believe they are worthy of love so they take on personas to attain it. Because of this, they are more image-conscious than the other triads. Within the triad, Fours are the most introspective. They focus internally on their own feelings but have difficulty understanding others feelings.
At their best, Fours are inspired, immensely creative expressing themselves and the world they see. Their creativity enables them to turn their experiences into value for others. They have superior emotional range and are able to avoid acting on every feeling they have. They know that they don’t have to be something special to win approval from others.
At their worst, Fours become self-destructive, hopeless, and filled with hatred for themselves. Constantly comparing themselves to others, they find themselves lacking. Morbid thoughts permeate their minds as their dreams fail and they fall into self-contempt. Full of shame they put a wedge between themselves and anyone trying to help them. Depression drives them to alienate themselves from others.
Fours try on identities like someone trying on suits in preparation for a big job interview. Because they find something lacking in themselves they are constantly trying different identities to fill that void. If you are a Four remember that you are more than your feelings. You are able to regulate and stabilize them. Friends, coworkers, and partners of Fours can help them by being around them but not getting drawn into their emotional highs and lows. When able to find this balance Individualists will be able to create and maintain deep meaningful relationships in all areas of life. Finally, for a Four to truly grow they need to stop putting off work or artistic/creative projects until they are “in the mood”. Set yourself an arbitrary deadline or just go create, the creative process will help you find balance and pull the intensity of emotions into something beautiful.
The Enneagram Type Four is “The Individualist” or “The Romantic”.
Fours are called “The Individualist” because they see themselves as fundamentally different from everyone else, even other Fours. They are also called “The Romantic” because of their wistfulness and longing to be authentic. The Individualist’s drive to be unique stems from a sense that something is missing from them. They don’t know what it is or where it’s gone but that lack makes them feel “different.” The only way they see to compensate for what is missing in their lives is to create something that distinguishes them from others.
For the Romantic, being authentic is everything. For them the only way to fill the void in their lives is by being truly unique which leads to an almost obsession with authenticity. Because they feel they are so different, Fours think that no-one can love or even understand them. They see themselves as both uniquely talented with special gifts and uniquely damaged or flawed in some way. They often have trouble with a lack of self-esteem and maintain a negative image of themselves.
“Melancholy is the happiness of being sad” ~ V...
“If carpenters built houses the way programmers write code, the first woodpecker to come along would destroy civilization”. – Gerald Weinberg
We all have to deal with errors in our code, or at least, we’re supposed to. However, you’ve probably experienced a situation where a small problem caused another small problem, which caused a big problem, which ended up taking an entire system down. If you’ve experienced this, you are probably also painfully aware that these failure can be very expensive and hard to recover from. Second order effects are usually not that hard to predict, if you are thinking about them. You’ll also find that neither you nor anyone else does a particularly good job thinking about second, third, and fourth order effects of decisions.
Massive failures, in particular, are easily predicted. For instance, the Japanese attack on Pearl Harbor was easily predictable, based on rising tensions between the governments of Japan and the US, the layout of islands in the Pacific, and advancing aviation technology. In fact, the attacks were predicted in 1910 by Billy MItchell, who analyzed the situation. However, in spite of these predictions, the US fleet still was caught unprepared. Not only did this cause a catastrophic loss of lives and equipment, but it also led to a larger war, a war that might not have happened (or might not have occurred in the same way) had things been prepared differently. At the end of the day, people in positions of power didn’t believe that such a chain of events could happen, nor were they adequately able to shift resources to deal with a rising threat. Such a threat couldn’t be moderated by academic theorizing, but would require being in a position to get regular feedback and iterate quickly (this is a little harder to do with battleships, however).
Antifragile design is more complex that simply handling errors and keeping them from causing problems. Rather, it is an approach to embracing and using the natural chaos of the world to improve your response to small problems, so that a chain of them doesn’t result in a massive failure. As explained by Nassim Taleb, “antifragility is a property of systems in which they increase in capabillity to thrive as a result of stressors, shocks, volatilitty, noise, mistakes, faults, attacks, or failures”. It is fundamentally different from the concept of resilency (the ability to recover from failure). Such systems exist in nature, in biological systems as diverse as muscles and immune systems.
There are general principles of system (and life) design that need to be applied if you don’t want to constantly be dealing with problems. The principles of antifragility are especially useful to observe when you start noticing catastrophic failures that manifest as a chain of smaller failures that increase in intensity until something breaks in a major way. Following these principles, you should be able to figure out and mitigate many of them.
The continuum of fragility
Fragile – Breaks when pressure is applied.
Robust – Handles pressure, but does not become stronger under pressure.
Antifragile – Uses pressure to drive improvements that make the system stronger over time.
Why antifragile in systems?
People expect systems to stay up, but as systems become more complex, the number of things that can fall apart increases exponentially. As a system scales in complexity, the cost of downtime increases as well as the difficulty of bringing things back online, unless you specifically design the system to improve recovery options.
A partially functional system that still allows most operational goals to proceed has less “cost” in terms of time, money, and management/customer irritation than a system...
Never gets boaring
I have been listening to all the podcasts from 6 months now. Each episode is interesting and lots of things to learn be it Defensive Coding or Getting Better Sleep. Thank you so much BJ and Will for sharing your thoughts and industry experiences.
I have been listening to the Complete Developers podcast for a little more than an year now. I must say that Will and BJ are doing a great job and they complement each other well. The topics chosen cover all aspects of the life of a developer very well. I have learnt a lot from it and would continue to do so. Keep rocking :)
Must listen podcast for all developers
I must say that this is must listen podcast for all developers as the topics being discussed starts from basic and then goes towards advanced level. The discussions are awesome for example in multi tenant apps or when not have microservices. Keep up the great work guys.