Virtual monkeys in charge of the zoo
Don’t want to sound picky but I see that a lot of bad decisions were made at the factory last year.
I’m a software developer and I’m gonna put on the geek glasses and throw a couple comments. I’ll try to be as destructive as I can
I’ll write first about some technicalities and mistakes regarding:
- devops hell
- Testing and environments
And I’ll end up with some comments about:
- Steve Jobs wannabes
- open mode, and creativity to solve problems
- shedding light
Let’s do it!
no GIT experience
Please rebase always and only merge when you have a public branch (a branch that can be accessed by others in the team). I always reference Linus T. in this classic mail chain. I feel proud when I share the link, it denotes geekiness.
The extended use of git plugins in your editor won’t make you learn or understand more git. experienced git users use terminal and there is a reason for it.
The main one is that it looks badass.
The second one is that we’re afraid of using the mouse.
The third one and less important is that we have more control.
When I started using GPS I thought I would learn new routes, but they don’t stick
start using the terminal, don’t be a lazy mofo
Use a GIT strategy. Don’t reinvent the wheel
My father says that everything in music is invented. Everything sounds as a Beatle’s song.
Some developers didn’t have the chance to learn the how and why of these because of a dev ops team was in charge of making this decisions. Try to understand git flow first.
CICD madness with microservices
Hold yo bear!
the obscure and dark realm of devops again! You should really talk to somebody that knows what are the best practices or at least be open minded with what others have to say about this. Then you can go to therapy and/or get 3 month unpaid vacation.
Bad strategies affect everyone in your team. You can make a real mess when going to production or publishing a new version of your app.
A typical problem when developing cloud architectures is what to test against what?
Should I test against a development environment, should I test against a pre production environment?
If you want to test against a development enviroment take this into account:
- Can you replicate your stack locally?
- Is it reliable?
“it’s complicated”, like my relationship with avocados
Well, “it’s complicated”…oh man… prepare to sweat bullets with this one. It can get really “it’s complicated” when you add more components to the scheme and zero OS friends published a solution.
Pre production env
If you want to test against a pre production enviroment take this into account:
- A single staging environment is not enough
Usually I see complicated, high maintenance, blocking local environments and a single staging environment, but let me elaborate…
Cloud applications can use a lot of microservices, that indicates that inter-relations between those are of extreme importance.
If you don’t let developers have their own temporal environment before integrating new code, you’re committing a mistake. A single environment being overwritten and crashed again and again by each PR is the cringiest and inefficient thing EVA.
A Solution to this involves fast deployments and fast environment removal. You’re stack should be able to be replicated in the cloud pretty easily but also be deleted with ease as well. That is why we use infrastructure as code, and it is not just a fancy term!
Yeah pyramid of testing and… (dies of boredom)
Unit tests are good but you don’t have to unit test everything. If you encounter yourself using mocks in unit tests, well, you suck, but it’s ok, I sucked too my man! there is a way out!
you don’t have to unit test everything. 100% coverage is, well, stupid
Your unit tests have to be clean and simple, and how do you do that? well, using pure functions in your code. You test those functions like there is no tomorrow. It will change your life.
The pyramid is an ok concept for most of your testing strategy, but with microservices architectures nowadays it changes a lot. Now we have scattered programs talking and being alive in the Matrix, like multiple agents Smith. It means that we need more integration tests than ever. It gets out of control quickly. The pyramid doesn’t look like a pyramid anymore. It looks like a day without bread, awful.
Be in open mode
One of the things that I see more and more in the industry is fucking inexperienced big children being arrogant, touchy and defensive. That behaviour only projects insecurity and it poisons the entire company with a cloud of inaccuracy, finger pointing culture, mistrust and “prone to fail process”.
A poser never makes up his mind
Society, capitalism make these kind of monsters. The easy path they take is to make the arrogant pose and luckily everybody will think that a phenomenon entered the room.
I can see you
Cruel leaders are replaced only to have new leaders turn cruel. Che Guevara
They are monsters, I’ve known some. They have been taught to do that, to be manipulative, to take things before anybody else, to be aggressive. They usually study people like Steve Jobs and their hero Elon Musk. Beware of the dog, take precaution. They are in the “close mode” most of the time.
Don’t be that person. End the manipulation and the condescension. Be kind towards others, and turn on the open mode. We need creativity and sensitive people that can listen to solve the toughest problems, not people that look like a rethought of Margaret Thatcher.
It’s not the 80’s anymore yo!
Shedding light in the darkness
Life’s not easy but I worked with people last year that chose the hard way: to be truthful to themselves, honest and kind.
I met a lad that didn’t pass an interview I had with him and came back later with some homework done. Nicely done man!
I worked with a person that “endures unto the end” and treats people with utmost respect. He has a senior level position.
I worked with people that just “do their job” and I couldn’t ask more of them because that is just fine.
Shedding light in the darkness does not pay off often, I know, but that is what we need, in life, at work.
beings of light.