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

31–40 of 293 posts

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

#31

Post by cncrnd »

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…

Agreed. I have a theory that the reason contractors want to change everything when they arrive is so that they have infinite work.

I also always see contractors wanting to start self-initiated projects from scratch rather than working in the codebase, which is of course easier to produce a visible result in.

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

#32

Post by pards »

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

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

#36

Post by gota »

mason55 wrote: post #15
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…

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-should-...

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

#37

Post by s_kilk »

mason55 wrote: post #15
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…

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...

Chesterton's fence has always bothered me a little because it presumes there will be a sensible explanation for the fence, and that the reason will reveal itself to us if we have the patience and guile to see it.

Knowing what I know about how some organizations work, I don't think this is necessarily a safe assumption.

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

#39

Post by dmichulke »

colinbartlett wrote: post #22
gpetukhov wrote: post #13

Linting and code style guidelines. Easy to introduce, but makes a big positive difference.

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 person benefiting from this is you. I'd hate to pay you for that.

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

#40

Post by aetherspawn »

macht wrote: post #34

I go from git to SVN. It's just easier for me to work with and once the team gets used to it, it's a win-win.

SVN is really heavyweight for branches and tags. It used to take like a minute to branch with SVN but when we swapped to git it took like less than a blink.

Also —rebase is way better than merge. I haven’t had to merge git for over 6 months but with SVN I was doing it twice daily, at least.

Post reply on HN