This post may seem like a joke at first, but it's actually not. There are a few words that, especially when you work as a software developer, just have some negative connotation associated with them and should be avoided, especially when you are the bearer of bad news... hehe.

At a new job my coworkers flamed me for not having git bash-completion in my terminal (Lol, really though). Well, they could have asked me in a nicer way hehe, but I shall still be thanking them for helping me to make my command line even more awesome! By the way, I added git bash-completion as a step in my ultimate pretty command line guide which you should definitely check out if you haven't already, but this post is specifically about git bash-completion and why you should use it, and I hope by the end of it you have git bash-completion installed in your terminal too! 😉

My team and I are working on a React project that runs in regular browsers, and we recently decided to use Cypress for end to end testing. It has an actually surprisingly nice you can use to write describe-it style test scripts that will load up a browser with any page on your site, click some things, interact with the dom, and then even do assertions that your page renders correctly. You can do "cypress run" to run your tests via the command line or "cypress open" to start this little application from which you can run all tests or just specific tests, and it creates this little sidebar that gives you a history of the commands it's running and details about what happened when things have failed. Anyway, yes Cypress is awesome, but that's not what thing blog post was supposed to be about...

Today at work someone presented on graphQL, and there was an interesting discussion among all the engineers in the room about it. There was been a few times where I have had the chance to learn about graphQL, and I feel like I often leave thinking, "hey, that's a cool" but then never actually start using it in my development. Welp, that has been somewhat of the case again. Lol

I've been recently doing a lot of test-driven development at my new job, and one of the things I've noticed is that sometimes we will just run into snags, times when we hit a wall where it feels like we aren't making any real progress forward. There have been a few times now where we have gotten the code down to make the actual product work, but we spend a lot of time struggling to get the tests to pass and to really test the system in a way they we felt was good and proper. The trick is juggling the fact that we want to be a lean team that develops quickly but that we also want to write tests first that will pass when we implement these new features. Sometimes that last "making the test pass when they should" can be a lot more challenging that it ought to be, and it sometimes seems that we're put in a position where we need to choose between cutting corners or further increasing the risk that we ship late. To be honest I don't really have a right answer for all this, but in this post I'll think out loud about some ideas.