You know the saying A players hire other As but B players hire Cs? Sometimes I feel like I’m surrounded by B and C players. Curious what things your eng coworkers do that annoy you and make you think they not A players, despite the real/perceived hiring bar at your company.
Here is an example: “senior” developers who refuse to write API docs or integration tests.
- Instacart / EngNot!ElliotmoreMain annoyance is senior engineers who determine themselves to be A players. The other part is engineers that hack not architect and think clearly through solutions (that might just be my antiquated way of building software)
- I don't think it's as simple as A, B, C etc even when accounting for experience level. Everyone has different skills and strengths.
More to the point, how does one draw a boundary between A and B, B and C etc.? It seems that you are trying to make a black and white comparison out of something that isn't one. Performance is hard to measure, and inherently somewhat subjective.
That said, I have seen less competent managers prefer to work with people who will make them (ostensibly) look good by being less skilled than they are in every area. A competent manager welcomes working with people of any skill level, including those who may be more skilled in some or all areas.
- "Integration tests are horrible to maintain and old school, the new hotness is healthchecks and testing in prod."
Please post a link to evidence. This is the first time I've read it and have no reason to believe it.
I can see the potential benefit of integration tests that run hourly against prod instead of for each PR branch. That said, in a huge engineering org with rapidly changing code, it's dangerous. Much safer in a small engineering org
- I'm not giving you evidence because you aren't paying me so eat a 🍆
Healthchecks: moving your integration tests into the live codebase so that you can continuously test and your infra can respond as soon as there's an issue ie. db conn fails, api contract mismatch, etc. This is even built into docker now.
Testing in Prod: really good instrumentation allowing pushing to prod even without tests but doing a blue/green or immutable deploy so you can rollback automatically if anything looks sus without affecting a noticeable amount of users.
- Facebook doesn't even write unit tests.
Sorry to burst your bubble but don't think it's going to be much better elsewhere.
Just focus on what you're doing and don't feel bound to your peers or company.
Btw. integration tests are horrible to maintain and old school, the new hotness is healthchecks and testing in prod.
I also want to add "game recognise game". You might be inexperienced and those Bs and Cs are actually onto something and you just don't understand. Do you know what an A looks like? Because docs and integration testing are outdated af.