Another time we got bought, merged into a new company, their CTO was our new CTO. In one of the initial meetings said "things won't change much" and, naturally, we didn't believe. She moved slow on all the things, methodical. Spent some time with each component team. It was months before we started making changes to better mesh with the new company. Very little chaos. Still admire that management style.
I also double checked on gptzero me and it 100% agrees with me.
I'm curious to know though whether or not the "author" used Gemini. I've been using Gemini a lot in the past year, and the writing sounds exactly like Gemini. But it's possible that all the models sound the same.
Edit: I'd like to add that I still liked the article and agree with it, and in general I find Gemini's writing style to be quite enjoyable.
In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, "I don't see the use of this; let us clear it away." To which the more intelligent type of reformer will do well to answer: "If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it."
— https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_...
Except in many cases it is your responsibility to ask. If something has indefined legal status, and no documentation, it is a major red flag. Very often corruption, drug or people trafficking or other shady stuff.
If you want gate in middle of the public road, show the paperwork! Or I will call authorities!
Maybe there’s a reason you’re on fire. Until you can say for sure, I will not put it out.
I will just be here roasting these marshmallows on your burning flesh. :)
https://i.pinimg.com/736x/a5/b3/10/a5b31033a487595f913639c35...
As a result, after 15 years as a software engineer, I’m genuinely considering leaving the industry altogether because the only roles available to me are ones where I’m expected to deliver features rather than organisational change and growth. It’s like my heaps of experience have navigated my career into a cup-de-sac, and the only way out is backwards. I’m so jaded. Hopefully it’s a phase. I need a coach. Help.
Reputations are hard to earn and easy to destroy. Trust building at any new institution takes a lot of time and effort and can seem annoying. But just doing solid work and communicating about it consistently will make sure that like minded people notice you, vouch for you and then give you more opportunities.
Props to the author if they simply don’t care though.
It’s critical to start showing some Phase 3 impact, even if not with a sledgehammer, before peers quickly loose faith
CMM says that an engineering team whose processes aren't written down is level 0, and writing them down, even if they are batshit, gets you to level 1. Which leads to a fun bit of catharsis with the older employees where they get to say things like, "and then a miracle occurs".
Also writing things down gives someone else a peek into what's going on in your head and they can correct bad assumptions you have before they get cemented and take more effort to dig out of your thought processes.
So I always start with fixing the documentation, the runbooks, the CI process. It's a deliverable you can engage in without breaking production, it demonstrates mastery, it fixes a pain point that the more professionally mature members of the team care about, which gets you brownie points with the right sort of people. And it makes it easier to onboard the next person, or pick back up a project that has been on the back burner for several quarters.
TODOs emerge from the documentation or get explained away as unnecessary or wontfix. By the time you're touching something you have a better idea of why things are like they are, so you make up for 'lost' time.
This is action, just not action that can tarnish both of us by shipping bugs to production.
Edit to add: I used to take ex coworkers out for coffee or beers around their last day and ask for a rundown of all the reasons they left. What you generally find if you let them keep talking is that they will run through the problems in reverse chronological order. The last thing they will mention is almost always what a joke the onboarding process was.
Last straws are the most recent thing that set the person off. All the straws before it add up, and if a person is already questioning the maturity of the organization on day 2 on the team, then I believe that multiplies your turnover rate. The longer you can go before a new employee says "what the actual fuck", is a multiplier on how long they will stick around.
Effectively, I think "the first 100 days" rule of thumb goes both ways. You get 100 days to show you're useful as an employee, but everyone already on the team is being held to the same yardstick by new employees. And if you're hiring at a high enough rate, having 20% of the team think the old employees are a waste of oxygen is not good for consensus building.
In such environments the people that do demonstrate a bias towards action tend to fall into one of two camps: those that wish they hadn't and those that are chasing attention.
The corporate developers who do have an overwhelming bias towards action, not the sociopath attention chasers, just end up contributing to open source projects unrelated to employment tasks.
Making the ultimate visibility tool isn't just helpful to me as a newcomer. It may be useful to many veterans and people who haven't had the time to make this tool for themselves.
But I'm also somewhat biased towards laziness/observation.
