Thus, unless you can ramp to expertise really quickly to leverage your skills developed elsewhere, I'd recommend (perhaps obviously) to try to move to peripheral teams where your skills and relationships transfer as much as possible.
Somewhat awkward if you later see them in a meeting.
Over the years I've come to say "design for deletion" when it comes to internal code. This means meaning more emphasis on making things straightforward to rip and out and replace, as opposed to stuff that is "configurable" or "extensible" etc.
As a junior developer, I know I spent too long on some things thinking that I could make a piece of Forever Art by adding ways for future developers to tweak its behavior.
Whether it needs to be replaced or not has absolutely nothing to do with how it got there in the first place. Yes, maybe the company avoiding bankruptcy due to your clever kludge. Thank you for your service. But today we are tripping over your kludge left, right, and center. So it gots ta go.
The people who think, "this is fine" tend to fit in better. From a team stability perspective that's fine? But echo chambers eventually eat themselves and new perspective can lead to new features or bug fixes.
I was trying to recruit people to help me fix the chaos. It's not my fault they decided it would be easier to start over somewhere else once they agreed about all the things that pissed me off.
That is incidentally one of the advantages of contributing fixes back to OSS. At least you don't have to fix the same bugs in your tools again at every job. After a few years you start to forget how you did it.
I’ve learned to send the new guy to ask instead of parroting back why we aren’t going to be allowed to change something stupid. Because once in a while they disappear for an hour and then come back with news that we’re finally going to fix it.
We all have to look at the same code. The person who writes it specifically for their own tastes has an undue advantage over everyone else because the code exactly matches their crazy. But if you write code everyone else can also read, you only slow yourself down a little and double or triple everyone else’s productivity. Or you can keep being the selfish asshole who uses appeals to authority. Don’t be surprised if you start encountering coup attempts.
Some people hit the ground running, and teams/organizations/companies can thrive if they find ways to embrace that. Sometimes people get hired at the wrong level, and everyone benefits if some sort of work demonstrates that quickly. I have seen promotions happen based on prudent choices around one's individual strengths, simply by choosing to do a bit of the right work and getting eyes on your capabilities. There is no "one size fits all" prescription for what someone should work on.
Having a "shadow lead" can be one of the best situations for your growth, too. Not only do you get the experience leading a thing (for most of what that means, anyway), you may end up with a very strong ally when you knock it out of the park. I had a version of this experience, and I've watched others have it as well.
I'm guessing most of the negatives here are based on your personal experience, and for that I'm sorry. Hopefully you can encourage positive changes in your company's engineering culture.
I imagine this will be determined by the culture and the system of rewards which are out of your control. A shadow lead could be an ally, or they could pin any deficiencies on you. The author’s comment is sound in my opinion: depending on altruistic behavior is a bad position to be in.
In a successful company with high retention, many senior engineers who would fill these roles as shadow lead, often have their ego turned down, less to prove, and will encourage you to succeed. In companies with a lot of churn, or always on the brink of disaster, you don't get that support.
overall though, I do agree with the article. orgs run on reputation, and it's slow to change, and snap judgements sadly matter.
In my feed and bookmarked.
very good writer, experienced dev.
Be the same ethnicity as engineering leadership in your org
Build your reputation by helping others get their job done while you do yours.
That was a part of the plot of Rand's _Fountainhead_, but you don't have to do it so selfishly, and doing it selflessly is possibly more effective in a non-stick workplace.
Is also contrary to football team advice, "stay in your lane and just do your job"; however, football teams are actually more like co-acting groups, where one may succeed while others, including the overall group, may fail so I'm not sure how applicable football advice is to the corporate world.
If an engineer asks the businessperson for extra time... that's when things get dicey.
But, that's what nights and weekends are for, right? Go get em tiger.
Just recently an engineering manager told me “I trust [IC7 engineer] to go where he is most impactful”
So this isn’t the only model, and successfully identifying and pitching working on high impact projects is a seniority marker that will lead to rapid promotion. In any organization. The pitch may look different in different places but I promise you - if an engineer is successfully pitching and delivering high impact projects promotion WILL follow.
Identifying and pitching high impact projects is a combo of technical and soft skills though, and the way this happens depends on the org.
When everyone can sit around one big table, you don't have to consciously polish your "brand" all the time -- most people have direct experience with you and base their opinions on that. You do good work and you will have a good reputation. If you have a conflict with someone who is a jackass or have a project that fails to launch, people know enough about the context to judge pretty fairly.
When there are hundreds of people on the engineering team, especially in a remote-heavy workforce, most people don't have direct experience with you and can only base their opinion of you on what they hear from others, i.e. your reputation. This goes for peers as much as leadership.
You have to be aware of how an org changes over time, and how things that were once not important are now essential skills for success.. and decide if any new essentials are skills that you are interested in developing.