The 2016 Summer Olympics wrapped up this past Sunday. Over the past two weeks, many of us have had the chance to watch athletes from all over the world compete, demonstrating their amazing abilities of strength, skill and dedication.
Many of us can only dream of accomplishing what these competitors are able to do.
While the Olympics may not be in our future, there is much we can learn from these amazing athletes.
The pressure to build software quickly is great. Management wants features added yesterday. The competition is breathing down your neck and you must produce products to remain a relevant in your space. You cut a corner here, delay writing those automated tests over there. “It’ll just be faster if I bolt the feature on here,” you tell yousrelf. You promise to come back and do the necessary refactoring later.
Later never comes.
About two years ago, we upgraded to Java 8. Over this time, I’ve discovered many things in the new version that I’ve come to appreciate. Some of the Java 8 features may seem minor, but I find myself using nearly every day. Going deep and learning these new features have made me more efficient and my code easier to understand and follow.
Let’s look at a few of my favorite features in Java 8.
The older I get, the more I understand that software development is as much about communication as it about technical knowledge. What we say and how we say it has a lot to do with how effective we are in our profession. Whether it’s coordinating with coworkers about some technical detail, asking for a raise, or getting clear on product requirements, nearly every aspect of our job involves some form of communication.
About once or twice a year, I go to some kind of software development related conference. Things move so fast, it’s hard to keep up. Attending a tech conference is a great way to keep up to date with what’s relevant and useful. By the end of each event I attend, my brain is full. I have all these ideas and can’t wait to put them into practice when I get back to work!
You go to a conference and see the world as new and shiny, where anything is possible. Then, you take off the rose colored glasses and the post-conference blues set in.
Music expresses that which cannot be said and on which it is impossible to be silent – Victor Hugo.
Music is all around us. We turn it on in the car, we hear it at the mall or in the elevator. When we need to tune out the world and focus on coding, we put on our headphones, turn up the volume and crank up the tunes. Many of us do their best work when they have some music in the background.
Technology is advancing at an amazing rate. The number of projects on GitHub alone is increasing at an exponential rate. There’s Docker, Amazon Lambda, React (no Angular!), and Spring and all its related projects. There’s Kafka and Elasticsearch and Zookeeper, oh my! Just keeping up with all the Netflix open source libraries is a full time job. With all this new technology and more showing up all the time, how do you keep up with it all?
Have you ever noticed that some software is like the energizer bunny—it keeps going no matter what’s wrong—whereas, other systems seem to fall over whenever someone sneezes? What’s the difference? What makes some systems much more robust and resilient than others?
As a software developer, what do you spend most of your time doing? Really, besides going to meetings and playing ping-pong, how do you spend the majority of your work day? I would guess that you spend more time reading code than writing it. Maybe you’re trying to come up to speed on a new project, or learn how an open source project works. Perhaps you’re just trying to puzzle out what the heck you wrote last week. Whatever the reason, every developer should learn how to read code, not just write it.
Software fails. After all, it’s written by humans and humans are fallible. We make mistakes. We forget. We don’t foresee all the possible scenarios. Given these truths, how do we build robust, resilient systems?