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

271–280 of 293 posts

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

#271

Post by jms703 »

cgb223 wrote: post #233
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…

We've got a new member on our team (from a different team within the company) who within his first week is already trying to shake things up with "fixes" Its driving me a little crazy. He is more senior than us, but doesn't have any of the context of why we do things the way we do He'll explain things to us we already know, and propose solutions to us we tried months ago that didn't/don't work After getting a little…

On the plus side, his ideas should give you a moment to reflect on whether or not the way you do things is still the right way. Sometimes you need fresh ideas and approaches. Unfortunately, it's harder to hear when forced like this.

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

#272

Post by cozuya »

zrobotics wrote: post #132
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.

My OP should have called out that I specifically let everyone know that I have no problem with them using git commit -n and git push --no-verify to get around it if they are in feature branches. But yes I implemented this on day.. 2 of my current position which was lead of a greenfield project.

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

#273

Post by dantiberian »

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

Just a note on Secrets Manager which you probably know, but is worth mentioning just in case:

Secrets Manager charges per Secret, but if you are storing non AWS values (API keys), then you can put several secret values in one Secret. Not sure if your 500 values number was 500 Secrets, or 500 secret values which could perhaps be grouped logically together into a smaller number?

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

#274

Post by nojvek »

Spend time talking to people, learning what the hard and hairy problems are. Playing with product and getting a feel for what customers experience. Dabbling in code, trying to make a mental architectural map and asking coworkers to validate assumptions. “What happens when someone does X?” questions.

First week is lots and lots of asking noob questions and documenting them if it’s not already done.

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

#275

Post by cncrnd »

wolco wrote: post #206
cncrnd wrote: post #66

Earlier quoted context omitted.

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…

When you come in on a contract you need to fix or add something specific. Keeping the existing codebase is usually last on the list of priorities.

When you're brought in to add something at a critical time but instead push for bigger changes because of inability to work with an existing codebase that means they need to find a better programmer for the time being to do the role you were hired for.

It's rare that existing employees don't realize a codebase is crap, and starting over they could do better...that's not why contractors are hired, to state the obvious.

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

#277

Post by calciphus »

I'm a product manager, so I'll vary a bit from the development-specific things already listed. Basically, when I get a new product line (or company), it goes the same way:

1. Gather hate mail. Find whatever complaints you can about the product and team you've just inherited.

2. Use the product. Try and break it. Act like an angry QA engineer.

3. Find the person or people who support customers on the product. Ask them what makes their job suck. Ask what's broken.

4. Ask them why they think it sucks / is broken - preferably outside the office (coffee, lunch, etc).

5. Meet dev team. Ask them why the product matters. Gauge their interest and understanding of the problem and customers. Ask what they think is important to address as a team.

6. Combine answers to 3-5, identify common threads. Look for places where there are common blocking factors (cost, time, focus, politics, history).

7. Find something to work on with the team, that can be delivered fast. Talk about what you want to do with support folks (from q3). Sanity check, make sure dev team understands the value of what they are working on.

8. Check in with superiors. Make sure you understand what's important to them. Talk about what you've heard.

I've found I can't come in and expect to be an expert in a given area overnight. But I can be good at asking questions and spotting painful things.

(edit: formatting)

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

#278

Post by troels »

gtt wrote: post #268
troels wrote: post #219

Earlier quoted context omitted.

I realise the way I put it may sound ominous, but it's for the good of everyone involved really. Most organisations are shockingly ineffective. Micromanagement and lack of long term planning is abundant. I get hired because I'm good at writing software. This is not wrong, but I can add much more value if I deliver what is needed rather than what is asked. My goal is simply to be able to do that.

Could you share a longer description of how do you do it?

I'm afraid I'm not deliberate enough to have an actual playbook I go by. It's more like; this is my goal for the first month or two.

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

#280

Post by systemtest »

PurplePanda wrote: post #57
systemtest wrote: post #45

Earlier quoted context omitted.

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.

what's the point of that? it takes a while to learn how to use your text editor well, and everyone is probably good at a different one. but they all pretty well have the ability to produce the same result, so why bother forcing one? it's better to (have a tool that can) specify what the end result should look like and let people work the way that they are good at.

In my team everyone uses IntelliJ Ultimate with the same settings.xml file. We all have the same automatic tasks that happen on each commit: reformat code, optimize imports, check TODOs, perform SonarLint analysis. This has greatly reduced frustrated merge-requests filled with unimportant details such as code formatting and newlines. It has also greatly improved the code quality because it will warn you that you left a TODO in the code or that a certain method could also be private before you commit the code into the repo.

Nobody has a problem with this, although in the Java world every corporate developer uses IntelliJ anyway. A couple of legacy project teams are still on Eclipse.

Post reply on HN