I remember being on a team where I'd frequently point out that the tests were not only flaky, but useless. I suggested that we delete the useless & redundant tests and either fix or delete the flaky ones.
That suggestion was met with not only resistance, but almost hatred. I think some of them got way too attached to these tests and could no longer see the forest for the tress.
> I don't understand why you'd do pair programming with two new hires!
There's nothing wrong with two new hires pairing. A few things a pair could be doing while the other is writing code:
1. Spike out a refactor of the current viewable block of code that the other pair just wrote or is currently writing. Looking at it as a spike instead of a hard refactor allows a pair partner to experiment and if the spike doesn't result in something better, throw it away; no harm done.
2. Jump ahead and spike out a function that the pair might need soon, but isn't ready to consume yet.
3. Watch for pair getting stuck and help them think. Ask questions like ... are you stuck or just taking a mental break? That's a helpful question because it makes them more comfortable taking mental breaks when they need one without fear that you're judging them.
Keep in mind, pairing is AMAZING when deployed with empathy and less judgement. For those that feel like they are being judged when pairing is likely because you are a bit judgmental when the shoe is on the other foot.
FYI, teams that pair daily, get more done and team members feel less lonely and more like a real team. Go Warriors.
Happy birthday HN. I absolutely love this community. Once I started reading HN somewhat frequently, there is no question that I became a better developer, thinker, researcher, and writer. The topics shared here seem to have no rival anywhere else on the internet ... at least, not as far as I am aware of.
I think this is a good time to admit that when I first came here, I was a bit shy to post anything about tech or programming, but by hanging out here and practicing what I learned here, I eventually felt worthy of contributing.
I'm just surprised people are more outraged that Spotify complied with the artist's request vs being outraged by Spotify's horribly cluttered (and confusing) UI.
I've been fortunate enough to have worked across pretty much every portion of the stack with the exception of hardware or core networking protocols. Everywhere else, I have experience and am comfortable.
Yes, you are definitely going to be trading for more stress and it is highly possible that it will be less fun, but that's not necessarily guaranteed especially if you land in the right role, right dev culture, and right leadership; however, that's a lot of things that have to go right, which, it almost never does.
I started with database admin, then sysadmin, then dev. Sysadmin is more fun and the people and environment are generally more fun; however, dev is more fun to understand depending on what you want to do with the knowledge gained. If you plan to build something in tech, you want to use this opportunity learn to be an effective developer.
That being said, if you don't care about that, then, maybe the stress isn't worth it. I personally now value having time to myself. That's really hard to do as a dev because whether you like it or not, you are carrying those hard problems around with you all day, every day, until they are solved. It's like a weight being placed on your chest from the moment you wake up, until you crawl into bed from your work desk.
Like all things in this industry, YMMV and you'll have to weight the pros and cons.
What the entire recruiting industry (this isn't unique to recruiting industry) fails to understand is, if the process isn't time optimal and fair, then engineers will eventually learn the nuances of the industry and build something more automated, time optimal, and fair. If you've been an engineer for more than a few years and have been paying attention, you probably already know this.
