If you aren’t using your own software you are missing out on everything great that you can learn from it. How do those features truly work? What happens when you use a function in a different way? How many clicks does it take to accomplish a task? What happens when something goes wrong? How do we handle errors on the client side? How long does it take to load? What do I think of when…
Where _____________ is the app currently being used by your team to accomplish a task that they deem important to their overall success. But you don’t use it, maybe you never had the opportunity or need. So the question now becomes, are you going to learn something new or make the entire team change their practice to fit to your needs? No hints needed.
There comes a time in every developer’s life when they realize they need to write better tests. Whether it’s a console, web, or unit test, they need to write better tests. If you’re at this point, here are some elements that are important to writing great tests; They should be objective – the result is the result is the result – there is no complex interpretation. They should be measurable – whether they do it…
All our spaces are changing. Where we work, where we live, what we do when we are there. They are changing into something different that enables us to define the area where we are at our best and most productive. And productivity is key to a workable space. The bean bag chairs never did it for me unless I was using one app to do one thing where I could sit there and type. But…
It should be testable. It should defend. It should be clear to understand. It should catch errors. If it is not the sole source of all the logging, it should provide valuable fragments that render what it logs usable. It should do what it is meant to do, not what we hope it to do