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

91–100 of 293 posts

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

#91

Post by leksak »

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 can't set it up without the Python binary you want already being on the machine which may be a hassle if you are chasing "latest" and you have machines in your ecosystem that run old stuff, for instance, Jenkins nodes.

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

#92

Post by 3pt14159 »

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…

If it's well tested a straight re-write is the right call. It's when there isn't good test coverage where things ossify.

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

#93

Post by mertnesvat »

majewsky wrote: post #65

One thing that I find sorely missing in many teams is onboarding documentation. So when you come in, document everything that you need to do (required permissions, development environment setup, mailinglists, subscriptions) and how to do it.

A good place to start, I did the same in the past.

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

#95

Post by Matheo05 »

I am a bit surprised all the comments so far are tech or process oriented. On my side, I try to say "Good morning" to everyone and get to know them a bit better. It allows me to quickly identify the key resource I need to get answer and being friendly usually make them reply faster.

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

#96

Post by icedchai »

noway421 wrote: post #94
troels wrote: post #8

The first thing I do is work to gain enough political leverage so that I can manage my own time.

To what extent? Up to days? Weeks? Months? Would you oppose daily standups?

"Daily standups" are morale killers.

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

#97

Post by jkingsbery »

s_kilk wrote: post #37
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...

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.

No, the point of Chesterton's fence isn't presuming there is a reason:

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

The point is that there might be a reason, and before careful consideration we won't understand what that might be.

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

#98

Post by carlmr »

awinder wrote: post #61
JustSomeNobody wrote: post #25

Earlier quoted context omitted.

> Process and code fixes are _much_ easier once you have good rapport with the team. And one doesn't get that by walking into a place expecting to make sweeping changes. What's worse is job hoppers were asked so this means people are going into a shop, making these changes, and leaving shortly after. The hell?

More realistically they’re going into a shop proposing changes immediately, getting slapped down, becoming disillusioned, leaving, and then trying again somewhere else. Even when people do make changes like this, it’s unlikely they stand the test of time, I’ve definitely seen people’s “pet changes” get rolled back within microseconds of them exiting.

You're absolutely right. "job hoppers" are often the very motivated people that are worth their weight in gold, but don't find a company that is on their level.

However as a manager you should probably not institute sweeping changes a "newbie" (he could actually be more of an expert than your own team, but you don't know this yet) suggests, but finding out why the newbie suggests them should be in your best interest. Often fresh eyes are the only ones that can see what is wrong. Dan Luu put this really well: https://danluu.com/wat/.

A lot of catastrophe's could have been avoided (especially stuff that's morally questionable) if people listened more to the newbie who still isn't conforming enough to your team that he still sees what's wrong.

So my advice (to the managers): listen to the suggestions, and put your managerial clout and preexisting rapport with your team (which the newbie lacks) to implement the good ones, if there are good ones.

If they aren't you can still explain why.

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

#99

Post by cwingrav »

majewsky wrote: post #65

One thing that I find sorely missing in many teams is onboarding documentation. So when you come in, document everything that you need to do (required permissions, development environment setup, mailinglists, subscriptions) and how to do it.

Every new person on my teams, I have document what knowledge they are missing and what their questions are. We then fix and update the documents we have to address this. If you're on a growing team, this approach saves time/money in the long run.

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

#100

Post by adtac »

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.

This will pretty much guarantee a decrease in productivity, as opposed to the original intention to increase productivity. Why can't everyone use their own editor? Enforce standards, not tools. Something like editorconfig (I use it in pretty much every large project I have) solves this for you.
Post reply on HN