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

181–190 of 293 posts

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

#181

Post by falcolas »

lvh wrote: post #154
falcolas wrote: post #148

Earlier quoted context omitted.

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?

We were looking at it for a configuration management backend. So, yes, 500+ values, consumed by microservices.

I still say - the only real value even when compared to other AWS services is the rotation, which currently only really works with DBs (and then only if your service connects to the Secrets Manager directly, with every DB open).

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

#182

Post by klibertp »

systemtest wrote: post #45
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.

My opinion is that every team member should have the same editor with the same settings. The settings should be easily accessible from Confluence or a similar knowledge base.

That's going to improve the overall productivity of the worst (maybe) devs while hurting the productivity of the best ones. For the latter, it took years to get to the level of proficiency they are on now with their editor, and they are not going to be as productive in the new one for a long time[1]. You're intentionally crippling them by taking their tool away - why would you do this? Why do you expect they'll put up with it?

[1] And that's assuming your chosen editor is objectively comparable in features with the one they used, which it probably isn't unless it's the one extensible in Lisp ;)

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

#183

Post by lvh »

falcolas wrote: post #181
lvh wrote: post #154

Earlier quoted context omitted.

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?

We were looking at it for a configuration management backend. So, yes, 500+ values, consumed by microservices. I still say - the only real value even when compared to other AWS services is the rotation, which currently only really works with DBs (and then only if your service connects to the Secrets Manager directly, with every DB open).

Yep, definitely not debating that it's overpriced and questionable value compared to KMS + storage of your choosing -- just surprised that you ended up with a model where it's nontrivial cost :)

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

#184

Post by thekingofh »

fragileScrump wrote: post #163

Basically, when I ask for a role, whereby I expect to be placed in charge of the project, I expect exactly that. Not some fluffy title, with a cushy salary. I expect to be able to destroy the scrum process, hang the scrum master. Toss agile in the garbage. Ask the product owner what they actually want. Do that, in about a month. Finish the project 6 months ahead of schedule single-handedly, because web apps are fucki…

Heck YEA. Get shit DONE. I've watched projects go in reverse because of process. I've watched people waste 5 hours a day in scrum. It's so corrosive, addictive to the scrum master/leads who benefit from tossing around their opinion, it favors the worst performers, isolates the best.

Handle process in a case-by-case basis. If something needs changing, change it, but move on and GET SHIT DONE. That's the only way to go. I don't care what people say, good programmers don't need to be babysat.

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

#186

Post by yeswecatan »

jtreminio wrote: post #149

A Docker or Vagrant setup to match their prod as closely as possible, for local dev purposes. It boggles my mind how many developers _still_ install PHP/MySQL/Ruby/Node/etc on their daily desktop and are surprised when something doesn't work as expected on production.

Do you typically choose one over the other?

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

#187

Post by test6554 »

james_morton wrote: post #89
gota wrote: post #36

Earlier quoted context omitted.

This reminds me of the Joel Spolsky's post on why you should never re-write your code from scratch [1]. The reasoning goes most 'ugliness' comes from bug-fixes that people encountered along the way, and by re-writing that 'two page function' you lose all that accumulated knowledge. In short, the hacks that make us want to rewrite code are there for a reason [1] https://www.joelonsoftware.com/2000/04/06/things-you-sho…

More likely the hacks are there because requirements changed and the software wasn't initially built to be flexible enough to support change. A rewrite will solve it in the short term - until requirements change again. However, I would much rather apply the new 'hacks' onto the rewritten 10 line function than figure out the original 200 line behemoth.

I have some code I inherited that I have rewritten it twice now and the second time is when it really became stable and also easier to work with.

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

#188

Post by gravis7777 »

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…

Dead on right. Love this approach. Hate when someone comes into a corp and on day 2 starts pushing changes when they weren't hired to specifically fix a broken process, just replace an employee who is moved on. After 60 days, you will know plenty about what is broken and by then will have earned at least some trust to begin implementing fixes.

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

#189

Post by JBReefer »

ryandrake wrote: post #158

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 repr…

How long did you last? I worked somewhere like that, most engineers lasted 3 months, I managed to squeeze out 4!

Places with issues like that tend to have TONS of other very serious issues.

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

#190

Post by hinkley »

gota wrote: post #36
mason55 wrote: post #15

Earlier quoted context omitted.

See also Chesterton’s fence. You don’t want to change something until you understand why it’s there in the first place. https://abovethelaw.com/2014/01/the-fallacy-of-chestertons-f...

This reminds me of the Joel Spolsky's post on why you should never re-write your code from scratch [1]. The reasoning goes most 'ugliness' comes from bug-fixes that people encountered along the way, and by re-writing that 'two page function' you lose all that accumulated knowledge. In short, the hacks that make us want to rewrite code are there for a reason [1] https://www.joelonsoftware.com/2000/04/06/things-you-sho…

My take on this is that it won’t help anyway. If there are problems in the code that have nothing to do with Chesterton, the fact is that the team wrote this code and asking for a do-over is magical thinking.

If you want to fix it, fix it. Find the other people who are fixing it and collaborate.

Advice I should follow myself: If they fight you on that, get out. They like their ball of mud, and they will turn new code into mud too. If you ever succeed, it will take you until it’s time to find a new job just to get things to tolerable. That’s an incredibly foolish investment in being right.

There are more people in the world that can be taught than there are teachers. Don’t waste your efforts on bad pupils. It just reduces our collective intelligence.

Post reply on HN