944 karma · joined February 12, 2011
[ my public key: https://keybase.io/niksko; my proof: https://keybase.io/niksko/sigs/4_K48wgjxKBXyJFpmjrvHFlKOAJVWwd3S-VbG3-S6Ng ]
Location: Vancouver, Canada
Remote: Yes
Willing to relocate: No
Technologies: Kubernetes, Istio,
Typescript, Golang, AWS, Terraform
Résumé/CV: https://resume.skouf.com
Email: n.skoufis@gmail.com
Hi, I'm an engineer with 7 years of experience looking for a new challenge. I've spent a lot of time in the Kubernetes space and am very comfortable with Kubernetes and adjacent tech (Istio, ArgoCD, Helm, Prometheus/Grafana), but I'm also a strong software engineer (TypeScript, Golang, Python). I've also done some work lately as a technical product manager on internal developer platforms. I'm a great writer and communicator, and I can lead and organize multiple teams toward a technical or non-technical goal.I'm open to a variety of work. I'm a quick learner and love picking up new tech, so as long as you're ok with giving me some gentle guidance on idioms and libraries I'm confident I can pick up whatever tech stack you need me to work on. I'm naturally very curious, and if you're working in an interesting industry with a great product that doesn't exploit its users, I'm eager to build something great with you. Above all, I'm looking for a company that has a strong purpose and values that match my own.
A note on remote: this is a hard requirement for me. The only exception might be a 'synchronized hybrid' where everyone is in the office on the same day(s), but that seems rare and you'd also need an office in Vancouver.
We haven't used _too many_ abstractions. We've merely leveraged abstractions in a way that makes a different tradeoff. A small number of abstractions trades off deep expertise for narrow perspective. A larger number of abstractions allows us to trade off a wider perspective for a shallower understanding.
Neither is wrong. Both are useful. Different situations will call for each.
That's basically what this is about. Aboriginal people have much less power and much worse outcomes. This referendum was proposing to give them a little bit more, in a pretty gentle, non-binding way. That was rejected.
In general, I've found that many many arguments about systemic inequality basically boil down to a fairly simple question: is it better to solve a problem slow and steady, or fast and (maybe) risky. Generally the people with more to lose, the people with more power, tend to say 'slow and steady is good enough for me'. The disadvantaged however would prefer a faster solution. Those with power often argue for slow and steady by saying 'the fast way is also risky'. That's basically what happened with this referendum. People voted for doing nothing over a measure which may have not done what it set out to do, but also may have helped.
I'm sorry to hear that, and that makes me worry about my future in this industry.
However
> If you can’t do that (I can’t), pick another occupation and keep the programming as a side gig thing because it’ll drive you insane and shave years off your life.
Won't this just apply to any career? Or do you think there's something unique about software that leads to this?
> Exploring other avenues such as bizdev
I don't think I fully understand what this entails, can you elaborate?
Question for the audience: are there places where it isn't like this? Can anyone attest to having worked in places like the one that the author describes, and then escaping to somewhere that isn't like that? If so, are you hiring? Or should I just be content with spending 2 or so years somewhere and then moving on? (2 years seems to be about the natural amount of time it takes for me to fully realize the dysfunction of wherever I'm currently employed)
* The author seems to be a bit older * The author drives an older car at home
As a younger person who drives an old car, I too had to spend some time reading the car manual to figure out how to adjust things like automated breaking and steering assist when I rented a new model Camry on a trip earlier this year. The Tesla likely has even more features, but the idea that you can just jump in to a brand new car and understand everything about how to use it seems far fetched.
Couple that with someone who is older and perhaps doesn't have as much intuition for digital user interfaces and you get what's in the article.
If neither of those things are true (i.e. your teams in India don't come in on the same days or come in sporadically, and your US teams have put in lots of effort to go remote with deliberateness) then I can't explain things.
Yes, all very moderate views in 2023
It's much easier to do prep work when you have a social safety net to keep you clothed, housed and fed while you're prepping.
It's much easier to place yourself in a situation where the opportunity can find you if you know that if opportunity doesn't find you, you'll be ok.
It's much easier to take a gamble that a bunch of hard work will lead to a fantastic opportunity if the cost of it not leading to an opportunity is very low.
Sure, but you iterate. We decided as a society that Polio was awful enough that we wanted to eradicate it. If we freed up enough effort that is currently wasted on chasing profits, we could eventually get to solving problems like "shit stinks and it sucks having to clean it".
I haven't, but I didn't say that shit didn't smell. My point was that one component of why some jobs are worse than others is social stigma. Working at a fish monger or in a butchers shop stinks, and you probably get way less PPE than a sewer cleaner would. But butchers and fishmongers have less social stigma.
> It's delusional to think every job that's undesirable but necessary could be automated and that it would be cheaper than ye olde good material compensation for doing something hard/unpleasant.
The fallacy here is that it _needs_ to be cheaper. Sewer cleaning is valuable. If it requires more investment to automate so that we have enough supply to meet the demand, so be it. The only reason we haven't already automated this smelly job is because it's easier to turn a profit if you just pay people peanuts. If profit is no longer motivating, you can make vastly different decisions.
Cleaning the sewers sounds objectionable. I think you shouldn't discount the idea that in a societal structure that's different from ours you'd remove some of the social stigma that comes from such a job. But at the same time, if you observed that very very few people wanted to clean sewers for whatever reason, and there wasn't enough supply to meet demand, then you invest more in technology that reduces the shortfall. As others suggested, automation.
OAM has a model of components (things like containerized workloads, databases, queues), traits (scaling behavior, ingress) and in the latest draft, policies that apply across the entire application (high availability, security policy).
It's all a little disjointed and seems to have lost steam. KubeVela is powering along, but it's the only implementation, and IMO it's highly opinionated about how you do deploys and works well for Alibaba and perhaps not for others. But it has some interesting ideas.
I agree with the author, a 'concepts' section is the big thing I find missing from the otherwise very useful 4 doc framework. This is also the most common addition that I see in open source projects, e.g. Istio and Kubernetes
I don't write as much as I would like, as you can see from the big gaps between posts. Some homelab stuff, a little Kubernetes, some food stuff as well.
EDIT: It has an obsidian plugin, though the last release was 2 years ago: https://github.com/deathau/cooklang-obsidian
In Melbourne, Australia, the local government that covers the downtown area and a few surrounding suburbs gives 2 votes to businesses and 1 vote to residents. Guess what kind of policy exists? Highly pro business, growing inequality for residents.