If you want to be happy, I think I figured it out…

"happy pills"by theseanster93 is licensed under CC BY-SA 2.0

Aristotle said, "Happiness is the meaning and the purpose of life, the whole aim, and end of human existence." I used to think to achieve this: I had to do things that made me happy.  I was searching for things that I could add to my life, like seasoning salt. This day doesn't feel that happy, so, add some drinks, some friends, and presto—I got happy! 

What happened was that I was distracting myself with things that made me forget what I should be doing.  And it made me less self-aware.  I stopped thinking about why I was feeling a certain way. I was entertaining myself, but I wasn't happier. I guess you can’t get happiness by chasing after it.

As a computer programmer, I like to think about things logically: cause and effect. Put something in and get an output. If this, then that. Simple. Add things to the mix, and they result in something that we can measure and track. How in the world can I do that with happiness? Enter Ralph Waldo Emerson:

"The purpose of life is not to be happy. It is to be useful, to be honorable, to be compassionate, to have it make some difference that you have lived and lived well."

I have realized that happiness is a side-effect, and one that's not necessarily intuitive. I can't always track how it happens; it just appears out of nowhere like a ghost and disappears just as fast. I wanted to find a way to guarantee it, to create it. It wasn't until I looked at the things that created happiness as a side-effect, that I realized that the times in my life I've found happiness are when I'm serving others and being useful, honorable, and compassionate. When I'm kind to others, I walk away feeling a real sense of happiness. That's deep. Like the other day, I helped this guy buy a new suit of Arabic clothes.

I had some ridiculously good Pakistani food last night, and my friend "BK" was telling me a story about a guy who was unhappy with his job and where he worked. He spoke to the HR person who helped him realize that he was good at his job, and that he loved the job that he was doing. The source of his unhappiness was that his career was plagued with gossip, time-wasting, and backstabbing office politics.

She challenged the guy to walk around the office while carrying a full glass of water. The only requirement was that he had to walk around the office three times without spilling a drop. If he did spill, he'd have to start the challenge over. It didn't take long, but the guy succeeded and made it around the office three times. He made it past all his co-workers who whispered and wondered what the heck was going on, but he did not pay any attention to them.

When he got back to the HR person, she asked him, "How did you feel? Did you get caught up in the back-biting office politics and gossip?" He responded, "No, of course not, I focused on the task of getting around the office with the water, not on the other stuff." He paused for a second and looked across at the smiling HR person and said, "Oh, I get it--thank you, I needed that." He finally understood that his problem wasn't all the bad behavior he was observing; what he learned was that if he stayed focused on his task and his job, then none of that other stuff would matter.

Back to life, our lives, to be exact.  Maybe you don’t need to carry a glass filled with water around your office, but what's the task that can help you change the way you see reality and get you into a positive place?

Recently, I've been living in Saudi Arabia and have had a chance to reset some of my habits and create some new ones. Going to the Middle East wasn't something that I was doing for my happiness; it was much more business than anything else. And I knew being away from my family was definitely going to make me unhappy. So I needed to arm myself with some things to do to make myself happier. If I am going to have to be away from the people I love, I at least should bring back something that I have achieved. I should come back better.

I'd read somewhere to start each morning by writing three things I was grateful for in a journal each day and to see what happens. So I started doing that, and at first, I found it to be easy, and it became transactional. Wake up, go down to the hotel's mezzanine level, drink three cups of coffee, eat a big breakfast, write down three things I was grateful for and then go to the university where I was teaching. 

What I didn't expect was it to work. And I realized that some mornings I'd become filled with emotion and really internalize the feelings of gratitude--those were the days that I felt the most significant effect. I learned that not only did I have to write down and think about what I was grateful for, but I also had to feel the emotions that go along with it. I had to feel the gratitude and be thankful for it all at the same time. I couldn't fake it or just be frivolous about it. 

So that's it, that's my secret. 

If you want to really find happiness in your life, you should try to start your day with gratitude. You have to feel the emotions and bask in the healing energy that is created when you do it. It's not a magic trick, but when you do it right, the effects are magical. You'll sing your way into the office, and your day will be better. Give it a shot; you'll be grateful you did.

What can some monkeys tell us about our culture?

Monkey see... Monkey do...

I came across an article a while back about a study that was done with some monkeys. I'm not sure if the story is true or not, and after a couple of google searches, I found mixed results. Instead of trying to link to one of those stories for my current article I'm writing about high performance and high morale in teams, I decided I'll just go ahead and write it myself.

It goes like this: Years ago a famous psychologist and his team took a group of five monkeys and placed them in a cage with a ladder and a bunch of bananas hanging down from the top of the cage in the middle of the space. The monkeys at first were allowed to eat some bananas and they loved climbing to the top and grabbing a banana.

The scientists watched and let them eat all of the bananas the first go around. After that, they placed another bunch of bananas on the hook and then when the first monkey climbed up to grab some of the fruit, they sprayed the entire cage down with water--soaking the monkeys and causing them to freak out.

They did this over and over again, each time a monkey would climb up on the ladder, they'd immediately start spraying ALL the monkeys with the cold water. Until finally, the monkeys started to beat the monkey who would climb up to the top. With the water and bananas, they created a behavior in the monkeys that whenever one of the other monkeys climbed on the ladder, they would all start freaking out and they would attack the monkey on the ladder so that the water wouldn't get sprayed on all of them.

Of course, after a time, no monkey would dare climb the ladder no matter how hungry they were. The scientists all looked at each other and were satisfied that they had conditioned the monkeys to be afraid of the beating and the water that would punish all of them.

Don't fall into the water!!!

Then the scientists did something different. They added a monkey from another group that had never been sprayed. As soon as that monkey came into the group, he saw the bananas and immediately went for the ladder--this caused the other monkeys to leap into action and do their thing. They, of course, beat the heck out of that poor new monkey until he learned not to climb the ladder.

The difference was, the scientists stopped spraying the whole cage down now that they had a new monkey in the cage. Can you imagine what that poor monkey was thinking? Anyway, the scientists waited until the new monkey knew darn well that if he got on the ladder, a beating was coming.

Then they added another new monkey, and they continued to do the same thing until there were no more monkeys in the cage that were subjected to the original water spraying punishment. Now they were just beating any monkey who went for the bananas, and none of the monkeys even knew why that whole thing had started.

The scientists had essentially created a cultural behavior in the cage. Get on the ladder, guess what, you get beat up--why? Who cares and who knows.

If we could have interviewed one of the monkeys and asked them why they would beat any new monkey who came into their cage and got on the ladder we could infer that they'd say, "That's the way we do things around here."

"That's the way we do things around here."

Think about that and think about our offices and organizations. Have you seen behaviors like this before? Or, have you been the new person in a meeting that is surprised about something that's happening in your office, and when you ask your co-worker or friends about it, they whisper and shake their head, "I dunno man, that's just the way we do things."

I've seen it before, I've been the guy who's gotten beat up and the guy who has delivered the beating. Sometimes I know exactly why and who, but lots of times I've just been one of the monkeys who got taught the hard way.

I think that this sort of thing can be good or bad. Some organizations have great habits and values--and we are lucky to have those behaviors ingrained in the fabric of the office. But sometimes there are habits that aren't as good and noble, but we still end up doing them, just because.

We should challenge the group and organizational habits that we come across that don't resonate with our internal dialogues and values. It takes real courage to stand up and tell others that something isn't right, especially when those others are our new co-workers, bosses, or whomever. Remember, that's why organizations need people who are operating with their eyes wide open and not afraid to challenge the status quo.

As leaders, and responsible citizens of the cultures we are a part of; I believe it's our duty to make them better by participating and providing honest and open feedback when we see something wrong. Yes, it takes courage and we might get beat up, but that's what leaders do, we lead.

Making the jump from monolithics to microservices

Written By Daniel Oostra

As companies begin to find more ways to save money and operate more efficiently, technology leaders are making key changes to their architectures as they develop applications. These changes offer a huge opportunity for developers to leverage their skills as programmers–and to enhance their skill sets with new DevOps practices and technologies.

Similarly, backend engineers are looking to boot camps and schools to add programming and coding skills to their resumes to make them more versatile and to be able to communicate with the developers and programmers working on applications on the platforms they support.

Just today I spoke with a systems administrator, Robert B., who also was trained to be a cloud security specialist and was interested in Coding Dojo. He was talking to me about how he could shell script, but his knowledge of compiled languages and practices were a complete mystery to him. He brought up containerization in his interview and stressed the desire to learn more about microservices. We had a great discussion and hopefully, we will have him join us at our onsite boot camp in March 2019.

My discussion with Robert prompted me to write this piece. As developers, instructors, and technologists, we need to investigate the shift that has happened in how applications are being developed and supported. To gain a good understanding of the architectures we are discussing, let’s begin by taking a look at what I mean by monolithic; then we can examine how microservices fit into the big picture of application development.

Monolithic Architecture

Today, and in the past, computer programs that have a monolithic architecture are built using a single unified software design model; where all the parts of the program are put together in one piece.

One challenge when working with this sort of software is that when you need to change one feature or function in the software, you might need to re-write the entire program to make that new change work.

That sounds tedious–and believe me, it can be. However, monolithic architectures are not all bad, applications developed this way can be easier to debug since all the parts are encapsulated in one location. They can be more secure since its’ not connected to external systems, and you can maintain total control of the content and experience that you provide your users.

When thinking about what a monolithic application is, think back to an old school arcade game like Centipede, Ms. Pacman, or Space Invaders. The game is played right there, you have one way to interface with it, you have different high scores (state), and the game changes the score data over time (state change). If the game makers want to change the user interface, they would have to re-engineer the entire game. Remember the desktop versions of Word and Excel? Microsoft took its monoliths and moved them to a microservices architecture with its’ launch of Office 360.

Let’s look at a more abstract example. Understanding what a monolith is the first step in understanding how to migrate to microservices. These types of applications take the user interface, the data access layer, and the data store and tightly bind them together into what we call a stateful application. All that means is that we have an application that stores and changes data over time and that the app can have what we call state. The key takeaway is that the state of these applications can and will change.

Modular Architecture

Now let’s look at a modular application. In the diagram below, we have a similar application compared to the one above, but, notice how on each layer of the application, there are multiple components. Now imagine if each component was completely independent of the rest of the system.

Look at how easily things could theoretically scale. In contrast, the monolithic application would be very hard to scale because there is no way to add additional components to the system in a way that would not break the rest of the system. With a modular approach, we can add components on each layer and grow the application to fit the exact needs of our clients. If we need more of something, we just plug it in and turn it on.


Computer scientists have been working with this sort of approach for a long time. We call it orthogonal design, which is just another fancy way to say modular design. Creating applications with orthogonality in mind is not just for computer scientists, we can use it in all aspects of engineering. We can take this approach and develop websites, mobile applications, and even desktop applications using modules and services that are available on the web via APIs.

Microservices

Now that we have all the background out of the way, it is clear from my perspective why anyone would take their application the modular route. My definition for what a microservice is that it is any program that serves a single function or discreet task, and can be integrated into any application seamlessly and easily, regardless of the platform. I’ve read other definitions that define a microservice is any service that only requires one team to maintain it.

Wikipedia defines a microservice as:

Microservices are a software development technique—a variant of the service-oriented architecture (SOA) architectural style that structures an application as a collection of loosely coupled services. In a microservices architecture, services are fine-grained and the protocols are lightweight. The benefit of decomposing an application into different smaller services is that it improves modularity. This makes the application easier to understand, develop, test, and become more resilient to architecture erosion.[1] It parallelizes development by enabling small autonomous teams to develop, deploy and scale their respective services independently.[2] It also allows the architecture of an individual service to emerge through continuous refactoring.[3] Microservices-based architectures enable continuous delivery and deployment.[4]

Wikipedia. (2019 Feb 12) Microservices, https://en.wikipedia.org/wiki/Microservices

We all play video games, and today, many of our favorite video games are collections of microservices.

Think about when you play Fortnite, do you think the Fortnite people wrote their own chat protocols and program to work in their game? Or, maybe when they get an additional million users, do they go out and buy more servers?


Of course, they didn’t, they tapped into a microservice that provided that service and saved them thousands of dollars in design, testing, and development, mainly because someone else spent all the time and money to develop that service. As illustrated in the diagram above, as the number of users increases, the “orchestration software” responds by turning on another service to handle the loads. Each one of the chat microservices can operate on their own and with other units, if something bad happens in one, then we just shut it down and the system continues without notice.

Virtually any program can be broken up into components that could be running in different rooms, cities, or countries. This all goes back to orthogonality and creating tools that can be reused, over and over again.

Preparing Our Teams

How do we make the most effective and efficient system from monolithic design to a microservices approach? We train our people. Taking our current teams of developers and systems administrators and exposing them to the benefits of this approach is the key. Once technologists see the savings in maintenance and support for older architectures, they will move their products to leverage secure, working microservices to scale and grow their online footprints.

Coding Dojo exists to assist the technical staff of your organization to make the migration from your monolithic architectures into the microservices environment. Currently, our instruction team is busy working on curricula that will support your organization’s transition, providing the tools and experience that will give them the vision to see the pitfalls and challenges of a software migration--before they start costing your organization precious resources.

With courses on containerization, microservices orchestration, and modern DevOps practices, let Coding Dojo’s corporate training team help your staff chart a clear and well-thought-out path to increase your organization’s technical efficiency and to develop a solid roadmap to saving money using microservices.