Some large unions have been corrupted, but that doesn't mean conceptually unions are bad. This is a great example, where UPS deliberately sought out a bad union for its employees to stifle more progressive organizing: https://isreview.org/issues/58/rev-ups.shtml
Thanks! This whole discussion has definitely made me focus on #1 and helped with my imposter syndrome.
I think #2 is probably too 3D chess for an org this small and flat. It really seems like this is just the culture and maybe it works for some people? I'm not a man so I'm kind of excluded by default as well.
#3 is definitely the big question - I don't think toiling away is going to earn respect, but it will get me a paycheque. It's funny that people on here seem to think getting assigned shitty tasks will make people think you're a rockstar instead of, you know, the person who does all the shitty tasks. In my experience that kind of reputation is self-perpetuating and, as you say in #2, not really recognized or promotable.
I said this in another thread but I've been in the industry for 10 years. I don't expect to come in and rearchitect things on day 1, but I expect the tasks to be meaningful. The stuff I'm working on isn't an on-ramp to bigger tasks or being better integrated with the rest of the team, it's a silo that nobody wants to touch.
If your perspective is that onboarding is basically hazing people have to do to fit in at your company, I think that's pretty messed up. The best places I worked at tried to get people to ship meaningful features that would have an impact quickly.
There are multiple silos of this where I work, not necessarily because nobody wants to touch it, but because we just don't have enough people.
I've picked one of them up and my teammate now come to me for advice when they deal with this silo of stuff.
Don't underestimate the small things, unless they're things that does not need to be done, in which case you need to raise this at planning and explain how they are not necessary to waste effort on, and bury them forever.
I've been kind of deliberately vague, but after a couple months it isn't like I'm an expert on the area of the codebase now and other people come to me for advice. Other team members actively dodge working on this silo and everything just gets deflected to me. It doesn't feel like being a respected person who has experience with an area of the codebase, it just feels like shit rolling downhill.
Not neccessarily hazing, but it's only natural that you won't be able to, on day 1, co-design the big refactor or switching from platform A to B or a big feature which touches existing code in very many places. Instead, you'll be given smallerand well defined tasks (which often means that they're boring) that will allow you to familiarize yourself with the codebase, the process, the team members etc.
Ideally it would round-robin across the team or have a dedicated team with more than one person. Having only one person know a particular part of the codebase is bad for bus factor and reduces the ability of the team to review code.
Ironically I'm a "implementation is 9/10ths of the law" believer, the proposals were PRs and working demos. Despite being a small start-up the team is not really into iterative development so much as lots of up-front planning and theory followed by big polished PRs.
I agree if I'm going to succeed I'll need to change my approach. I usually learn by doing and experimenting but it's tough to make incremental changes here to understand the codebase better
Wow. That's tough. If a working demo doesn't convince them, I'm not sure what will. "See this? Do you want this?" is a pretty simple question. Do they need more evidence of unit- and integration testing? Do they need some/more user feedback before proceeding?
Remember, some people don't listen to reason, some of your wise seed will fall on rocky ground, and don't try to teach a pig to sing. I'll stop now :-) Best of luck again.
It's mostly code quality / style / archtectural objections. Some of which are understandable since I'm new to the codebase and it's a prototype to show the feature, but taken together all the feedback basically rewrote the entire feature. I've pretty consistently had better experiences contributing to large open source codebases than getting a feature into this codebase so I don't necessarily think it's that I'm bad at receiving feedback?
For some more background, I've been working in the industry for 10 years. In the past imposter syndrome was a barrier but there was interesting work and I got regular feedback from my team that made me feel included. It's only recently that I've become apathetic and withdrawn from giving my opinions.
This is known as "not putting your hand back on the stove". Perfectly understandable. Next, please realise that you need to be in a place where your experience is valued.
I think a more accurate analogy is "there's a wildfire and firefighters asked you to conserve water so they can fight it, but some people decided to run their taps 24/7 out of spite and now there's rationing"
I think this is closer, but perhaps needs a slight change. I don't think it's out of spite; it's not like people are taking _more_ risk AFAICT. So maybe something like:
"there's a wildfire and firefighters asked you to limit water use to only drinking water, but some people decided to keep taking long showers, washing dishes, etc"
While on paper that analogy is sound, I feel in practice the asks being made are more extreme and disruptive than short-term water conservation. Others may disagree.
Yeah, and again, the issue isn't that your house is on fire or that there's a wildfire, it's that there's a global pandemic that in absence of any "conservation" measures on your part displays a superlinear growth path - so, yes, the asks being made are much more disruptive, because the event that's occurring is much more dangerous.
Why would you wear a mask solely because of politics? It's a good thing to do that has no downsides and it might help other people. It might even help you. Worst case it was a little inconvenience.
I don't want to be the economist who doesn't pick up the $20 bill but the entire real estate market is based on trying to identify dislocations in price. Plus even if you write a python script that finds underpriced houses on average how many losers can you afford to finance and how long can you hold out for a buyer?
Politics isn't just about promotion. It's about what kind of work people get to do, whose opinion is respected, etc.
I don't care about getting promoted in my current role (at a small start-up where the eng org is flat), but I'm miserable because there's obviously a clique of people who are "trusted" and take over the technical direction of anything interesting. What's left is basically just implementing their ideas and then having them rewrite it on you or nitpick it in PRs until they practically wrote it.
