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

131–140 of 293 posts

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

#131

Post by klibertp »

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…

Rewriting the code from scratch does not necessarily mean clean-room reimplementation! It doesn't even mean you can't include parts of the original in the new code.

Rewriting from scratch means rethinking the design, or basic structure, of the code while keeping all its functionality. It's not about getting rid of hacks, it's about lining them up neatly in one place instead of having them all mixed, twisted, nested and threaded through the code everywhere.

Well, at least if you know what you're doing, instead of just randomly deciding on a rewrite because it's more interesting that way or because you can't be bothered to read and understand the original. Then, I agree completely with Joel, it's most of the time a grave mistake which made countless companies and developers fail.

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

#132

Post by zrobotics »

cozuya wrote: post #119

(front end js) My new favorite tool is the ridiculously named husky package, which allows for configurable git hooks inside of package.json. Specifically what I'm doing now is precommit eslint and prettier, and prepush test:all i.e. people on my team will be unable to commit if they fail lint and unable to push if they fail unit tests. There's of course positives and negatives to this approach but the former signific…

And you do this in a new job? Introducing a linter the first week seems like a great way to make your new coworkers hate you. Sure, it's a good thing to do, but if your teammates aren't already using one then unilaterally introducing this into the commit process seems a little radical.

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

#134

Post by thijsvandien »

yorwba wrote: post #71
leksak wrote: post #12

Earlier quoted context omitted.

Where do you stop short? I'm conflicted. I sometimes look at Docker and am like "this is great", but I also sometimes look at a plethora of Dockerfiles and I'm like... what are we doing wrong? Do you, for instance, Dockerize small Python tools (or similar)? How well does this work? I remember one project where we had tons of small Pipenv projects and one pain was that a few were Python 3.5 and a few others were Pytho…

> we had tons of small Pipenv projects and one pain was that a few were Python 3.5 and a few others were Python 3.6 Isn't pipenv supposed to take care of that? You pipenv run the tool and it's automatically executed in the right virtual environment.

You'd have to combine it with pyenv to allow for multiple interpreters and automatic switching between them.

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

#136

Post by chatmasta »

pards wrote: post #32

>> For the first month or so I take a very humble listening position .. and then - Everything in source control - CI - Static code analysis - Artifact repository - Automated deployments, incl database and configs - Branching strategy & pull requests - Standalone dev env per developer

What do you use for an artifact repository? I’m assuming you mean the cached artifacts of builds, but also vendor artifacts/cache like npm_modules or docker containers?

This sort of vendor dependency management is a problem I haven’t found a great solution for yet. I’m actually thinking about creating a product that’s implemented as a proxy and supports multiple package managers, including docker, and caches all downloads keyed by branch. This way in the event of some catastrophic dependency failure you have a place to find the last working set of vendor dependencies that didn’t break the build.

Would anyone be interested in this? What is current best practice for this workflow?

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

#137

Post by kevinmchugh »

bbarn wrote: post #115
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…

I was going to say "Happy Hour" but this is really what I meant. I focus first on understanding how the team works, their motivations, their past pain points, and honestly become one of them before I suggest changing what is then _our_ process.

I wouldn't, on the first day, try to take up more of my coworkers time. I would wait until I learned the norms about after-work outings and what sort of obligations they have outside of work.

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

#138

Post by klibertp »

cncrnd wrote: post #66
Techinica wrote: post #62

Earlier quoted context omitted.

As a person working in this scenario I find the biggest issue coming into work on an established code-base is the lack of documentation and a lack of interest from the company's own people to divulge any information about the code base. This unfortunately leads more often than not to the situation you describe, re-written code or projects perhaps unnecessarily separated.

Very true as well, and if that were plainly stated the problem could be addressed. The issue is that some of these people are smooth talkers able to convince managers that these big shifts are necessary right away...and inevitably end up abandoning big projects they push for. Others are able to poke around the codebase and ask questions till they can contribute in a meaningful way, but these are rare in my experience…

> Very true as well, and if that were plainly stated the problem could be addressed.

That's not, at all, how this works, especially for newcomers.

If the new programmer on your team doesn't want to work on a larger code base, it's your responsibility to notice this early, initiate a talk with them about the reasons and actively try to fix the problems they have.

Reading code is hard enough, but reading it under pressure of being the new guy makes it even worse. Don't expect many people to be able to cope with this without serious effort on your part. If you can't be bothered to effectively support them in understanding your code, they are not likely to care about that code sufficiently to productively work on it.

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

#139

Post by MaxBarraclough »

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…

> most 'ugliness' comes from bug-fixes that people encountered along the way

That's reality, sure, but there's no reason not to document it properly. Inadequate documentation seems to be assumed implicitly here.

If a (competent) reader is thinking Why on Earth does this code do that?, it means you've written unmaintainable code with too few comments around the necessary-but-ugly workarounds that you've used.

If you have properly commented everything, the reader won't mistake the necessary complexity of the code for a giant-ball-of-mud.

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

#140

Post by falcolas »

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 passwords. It can't even rotate all passwords, just those for a specific subset of AWS services.

Should instead start with parameter store (which is free but still offers encrypted password storage) and then figure out what parts really need a rotating password and that are operating with services which Vault can rotate passwords for - at which point you migrate only those.

Post reply on HN