Working on a remote team, we need to be extra creative to find ways to socialize, get to know each other better and even share a few laughs. Those natural moments like a quick hello-how-are-you in the hallway just don't happen. That's why we've enlisted the help of our very own custom bot member, Ein.
Our beloved Chief Code Whisperer, M. Scott Ford, was invited – again – to be a guest lecturer at the Harvard Extension School. Watch this FREE class on continuous integration, continuous delivery, and DevOps from our own “Bob Vila of the Internet” (and special thanks to Trainer and Coach Richard Kasperowski, Teaching Assistant Wendy Wong, the Harvard Extension School, and the amazing students in the Agile Software Development class).
Over the past year, we’ve written a lot about empathy on this blog. We’ve discussed empathy-driven development, the empathy spectrum, and the fact that empathy is a skill. And like any skill, it can be learned and takes practice to build. But perhaps one of the most important posts was actually an update to an existing one.
As a person who has worked in enterprise software and technology for almost 20 years, I always marvel at how different this industry looks from twenty, ten, or even just five years ago. Over the last two years, the landscape has shifted for classic enterprise vendors like IBM, Oracle and Microsoft in dramatic ways, but the massive tectonic shifts we now see have only been due to the incremental changes deep below the surface for decades.
If you love old architecture and castles, you'll fall for Bratislava. Easily one of the most beautiful places you can visit in Europe, this Slovakian capital is small enough that you can drive/walk quickly to most places, but big enough to fill your schedule for a few days. It may surprise some to find out that, when it comes to software development, the area is very quickly becoming one of the European tech hubs. Last month, Bratislava hosted two big conferences in one week.
Over the years, I've heard a lot of different attitudes regarding code that’s going to be thrown away. Let me be clear here. I’m not talking about code that we think might get thrown away. I’m talking about code that we know will get thrown away.
Last Friday, I caught a friend’s band at a local pub. I know how it sounds. “A friend’s band. That’s cute.” Except it’s not like that. This friend is an exceptional guitarist. When he plays, it’s like watching Joe Satriani, Jimmy Hendrix, Slash. His instrument becomes an expression of his soul.
I recently started writing tests for an Angular application, so I had to go through the entire process of researching the tools, installing and setting up the libraries, writing the tests and learning the tricks. Here's what I discovered.
When building a feature or fixing a bug, you will be reading the code that exists. One thing I do often is ask, “Why was this done this way?” Programming is not a binary profession. Fuzzy logic would be a better way to explain how problems get solved. Just as programmers' experiences vary, you can find many solutions to get from 0 to 1. So, when I want to answer my initial question, I leverage git blame.
Is your code difficult to work with? Chances are, it’s time to get rid of code you don’t need. That can be a scary prospect, but the rewards can be well worth the effort. Recently, I was inspired by KonMari, a technique for decluttering physical spaces, to help me visualize how to refactor codebases to make them easier to work with.