cbushko

If you have a datacenter of your own and several VMs, redis would be fine as a persistent store. I wouldn't do it but it would be fine.

If you are in the cloud and have any hint of using kubernetes then DO NOT USE redis as a persistent store. The problem is that redis' master/slave and replication pattern goes against the load balancing and Service objects of kubernetes. Redis was created in a time when it expected physical nodes to be available 24/7 and is not designed for nodes to go away. It can handle it but it isn't designed for it. Two different things.

Redis as a single pod and a cache works great. I would never use redis as a DB. We have DBs specifically designed to be DBs.

When you are old, everyone looks young. =)

I see 35 year olds and think "that guy is just a kid"!

I do the following:

- read, read, read about the topic at hand. I find that finding a good book on the topic gives me a baseline of information even if I do not understand or retain it all.

- use the information. Play and build what I am learning about.

- as I work through day to day issues and find things I will probably need in the future, I save them as a page in a zettlekasten using vimwiki. Writing these things down is new for me and it has already paid off when answering questions.

As an add-on to protecting your time. I will help just about anyone that needs help but be wary of people that send you direct slack messages.

Often they are messaging you directly because they are stuck. That is fine as we all get stuck sometimes. If they directly message you often they:

  - are lacking the skills/time/training to do their job. Been there.
  - are under pressure to get results quickly. Been there too.
  - are lacking the people/resources on their team to get results. Yup, been there too.
  - more horribly, they are taking credit for your knowledge and using you to get ahead. This has happened to me and I was pissed.

You have to break out of this cycle.

  - In your standups/scrums/reporting, make it very well known that you 'spent X hours helping Y with Z'. You do not want to get in trouble for missing deadlines because you were helping someone else. You also want to be known as a helper/fixer because those are useful to teams.
  - Move the chats from direct messages to private channels. You need to let others know what is going on and more importantly you need to spread the knowledge that you are an expert of.
  - Moving to a channel also publicly sells your skills and knowledge to a wider audience.
  - Moving to a channel lets all managers know that something is lacking somewhere. Either their team doesn't have enough training, people or docs to get the jobs done.
  - Start writing documentation or updating the current docs. There is a gap somewhere in the docs if your knowledge is directly needed. Even 2 paragraph FAQs are useful to everyone. Having a doc will save you time in the future as you can just point people to it.

Note: Always give credit where credit is due. If someone helps you out, let the world know how awesome they are. This will help you out in the long run because you will be known as someone that is humble, human and a growing.

edit: the formatting is always terrible for me

"Effort Asymmetry". That is a fantastic phrase and is so true.

I've been the 'fixer' in so many situations and I have a tactic for this. I ask them for the following things:

  - a ticket to track the work
  - that they get approval from my manager to drop all of the work that I am currently doing and affect other peoples timelines
  - that they document the problem and how they want it fixed
  - that they get approval for the extra hours required

You'd be amazed at how many "critical" issues disappear when you ask for these things. I personally think it is only critical because someone wants to dump the problem on you so that they can go home to their families.

I feel your pain and I have been/am in your shoes.

Unfortunately, you will not get the kudos for things you build unless you spend time selling those projects. I personally hate this as I want to spend my energy on building things that make a difference.

I think speaking up is fine. It is when ANY engineer is lazy and doesn't bother to:

  a) do any research before asking the question, 
  b) trying to understand the answer given or 
  c) doesn't follow the answer given.

I will help anyone that asks but if they are just using me for quick answers and never learning anything then eventually they will use up their credits with me. I cannot do their job and mine at the same time...

> So I proposed this to my manager, and he responded: we tracked all bugs in our system for the last 10 years, and when you look at fixed bugs that get broken again, it only occurred very rarely. So in the end, doing that was not the best investment of effort.

That sounds very hand wavy.

It is making the assumption that:

  - your bug tracking system and people are so good that they have found all the duplicate tickets.  
  - they don't make mistakes and find all duplicates for tickets. 
  - your code is so good that it hasn't had any side effects that caused regressions. 
  - your boss is so good that he has a full grasp on 10 years worth of bugs.

edit: formatting

You just sparked the thought in my head about how much has the pandemic changed this?

With myself working from home and my kids being virtual that they have been to see what my day to day is like.

I think they realize that I have too many meetings and how much it stops me from getting real/deep work done..

I found that this starts to change as the kids get older. Mine are 8 and 11. They become a lot more independent and it frees up 15 minutes here and there.

I ran Jenkins at 2 companies for probably a total of 13 years.

I will do everything in my lower to never use it again as I feel that I wasted so much time fighting it.

Plugins, dependency hell, slow UI and so many other terrible things about it. Having to back the entire thing up on every change because you may never get it back into a usable state if you change something. That even happens if you have scripts in git to set the whole thing up. What a waste of time.

In contrast, I had just as good of a system running in Gitlab in a week and more importantly the other developers are able to pick it up and extend as they wish.

- I think VSCode is a great piece of software until my it starts using most of my laptops resources and my fan kicks in.

- I do a lot of work in a terminal. VSCodes terminal support is pretty bad. It might be better when they get nicer terminal tab support (not what they recently added)

- vim + terminal is considerably lighter and faster

I recall two things that people complained about with the Mac support

- the USB-C charging was terrible because if you turn off the monitor it stops charging the laptop. I believe the same happens when the monitor sleeps. There is also this weird connectivity issue that happens if the mac with USB-C goes to sleep and the monitor is in use with another port. It keeps detecting/undetecting the USB-C port. I think it basically comes down to a lack of consistent power connection from the monitor to USB-C port. I knew about this problem and I just make sure my mac has a power brick plugged in.

- the 2nd problem was that their isn't any Dell software for mac which means that all settings and switching is done through the buttons. Luckily, someone hacked this together.

https://github.com/kfix/ddcctl

Overall, the monitor is absolutely fantastic and I would buy it again. I spent at least 40 hours researching monitors and looking for a high resolution (4kish), 32" or larger, IPS monitor. Everything else was either super expensive, out of stock/no longer made or had major problems.

I bought the 34" curved Dell monitor (U3419W) with the KVM switch built in and I am very happy with it.

Dell's Mac support is pretty bad but being able to hook 3 computers upto the monitor works very well. I use usb-c, HDMI and display port.

I found a command line tool for mac that sends the correct command codes to the monitor to make it even easy to switch machines. My one laptop has the touchbar and it is easy to add buttons to it for monitor switching.

So basically you never have to mop your hardwood floors ever again?

For anyone that is balding but wants to keep their hair very short, I have been rotating between 2 Panasonic wet/dry beard trimmers for the last 10 years.

It is wireless, adjustable and I shave my head in the shower.

I have this older model and it is great but I do not know about the newer versions.

https://shop.panasonic.com/personal-care/mens-shavers-and-gr...

Background: I worked at a very toxic startup that was run like a high-school where there was a lot of drama, backstabbing and everyone was trying to be the cool/popular kid. I learned a tonne there, especially about the type of person I don't want to be...

Best: Focus on the project and making it good. If you are correct in your ideas then good. If you are wrong but the project is better then good, everyone wins.

Worst: "perception is reality", coming from a COO that had no idea about technology and what people do but they were second in command and making a lot of decisions.

It taught me that you have to play the game and sell your accomplishments so that upper management sees you. You do not have to market yourself but do not complain about not getting credit for the amazing things you do if you do not sell yourself.

The book content is basically on their website: https://threedots.tech/series/modern-business-software-in-go...

A heads up, the book is essential the content of their website:

https://threedots.tech/series/modern-business-software-in-go...

I am using GKE, buckets, cloud SQL, pubsub and IAM, big query.

Our costs are 1/3rd of what AWS was.

Their support isn't as good as AWS.

I use terraform for everything and Google authors that provider and I find that their resources are very consistent.

IAM is a bit of a mess but at least it is a consistent mess.

I've done about 6 requests for increased over the last 2 years and all have been accepted. All I had to do was giveca valid business case like:

"We are setting up more customer environments and are running out of X"

It was usually increased within the hour.

I would think a vehicle is a better analogy.

This car has tires, you create, delete and patch them. It also has an axels, gas tank, etc.

This truck has tires, axels, has tank

This motorcycle has tires, axels, etc

To me it looks like they mostly contribute to projects that are SDKs to use AWS.

The fire is 1/3 of the cost of the frying pan.

This resonates with me so much as I was in this position 3 years ago.

My boss came to me and said "we want to move from AWS to GCP, using kubernetes and not have it be a mess like we have now"

I was new, senior, free from ownership. I chose to stay as a team of 1 so that I wasn't burdened with fires and meetings. It freed me up to put my head down and get the work done.

The grind was learning GCP, kubernetes, terraform, the platform/product, gathering requirements from several teams and mentoring people that would pop into the project as their time allowed.

I won't lie as learning new things was great. The project was partially greenfield as it was a platform migration and not a product rewrite. There were a lot of constraints & debt to deal with.

Maybe the new employee churn is one of the reasons that most startups get so much done... the new people are not burdened by ownership and being the subject matter experts. They are free to do things, good or bad. :)

For me, using Kubernetes is all about the patterns that it provides and how it removes a certain class of problems for you.

Deployments, scaling, logging, etc are some of the patterns it provides and the consistency matters. How many of us have worked at companies where deploying two services have been completely different? One team runs the jenkins pipeline while another team FTPS the files over. Now multiply that by several services and several tasks (logging, scaling, etc).

The benefit is in the patterns and standards it provides.

I only have one thing to point out about Borg and that is large numbers of Borg developers started working on Kubernetes. They got rid of Borg mistakes and replaced them with all new mistakes. :)

I don't see K8S being about lock-in at all. Using a cloud provider gives you some sort of lock-in and you should be utilizing that providers strengths.

Using Kubernetes is all about the patterns that it provides and how it removes a certain class of problems for you. Deployments, scaling, logging, etc are some of the patterns it provides and the consistency matters. How many of us have worked at companies where deploying two services have been completely different? One team runs the jenkins pipeline while another ftps the files over. Now multiply that by several services and several tasks (logging, scaling, etc).

The benefit is in the patterns.

That's fair. As I pointed out in another reply, most of my experience is with GKE so I may be spoiled in how painless it is. All I can say is that GKE is treating me well. Node upgrades are seemless, defaults are decent, it was very easy to create clusters through the console or terraform. I only run 5 clusters and that is not that huge compared to others.

I've used ECS more than fargate. My biggest problem comes from reliability and having to manage things. We still run things on ECS and we get about 30x as many maintenance things we need to do, like retiring instances or instances just dying on us and we have to move things off of it manually.

I have a little bit of experience in Fargate from a previous job but not enough to make a real conclusion about it.

I've never used EKS but I do have friends that would rather roll their own version of Kubernetes on EC2 instance instead of using EKS.

Interestingly, we don't have any of these problems with MySQL. We have several read-replicas on our DBs and things have been stable.

I will guess that you are much higher scale than us.