Podcasting has definitely been a journey for both of us. When we started BJ wasn't even a developer and Will was working for himself. Now 8 years later BJ is leading a team of developers and Will is back working for himself. It has been an amazing journey with you all this past years. We have both learned a lot about ourselves, programming, leadership, and audio engineering (well Beej learned about audio).

However, like all things, it can't last forever. Sometimes you just hit a point where you realize that you can go on, but your heart really isn't in it any more. That's kind of where we both are. We've enjoyed our time podcasting and it's been a very memorable eight years. The podcast has changed us both a lot, and that's the real reason we are stepping away from it. We've both gained many new skills, and more comfort with more difficult tasks. And now we both have goals of our own that don't really mesh well with the podcast.

The post A Farewell To Our Fans appeared first on Complete Developer Podcast.

Hosted on Acast. See acast.com/privacy for more information.

Simple systems fail simply. Complex systems also fail simply, but their interconnectedness with other systems makes mitigating failures much more complex. Past a certain level of complexity, system failures are an emergent property of the system – that is, the set of system parts has a set of failure cases that the individual parts do not have by themselves. This means that it is more difficult to predict what can go wrong with a system. At some level, prediction is nearly impossible. However, you can predict many of the things that are likely to cause problems, simply by engaging in a few fairly simple thought exercises, you can greatly reduce the number of unexpected problems that your system encounters.

While it can be tempting to wait until a problem occurs to try to mitigate it, this is unwise in a production system that other people are dependent on. A system failure usually costs money at a minimum, and the problems can be far more severe than that. As a result, it's common for software services to include a Service Level Agreement or SLA, that dictates expectations about the frequency of system outages, response times, and time expected to complete work. Even if your system is engineered so that it doesn't completely fall over when a problem occurs, it can still violate an SLA and cost money. The consumers of your application probably have their own clients who have their own expectations. SLAs tend to bleed inward from clients to the services that they use and then to the services that those services use.

In contrast to SLAs, systemic problems, including both errors and latency tend to bleed outward from one service to its clients and then to the clients of that service. As a result, when you are thinking about how to find potential systemic problems, it's often best to think of these problems from two different angles. That is, you need to consider how errors and latency will bleed out as a result of a problem, while also considering how SLAs bleed in to put more stringent expectations on your system than you might expect. In effect, you are dealing with a balance between tolerance for errors and difficulty in error mitigation. Depending on how critical your system is to your clients, these expectations will vary.

You can't prevent every problem in a system, but you can usually prevent a large percentage of them by planning ahead. However, until you've encountered enough unexpected problems, it can be difficult to envision how something can go wrong, or even have a realistic thought process for thinking about what can go wrong. However, if you go through the thought exercises we've outlined here, then you have a good chance of preventing most of the problems that will plague a complicated application. While this doesn't fix everything, it can give you enough breathing room to fix the truly unusual problems that you'll occasionally encounter.

The post Preempting System Issues appeared first on Complete Developer Podcast.

Hosted on Acast. See acast.com/privacy for more information.

Feedback is any information, observation, or even opinion about the performance or behavior of another individual our group. It can be formal as in performance or peer evaluations or informal such as with mentoring a junior developer. It is a form of communication designed to provide guidance that helps the other person to grow and achieve their goals.

Providing feedback gives insights and identifies areas of improvement. Often it is used to guide those you are leading toward personal and professional growth. To the person receiving the feedback it can be stressful, especially if it is not all positive. It can also be very stressful to the person who is providing the feedback, especially if they are not a confrontational or naturally assertive person. Having a plan of action when providing feedback not only helps the person receive it better but also helps the person providing the feedback.

As feedback is a way to help achieve goals the technique for creating effective goals (SMART) can also be applied to providing feedback. To review, SMART stands for Specific, Measurable, Attainable, Relevant, and Time-bound. Applying SMART to feedback will better define what you are getting across and make it more actionable.

SMART (Specific, Measurable, Achievable, Relevant, and Time-bound) is a framework most often used in goal setting. However when applied to providing feedback it will enhance the abilities of the person providing the feedback and allow the recipient to better understand what they need to do to achieve their goals. Using this framework ensures that the items coming from the feedback are actionable, well defined, and focused on the issue or goal at hand. Whether you are doing performance plans for those working for you, peer or code reviews, or just mentoring someone who is not as far along as you apply the SMART framework to your feedback and see the improvement in reception and accomplishment.

The post SMART Feedback appeared first on Complete Developer Podcast.

Hosted on Acast. See acast.com/privacy for more information.

Database sharding is a process of storing a large database across multiple machines. Because a single machine can only hold and process so much data, eventually some systems will scale beyond the ability of a single machine to handle data. Further, as systems scale, they may also need to split data between machines due to security and location considerations. Database sharding overcomes these problems by splitting the system into smaller chunks, allowing work to either be done in parallel, or only in the locations with the relevant data.

Obviously, it matters a lot how you split up your data. For instance, it's unlikely that splitting a customer table based on the customer last name will be as helpful in a large distributed system as it would be to split up customers by location. You probably also want to have shards that are roughly the same size. The idea behind sharding is to improve performance, specifically via parallelization, but it's also helpful if it also provides some resilience to outages. So that will also need to be a consideration when you start thinking about sharding.

Database sharding can be a very useful tool for making your application more resilient to load. However, it's complex and you really need to think through it carefully if you are considering using it in your environment. There are several different ways to do it, with different advantages and disadvantages, and these will need to be thoroughly considered before starting. Plus, sharding is actually a fairly drastic operation, requiring support and extra work for the remaining lifetime of your application. This means that you shouldn't really consider it until most other options have been exhausted.

The post Database Sharding appeared first on Complete Developer Podcast.

Hosted on Acast. See acast.com/privacy for more information.

Effective communication is a vital aspect of any organization or team's success, and one tool that has been proven to be very useful is the Four Square Report. This report is a simple and effective way to communicate information about a project or task to a team or stakeholders. It was originally developed by the U.S. military to help soldiers communicate critical information in a clear and concise manner, and has since been adopted by many organizations and industries.

4 square reports were refined by the construction industry and have since been adapted to fit the needs of software development teams. The reports are based on the idea of breaking down progress and issues into four categories: achievements, roadblocks, plans, and risks. By providing updates on these four areas, the entire team can quickly understand what has been accomplished, what challenges are being faced, what the plans are moving forward, and what potential risks may arise.

The effectiveness of 4 square reports lies in their simplicity and clarity. They are quick to create and easy to read, making them ideal for agile development teams that need to keep pace with fast-moving projects. Additionally, by regularly updating the reports, everyone on the team can stay up-to-date on progress and potential issues, allowing for early identification and resolution of problems.

The 4 Square Report is a versatile tool that can be used in a variety of situations to help with decision-making and project planning. By considering four key aspects of a project or decision and filling out a simple, visual report, you can gain valuable insights and make informed choices. Remember to identify the most important aspects, be thorough and objective, use the report for collaboration, and revisit it regularly. By using the 4 Square Report effectively, you can increase the chances of success for your projects and decisions, and learn valuable lessons for the future.

The post Four Square Reports appeared first on Complete Developer Podcast.

Hosted on Acast. See acast.com/privacy for more information.

If you haven't noticed, technology moves fast. There are constant improvements and reworking of every programming language out there. Sometimes the changes are small and easily dealt with, while sometimes the changes are huge. Complicating things further, most developers need to learn a wide variety of tools and frameworks in order to be effective in their current job. At a minimum, most of us need some kind of front end framework, a database (and its associated libraries), an IDE, a source control system, and some sort of devops. For most of us, it's worse than that. And it gets even more fun as your team tries out new technology or you switch jobs, as that often means learning two or three new tools in a short period of time.

Lots of developers (ourselves included at some point) attempt to learn on the fly by having training videos playing in the background while they are working on something else. While you can learn a little this way, this usually doesn't work very well. Lots of developers will also buy courses from Pluralsight, Uedemy or other vendors, or even find courses free online from sources like FreeCodeCamp, and still spend an inordinate amount of time trying to learn. Pretty much every developer has tons of courses available to them that they either completed while learning little, or didn't complete at all. Even more of us have stories of online tutorials that were out of date, covered the wrong things, or had errors in them that frustrated us and made us quit. And everyone has examples of tutorials that showed the rosy side of a new framework, and then abandoned potential learners in a mire of real-world troubleshooting they were unprepared for.

However, there is a better way to ensure that you get the most out of online tutorials. Not only is it possible to quickly learn from online tutorials while retaining information, but it's also possible to do so in a way that is fairly time efficient, gives you good experience with the tools you are trying to learn and teaches you to work through common errors. Further, the process of learning is not isolated to the process of watching a tutorial, but also helps you choose more appropriate tutorials, while making sure that you learn what you came to learn. And this process also helps you get real world experience actually applying what you learned afterward and helping you find the next thing to learn.

With the wide variety of libraries, platforms, and databases available on the market now and with the rapid evolution of tools, it's absolutely necessary to learn on the fly as the need arises. However, most people haven't really thought about how they learn and often have internalized some maladaptive learning strategies. This is especially true in software development if you attended structured, formal classes. It can be difficult to learn in an unstructured manner, especially if you aren't used to doing it. It can also waste a lot of time. However, there are a lot of tricks that can make such learning more effective and efficient in terms of the time you spend. We hope the tips in this episode will make your next “learning adventure” more effective and time efficient.

The post Getting the Most From Programming Tutorials appeared first on Complete Developer Podcast.

Hosted on Acast. See acast.com/privacy for more information.

Understanding ACID and BASE databases is critical for any organization or individual who is involved in developing, managing, or using modern database systems. Both types of databases have distinct characteristics and trade-offs, and choosing the wrong one can have serious consequences on the performance, reliability, and security of your application.

ACID databases are designed for applications that require strict data consistency and accuracy, such as banking, e-commerce, and financial systems. These databases provide strong guarantees that all transactions are processed in a reliable and predictable manner, ensuring that the data is always in a valid state. However, these databases can be slower and less scalable in distributed systems, and require more resources to maintain consistency.

On the other hand, BASE databases are designed for applications that prioritize availability and partition tolerance, such as social media platforms, content distribution systems, and other distributed systems. These databases provide high availability even in the face of network partitioning or system failures, and can be more scalable and flexible than ACID databases. However, these databases may provide temporarily inconsistent data and can be more complex to manage.

Understanding the differences between ACID and BASE databases can help you make informed decisions about which database to use for your application. By considering the specific requirements of your application, such as performance, scalability, consistency, and durability, you can choose the database that best fits your needs and ensures that your data is accurate, reliable, and secure.

The post ACID vs BASE Databases appeared first on Complete Developer Podcast.

Hosted on Acast. See acast.com/privacy for more information.

APIs are a huge part of development today and one of the most common types of API out there is a RESTful API. REST stands for representational state transfer, which is a software architecture that imposes conditions on how an API should work. Essentially, it was created as a set of guidelines for how communications should work between disparate systems on a complex communication network (like the internet). REST is implemented atop HTTP and uses the standards in the underlying protocol as part of the standards for communication. In a RESTful API, client and server applications are considered to be independent, that is, details from one should not leak into the other, to the extent possible. This also implies that API calls for the same resource should look the same regardless of where they come from – indeed this is required to decouple the client and the server.

RESTFul APIs are built around the inherent statelessness of HTTP. That is, a persistent connection between the client and server is not assumed. This has profound architectural implications in regards to how resources are accessed and mutated. In order to make this disconnected architecture perform well across the internet, this also means that caching will be used heavily. Caching implies further architectural constraints around resource access, as well as careful coding server side to ensure that items are cached (and removed from cache) appropriately. This helps both client side speed and server side scalability. In addition, the lack of a session makes it far easier to spread a workload across multiple servers, as there is no need to synchronize state between them or keep sessions sticky.

Restful APIs are pretty much bog standard web technology at this point. Not only do complex frontends use them, but clients, QA, and other parts of your own system will often do so as well. While Rest APIs are generally standard at this point, there are a lot of mistakes you can make when designing them that make it harder to use your API, create excess load on the server, or just generally increase the frustration level of all involved parties. Certain antipatterns also look good initially, but end up causing problems later when your system gets more users, or more HTTP savvy integrators working with it. We hope this brief overview is enough to save you some time up front on your next API project.

The post API Anti-Patterns appeared first on Complete Developer Podcast.

Hosted on Acast. See acast.com/privacy for more information.

There is a common demonstration, that we'll do as a thought experiment, when talking about priorities. It has a person fill a bucket with sand, then try to add as many pebbles to the bucket as possible, following that they are to add larger gravel, then fist sized rocks. The obvious thing that happens is the bucket fills with sand and they are not able to add much else to it. Then they are instructed to add them in the reverse order so that larger rocks first, then gravel, then small pebbles, then the sand. Doing it this way more large items are able to be added to the bucket then the smaller ones fill in the space left by the larger items.

This is used to demonstrate the necessity to prioritize the important items and fit them in first then go in order down to the least important. The larger rocks represent higher priority item whereas the smallest grains of sand represent the least important items. If you fill your time with low priority items you won't have space for the higher priority ones, but if you start with the larger ones then you'll be able to fit smaller and smaller ones into the gaps.

Where it gets tricky is in determining where an items falls in priority. Typically the very high and the very low priority items are obvious. A medical emergency is a very high priority item, responding to a friend request from someone you haven't met is a very low priority item. The rest of the items may not be as obvious and be more difficult to prioritize.

Prioritization can help you to maximize your efforts onto the items and tasks that will give you the most reward. However, a problem with the bucket example (demonstration) is that once you fill in all the gaps with the smallest grains of sand there is no room to breathe in the bucket. It becomes difficult to make adjustments when everything is packed so tight into the bucket. The same is true of your schedule, when you pack too much into it you don't have capacity to make adjustments. This can work for a while, especially when you are at crunch time but shouldn't be the norm as it is not maintainable. Use the information discussed here to guide you when you are planning out your priorities and don't forget to leave some room to breathe in your schedule.

The post Prioritization appeared first on Complete Developer Podcast.

Hosted on Acast. See acast.com/privacy for more information.

Mob programming is a technique for getting multiple developers in the room, working on the same code. While possibly not the best technique for many situations, it really shines in certain narrow use cases. When it does work, it can often produce impressive results that a few separate developers couldn't produce on their own. The collaborative aspects of mob programming are similar to pair programming in some respects, with very similar upsides and downsides.

In a mob programming session, a stakeholder and the team will first identify the goal of the session, which should be a testable outcome. Then everyone works together to come up with a general strategy and procedure for getting the work done, including what tools will be used to accomplish the work. This is a critical first step if you want to avoid stopping and rewriting code frequently while everyone else is watching.

Then, when the session begins everyone goes into a room and works together. One person will be typing for a while, while the rest of the team looks at the screen (or hopefully a projector) while the first person works. They will offer feedback as the first person does some work. The person writing the code will change frequently so that they don't burn out. The rest of the team is there to support the first person as well as to offer feedback about various aspects of the code. In effect, this allows for the session to have the blessing of the entire team, and to incorporate the knowledge of the entire team. More tasks will probably be assigned to various team members as a result of the session as well.

Mob programming is a seldom-used, but often powerful approach to getting software written. While it's not always the best choice, it can be very useful for improving team collaboration or for exploring areas where there are gaps in the team's knowledge.

The post Mob Programming appeared first on Complete Developer Podcast.

Hosted on Acast. See acast.com/privacy for more information.