HN

Comments (31)

• mettamage
  This whole conversation reminds me of the Career Cold Start discussion [1]. I remember looking it up at some point when I started a new job. It was somewhat useful, but a lot of this is also hard won knowledge once you understand what actual "working at a company" entails. I'm only beginning to get that sense after 7 years work experience at different companies (small startups, scaleups and now F500).[1] https://news.ycombinator.com/item?id=16550270
• edoceo
  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.
• Menu

  arnorhs
  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.
• Menu

  emil-lp
  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_...Related: https://news.ycombinator.com/item?id=38653711
• ChrisMarshallNY
  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...
• danpalmer
  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.
• pm90
  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.
• Menu

  beaker52
  This article is great advice that I should take if I ever get a role where I’m not going to be pressured into delivering some kind of low-value BS during Phase 2 that causes me to hasten the delivery the most useful organisational changes I can. I can’t help myself when the wick gets turned up.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.
• Menu

  jgable
  OT: This is the first time in a while that I’ve seen the phrase “load-bearing” used in a natural way. :-)
• el_benhameen
  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.
• iSloth
  Solid approach, although I’ve certainly seen many managers/staff that never actually break out of Phase 2It’s critical to start showing some Phase 3 impact, even if not with a sledgehammer, before peers quickly loose faith
• Menu

  hinkley
  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.
• austin-cheney
  My experience as a long time corporate software developer is an exceptionally heavy bias towards inaction. There always seems to be fear and hesitation towards any kind of pivot or new initiative outside the rails of comfort. For example most corporate software developers cannot write an original new application from the ground up no matter how tiny or simplistic.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.
• antisthenes
  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.
• anon
  undefined
• anon
  undefined