Live data from Hacker News

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

news.ycombinator.com

111–120 of 293 posts

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

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

In my experience, it's extremely difficult to know which particular lines of code are obsolete. This becomes even more difficult as a codebase ages and is worked on by more contributors. Add on another exponent for every business stakeholder that has a hand in defining the business rules—especially if you have requirements coming from multiple sources that may not be aware of each other.

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

#112

1. Every now and then we run into Paywall. Give everyone employee debit card so that they can buy stuff which helps their productivity. 2. CI using Drone.io 3. Add trello 4. Everyone gets their own AWS account. It makes it trivial for them to experiment with new ideas from their home or at office without begging anyone for credentials. You start by empowering your employees. Now, we consult startups which work differ…

My company is currently using drone. The lack of first class scheduled builds is a real buzzkill. Jenkins or similar feels like a much better solution atm still (you can still push for containerizing jobs either way)

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

#113
post #36
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…

That article by Joel Spolsky was one of the few I can't fully agree with. The greatest successes of my career have often been in creating "next generation" implementations of software using newer or better technology and designs. Those re-implementations have resulted in very significant performance and productivity gains. While rewriting things from scratch can definitely be a naive impulse, there are times when it's the right way to improve a product, and if you fail to do so, your competitors will. The trend towards microservices tacitly recognizes this, I think; one of the tenets being it should take a small team a couple of weeks to rewrite any component of the system from scratch. When software was written poorly to begin with and has grown unmanageable by layering hack upon hack, it can pay to take a step back, look at the actual requirements, and consider if there's a better way.

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

#114
post #26

If you just arrived at a company why are you pushing to change anything. They obviously already have a working process and you should be careful to change anything that works, especially when you may not yet know all of the more hidden details.

There are lots of useful changes you can make that don't break the world but do materially improve things. I already gave an example elsewhere of aws-vault. Similarly, CI/CD/code review are easy wins that not everyone has already. You're assuming everything is copacetic right now, but that's not a given. I doubt any startup would take the position that there's nothing left to improve. That doesn't mean you're going to start by burning the world down and starting over.

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

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

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

#116
post #37
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.

Chesterton’s fence is an idea to help you counteract the exact notion you are expressing here. You must prove that the reason for its existence is no longer sensible (or, perhaps, never was sensible) before removing it. There is no probability distribution associated with the proverb, except that there is a nonzero chance of sensible explanation.

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

#117
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…

This is one I learned the hard way. I made a number of much-needed fixes at a job where they'd never really had a dedicated technical person before. People freaked out. I hadn't communicated what I was doing and why it was necessary, and it took a while to earn goodwill after that. Lesson learned: don't implement a solution until you've convinced everyone they have a problem and this will fix it.

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

#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 significantly outweigh the later in my experience.

Post reply on HN