I am an IT professional with more than 15 years of experience in writing amazing applications, executing challenging projects, and managing top performers teams.
I have a narrow blend of technical knowledge and management skills which allows me writing code every day without loosing track of the projects big picture
(This is a sample website - you’ll benpm building a site like this on our Next.js tutorial.)
Blog
- Growth Talent
We often find companies or teams reluctant to hiring growth talent (A.K.A Juniors or Trainees). Among the typical excuses, the most common ones are "the team has a very aggressive roadmap" and "the problems the team solves are too complex." Although these might be legit, I'm biased towards thinking that most of the times it's just management unable to working with different seniority or insecure about the ROI.
- When to Use Static Generation v.s. Server-side Rendering
- Two Forms of Pre-rendering
- Humans of the Digital Transformation
"Software is eating the world" sentenced Mark Andreessen on August 2011 on his famous essay published by The Wall Street Journal. He made references to a wide range of topics, from which I find this one particularly interesting: Virtually every company should become a software company. This concept has become a cliché, and I'm trying not to make it super extense, but providing some examples on how software companies are leading their (not software) industries (let's call their vertical industries for abbreviation).
- Team handoff document
I recently had to hand off the teams I had been managing for the last 2 years. Luckily, it’s because I was promoted and started running a new department that doesn’t include those teams. Thinking about the knowledge transfer to be made, I realized that I wouldn’t be able to track the tons of information to be transmitted if I didn’t make notes. This wasn’t just about what the teams had been doing, but also about what I had come to envision for them in the future. So, I spent a week collecting all the topics that came to mind in order to write a handoff document for each team, as a way to better organize the discussions around this process.
- Doing my part (this far)
Abuse against any minority is wrong. It has always been wrong but these days it is simply unacceptable. Do you see how simple that enunciate is? This is something we might all agree and yet, abuse is still there.
I am a white man in my 30s and it is hard for me to find my place in this fight. I am a child of the patriarchy and I'm sure I'm full of (sh)it. I'm also sure that I don't want to be part of the problem. I'm also sure that I want to be part o the solution.
- That's not our code
The first time I read about the "Conway's Law" was in the context of an excellent book: "Building Microservices" by Sam Newman. The law states that: "Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure".
- APIsAR Episode V - API Management with Azure
During an event that took place on May 3, 2017 in Buenos Aires, German Küber facilitated a presentation about API Management with Azure, the API Platform developed and commercialized by Microsoft.
- Owner vs. Victim theory and the pitfall of overusing it
If I already have your attention, let me tell you that this is not the place where you will find the meaning of the "Owner vs. Victim" theory which can be found in bazillions of different sources. It will be generally explained, though, since we are talking about it. This article is more about the pitfalls of people reading people and how misusing this theory could lead you to miss important communications.
- APIsAR Episode IV - Introduction to GraphQL
During an event that took place on November 9, 2016 in Buenos Aires, Horacio "Qcho" Gomez presented an introduction to GraphQL, the technology developed and used by facebook to build their own APIs.
- About predictability and clearly defining team goals
It's an Engineering Manager responsibility to guarantee the team health measured in terms of qualities such as performance, commitment, accountability and predictability (among lot of others). However this can't be forced by the Manager. It's actually the team effort and its proper channelling the decisive factors for achieving these goals. Because these are goals, aren't these?
- Acronyms seriously suck
While I was reading "Elon Musk", on a bus while commuting home, I couldn't help laughing of an email he sent to all SpaceX employees regarding to the misuse or excessive use of acronyms. The subject line was: "Acronyms Seriously Suck" (you can figure out the acronym for it by yourselves).
- A Compendium of Software Architects’ Pathologies
By Marcos Chicote, Guido de Caso, and Norberto Herz
Soon after the field of software architectures was formally born thanks to the work of Garlan, Shaw, Notkin and others in the early 90s, the role of the "Software Architect" emerged in the software development landscape. Following the definitions of the Software Architecture community, the architect's job is to define the high level design of a software system or, in other words, make the principal design decisions that build a bridge between requirements and implementation.
However, in practice things are not that simple, and the architect's job is full of pitfalls and contradictions. We describe what we call are five pathologies that can affect software architects, including symptoms and prognosis, with the goal of sparking more discussions about this role and its desired evolution. - Nobel 0.2 supports Swagger and RAML
Time ago, while I was working with the team building RAML, I took advantage of a hackathon to build the first version of Nobel. Briefly, Nobel is an application that uses an API high level definition written with (Swagger or RAML to generate the Arduino code implementing that API. That first version only supported RAML as the definition language. Recently working and researching a bit more about Swagger and its toolset, I was able to add support for this language as well.
- Docker in acción I
Several years ago, speaking of scalability used to bring up a series of surprises of all kind. People talking about scalability as a hardware quality, people getting too much surprised when listening that it's not the hardware just scaling, but the applications being written in such a way that can scale, and for sure, the little distinction between horizontal and vertical scaling.
Fortunately these days, the concept has been digested, explained, and apparently understood. However, I'm still curious about getting why this topic was source of so much confusion. I'm not sure which ones is the cause and which one the effect of this new era, but virtualization plays a starring role, and specially the containers based virtualization. This is the first of a three posts saga, in which I'll be covering some scalability fundamentals, DevOps rol/culture, Docker introduction, installation walkthrough, first steps, and docker registry configuration. This first post is about DevOps and scalability. - From API to Streaming API
There are so many pros on building an API that exposes our application resources. It's particularly important to achieve reducing tiers coupling to the minimum, but even better, this allows different applications to access our resources. For well designed APIs this will also happen in an intuitive way.
But even the best APIs could be implemented in a way that the client needs to make a call every time it needs to know the state of a resource. For this case, the API will have to return the entire resource every time it's requested.
But, wouldn't it be more efficient if the API only returned what has changed since the last time it was queried? And wouldn't it be even more efficient if the client didn't need to call the API to check if something changed?
Streaming APIs (when implemented properly) try to solve exactly that. On this post we will see how these could be implemented and how streamdata.io works in order to turn a traditional API into a Streaming API. - Expressive code in Javascript
There are many (maybe too many) aspects to take care of when writing a piece of code: performance, maintainability and readability, for mentioning a few of them.
One aspect I find particularly interesting is "expressiveness" which means "the ability of enunciate what is being done".Since I am a Javascript Hipster ("I loved it before it was catching on") I would like to show some examples of how Javascript lets us be really expressive working with arrays (and some particular functions): forEach, filter, map, reduce, every and some.
- Moving to GitHub Pages
With this (not that) recent desires of writing at ourBit again, I realized that the tools provided by blogger by Google were not good enough or didn't fulfill requirements that, in my opinion, should be provided by a blogging platform out of the box
- SPAM - Real case
Those who understand about technology (and maybe a little more than "understand"), are used to warning, explaining, or scolding our friends and family about misusing the e-mail. There is a particular concept that is usually disregarded despite of being a simple one (mostly because of lack of knowledge or attention. It could happens to anyone).