17 karma · joined October 16, 2019
My learning here: new is not new if the culture stays the same. Also: never underestimate the power of old. People always talk about the new, shiny stuff. But old was there first. And is much more resilient than it seems.
This is exactly the situation I´m currently in. Company decided to migrate from big on-prem kubernetes to AWS. Now every team got their own account and well... good luck, you´re on your own now. We´re a small team of three developers. Although we have three certifications under our belts (AWS Dev, CKA, CKAD) it took us almost three months to configure AWS and set up the Terraform pipeline and define processes like "upgrading cluster". The "enabling" part was basically missing in the whole cloud strategy of the company. It was more like: good luck, you´re on your own now.
In fact we made contact with a neighboring team. Only to find out that their use case was so different from ours that collaboration didn´t make any sense. For them Kubernetes was not a good fit, for us it was the way to go.
Speaking of sharing a cluster or AWS ressources: we figured out that it is not allowed due to billing reasons. Company policy is: One product per AWS account.
If you ask me I see a shift of paradigms happening here. Now you hear a lot about "enabling teams" instead a dedicated team for infrastructure providing services (e.g. the Kubernetes podcast from Google). I´m not convinced yet. I think this is more like kicking down responsibility down the chain. And then it feels more like: Someone needs to do the dirty work but nobody wants to do it.
It might work if you don´t have to provide Service-level agreements (in our case: we don´t). For us it is just more work to do. And our work shifts from dev to ops. Instead of writing software we´re mostly busy with configuring cloud resources. This will ease a bit once everything is running. However: I see this whole change more as ... uh, strong word... ideologically motivated. Cui bono? Neither our team, nor our users nor our infrastructure bill.
This. Booking a freelancer is a completely different game than hiring an employee. There are legal aspects here because big company A hires small service provider company B aka freelancer to do work. In my experience companies looking for freelancers need experts with very specialized skills on framework X or cloud provider Y.
Thank you for expressing that thought. However: I came quite to the opposite conclusion. I´m currently working in a small team with members that are not so versatile in coding, coming from a JavaScript background. It has been surprisingly easy to teach them Spring Boot. You follow a typical layout and everything falls into its place. I have my reservation that the same holds true for Go. It feels like there is much more room for confusion. Do I use global functions or receivers? How do I inject my dependencies and where do manage them? How do I build constructors and do I really need them? I found surprisingly little advice on those topics.
I just see a pattern in that story: Save your precious time. Use your resources in a better way. Be more efficent. Amass more resources (that could be personal fitness or wealth as well). Here the resource is knowledge. And they finally turned the quiet nerd realm of reading books in solitude into competition and sports.
Wondering what you do after year two when having read 400 books. Will you be able to recite what was in book number 42? And then what? You start a discussion with your coworkers about Plato or some obscure sociological theories? You could do that but this might not go anywhere (speaking of personal experience here).
I guess the idea is to speed read your way through as fast as possible to get the numbers right. So you can simply throw in some quotes like the article did with Orhan Pamuk. Why not ambling a bit and enjoying books instead?