This is a weekly newsletter on the Software as a Service world. Learning, building, and shipping. Written by Ethan Mick.
Starting anything new is both exhilarating and daunting. There is so much promise and uncertainty, a tantalizing promise of what might be and if you will be able to achieve it. Only one way to find out.
The Best Bits
- Kagi is a paid search engine that is better than Google. They now offer unlimited searches for $10 a month.
- ChatGPT can now understand images, listen, and speak. Integrate this with your SaaS for impressive features.
- Postgres can be used as a queue (Like SQS, Kafka, or RabbitMQ). And it's not even bad at it!
- Subdomain Center, A SaaS that finds all the subdomains of a given domain.
How I learn when joining a new team
I recently started a new contract with a midsized software company. This company makes over $100 million a year in software revenue and has a large (200-ish) software development team.
My job is to help them increase their observability throughout their infrastructure and application stacks.
It's taken me about 24 hours (spread over 4 days) to understand everything I need to understand to accomplish that job. I've worked about 6 hours a day.
At this point, I understand:
- How they organize their projects, write feature requests, review pull requests, and organize their Git projects.
- How their build pipeline works, where the shared libraries are, and where they store build artifacts.
- What their infrastructure looks like, how it functions, how data flows in and out of the apps.
- How the apps function, what they do, how they do it, and how the company makes money.
- How they observe, monitor, fix issues, run their DevOps, handle rotations, pagers, and where the team responsibilities are.
- Lots of nitty-gritty details on the GitOps flow, software used, packages, and politics.
It's a lot.
Here's my strategy for joining a new team and getting up to speed quickly.
- When you show up on day 1, you've already been hired. You've been vetted. You've gone through the challenging interview process. No one wants to see you fail. Everyone is on your side. You need to leave the mentality of "Oh my god, what if people don't like me or think I'm good" behind and step into the mentality of "I've been hired to do a job and do it well. Help me get there as quickly as possible." Mindset is everything.
- Start with what you know. It doesn't matter if you are a junior developer or a senior architect. Every place does things differently, but there are lots of commonalities. Start there. Find the things you know and start branching out from there. For me, I know how infrastructures and apps work. What I didn't know was how exactly this company applied those techniques.
- Ask questions. Say upfront, "I'm going to ask a million questions." And then ask a million questions. Be smart about what you are asking. If it's something you can Google, do that. If you can ask ChatGPT what something is, do that. Don't drop proprietary code or data into ChatGPT if it's against company policies. But you can ask how things work generally or remove data to make a question more general.
- When learning something new, bring it back to what you know. I've used ArgoCD a lot for Kubernetes continuous deployments. This company uses FluxCD instead. I specifically asked ChatGPT to compare and contrast those two things and give full examples of how both work end-to-end. I read the docs on Flux and set up an example app that's deployed with it. I now feel comfortable enough to know how it works. But I started from what I already knew.
- Learn the stack, either bottom-up (infrastructure first, then application layer) or top-down (how do the apps work, how do they communicate, how do they run?). Depending on your skill set, you will be happier starting at the top or bottom of the stack. As an architect, I like going bottom-up. Show me the infrastructure because that defines what can communicate and how they do so. Then tell me what the apps do. At the same time, I talk to the product organization to learn how the company makes money and builds a product so when I get to the code, I can check... is this really doing the right thing?
- To learn all these, ask who can give you brain dumps via meetings and schedule as many as you need. Drop a meeting on their calendar, ask important questions you can't learn from Googling/ChatGPT, and understand the pain points. At the end of each meeting, I like to ask, "What am I not asking? What do you have on your mind that I might not know about?" It helps uncover my blind spots and leads me to new things to investigate.
That's how I've onboarded to a new company and team in 24 working hours. I'll be starting to work on the implementation in the next day, knowing how the product works at a high and low level.
A common setup in AWS is to have roles with elevated permission that a user assumes when they need to take an action. Assuming this role, especially when protected with MFA, is... annoying.
Luckily, AWS Vault is a great command line tool that lets you assume a role on the command line so you can execute commands with it. You need to set your AWS profile configuration to have the role you want to assume:
[default] region = us-east-1 [profile admin] mfa_serial = arn:aws:iam::111111111111:mfa/admin
And then you can run the following:
aws-vault exec admin -- aws s3 ls
- YouTube Subscribers: 3,945 (+166 in the last 7 days)
- Newsletter Members: 730 (+34 in the last 7 days)
This week, I've been super busy onboarding at my new contract, and my kid was sick for a few days, which took a lot out of me. I'm hoping to get a video up soon, though, so stay tuned.
I played around a little bit with ChatGPT's image recognition, and it's... quite impressive. It was able to read a receipt and transcribe it perfectly. Lots of fun opportunities for building around this new tech.