One evidence of a flatter world today is the rise of geographically distributed teams. This isn’t something new, distributed teams have been around since ages and have given us a lot of Open Source software. Imagine not having Linux, Firefox, Apache, VLC, … ad infinitum.Distributed teams have also aided the software outsourcing industry to prosper.However, today even companies who do not outsource their work have their team members distributed across the globe.
So, what do you think is the number one skill required to work in a distributed team?
Effective communication.
Effective communication requires us to have a good hold on the various modes of communication – Reading, Writing, Listening and Speaking.
And I believe if we read more, we can improve our writing, listening and even speaking.
I’m sure all of us do a lot of work-related reading. However, I find that reading books not directly related to our work is also required.
Apart from just vocabulary and grammar, reading books on various topics improves one’s general knowledge, imagination, and creativity among other things. And these benefits can also help bridge gaps in distributed teams, between team members from different countries.
Getting into the habit of reading is not easy; given how we are always catching up with our fast-paced and hectic lives.
However, I believe that like any habit, the habit of reading books can be picked up with just a little bit of effort. By the way, to understand more about habits, please read – The Power of Habit by Charles Duhigg.
As per Charles Duhigg, more than 80% of what we do in a day is driven by habit, which means that most of the times we are on auto-pilot, except when we are exerting ourselves mentally or physically in order to pick up a new habit.
Really, an interesting book, I highly recommended it!
Enough meandering, let’s see how we can read more.
How to start reading more?
One of the ways to build a habit of reading books is to set aside some time in your day. It could be anything as per your convenience – 20 mins, 30 mins, or 1 hour.
I recommend scheduling it in your calendar so that it’s harder to skip it.
Remember, you need to make reading a daily habit.
What kind of books should I read?
Find a book on a topic that interests you. It could be fiction or nonfiction. I would recommend reading both. There are many writing genres, pick any.
What if I find the book boring?
Google says there are an estimated 145 million books in the world today. So if you are not enjoying a book, even after reading forty – fifty pages, leave it and move to another book.
And if you’re enjoying it, stick with it to the end.
Blogs vs Books?
Blogs are great, some blogs are just awesome. However, usually, blogs are about a specific topic, whereas books usually contain various related topics.
Blogs are typically written by one person, whereas a book usually has a team behind it. Apart from the author, there are reviewers, editors, people who want to make sure that the book should be good enough to sell so that it can make money.
How to find good books?
Hunt for bestselling books under various topics on Amazon or GoodReads
We are living in a world where communication is taken way more seriously than ever before. Communication has been taken to a different level, from letters to mobile communication to emails to sms to Whatsapp to Snapchat and the list can go on.
Today the most basic form of communication is either email or chats or messaging (be it sms or Whatsapp). Although personally I do not favour the modern forms of communication since it kills the whole corporate feeling to it, I have come to accept it, as it is a vital part of corporate communication.
In today’s world, we communicate more in the form of written rather than verbal text because of which the language used and the correct use of grammar surfaces as of the utmost importance, especially while writing to clients. Clients might just take the literal sense of what we say and miss the whole point altogether!. So here are 8 things, one should be careful about while writing a corporate email!
1. The KISS Rule
Keep it simple silly. No one likes to read long paragraphs or a long story in an email. It’s best to keep it short, simple and crisp. That is how a client would like it. But when I say simple it doesn’t only mean the simplicity of thoughts. More than the content it is the presentation that should be kept short and simple.
2. The Formal/ Informal Email
Depending on whom we are writing to, the tone and the content of the email changes. The kind of client he/she is left for you to decide. Remember, sometimes we should be very subtle about our opinions because not everyone can take honest suggestions in the right way. Here’s a short example of informal vs formal writing.
Informal: It is a bad idea.
Formal: I am not sure if this would be a good idea.
3. Spelling
This is where most of us go wrong. We depend a lot on the auto correct option but it’s not always a good idea. At times you need to double-check certain spellings, especially the client’s name while writing!
4. Never Say No
A client would never like to listen to phrases/words like; no, we cannot do it, it’s impossible, etc. So how would you convey a “no” to a client? There are a lot of ways to do it, here is one example: –
Instead of saying “we cannot do it” you can always say “what we can do instead.”
4. Proofreading
This one I would say is the most important part of writing emails, ALWAYS proofread what you have written. I know we live in a crazy – busy world and it is very easy to just press that send button but get into a habit of double checking what you have written.
5. Watch Your Grammar And Your Capitals.
We have to be very careful about not making silly grammatical mistakes. Like for example; we should not forget who we are addressing and keep the gender correct throughout the email. A “her” cannot be addressed as a “him”, so we need to watch out. Take care of your singulars and plurals too.
6. Punctuation
Punctuations are something that could be overlooked if it is an informal email, however while writing to a client it needs to be attended to. As we are trying to create a good image to our client (especially your potential customers whom you are writing to for the first time.
7. Write Accurate Subjects
For easy access for you as well as your clients go the extra mile and write accurate email subjects. Create versions of documents so it’s easy to pick out the latest version of a design or copy, it will be appreciated deeply.
In the world of “one-up” IT, it seems like almost everyone is wanting to understand how to integrate microservices into their solution architecture. And rightly so. The benefits of using microservices are numerous and varied. Let’s examine some of these positives and consider if they can help you solve some of the problems that you are facing today.
Agile scalability
In a traditional Web application, you can author scaling rules such that when a certain request count is reached, additional instances of the entire Web application can be automatically spun up on newly (and dynamically) allocated Web servers. However, you do not have any control over which specific area of that Web application needs to be scaled. Do you need to scale the entire Web app, or just a part of it?
For instance, there could be a queued backup of HTTP requests waiting to post values into a payment system. Perhaps there is a rather extensive validation algorithm that needs to be processed before the payment can be finalized. This small yet often-accessed part of the Web app could thus become a bottleneck. In traditional scaling of a Web app, to scale up new Web servers would be dynamically provisioned, the entire Web app will be loaded onto those servers, and the process will continue.
A more efficient architecture design would be to scale up just the payment service on its own. Not only would that be quicker (since you are not provisioning new versions of the complete Web app), but it uses less resources (since you are only scaling a piece of the solution).
To further save in resources and time, add in a cloud provider to leverage its container technology to host microservices and other cloud services to help with innovation, scalability, provide resource optimization.
Focused development
The goal of “micro” service is to do one thing only but do it very well to meet the needs of the business. This typically means a small team, a finite and very focused development scope, and functionality to design and implement the microservice very well. Services should be “slim” and keenly targeted and no overlapping functionality with other supporting microservices. When this is accomplished, consumers of that service can thus focus on using that service and could care less about its implementation or how the microservice accomplishes its goals.
Keeping development focused at the microservice level gives teams the chance to experiment. It is very very easy for multiple versions of a microservice to co-exist for A/B testing. You can route certain percentages of requests to the different versions, assess /compare the results, and then make design decisions. This can be done multiple times per day if necessary. This ability to experiment is not possible with anything larger than a microservice.
When decomposing the monolith down to microservices, we are now free to implement each microservice in the most effective way. This may mean using a different version of Java or NodeJs than what the other microservices are using. Or you can go all the way in on polyglot development and allow teams to choose the specific technology (e.g. Java, .NET, Go, etc.) they want for their given service.
DevOps Integration
With all these independent teams developing non-overlapping and focused microservices, how to we integrate this all together into a viable solution? The DevOps model can serve as a facilitator. Both microservices and DevOps offer an agile model that is a key component of the microservices model. Well-designed microservices follow this model to assist in development, speed, and agility – yielding smaller and more frequent releases. Continuous Integration (CI) is all about integrating frequent releases and thus is a perfect platform for a microservices release model. This model encompasses shorter build, test, and deployment cycles that fuel the ability to quickly roll out new versions of a service.
Microservices bring additional productivity to DevOps by embracing a shared toolset, which can be used for both development and operations. That common toolset establishes shared terminology, as well as processes for requirements, dependencies, and problems. This encourages development and operations teams to work better with one another, allowing those entities to work jointly on a problem to successfully fix a build configuration or a build script.
DevOps and microservices work better when applied together. This is especially true when DevOps automation is added to the equation, ensuring you get the same process followed exactly each time through the CI/CD pipeline. Automation also cuts down significantly on the time to process the new code/build/test/deploy cycle.
Standardized Communication
Microservices communicate using common mechanisms, such as RPC (such as REST or SOAP), or messaging. This promotes easy interaction with them. With RPC, a service makes a synchronous request to another service, then waits for that called service to respond back. While it is a simpler programming model due to the logic of the caller continuing immediately upon return from the RPC call, it can also have blocking/waiting issues while calls are waiting to complete.
If asynchronous communication is required to avoid blocking calls, then messaging can be used. Here a message is “published” into a message broker. That broker takes the message and forwards it on towards “subscriber” receivers who have registered to be notified if this message is published. The publisher (calling code) can then return immediately after publishing the message to the broker and does not have to wait for the message to process.
Evolutionary Architecture
One of the big architectural benefits of microservices is how well microservices support the ability to implement an “evolutionary” architecture. This allows you to continually innovate and incrementally change without incurring any significant cost, risk and change to those services that are running on it.
The advantages of microservices
These are the primary positives of microservices. Together they form a very efficient and streamlined agile model for development. However, microservices are not a technology to blindly make everything better. There is overhead in developing them, and it is a more complex model in certain ways than a monolithic architecture. Due to this complexity, we must use the Agile development method, and DevOps automation.
/getty_proofreading-184928153b-56afa02f3df78cf772c6cfb9.jpg)
