| Femme Fatale Studio |
|
| french creative studio, somewhere between sophistication and simplicity | |
| cube composer |
|
| Funny tiny game calling array manipulation logics. | |
| Managing Operations in Group Chat |
|
| (book) ChatOps can increase your operational efficiency. Learn how in this free 75 page report from O'Reilly and VictorOps. | |
| Essential Electron |
|
| Quickstart your electron skills. | |
| Itsy-bitsy-data-structures |
|
| All the things you didn't know you wanted to know about data structures | |
| Maintainers-wanted |
|
| List of projects looking for new lead maintainers, either abandoned or just looking for someone else to lead. | |
| Client_side_validations |
|
| Client Side Validations made easy for Ruby on Rails | |
| Vizceral |
|
| WebGL component for displaying animated traffic graphs | |
| Journey of a Trailblazer (1) |
aug 21
|
| Looking for some standards and conventions to refactor? | |
| About Sinatra 2.0 |
aug 22
|
| Just released in beta, here is the huge list of changes. | |
| Pure RSpec JSON API testing |
aug 22
|
| how to test JSON API in Ruby on Rails or in plain Ruby application with nothing more than RSpec 3.x | |
| The Pure Function As An Object (PFAAO) Pattern |
aug 23
|
| In this article, I want to demonstrate a nice way to write functional-style code in Ruby. | |
| 10 reasons why you should give Elm a try |
aug 23
|
| Totally subjective but convincing sales pitch for Elm. | |
| Hunting for great names in programming |
aug 23
|
| One of the real delights of programming is picking great variable, method, and class names. | |
| Phoenix vs Rails: Views and helpers |
aug 24
|
| Here's an overview, case study and comparison to Phoenix of the V part of Rails MVC as experienced across the years. | |
| Document your Already Existing APIs with Swagger |
aug 25
|
| Document APIs by editing a config file that is either json or yaml. | |
| The State Of JavaScript: Front-End Frameworks |
aug 25
|
| A few preliminary results from a survey by Sacha Grief. | |
| Building Rails API's with JSONAPI and JSONAPI-Resources |
aug 26
|
| JASONAPI is a fairly new protocol, but has been methodically designed to handle most use cases | |
| Using WebP Images |
aug 26
|
| WebP can yield a substantial reduction in the size of images on your website. | |
| From monolithics to microservices |
aug 27
|
| A software design approach to microservice evolution. | |
Earlier this week I read an article on linkedin, deliberately anti-remote, and a bit later on another one very pro-remote on freecodecamp. I'm tempted to think one is the response to the other. But maybe not.
The fact is that switching to a remote organization is a tricky move. It feels like the move from monolith to micro-services, honestly. People that make decisions about it rarely envision the extent of the change. And those change look similar in nature. Team architecture and software design are not that foreign. More autonomy for services or people, self-contained activity, requirement for clear communication channels and protocols, extensive architecture for monitoring, reporting or just plain visibility, more debugging tools and processes, and much more.
The same way one will have to think about all those when switching to microservices, the one that thinks about making his team remote will also have to consider the exact same parameters. But that is all on the principles. About the implementation, remote teams really need a strong chat culture, an easy and transparent logging policy for all communication channels, various tooling similar to chatops tools for assisting communication activity. Remote organization also need to have all their processes online, and not need much (if at all) any synchronous meetings.
From my perspective there are various very beneficial side-effects to make a team remote. There is more traceability as everything is online and not in corridors anymore. In some cases that I experienced, it also leads to a less arbitrary perception on team members, because they can be judged more on results (if you have measure tools prepared accordingly) than on attitude and mouth-skills (did you noticed that irl meetings are sometimes just a mouth-o-cracy?). But it's accurate to say that on a short term, it is more time consuming. The real benefit rises on the long run.
What I didn't find in any articles on the matter, is the life-cycle dimension. A software project has a life expectancy, from a business point of view. It's the same game as with the technical debt. It is acceptable business-wise to live at credit for a time, until a certain milestone. A lot of projects are just extended MVPs intended to convince big money that they could deserve some attention. For such project, you want very fast paced environment. It's easier to coerce your slaves employees to go above and beyond the expectations, when in a physical environment. This is a disposable context, and you can skip team debt as much as technical debt. And you really need physicality for that purpose.
So, I would say, if a company is not making the move towards remote organization, maybe there are very good reasons for that. But I will be very cautious to understand what are the real reasons. They may stink. And if they are remote, but they just came to it recently, I would be careful about the tooling they prepared for it.
