The reason you “git blame”
I’m really good at searching Google. I’m a “prompt engineer” too
Did it work? How do you know that? A consumer of your package sends a int when your package expects a string.
Bluesky is still in beta. It’s intentionally not open to the general public because federation hasn’t yet been opened up and they only have one instance running.
The nice thing about Bluesky’s architecture (over ActivityPub) is the fact your content and identity is portable. So you can move over to a different instance as they start to come online.
I think the important takeaway from articles like this is the fundamental misunderstanding of decentralized social protocols. It shouldn’t be on one central authority how things are moderated globally. These kinds of articles kind of prove the point.
Nothing wrong with Java or JVM based languages. They’re just not the shiny new thing anymore.
I don’t know what kind of software you write at your company. It could be that the JVM was a poor fit for the stuff you do and Rust is far more suited. Or it could just be someone in leadership read a blog post where some company migrated from Java to Rust and saw a billion percent perf increase despite their use case being specific and not at all applicable to what you do and decided to decree that everything gets ported to Rust… or any dozen of reasons in-between
Plus it has a large library of great games that can be found cheap/used. Easily worth $100
Most of what you’d be playing on PS5 are PS4 games anyway
Buy the cheapest MacBook model you can find with an M-series chip and as much RAM as you can stomach the cost for.
I’d say 8gb is barrrrre minimum for doing app development. You’ll want 16gb.
Listen, I’m the last person you’d expect to recommend a Mac. I am an Android guy. No other Apple products in my place.
…but I’ve owned every top end model from pretty much every relevant PC manufacturer just trying to find something as reliable, hassle free, and well built as my work Mac and it just doesn’t exist.
The MacBooks are just in a whole other class. The battery life, the standby time, the speed of those M1/2 chips, runs cool and quiet.
I’m neutral on MacOS. It tends to stay out of my way. I don’t use any of the Apple apps. It is usually stable as hell. My work MBP currently has an up time of 68 days without a reboot, and the only reason it rebooted last time was for security patches.
Build quality is unmatched, screen is great, trackpad is still a generation ahead of anything else, keyboard is great.
I accept my fate, Fediverse. Roast away
Depends on what you mean by miscellaneous.
Are we talking about things my team calls “chores”? Things like upgrade some dependencies, or fix something annoying about the DX or build, look into that new library the team’s been talking about maybe using to replace some jank part of the app?
If so, we have an epic we simply name “chores”. We stack the backlog of chores based on priority and we attempt to get at least one done a sprint.
It’s not critical stuff. It’s not blocking anything (yet). It’s just housekeeping and maintenance stuff that doesn’t fit into regularly planned and scheduled deliverables.
Whenever someone says something like “man, our version of Node is super old. We should really look into getting onto at least the current LTS”. That’s when you say “Add it to the chores!” so you all don’t forget about it.
I actually winced
Tip 1: Assuming you are starting work at a company that has a healthy culture, do not be afraid to ask for help! There’s a lot to learn and it’s going to take time to get up to speed. Don’t freak out because you aren’t slinging PRs like the rest of the team after a week.
However when asking for help, you should open with what you’ve done already to help yourself. It’s important to respect your peer’s time, so trying to optimize for efficiency and help them help you as much as possible.
Part of this is also not spinning your wheels and struggling for so long that they need to spend a ton of time helping digging you out of the hole you dug for yourself.
Tip 2: Next is it’s important to pay it forward. Docs are super outdated and you got more current knowledge from a braindump from a more experienced engineer? UPDATE THE DOCS!
Tip 3: Once you find your footing, and ship some projects and get a feel for things, it’s important to find your voice. If your most Senior engineer on the team proposes something, don’t just follow it blindly. If you see a blind spot in the approach, please raise it! Ask questions!
Truly great senior engineers hate it when the team just rolls over and blindly accepts their proposals/architecture. They want feedback! No one is perfect or sees everything. They want the team’s help to stress test the approach.
Tip 4: Make sure you keep an open dialog about expectations with your manager. Never assume your manager knows how you spend your time every moment of every day. Ensure you give your manager visibility into your “invisible work”.
Examples of invisible work would be taking time to help a new hire. Having conversations with people on another team you depend on or who depends on you to come to consensus on an approach that is beneficial to both teams. Or something like updating documentation or spending time in meetings to review engineering designs, collaborating with product and designers, etc etc etc
Tip 5: Don’t be a dick. Avoid being super defensive and assuming others are out to get you, embarrass you, or generally are operating in bad faith until they prove otherwise.
Tip 6: Respect what came before. You’ll surely come across some seriously jank code, or a ton of tech debt, or poor approaches. Due to business needs of the time, crunch time, lack of resources, etc are often reasons people did what they did. They very likely know certain things are bad. Calling out bad code or architecture isn’t impressing anyone. They know.
When identifying these things, start by asking for context. Come with solutions that are attainable. Calling out things without fresh ideas on how to solve these known problems is not helpful and a waste of everyone’s time. Focus on approaches for how to fit fixing the problems into your team’s resourcing.
Tip 7: Learn to communicate in a way that resonates with your audience. Try to understand their motivations and what matters to them. Saying that something sucks and we should rebuild in your preferred tech is not an argument. What’s the value? How long would it take? What are the trade offs? How does doing this work achieve the businesses’ goals?