I recently found myself at a Meetup where half of the attendees were from a local front-end bootcamp class. They were connecting, looking for future job prospects, and practicing their…
Remember as a child how much of your time involved play? Whether it involved Barbies, Legos, or creating an empire in your backyard based off a leaf-based currency, you were…
Incorporating DevOps into your organization is not a zero-sum game. It is a journey. And like most journeys, it can be measured. When measuring your DevOps journey, you need to show progress as well as setbacks. Additionally, it’s critical that you make sure these measurements are accurate, automated, and visible—just like your DevOps.
There’s a common misconception that’s permeated our profession: Architects don’t need to write code to do their jobs. Now, this may seem like a harmless approach. After all, writing code is what developers do. And architects should be busy with more important tasks. However, keeping architects from writing code can limit the potential of your development teams. It can also result in an architectural mess when requirements and business needs change.
We often focus on code fails. But what else have we seen and done that makes us drop our heads in shame and frustration? What else do we laugh (and cringe) at when reading code? The comments! Whether they’re redundant, unreadable, confusing, or there’s just no comments at all, we can learn a lot from failure. And to spice things up, I’m going to throw in a biking analogy. You’re not sure if that’ll work? Me neither. But let’s go on this ride together and find out.
You’re a clean coder. You use descriptive names for everything. You’ve refactored your app into a shrine of single responsibilities. Even your slightly crazy, off-the-grid uncle can follow the code. (Hi, Uncle Joe!) The app not only documents itself, it documents life. Or does it?
You were sold the promise of the cloud. The performance gains were going to make everything better. Costs would go down since you’d only be paying for the resources you were actually using. Unfortunately, when all was said and done, the cloud didn’t deliver. So where did things go wrong? Is it your app? Is it the cloud itself? Or was there something else that caused this pain?
Your application is deployed. But what does that mean for your customers and partners? Does everything work for them? And what about when things do go wrong? Are you the first to know? Or do you only know there’s a problem when your customers tell you something’s wrong? When that happens, are you able to diagnose the issue quickly?
You've delivered your product, application, or website. You're seeing some traffic and even some conversions. But something is holding you back. Could it be speed? In today's world of limited patience and shortened attention spans, you have to make sure that you're giving your customers the enjoyable experience they need to stick around.