Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: What is the first thing you implement at a new company?

news.ycombinator.com

Post reply on HN
Print view View original

151–160 of 293 posts

Re: Ask HN: What is the first thing you implement at a new company?

#151

Post by klibertp »

dmichulke wrote: post #39
colinbartlett wrote: post #22

Earlier quoted context omitted.

In that vein, I invariably have one massive commit on every project to remove trailing whitespace first. That way when my well-behaved editor removes them with each commit, it's not littering up the diff.

Frankly, I saw this in a few projects and it feels like the responsible is one of those people that can't actually code but wants to convince management of their impact with their huge commit stats. I also hate whitespace but it's just a symptom (the other developers' editors / git config probably don't show the trailing whitespace). Given this, it's a mere symptomatic remedy, the problem will reappear, and the only…

For what? 30 seconds of writing a sed command in the shell? I can donate that kind of time to the project for free, really.

Re: Ask HN: What is the first thing you implement at a new company?

#152

Post by [deleted] »

fastbeef wrote: post #6

For the first month or so I take a very humble listening position, even if I immediately see things I want to fix. More often then not, there is a background and a history to things that could lead to a) my “fix” being unnecessary and/or ill-informed and b) friction with the rest of the team because here comes a whippersnapper upending all our stuff. Process and code fixes are _much_ easier once you have good rapport…

[deleted]

Re: Ask HN: What is the first thing you implement at a new company?

#153

Post by delinka »

acconrad wrote: post #150

The very first thing I do is update documentation. You're a fresh set of eyes and so documentation for onboarding, setup, and building the application on your laptop is the kind of thing that often goes by the waist side. Did a step not work because you've updated your OS? Was there a critical typo in the terminal? These things provide immediate value to all future hires.

...by the wayside

Re: Ask HN: What is the first thing you implement at a new company?

#154

Post by lvh »

falcolas wrote: post #148
lvh wrote: post #143

Earlier quoted context omitted.

You appear to be confusing aws-vault, a gratis and open source project that manages IAM credentials, with AWS Secrets Manager, a hosted AWS service that stores and manages secrets. I agree AWS Secrets Manager is overpriced but I doubt it's a major expenditure for anyone. You should probably just use KMS instead and dump the ciphertexts wherever you want. Parameter Store is a fine place for them.

I did. Clearing up. That said, it is a major expenditure when used as part of the automatic workflow. And parameter store has KMS encryption/decryption built-in. Alongside full IAM level isolation.

So, concretely: $0.40/secret/month (prorated if What are you doing with it that makes it a major expenditure? That seems like a drop in the bucket compared to anyone's compute. Are you dumping 500 secrets in it?

Re: Ask HN: What is the first thing you implement at a new company?

#156

Post by dood »

soulnothing wrote: post #125

Documentation is my biggest thing. I start with onboarding, CI/CD. Then start adding api and archicture documentation. This forces me to learn, and ensure I digest well enough to explain to other people. Once that's done I start adding unit tests, monitoring, and additional dashboards.

Documentation has some great properties as something to work on in early days (so long as you aren't immediately firefighting).

* Documentation always sucks, no-one wants to do it, and everyone knows it has room for improvement. It shows you're willing to roll your sleeves up and do the less glamorous stuff.

* Working on it prompts you to ask simple questions so is a good way to get to know people on the team, and in the process learn the history of the team, why things are the way they are, and where the dark corners are.

* You're immediately creating value, rather than doing bugfixes no-one cares about or having meetings about things which are months away from fruition, and demonstrates you're here to make things better for everyone.

Re: Ask HN: What is the first thing you implement at a new company?

#157

Post by lvh »

falcolas wrote: post #140
lvh wrote: post #109

Latacora perspective, AWS specifically: go install aws-vault. https://github.com/99designs/aws-vault There are a ton of benefits to aws-vault. Strategically: getting everyone on an aws-vault workflow is step one to eventually making your IAM story great. We'll be publishing some general stuff about how we think you should start cleaning up your IAM story. We have Strong Opinions(TM) on how to get you from "bunch of p…

Oops. I was thinking of the wrong tool. Personally, my biggest peeve with temporary IAM credentials is the duration. Having them invalidate in the middle of a Packer build is a real mood killer. Our own company got them extended to 12 hours recently, which was a huge win in this department. Original content - about Secrets Manager: AWS Secrets Manager is stupidly expensive for a password manager that rotates password…

Replying to new content: it's true that Hashicorp tools in particular are hilariously bad at dealing with expired credentials. Terraform doesn't realize the error and just sits there banging away (retrying) forever.

If this is really a problem (that is, you reliably need more than 1h of role time and you can't get AWS to extend your duration for you), aws-vault knows how to mimic the metadata API. This resolves the issue, since it will transparently get new credentials for you.

Re: Ask HN: What is the first thing you implement at a new company?

#158

Post by ryandrake »

I once joined a company and found out on day 1 that they had:

1. No source control system

2. No bug/issue tracker (or formal software QA)

3. No build automation

4. No dedicated build system

5. No pre-launch checklists

Basically, the latest release was whatever happened to be on one of the engineer's hard drives whenever someone frantically ran in and said "we needed to release!" You can imagine how fun it was to repro when customers reported bugs. And they did, Gandalf, they DID...

Those were the first things to address because they were obvious gaping wounds and I could implement them myself without really having to convince anyone. The CEO thought they were a waste of my time (I hired you to write codes) but didn't actually stop me from setting them up. The next things lacking would take more effort to fix because they were people/process dependent: like no code reviews, no software development process, no bug triage process, etc.

Re: Ask HN: What is the first thing you implement at a new company?

#159

Post by icedchai »

falcolas wrote: post #147
icedchai wrote: post #96

Earlier quoted context omitted.

"Daily standups" are morale killers.

Daily standups for remote workers are godsend. You'd think you could rely on people to communicate over chat or email, but the standup actually gets everyone talking and discussing.

Perhaps. But do they really need to be daily? Maybe 2 or 3x a week.

Re: Ask HN: What is the first thing you implement at a new company?

#160

Post by _wmd »

aplummer wrote: post #84

I'm a consultant, the biggest thing to understand is that you don't work for the company, you work for the individuals in the company. You need to immediately start solving what they think is the problem, to build the capital to solve their actual problem. Ex. Company thinks they need more developers to ship on time (you). First, make sure you're getting tickets done and helping them with the metrics they know, then…

Everything here, but with an important tweak to step 1: it's impossible to know what needs fixed until you've actually gone through the motions of trying things as they are today. It's easy to come in pushing all your 'best practice', but any of it could be a bad idea in any particular scenario, and it's impossible to know without context

I don't think I've introduced anything revolutionary in the last few places I've been (going back ~2 years+), and that's also a fine outcome. Often it turns out that causing disruption to something that works well enough is far more counterproductive than simply leaving things as they are. Save the churn for a big change that really provides an important benefit, otherwise it's not worth the time

Post reply on HN