devleader

I use both unit tests and functional/integration tests as tools in my development I like both approaches. I use both approaches. They're separate tools for separate situations in my development process. I know from many conversations (especially online where we have plenty of strong opinions) that people seem to gravitate to one or the other. Unit tests are too brittle. They don't offer value. You can't refactor code with them. Functional tests are too much work to setup. They're too complicated. They aren't granular enough to catch issues in a helpful way. Instead of focusing on all of the reasons why not... Try thinking about situations where these can be helpful tools. Watch the full video here: youtube.com/watch?v=6so35iZN…

I like architecting my code to be reusable and extensible But I recognize that this isn't always worth investing into -- at least not to the degree that I like to focus on it. When I build things in my own personal projects, more for learning and as a hobby, I often follow patterns a bit more to an extreme. Why? Why would you go over-engineer things of fall into anti-patterns, Nick?! So I can learn. So I can go get the hands-on experience and understand WHY these things breakdown and where they might still offer benefits. Watch the full video here: youtube.com/watch?v=6so35iZN…

Here's what happened when I didn't hook up my tests to my build pipeline... I broke stuff. I broke... a lot of stuff. In production. And the extra embarrassing part was that I *HAD* the tests! I just chose not to run them. To be more fair, I had tests that would have caught the breakages but I locally ran a different set of tests that didn't cover where the issue was. CI/CD can be a life-saver... don't underestimate the value! Watch the full video here: youtu.be/4Tsmo9IAzQI

There are different ways to implement the same design patterns. A simple example is with the Observer Pattern! If we have observers and observables, we can create the pattern so that: - The observer registers to the observable - The observable tracks all ofthe different observers - OR... we could introduce a dedicated class to manage the subscriptions. What other ways can we approach it? Watch the full video here: youtu.be/pP2nnzWRJnA

Look! This code is so much more readable when we force it all onto one line! ... said nobody ever. This is a misconception that I think is almost like a phase that many programmers go through when they're learning aboiut refactoring. Being able to do something in fewer lines of code seems to give the illusion that the code is more efficient. Not only is this not often the case, but the readability is greatly impacted when your lines of code get wider. The more you have to scroll left to right, the more taxing it is to read through code. And no, a wider monitor does not help. Watch the full video here: youtu.be/R0Ed8LIGcyY

THESE will make you a high quality candidate for software engineering... Coachability. Soft Skills. In my conversation with @JohnVandivier, he highlights that these two traits of software engineers really help you stand out. John has found the research on post-secondary and alternative credentials highlights a skill gap in soft skills. That is, between traditionally educated and alternatively educated individuals in the eyes of employers, one of the biggest skill gaps observed is not technical... but soft skills! What are your thoughts on this? Watch the full video here: youtu.be/IfpFm44-2ZM

Maybe "Agile" isn't working for you because... You aren't actually being agile. Many teams do it. We've all seen it before. You might even be on a team that's doing it RIGHT NOW -- and that's okay, because awareness is the first part. In this discussion with Jade Wilson, she points out that many teams are stuck in a process. None of the values of scrum (or other Agile approaches) are being considered. Of course, if you're hyper-focused on a process, you might even notice that just by the definition of the word you're not being very agile! Is your team truly being Agile? Watch the full video here: youtu.be/1EBogK5KCR8

When using flag enums in CSharp, did you know... When we call ToString() on a flags enum value, it will print out each of the flag values being matched! This is a huge readability boost, especially when debugging. Mentally flip-flopping between numeric and string representations can be tiring, so having it prepared for us in a convenient way is awesome! Watch the full video here: youtu.be/_yUOrzTCpGU

When's the last time that you used binary in CSharp? Even in my digital forensics software days, I was rarely relying on binary representation of anything in CSharp... However, if you're using enums as flags then you should get familiar with binary! Each flag represents a bit being turned on, so it's important to understand how they get combined and how to test for bits. Watch the full video here: youtu.be/_yUOrzTCpGU

Some of my favorite tests do a lot of heavy lifting integration tests have proven to be invaluable. In my ASP NET Core apps, I have tests that will launch the entire app stack. Not just that - They'll launch Testcontainers to have my databases ready to rock and roll alongside my app. Yes, my unit tests tell me with precision when something breaks... But my functional tests give me high-level confidence that the pieces are working together Watch the full video here: youtu.be/4Tsmo9IAzQI

This one thing kills most of the value of your tests... Different tests have different types of coverage, and as a result, offer different kinds of confidence benefits. I like unit tests for ensuring specific code paths are run how I'd expect. They don't help with refactoring but they help prove to me my code does what I said. I like integration and functional tests for more general confidence and ability to refactor. They might be a bit harder to setup, tear down, and reset, but they are incredibly helpful. But the one thing killing your tests: Not running them. Make sure you wire these up to get coverage automatically or you'll end up like me (in too many situations). Watch the full video here: youtu.be/4Tsmo9IAzQI

How did Callie Buruchara become a senior in a short period of time? She did 7,281,392 LeetCode problems. ... but you'll never guess how many linked lists she reversed! Callie attributes much of her success to getting her senior role to her communication skills. She explains that communication and people skills were able to shine when her team needed more informal leadership and guidance to bridge some challenging times. This is one of the ways that Callie REALLY stood out. Does that mean she can't reverse a linked list? I'm sure she can. Callie is still very technical, but she has a strong set of communication skills to allow her to work very effectively with others. Watch the full video here: youtu.be/AWTwji6mmeA

Your definition of success is all wrong. These were powerful words to hear from Callie Buruchara when we sat down for a recorded chat about communication for software engineers. Callie explained that for individuals trying to get into software engineering, they see her as someone who is very successful. And she is! She's a senior software engineer doing awesome work. But their view of success is not the same view of success that Callie has. It's not about knowing all of the coding languages. It's not knowing every tech stack. It's not about always writing perfect code. How do you view success in a software engineering career? Watch the full video here: youtu.be/AWTwji6mmeA

Why should I care if they don't understand? It's their problem. Callie Buruchara says communication in software engineering is one of the most important skills you can have. And I 100% agree with her. But why? Why should you care? Isn't it the other person's problem if they don't understand what you're trying to say? It's certainly got to be their lack of experience or their lack of communication skills or some other deficiency on their part. ... Right? This was such a great conversation with Callie to go over the many reasons why software engineers NEED to have good communication skills. Watch the full video here: youtu.be/AWTwji6mmeA

This is one of THE most important software engineering skills It's not reversing linked lists. It's not traversing trees. It's not how to implement bubble sort (please don't). It's communication. One of the most important skills you can learn as a software engineer is communication. I sat down to chat with Callie Buruchara to discuss this, and it's not just "Okay, it's important, go do it!"... We talk about WHY. We talk about the situations it's helpful in. And just like anything else -- you get better by practicing it. Watch the full video here: youtu.be/AWTwji6mmeA

Feedback is something that REALLY needs to be tailored In this discussion with Callie Buruchara, we sat down to go over communication skills for software engineers. Of course, feedback is a big part of working in teams AND a big part of being able to grow in your career. But have you stopped to think that how you give feedback shouldn't JUST be based on your personal style? You need to adapt it to the person you're giving feedback to! This can also help explain why sometimes getting feedback from certain individuals isn't as great -- perhaps they aren't doing a stellar job adapting their approach to suit what works best for you. You know what could help that? Communication. Watch the full video here: youtu.be/AWTwji6mmeA

Every other learning modality is second best to project-based learning for software engineers. @JohnVandivier has gone through the data that supports this -- and if you tag him, I bet you he can point you directly to it! There are lots of resources and ways that we can learn: - Reading articles - Watching videos - Course-based learning - ... you name it! But building things is essential for learning software engineering. John even recommends the learning-in-public approach that can help even further in your job search. Do you agree with what the data suggests? Do you find that you learn more effectively in other ways? Let us know what we missed! Watch the full video here: youtu.be/IfpFm44-2ZM

You probably don't want to hear this but Waterfall actually works. And before you rush to furiously write angry messages... I didn't say that other things don't work. I also didn't say Waterfall always works. In my conversation with Jade Wilson, she shared that her team doesn't just follow one software development process blindly. In fact -- they might use a variety depending on the situation. That's right! Waterfall sometimes AND Agile in other situations. Different types of deliveries require different approaches, so there is no one right way to deliver things. Have you successfully worked across different delivery methods? Watch the full video here: youtu.be/1EBogK5KCR8