Complete Developer Podcast

In this episode, we discuss our journey through podcasting, where it all started, where it lead us, and why we are stepping away from it.Read more

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.LinksJoin Us On PatreonLevel Up Financial Planning 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.LinksJoin Us On PatreonLevel Up Financial Planning 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.LinksJoin Us On PatreonLevel Up Financial Planning 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.LinksJoin Us On PatreonLevel Up Financial Planning 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.LinksJoin Us On PatreonLevel Up Financial Planning 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.LinksJoin Us On PatreonLevel Up Financial Planning 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.LinksJoin Us On PatreonLevel Up Financial Planning 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.LinksJoin Us On PatreonLevel Up Financial Planning 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.LinksJoin Us On PatreonLevel Up Financial Planning The post Mob Programming appeared first on Complete Developer Podcast. Hosted on Acast. See acast.com/privacy for more information.

File transfer protocols can begin to look like alphabet soup when you first start learning about them, or even after you've been a developer for a while.Read more ›The post File Transfer Protocols appeared first on Complete Developer Podcast. Hosted on Acast. See acast.com/privacy for more information.

You've probably heard of DDOS (or Distributed Denial of Service attacks). They are a common scourge of the modern web and are something you will occasionally see if you work on a popular product.Read more ›The post DDOS Attacks appeared first on Complete Developer Podcast. Hosted on Acast. See acast.com/privacy for more information.

Git is a powerful tool that is essential to the software development process. It was created by Linus Torvalds in 2005 as a way to manage the development of the Linux kernel. Today, it is widely used by developers all over the world to manage their own projects and collaborate with others. Git has become the industry standard for version control. With Git, developers can easily keep track of changes, experiment with new ideas, and collaborate with others on the same project. If you’re new to Git, the terminology and commands can seem overwhelming. However, Git is well worth the time and effort to learn. You only need to learn a few to get started. With Git, you can keep track of all the changes you make to your code, experiment with new features without worrying about breaking anything, and collaborate with others on the same codebase. Git is also great for organizing your code and keeping it up-to-date. With Git, you can create branches for different features or experiments, and merge them back into the main codebase when you’re ready. Learning Git is an investment in your future as a developer. It will not only make your life easier but also make you a better collaborator. By using Git, you’ll be able to work with others on projects more effectively, and you’ll be able to contribute to open-source projects more easily. Git is a powerful tool that allows developers to collaborate effectively and keep track of changes to their codebase. By understanding the basics of Git, you can become a more efficient and productive developer. Remember to use descriptive commit messages, keep commits small and focused, and use branches and pull requests to collaborate effectively with other developers. And if you’re ever stuck, don’t hesitate to use Git’s built-in commands like git status, git log, and git diff to help you understand the state of your codebase. Links Join Us On Patreon Level Up Financial Planning The post Basics of Git appeared first on Complete Developer Podcast.

Most of us have a reasonable working definition of what “agile” means in a software development context. We all know what it is SUPPOSED to mean, what it means when implemented correctly, and we even probably have some expectations when another developer uses the term. But when talking to a non-technical person, especially someone in an upper management role, we often have a hard time articulating it. And the results of this can be disastrous. There are plenty of magazines, websites, and podcasts that delve into what agile can do for an organization from the executive perspective. And because these are often written by people who stand to make a great deal of money if someone hires them, they can often veer into showing agile as a “silver bullet” for all the organization’s problems. Furthermore, developers can exacerbate this by assuming that management understands the word the same way that they do. One of the greatest weaknesses that developers have is a bias towards assuming that other people have the same knowledge as we do. This, by the way, is a very common and normal human failing, and it’s something you’ll see in any group with specialized knowledge. Developers who find themselves in non-agile (or fake agile) environments are often quick to complain and suggest doing things in a more agile manner. While this is fine if you explain exactly what you mean, it is absolutely NOT FINE if you don’t. It’s best to be aware that there are a lot of misconceptions going around about what agile is and what it is not. You really, really want to avoid having management try to implement “agile” in the way that they understood it from an article they read in a business magazine (ask us how we know). Explaining agile to non-technical people, especially executives, is difficult. It’s also something that you are likely to have to do, especially as some segments of the business press do so in an incorrect fashion. If a non-technical person has heard of agile, they probably have misconceptions about it that aren’t going to help. Well-implemented agile will make most organizations more responsive to change and will allow for quicker delivery of working software, but the way that that happens is a bit counter-intuitive. If you aren’t used to it, it’s easy to get the wrong impression of what should be happening at th earlier stages of the process. Worse still, if a non-technical person is in a decision-making position for the agile team, they may force agile to be something that it is not. It’s important that we explain these things correctly, otherwise agile-gone-bad has the potential to be as bad or worse than any other methodology. Links Join Us On Patreon Level Up Financial Planning The post Explaining Agile To Non Technical CoWorkers appeared first on Complete Developer Podcast.

Almost all development work today is done on teams, both due to the complexity of our work and the sheer volume of it. As time has gone on, development work has also become more intensely collaborative, and “throwing work over the wall” has been acknowledged as being a terrible idea. As a result, the personalities of one’s coworkers has become more and more important. Unfortunately (or fortunately, depending on your perspective), developers exhibit a lot of personality quirks that are common in the larger population, but we often have our own unique “spin” on them. It’s important to realize that most personality quirks, no matter how irritating, are there because they serve a purpose. Sometimes a personality trait was useful in dealing with a dysfunctional environment in a previous workplace, and sometimes the personality trait is currently useful in your current environment. Personality is often closely tied to emotional reactions to a situation, and as a result, you often find that you have to address those emotions in order to work well with a person with certain personality traits. While extreme versions of personality traits are often a serious problem, more mild versions of certain personalities can still create some difficulties in a work environment, both at the individual and team level. The trouble is, a lot of these personality characteristics are supremely useful in some circumstances as well, so you probably don’t want to cause someone to change their personality. Rather, you want to figure out a way to work with them so you get the upsides while avoiding the downsides. In some cases, their personality will change over time, but that’s something that is their choice, not yours. You just have to figure out how to deal with it in the meantime. There are a lot of personality types in development that can create problems in team dynamics, but it’s important to realize that these personality types are there for a reason and that they serve as an adaptation to a specific environment. When encountering (or embodying) these personality characteristics, it’s important not only to see how they annoy you and cause problems, but to also see where that viewpoint is useful. It’s also very useful to figure out how to engage with that viewpoint, both to help with team dynamics and to help the individual growth of team members. Links Join Us On Patreon Level Up Financial Planning The post 404 Personality Not Found appeared first on Complete Developer Podcast.

ChatGPT is a powerful language model developed by OpenAI that has been trained on a massive amount of text data. It is capable of answering a wide range of questions and generating text in response to prompts. ChatGPT has been used in a variety of applications, including chatbots, language translation, and text completion. For software developers, ChatGPT can be a valuable tool for improving code quality and efficiency. By using ChatGPT, developers can ask natural language questions about their code, get suggestions for improving it, and even generate code snippets. This can save developers time and help them catch errors and improve the readability and maintainability of their code. ChatGPT is a powerful language model that has the potential to transform software development by making it easier for developers to understand, write, and maintain code. With its ability to generate natural language descriptions and code snippets, provide intelligent code completion suggestions, and identify potential code smells, ChatGPT is a valuable tool for developers looking to improve their code and streamline their development process. As NLP and machine learning continue to evolve, we can expect to see more innovations like ChatGPT in the software development space. This episode was completely written by ChatGPT. Links Join Us On Patreon Level Up Financial Planning The post ChatGPT for Developers appeared first on Complete Developer Podcast.

Breaking down your goals into more manageable tasks creates the flexibility to adjust as needed and brings clarity to the goals. When seen from the perspective of a step by step process goals are seen not as daunting behemoths to be gazed on in wonder but as complex things that can be accomplished through diligence and careful planning. This makes the process of achieving a larger goal more achievable. In order to break down a goal it must be SMART: specific, measurable, achievable, relevant, and time-bound goals that provide a clear and concise road-map for achieving your desired outcome. Specific goals are clear and unambiguous, while measurable goals have clearly defined criteria for success. Achievable goals are challenging but realistic, while relevant goals are aligned with your personal or professional aspirations. Finally, time-bound goals have a clear deadline, providing a sense of urgency and helping to track progress. By setting SMART goals, you can break down complex tasks into smaller, achievable steps and stay focused on your ultimate objective. Accomplishing smaller steps along the way can provide a sense of accomplishment and keep you motivated to continue working towards the goal. Breaking down your goals increases your accountability as well because it provides a simpler road-map for you to follow in order to reach your larger goal. This simpler road-map helps you stay on track when going after larger, seemingly impossible goals. Throughout this year we are showing you how we break down our goals, use the information in this episode and the examples throughout the year to make even your most lofty goals doable. Links Join Us On Patreon Level Up Financial Planning The post Breaking Down Goals appeared first on Complete Developer Podcast.

Depending on your use cases, your application may need to work well on Apple, iPhone, Windows, Apple, Linux, and even various types of tablets. And that’s just if you are looking at the US market – international markets have loads of other options. This is part of the reason web applications are so popular – it’s a way of making cross-platform concerns into someone else’s problem. And frankly, that’s a pretty rational approach, as dealing with the quirks of dozens of desktop, mobile, various tablets and the like is often more than an application development team can handle. However, a web application, even with all the fairly-recent advances in things like PWAs, may not be sufficient for your clients’ needs. In particular, if you are dealing with disconnected data, memory or processor intensive applications, or just applications that use the file system, you may need to run your application outside of a browser sandbox. And if you do need to support multiple platforms, building a cross-platform app is often the correct choice, both from a business and a development standpoint. But, like most things in life, there are tradeoffs that you need to consider. By definition, any cross-platform framework that you use is going to mean yet another layer of abstraction between you and the system on which you want to run. And all abstractions, every last one of them, tend to leak. All abstractions are simplifications of a more complex problem. While that simplification may be beneficial, you’ll need to take special care to make sure they are not OVER-SIMPLIFICATIONS. If they are, then you are going to have to work around them. This is, essentially, the core problem in cross-platform development. Cross-platform applications offer a lot of advantages both to developers and to the companies that employ them. That said, there are a number of pitfalls that you figure out after you’ve worked on a few of them. The added complexity of these applications can often be difficult to see up front – usually by the time you find something that is difficult or impossible to handle, you’re already well into sunk cost territory. However, many of the problems you’ll encounter with any cross platform application framework (whether mobile or otherwise) are actually fairly predictable. If you know what the likely issues are going in, you can more effectively evaluate the risks they pose before you’ve invested in learning and using a cross-platform tool. Links Join Us On Patreon Level Up Financial Planning The post Cross Platform Pitfalls appeared first on Complete Developer Podcast.

“The habits we choose to live by can shape our lives and define who we are.” – Stephen Covey As software developers, our habits can greatly impact our success and the quality of our work. The 7 Habits of Highly Effective People is a book written by Stephen Covey that outlines key habits that successful people have in common. Last year we discussed these from a negative sense, talking about 7 habits of unsuccessful people. These 7 habits are ones that were not developed but discovered when looking at the most successful people and what they have in common. The most successful people will exhibit each of these habits in one way or another in their lives and/or careers. Each of these habits can be applied to your life and career. From being proactive and beginning with the end in mind, to putting first things first and thinking win-win, these habits can help you become more effective, improve your relationships, and achieve your goals faster. By seeking first to understand and synergizing with others, you can foster creativity and build stronger relationships. And by sharpening the saw and taking care of your physical, mental, emotional, and spiritual well-being, you can maintain a healthy work-life balance and continuously improve your skills and abilities. Use this information to adopt these habits and become the most effective version of you. Links Join Us On Patreon Level Up Financial Planning The post 7 Habits of Highly Effective Developers appeared first on Complete Developer Podcast.

Architecture projects are some of the most fun projects in development. Or at least they often appear that way. There is often the perception that in these projects you can fix all the little things that annoy you in your work environment. You can make it easier to roll out new features, while keeping the system more stable and easier to maintain. While this can be true, there is some risk here. In particular, many architecture projects seem to have no purpose other than massaging the egos of the developers on the project. While you might get away with this for a little while, it will eventually cause problems for you. It’s also very easy for developers to get caught up in “building castles in the sky”. Left unattended, developers tend to build more and more complex things over time – it’s one of the things most of us enjoy. While often useful within a proper context, it’s far easier to get lost in the weeds on architecture projects. It’s also a mistake to think of architecture projects as projects that don’t have customers. An architecture project almost certainly has some indirect impact on clients, otherwise why do it? Your clients also include the rest of your team. Other developers will have to deal with the implications of your changes. QA will likely have to change test procedures. Operations may need to deal with new and different errors while deploying brand new resources to various environments. Your database administrators may deal with changes to system load. Your security team will likely have new things to audit and potential new vulnerabilities to worry about. Even groups like customer support, sales, and the like may be impacted, depending on what you are doing. Architecture projects can be fun and can provide huge improvements to software systems, provided that they are conducted correctly. However, many developers (ourselves included at various points) get too focused on the architecture considerations we are dealing with, while ignoring the impact on the rest of the system. This can cause a perfectly good architectural solution to fail in a drastic manner. It can also alienate the rest of the team, irritate management, and actively harm customers in a way that WILL cause problems for your team, if not the entire organization. Fortunately, most of the big mistakes you can make are very easily avoided, provided that you plan ahead, use an iterative approach, and involve the rest of the team. Links Join Us On Patreon Level Up Financial Planning The post Software Architecture Mistakes appeared first on Complete Developer Podcast.

Social engineering is defined as the use of psychological tactics to manipulate individuals into divulging confidential information or performing actions that may compromise their organization’s security. Social engineering attacks often target the weakest link in an organization, which is the employees. They are looking for easy access into a system. It is important to have a firm grasp of social engineering as software developers since we are in a unique position to create security systems and protocols that are resistant to social engineering attacks. By understanding these attacks, developers can build systems that better protect against them. Social engineering is a serious threat to software developers, as we are often targeted because of our access to sensitive information and technical knowledge. It is important to be aware of the different types of social engineering attacks, such as phishing, impersonation, baiting, pretexting,. This is not an exhaustive list as social engineers are always coming up with new ways to access things they shouldn’t. Use the best practices discussed to reduce the risk of falling victim to a social engineering attack. Links Join Us On Patreon Level Up Financial Planning The post Social Engineering appeared first on Complete Developer Podcast.

The unix philosophy was originated by Ken Thompson and describes a set of cultural norms and approaches to minimalist, modular software development. This philosophy was based on the experience of the leading developers of the unix operating system. In the early days of software, there weren’t as many software tools as there are today – in fact, software tools (that is, tools that software developers use to build software), were not really around, at least not in a form you’d recognize today. Software tools, as envisioned by the original unix developers, were a set of simple tools that could be combined to accomplish a task. These included things like source code editors, compiles, debuggers, and the like. This was also the philosophy for building unix operating systems and is largely still in use today at some level in every major operating system. There are a number of historical descriptions of the unix philosophy, going all the way back to the early 1970s. While emphasizing different points, they all were trying to reach the same result, that is, making it as clean as possible to build software in a modular, transparent, and combinable manner. These approaches favored simplification of code and systems over raw performance (although obviously, performance implications still had to be considered as well). The approach also introduced ideas that we are still refining today, such as early and iterative testing of new ideas, rather than building the entire system before doing any testing at all. They even talked about larger systems being composed of smaller tools with smaller scope being composed together to produce the required functionality. You might recognize the former as sounding similar to what you’ve heard while learning agile and the latter to resembling discussions about the single responsibility principle, as well as microservices. While the unix philosophy is old, it’s still very relevant for the way software is built today. In particular, the lessons of the early unix pioneers will probably always be relevant for software development. They learned the hard way about what is required to make stable, maintainable software for general purpose computing. Even in today’s world of massive, distributed, cloud-based systems, the early lessons from the old unix days are still good ones. After all, you can still see echoes of the unix philosophy in today’s discussions about microservices. This is unlikely to change, even in your lifetime, because these principles are based upon hard won knowledge at a time when computing was very different than today. Links Join Us On Patreon Level Up Financial Planning The post Unix Philosophy appeared first on Complete Developer Podcast.

You don’t have to be a morning person to start your day off right. A good morning routine can make a tiring stressful day survivable and possibly enjoyable, whereas a poor morning routine can destroy even the most enjoyable of days. The less of a morning person you are the more important a routine becomes as it reduces the requisite cognitive functioning early in the morning when you may not be fully awake or aware. However, a morning routine is nothing without a good night before it. That’s why we talked about nightly routines first a few weeks ago. For a successful morning routine your nightly routine should be established and you will need to get a good night’s sleep. Though there are times that this may not happen, which is why having the routines at night and in the morning are there. Also, with a good nightly routine you are able to set things up for yourself to get more done in your limited morning hours. As you can see the implementations of the elements of the morning routine vary but they are still there. How you implement your routine may be different based on your life, schedule, and circumstances. You may have small children to get ready for school, or you may be in school yourself and have a roommate. Whatever your circumstance take some time to find a way to incorporate these elements into your morning and you will see a significant difference in your day. Links Join Us On Patreon Level Up Financial Planning The post Improving Your Morning Routine appeared first on Complete Developer Podcast.

We had an issue with out CDN, we apologize for the issues with access to the episode HTTPS and SSL. We fixed it on the website but the podcatchers did not update because the RSS didn’t push a new episode. This apology should fix that so that you are able to listen to that episode now. Thank you for listening, Will and BJ The post Apology appeared first on Complete Developer Podcast.

As security concerns have become more and more important on the web, there has been a growing movement to make sure that communication between the client and the server is ALWAYS encrypted. There are many reasons for this. For one, encrypted communications are more difficult to spy upon, and more difficult to tamper with in transit. It also means that people feel safer dealing with sensitive data online, including financial transactions, medical information, and private conversations. To varying degrees, secure protocols also help assure the client that they are sending data to the correct recipient as well – after all, there is no such thing as secure communication without verifying the recipient. Encryption on a transport channel is also small, but critical part of the larger security picture – if you can’t trust the data coming in, many other operations on that same data are a bad idea at best. HTTPS is intended to help protect traffic on the web, both from people spying on it in transit, as well as people who want to tamper with the traffic en route. While this may not sound like a particularly scary problem, it is actually very insidious. If a third party can tamper with data in transit, they can insert false information, or even compromise the client with things like malware. SSL and HTTPS are commonly used on the web to help protect traffic from these threats. While HTTPS and SSL are not that complicated on a surface level, the implications of them are often not discussed in detail. It’s kind of a shame, really, as they provide a lot of value and are there for good reason. While there is a tremendous amount of depth to these topics, they really aren’t that complex at a surface level, which is where most of us will encounter them. Understanding these basics will help you make sense of a lot of things you encounter while building web-based applications. Links Join Us On Patreon Level Up Financial Planning The post HTTPS and SSL appeared first on Complete Developer Podcast.

Mike Acton gave a talk at the Game Developer’s Conference back in 2019. In that talk he detailed behaviors that he expects from developers he works with regularly. They are positive statements that he then discusses the problems arising from a lack of each behavior. In a previous episode we reacted to the first half of Mr. Acton’s list. We gave ourselves a time-box to keep from going over and better facilitate discussion. As with the first set, sometimes we’ll agree with him and sometimes we may not. This is a long list, it took two episodes just to discuss the whole thing. When hearing or reading it the list may appear overwhelming. You may think, how can anyone possibly exhibit all of those behaviors. It is probably not possible for any one person to exemplify all of these behaviors all of the time. You should strive to improve in the areas where you are not showing these behaviors. Every little step is progress toward becoming a better you and living a better life. Links Everyone Watching Is Fired Join Us On Patreon Level Up Financial Planning The post Everyone Listening Is Rehired appeared first on Complete Developer Podcast.

At work, your boss probably (hopefully) has a pretty good idea of what needs to be accomplished in the next few months. Many business owners have found that productivity frameworks, like the twelve week year, help considerably with productivity. There is a good reason for this – Parkinson’s law specifies that the work will expand to fill the time allotted to it. Systems like the 12 week year help reduce the amount of time available, meaning that (within limits) things get done in a more efficient manner and prioritized differently. A system like this is also helpful in the sense that you only have to have very detailed plans for the next quarter, rather than for the entire year. Since so much can change in a few months, it makes sense to organize your planning process in a way that allows you to plan in a more responsive manner. It also helps to provide urgency to your current priorities in a way that most companies only experience at the end of the year. Many organizations experience a spike of sales during the last quarter because people are trying to meet their yearly goals before the year ends. So, what is the twelve week year? Essentially it is a system that is built on 8 ingredients of success – three principles and 5 disciplines. The three principles are accountability, committment, and “greatness in the moment”. This last one needs some explanation – it essentially means doing your best work to do what is needed, even if you aren’t feeling it in the moment. There are also five disciplines – having a clear, consistent vision, breaking your vision into a plan with priorities, using process tools to stay on track, using measurements for feedback, and effectively using your time. In a business context, these things work well due to having some portion of the supporting structure in place. The twelve week year framework essentially helps with accomplishing your goals by treating a 12 week period as if it were a year. You have 12 weeks of focused and planned-out work, followed by a week for planning, reviewing, consolidation, celebration, and a little bit of a break. This cycle and overall structure is very useful when you are trying to be more personally productive, but you do have to modify things a bit to make it fit with your own life. In particular, barring a rather strange psychological makeup, you probably don’t have an adequate mechanism for enforcing process controls on yourself in your own life. You also have a bit more of a chopped up and unpredictable schedule in your personal life than what you would have in the office, so that has to be taken into account as well. Further, you may find it difficult to measure progress in some areas, and your workflow may be very vulnerable to disruption. The structure of the twelve week year can help you a lot on being productive on your own personal projects, provided that you modify it slightly to deal with the less structured and more chaotic nature of your personal life. Because your personal life is probably not as structured as a business needs to be, some modifications will need to be made to provide appropriate structure. Additionally, because you probably do already have a full time job, this structure has to be modified further so that you don’t end up burning yourself out. Finally, it’s critical to rotate your focus between several different areas of your life over time in order to keep things balanced – your day job probably has one single function, but your personal life does not. Links Join Us On Patreon Level Up Financial Planning The post 12 Week Year Overview appeared first on Complete Developer Podcast.

In a talk given at the Game Developer’s Conference, Mike Acton discussed what annoys him about most of the developers he’s worked with over the years. He lists them as positive statements and then discusses why a lack of that particular statement annoys him. While they were written for game developers they are generic and apply across the development landscape. This will be a little bit different from other episodes. We will go through Mr. Acton’s 50 things expected of developers reacting to them as we go along. Sometimes we will agree with his assessment and other times we may not. To make this easier and be able to hit all of them we have group related ones while still keeping them in the original order. Some we will talk about as a group, others we will discuss individually. We are putting a time-box on this episode and will get through as many as we can within that time. There is a lot to unpack in these expectations and the consequences of not meeting them. Your goal in improving yourself and becoming a better developer should be to meet as many of these as possible. Don’t feel terrible is you do not meet them all, none of us meet all of them all of the time. Keep doing what you are doing to meet the ones you are meeting. The ones that you haven’t gotten yet can become future goals for you to work toward while improving yourself. Also, look for these in other developers when times are good. They will be an indication of how it will be working with them during the difficult times. Links Everyone Watching Is Fired Join Us On Patreon Level Up Financial Planning The post Everyone Listening Is Fired appeared first on Complete Developer Podcast.

While this year’s theme is time management, there are some things you should get in order before you start trying to structure a productivity system to help with your time management. In particular, you need to actually be able to track tasks that you need to do, whether they are on your most critical projects or not. You need to be able to focus on a single tasks or similar types of tasks effectively for a period of time. You need to be able to manage useful documentation, as well as more secure data so that you don’t waste time due to lack of structure. You also need to be able to track things like your habits and moods as part of creating useful feedback for your productivity system so that you can continue to improve. You also need to have some tooling in place for lightweight automations – a task that is done for you automatically ceases to be a burden, after all. Finally, you need to have a clean way to plan your work, beyond the level of what a todo list application can provide. The most effective time management and productivity system you can build is one that provides just enough structure to meet your needs and then gets out of the way. However, there are some things that seem to be common to most such systems, especially systems that developers build for themselves. As developers, we have some things on our side when trying to improve our personal productivity. For one, we tend to understand how systems can be wired together and automated. We also tend to be a little bit more comfortable “rolling our own” as far as software is concerned – if we don’t have a simple tool for a simple purpose, we can build one. However, therein lies the challenge. As developers, we can build systems, but we need things to be structured reasonably well if those systems are going to tie into other systems. Towards that end, we need to understand the various roles that different pieces of software play in our productivity systems along with which things they CANNOT do well. While improving your time management and general planning skills is absolutely critical, they are severely hampered unless you have some other things in place to help you. These underlying structural pieces will make it easier to better manage your time and productivity, as well as making it easier to automatically track what you’ve done. Even better, because you are probably a software developer (or at least a techie), these tools can really help you scale up what you are doing, to the point where larger automations or outsourcing can help you further. These tools also help you to remain relatively location and context agnostic, which means that you can continue to operate your productivity system no matter where you are. Best of all, if done properly, it all connects together well enough that you can use the right tool for the job in the moment while being certain that the data is available in some future moment when you need it. Links Join Us On Patreon Level Up Financial Planning The post Time Management Baseline appeared first on Complete Developer Podcast.

This is one of the most fun episodes we record each year. Both Will and BJ look forward to reviewing their predictions from the previous year and creating new ones. It’s important to stay up to date with the changes in technology, especially in your particular field. While this year was less unpredictable than some other recent years, it did see a lot of interesting developments both in tech and outside of it. For many people, it has been a tough year and nearly everyone has had to make some adjustments. Whether we like it or not, though, this year is nearly over and the new year is about to begin. In many respects, 2022 was a mop-up operation for the things that happened in 2020 and 2021. While the pandemic story and other things caused by it are far from over, for many, this year did represent a bit of a return to something resembling normal life. However, like all years so far in this decade, a number of curve-balls were thrown. We hope you made tremendous personal progress this year. We look forward to 2023. Predictions BJ’s Predictions There will be a boom of AI created art. Already AI artwork is selling within the art community. This will trickle down to the regular buyer, we may even see AI artwork in big stores like Target within the year. That said, with the prevalence of AI artwork, even stories, human created and original works will become a premium. We’re going to see a social media decline at some point. It may not be this year but I’m predicting it now. From the inane censorship issues to Elan Musk buying Twitter and bans on Tik Tok because of it’s parent company. I’m predicting that the newest generation is going to push back and we may even start to see a move away from using social media as a form of communication. Renewed turmoil in the Middle East. Iran is disbanding their decency police force and as of this recording considering removing or revising some of the laws around what women must wear in public. While this is a win for women’s rights and freedom, there will be zealots who do not like these changes. This is likely to lead to unrest and that area becoming another hotbed. New suppliers for cheap computer components will emerge. With the current and looming issues between the US and China among other things there is an opportunity for a new or several new suppliers for cheap electronic parts. It would be nice if we could get some manufacturing back on US soil but not likely so I expect to see one or more of the US allies (US influenced) countries to emerge and a new hub for exporting cheap parts. Will’s Predictions Significant supply chain issues will continue and will be exacerbated by governments being dumb. These may correspond to supply shortages, or be the results of war. These shortages will almost certain impact fossil fuels, food, medical supplies, and electronics. While this will make both consumers and business more price sensitive, it may open up opportunities as well. There may be a lot of money to be made for those who can save companies a lot of money. More global flashpoints will flare up. If anything, the situation in Ukraine and all the rhetoric around it, didn’t make anyone look like a definite winner who can’t be beaten. As a result, other parties are likely to become more bold. This will lead to large scale human migration in addition to shortages. You’ll also see an increase in tension between western countries and the rest of the world, as the latter have grown tired of being pushed around and the leaders of the former are desperate to keep attention off their failed policies at home. This might open additional fronts in the chaos. There will be a lot of tech layoffs. Many tech companies have excessive headcount and a lot of them have become slow and unproductive as a result. However, there will still be plenty of companies hiring and at good rates in an effort to avoid employee attrition due to inflation. Now is a good time to really lean into the effort of expanding your skill-set and personal network before you need it. Outsourcing is going to get more complicated and may offer less of an advantage than before. Besides the complications that a supply chain issues and wars create, standards of living are rising in many places outside the west. This tends to raise the salaries of overseas workers. There will also probably be more regulatory pressure applied to make sure that citizen data from certain zones (probably the EU, not the US) doesn’t end up on overseas servers. As emerging markets get better, this may also create opportunities for serving those markets, rather than one-size-fits-all solutions that are more common to the bigger markets. And all this is without considering the risk of widening regional conflicts. Links Join Us On Patreon Level Up Financial Planning The post Predictions 2023 appeared first on Complete Developer Podcast.

The theme for 2022 was resilience. Over this past year most of us have gotten at least one lesson on the importance of resilience, whether it was because of a job loss, a major change in a relationship, a death in the family, or because their entire social life was upended. However, the fact is, life changes, and sometimes changes a lot in a very short period of time. Fragility is the natural state of things – it takes systems, planning, and preparation to set things up so that they can be relied upon, even if the assumptions underlying the system become unstable. Note that resilience doesn’t fix things that are fundamentally wrong – it just smooths out the disruptions that occur when surprises happen. It’s been an interesting year for us this year. We hit several of our goals, others changed due to life circumstances, and even others are still in progress. Sometimes it would be nice to not live in times that will be in the history books other times it’s exciting to see what’s going to happen. No matter what is going on in the world around us we learned this past year about being resilient and creating goals that will stand through even the tough times. As we go into 2023 we will spend our time learning how to better accomplish our goals by managing ourselves and our time wisely and breaking our goals down into manageable chunks that we can accomplish. Resolutions Beej Get at least one Azure certificate. Yes this is a carry over from last year but I still plan to complete it especially now that I’m on the regular performance plan schedule at work. I’m going to follow Will’s advice and get the fundamentals (AZ 900) certification first, then work toward the developer (AZ 204). Learn to play 4 worship songs on the keyboard, not the synth (playing whole notes). Be able to play the full song along with the recording of the band playing. At least one will be a fast song, likely the third one I attempt to learn. I’ve already learned to play some parts of songs but not a whole worship song. As a bonus goal, outside of my control, I’d like to be able to play the keyboard with the band either in practice or at a special event like a creative night. My long term goal is to become fluent in Albanian. For this next year I plan to get more regimented with my study by setting aside daily time to study Albanian. I also aim to have a full conversation in Albanian beyond small talk/casual greetings. Create a creative space in my house for doing all the creative activities (painting, music, writing, photography, etc.) that I do. I spend most of my free time involved in some sort of creative activity. The largest room in my house is barely used when I’m awake, bedroom. Over the course of the year I plan to move my office into the spare (creative) room, then move my bed into the room I now use for an office. After doing that I will turn what is now my bedroom into a creative arts room. My primary goal for the year is to maintain the gains (or losses) I’ve made this past year. I’ve reached a healthy weight and am developing a healthy lifestyle. That said I also want to push myself as that will keep me focused more than maintenance. Right now I’m running about 10 miles per week on average (1.5 on lifting days and 2-3 on cardio days). I injured myself pushing too much too soon this past year so I’m going to increase but slowly. My goal is to work myself up to averaging 20 miles per week (2 on lifting and 5-6 on cardio and adding 4-5 on weekends). Cutting back and focusing on saying no this past year along with hurting my knee running has shown me the benefit and necessity of rest. In addition to continuing to have a night for creative endeavors, this year I plan to take one day off completely from any sort of work. A big part of this is reducing screen time so less time in front of the computer, watching TV, and playing on my phone. I’m going to track my screen time on each of these devices and aim to reduce it by at least 30% by the end of the year. Will

Have you ever wanted to write a book, start a business, learn a new skill, learn to play a musical instrument, change careers, or simply become world class at something you like to do? Did you try for a bit, only to realize that you didn't have time to do it, that you couldn't achieve your goal?Read more ›The post Time Management Mistakes appeared first on Complete Developer Podcast. Hosted on Acast. See acast.com/privacy for more information.

We hear a lot about how to be a good leader, but rarely about how to be a good follower. If we are all leading then who is following? Following isn't about blindly agreeing with leadership but instead is the ability to work within any role to improve yourself, your team, and your organization.Read more ›The post Being A Good Follower appeared first on Complete Developer Podcast. Hosted on Acast. See acast.com/privacy for more information.

Many people will tell you the importance of a morning routine, however without a nightly routine our evenings are all over the place and we are left with sleepless nights, but not in Seattle. To improve sleep and rest we have to look at habit formation and building routines and rituals into our evenings.Read more ›The post Creating A Nightly Routine appeared first on Complete Developer Podcast. Hosted on Acast. See acast.com/privacy for more information.

Integration points in complex systems have a tendency to surprise you, usually in an unpleasant fashion. While it takes a while to discover the underlying antipatterns that caused the system to have problems, there are certain "smells" you can look for that indicate common sources of issues.Read more ›The post Integration Code Smells appeared first on Complete Developer Podcast. Hosted on Acast. See acast.com/privacy for more information.

So you got a new job and you are starting in a couple of days. You are probably both excited and anxious. What will the first day be like? If you are like many people, your first day at a new job will be something that happens to you, rather than something you control. Not ideal.Read more ›The post Add Value On Your First Day appeared first on Complete Developer Podcast. Hosted on Acast. See acast.com/privacy for more information.

The millionaire mindset is a common phrase in the hustle culture of people who are working hard to better themselves and make their world a better place. But what exactly does it mean?Read more ›The post Millionaire Mindset appeared first on Complete Developer Podcast. Hosted on Acast. See acast.com/privacy for more information.

Procrastination is an insidious venom that slowly eats away at us by making us think we have plenty of time to do the things we need to do but may not want to do. Today is the day to stop procrastinating!Read more ›The post Today Is The Day To Stop Procrastinating appeared first on Complete Developer Podcast. Hosted on Acast. See acast.com/privacy for more information.

You write code and solve problems, but are you a good engineer? Are there things you can do to improve yourself and be a better developer? What does it take to be a good software developer?Read more ›The post 10 Rules To Be A Good Engineer appeared first on Complete Developer Podcast. Hosted on Acast. See acast.com/privacy for more information.

Lots of developers are self-employed. While many are happy, there are some pitfalls to the process that can trip up the unwary. From taxes, to interpersonal relationships, being self-employed will teach you a lot of things, but you really don't want to learn the hard way.Read more ›The post Downsides of Self Employement appeared first on Complete Developer Podcast. Hosted on Acast. See acast.com/privacy for more information.

There is definitely a cycle to the financial system. Things get easier for a while, and then things get harder. While we don't want to delve into the reasons too deeply, there's a pretty good chance that some rough times are coming.Read more ›The post Layoff Resilience appeared first on Complete Developer Podcast. Hosted on Acast. See acast.com/privacy for more information.

As a project becomes more successful, it almost always gets larger. Over time, teams usually get larger as well. Eventually, this means that the previous structure of the application becomes insufficient and needs to be refactored.Read more ›The post Managing Large Refactorings appeared first on Complete Developer Podcast. Hosted on Acast. See acast.com/privacy for more information.

Difficult conversations are not easy or fun, hence the term difficult. Maintaining interpersonal relationships in the workplace involves problem solving and a fair amount of compromise when dealing with difficult situations.Read more ›The post Difficult Conversations appeared first on Complete Developer Podcast. Hosted on Acast. See acast.com/privacy for more information.

If you aren't constantly dealing with the database, you probably have some misconceptions about how indexes work. These misconceptions not only tend to bite you, but they tend to do so at the worst possible time, when your system is under load or when you've just rolled out a new feature.Read more ›The post Database Indexing Mistakes appeared first on Complete Developer Podcast. Hosted on Acast. See acast.com/privacy for more information.

What motivates you when the rewards seem far off? What drives you to keep pushing when you are tired and worn out? It's not likely the pay or some big reward at the end. It is your own intrinsic motivation.Read more ›The post Basic Psychological Needs of Motivation appeared first on Complete Developer Podcast. Hosted on Acast. See acast.com/privacy for more information.

In many development shops, Single Page Applications (or SPAs) are the user interface of choice, especially if they are already in use in other systems. While this is often a laudable and reasonable choice, it's a good idea to understand the tradeoffs of going with this approach.Read more ›The post Tradeoffs of Single Page Applications appeared first on Complete Developer Podcast. Hosted on Acast. See acast.com/privacy for more information.

You've made it, you've accomplished your goals. Now what? How do you continue to be successful? Success and failure are intertwined and success if not stable can lead to failure.Read more ›The post Success Stabilizers appeared first on Complete Developer Podcast. Hosted on Acast. See acast.com/privacy for more information.

If you are lucky, someone will tell you what they actually want on a dashboard when they tell you to make one. If you're unlucky, you probably are going to have to figure it out as you go. Thankfully, there are some principles you can apply that will help you create application dashboards that are useful.Read more ›The post Better Dashboards appeared first on Complete Developer Podcast. Hosted on Acast. See acast.com/privacy for more information.

Breaches of payment systems are extremely serious. It's a great way not only to have major business problems, but to look like an idiot in front of all your clients, while causing them all kinds of headaches, including potentially emptying their bank accounts.Read more ›The post PCI Compliance appeared first on Complete Developer Podcast. Hosted on Acast. See acast.com/privacy for more information.

A major security vulnerability will be found in someone's web application this week. The OWASP Top Ten list of web application vulnerabilities has recently been updated. Read more ›The post OWASP Top Ten 2021 appeared first on Complete Developer Podcast. Hosted on Acast. See acast.com/privacy for more information.