Ask HN: What is the first thing you implement at a new company? • Hacker News Board

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

#171

Post by JoeAltmaier » Wed, Jun 20, 2018, 2:23 PM UTC

fragileScrump wrote: post #163

Basically, when I ask for a role, whereby I expect to be placed in charge of the project, I expect exactly that. Not some fluffy title, with a cushy salary. I expect to be able to destroy the scrum process, hang the scrum master. Toss agile in the garbage. Ask the product owner what they actually want. Do that, in about a month. Finish the project 6 months ahead of schedule single-handedly, because web apps are fucki…

That's one approach. I think its called 'cowboy'? And it can actually work, if the job can actually be done by one person. Still, its not clear where communication and documentation come into it? What if you're hit by a bus, proverbially.

Things are done different ways for a reason, sometime. The heavyweight process that essentially disrespects the individual contributor (agile et. al.) has a place in a corporate, accountability ecosystem where reporting is required. But it definitely turns the individual into a factory worker, on a line, putting screw A into slot B.

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

#172

Post by raziel2p » Wed, Jun 20, 2018, 2:23 PM UTC

bpicolo wrote: post #112

stealthmodeclan wrote: post #19

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)

Jenkins's main problem for me will always be the lack of focus on storing pipelines/jobs as source code. Jenkinsfiles are horrible both to read and write.

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

#173

Post by Cofike » Wed, Jun 20, 2018, 2:25 PM UTC

fragileScrump wrote: post #163

Basically, when I ask for a role, whereby I expect to be placed in charge of the project, I expect exactly that. Not some fluffy title, with a cushy salary. I expect to be able to destroy the scrum process, hang the scrum master. Toss agile in the garbage. Ask the product owner what they actually want. Do that, in about a month. Finish the project 6 months ahead of schedule single-handedly, because web apps are fucki…

Well that was certainly an interesting read.

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

#174

Post by JoeAltmaier » Wed, Jun 20, 2018, 2:26 PM UTC

lolsal wrote: post #170

fragileScrump wrote: post #163

Basically, when I ask for a role, whereby I expect to be placed in charge of the project, I expect exactly that. Not some fluffy title, with a cushy salary. I expect to be able to destroy the scrum process, hang the scrum master. Toss agile in the garbage. Ask the product owner what they actually want. Do that, in about a month. Finish the project 6 months ahead of schedule single-handedly, because web apps are fucki…

Your attitude (if not sarcastic, maybe I missed the clues) makes me think you have not ever worked at a large company or on software that is more complex than a CRUD application.

Young folks think, since they've only seen large projects done the Agile way, that its the only sensible way.

Yet so much got done, for decades, without agile's help. Even at large companies, sometimes. Even on large projects.

I imagine the vitriol above was a response to the dehumanizing effect that agile has on the individual contributor. They become, by design, a replaceable unit. "Hey get me a 6-pack of programmers for this project!"

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

#175

Post by dasil003 » Wed, Jun 20, 2018, 2:28 PM UTC

carlmr wrote: post #88

Joeri wrote: post #68

Earlier quoted context omitted.

I understood it differently. As in: there is always a reason for the fence but you never know whether it is justified or not without understanding it. Don’t tear down the fence until you understand why it was put there for the wrong reasons.

True, but what I think s_kilk was getting at is that sometimes (especially in software) a bad developer will put a "fence" somewhere without a reason. And if that person already left the company, maybe you can never find out why. That's why it's important to start with some testcases of required behavior, and then refactor only code that is supported by tests. Because sometimes the fence is there for a reason, but of…

Even bad developers have reasons, you may not be able to divine those reasons but they may be legitimate. The would-be refactorer would do well to consider carefully what the reason might have been, even if a git-blame reveals a less-than-excellent contributor.

As an programmer I always try to capture these reasons in my commit messages, after a decade of doing this I’ve gotten a lot of thank you notes years after leaving a project, and I’ve even reminded myself details about my own thought process that I had otherwise would have long forgotten.

One thing I’ve learned by having long tenures is that context change over years is much more likely the reason for nonsensical code than developer stupidity.

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

#176

Post by falcolas » Wed, Jun 20, 2018, 2:30 PM UTC

icedchai wrote: post #159

falcolas wrote: post #147

Earlier quoted context omitted.

Daily standups for remote workers are godsend. You'd think you could rely on people to communicate over chat or email, but the standup actually gets everyone talking and discussing.

Perhaps. But do they really need to be daily? Maybe 2 or 3x a week.

Having tried all three, every day built a lot more comradery than 2-3x per week. It also helps the remote workers feel more in touch with what's going on.

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

#177

Post by rapfaria » Wed, Jun 20, 2018, 2:31 PM UTC

klibertp wrote: post #131

gota wrote: 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…

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

> at least if you know what you're doing

Isn't this exactly the problem? I know "what I'm doing", but don't have the added knowledge of several engineeers through several years, and rewrite it's not necessarily a 1:1 transcription to a new language or structure.

If something is bothering the team daily, than yes, a rewrite might be needed, which is different, and hardly something I would exclusively by myself.

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

#178

Post by triggercut » Wed, Jun 20, 2018, 2:31 PM UTC

1.Find an established religiously held standard that has little actual value (tabs vs. spaces).

2.Spend the first month gas-lighting everyone into changing to the oposite until enough people force a change in policy.

3.Survey my new kingdom with my loyal band of disciples (whilst intermittently switching between tabs and spaces to enrage the holdouts)

4.Quit

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

#179

Post by makmanalp » Wed, Jun 20, 2018, 2:31 PM UTC

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…

This honestly took me a while to learn - it's so easy to jump in and be a smartass (and I've been guilty of this before) about how bad things are, but a) suggesting small, incremental changes that demonstrate a nuanced understanding of where things went wrong and b) volunteering to work on making things better goes a long way. Most of the team will already often know and agree on what is bad - but just won't be empowered to fix it somehow.

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

#180

Post by lgleason » Wed, Jun 20, 2018, 2:37 PM UTC

It depends on the project. The biggest thing is to assess where the team is at. I just left a project where the team had serious issues and the leadership did not have the desire to fix it...IE: a tech lead that was more of a mid level dev running a command and control style thing. The team, with more experience, did not have a say in the architecture, what they got to work on etc.. All devs had to get their commits past the mid-level lead, the lead would reserve most of the fun and hard stuff for themselves and leave the scraps for the rest of the team. The lead had multiple silo'ed efforts and, as a result, had a higher number of commits etc. on code base partially because they were constantly declining PR's from the rest of the team to do it their way.

Now if you have a team that is actually open to your ideas things are VERY different. I've worked on them and they are amazing. The key thing is to evaluate where they are at and apply what is going to work for them. The biggest thing is to avoid the one size fits all approach.

With the original comment for this thread, my biggest issue out that gate with their approach is that you are using a lot of branches which negates the benefits of CI etc.. Why not instead try to figure out how to reduce branches and have more people checking in working code to dev with unit tests?