Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- This is why I like to build analysis tools first.
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.
by antisthenes - Nobody talks about SEI anymore but their Capability Maturity Model informed and/or aligned with how I approach new-to-me projects whether that 'new role' is internal or a new employer.
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.
by hinkley - I do the same. You work your way around the edges and get a genuinely good feel for the workflow while improving on it as you go.by lobofta
- It's also, inevitably, the newest people who are often the best at fixing basic documentation — because they're the ones who don't already know it.by gsnedders
- Thoughtful and to the point, I like it. I’m curious how long this process takes others. I’m in a new role for the first time in a while and trying to find the right balance between ramping up quickly and taking enough time for deeper learning.by el_benhameen
- There's one caveat to this – I think it's good to have bias to other people's actions early on in a new role. Taking on little projects that are already understood, taking on cleanups, things other people aren't volunteering for, is all a great way to find where some of the bodies are buried, understand how the team works, and prove yourself as a team player.by danpalmer
- OT: This is the first time in a while that I’ve seen the phrase “load-bearing” used in a natural way. :-)by jgable
- Pangram says 100% AI generated.by simianwords
- Is it natural? It immediately made me suspect AI, if for no other reason than every human is avoiding it now so they’re not confused with AI.
Props to the author if they simply don’t care though.
by sillysaurusx - My last few jobs I started with a listening tour. I talked to everyone who was relevant to the job and asked them:
- what is going well,
- what is not going well
-what do hope that I will fix
-what should I do
-what should I not do
I put those question in the agenda for the meeting invite so they could come prepared. Then we took the conversation from there.
I put it all into a google doc, then synthesized it into summary that hid the identities of the people who said it and used it as my guide for the first few months.
by jedberg - Great approach - I'd add a key one: "Who else should I talk to / who is (regardless of title) effectively responsible for X?"by chrisweekly
- Sort of the antithesis of "Move fast and break things." I find it quite reasonable, but also despair that this advice even needs to be given. It's just basic "horse sense."
https://i.pinimg.com/736x/a5/b3/10/a5b31033a487595f913639c35...
- Solid article. Its worth calling out one thing thats maybe not emphasized enough though: while your contributions may start small make sure to publicize them appropriately. No need to cross post to every channel, but do post about it somewhere or socialize it somehow. Take a lot of time to craft a thoughtful and easy to read message.
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.
by pm90 - When I hear "Bias toward action", it reminds me of von Hammerstein's typology:
> I distinguish four types. There are clever, hardworking, stupid, and lazy officers. Usually two characteristics are combined. Some are clever and hardworking; their place is the General Staff. The next ones are stupid and lazy; they make up 90 percent of every army and are suited to routine duties. Anyone who is both clever and lazy is qualified for the highest leadership duties, because he possesses the mental clarity and strength of nerve necessary for difficult decisions. One must beware of anyone who is both stupid and hardworking; he must not be entrusted with any responsibility because he will always only cause damage. [0]
So reframed, TFA argues that one must be "hardworking and clever" instead of "hardworking and stupid".
[0]: https://en.wikipedia.org/wiki/Kurt_von_Hammerstein-Equord#Cl...
by nbernard - This article is highly AI generated. The first paragraph is probably not AI generated, but the rest is definitely.
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.
by arnorhs - I think this comment is AI generated.
- Who cares!by udfalkso
- I don’t see why it is interesting to claim that a piece is AI generated, especially in light of the concession in your last paragraph that you liked the article.
AI is a tool. It outputs things only when asked to. Asking it requires skill. Saying “This is AI generated” is like pointing at furniture and saying that “power tools were used to build that” or at a program and saying “that’s not assembly, a modern garbage-collected language was used to build that” or at a meal and saying “this was cooked in a kitchen with a modern temperature-controlled oven” or at a paper and saying “this was obviously typeset in LaTeX, not roff or plain TeX.”
So what? Give me a shop full of power tools and I can’t build any furniture, give me Python and a bunch of libraries and I can’t write Mercurial, and give me any LLM and I couldn’t have written this piece.
Does the conceit come from the idea of “some LLM wrote this, so anyone could”? This is like walking through a modern art museum and seeing some obvious-looking piece and saying “I could have done that.” Well, you didn’t.
by massysett - The AI generated images are classic slop to the point of being actively distracting.by travisd
- The title was already a clue that it's AI-generated, and it only gets worse...
The first paragraph is probably not AI generated
"A bias toward action is a superpower only when applied correctly - here's how to frame it as moving decisively after building context, not rushing in before you have it."
...followed by many, many bloated words that can basically be summed up in two words of old Internet lore: LURK MOAR
I agree with the article too, but I didn't have to read that many words to know. "Don't just start doing things because you want to show off, and understand what value you're providing" is how I'd phrase it.
by userbinator - Definitely stinks of LLM phrasing, metering, and punctuation. But I'd say the ideas are the author's alone and they do cut through.by nzeid
- Cannot cite Chesterton's fence too often.
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_...
by emil-lp - I’ve always liked Chesterton’s Fire.
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. :)
by NoItsDanger - As a counterpoint, being useful is not always a sufficient reason to resist changing. Historical design can be also be flawed or just accidental.by misalliance
- > a fence or gate erected across a road.
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!
- I had a role, we got a new CTO. This man could not stop wiggling things. Almost from day one. Not just small things but larger things too (let's migrate to a new issue tracker/wiki thing (back when Redmine was popular)). Flipping staff to new focus (eg: moved a help-desk staff to top NetAdmin, replacing Cisco Certified guy, which caused some havoc during an audit). What a mess, just had to put his fingerprint on everything!
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.
by edoceo - I think there's a middle ground. I used to be intensely critical of "doing things just to do things." The more perspective I get, the more I realize that, in a situation where things are not going right by whatever criteria you use to determine that (outside scope here), you need to make changes.
The right way to make those changes, or at least one way and I don't know a better one, is to perturb the system and see how it responds. This is necessarily risky and uncomfortable, and choosing the right things to perturb and the magnitude of those peturbations is a very, very tricky skill.
But ultimately if you're dealing with an opaque system, which most companies are, and you want to make it a more transparent system that can change, that risk and discomfort are necessary side effects.
This is of course very situational, and the methodical method is by far preferred, but if you'll permit a metaphor: you get dropped into an unfamiliar cockpit, and the controls are labeled in some foreign language. The plane is crashing, or at least you don't know if it is. What do you do? You wiggle things and hope that, in doing so, you don't crash, and you take very careful note of what happens.
by jaggederest