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

101–110 of 293 posts

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

#101

Post by geezerjay »

oreganoz wrote: post #10
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…

Yeah, I have to say I'm a bit surprised to see people so eager to change things that are working, so fast.

Sometimes those things that are working imposed a hefty load of technical debt, which newcomers are tasked to pay up with compound interest due to the unfamiliarity with the codebase. Therefore rewriting some components may actually pay off in productivity in the short run.

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

#102

Post by mhd »

clemParis wrote: post #9
vortico wrote: post #5

What's three amigos? Never heard that term in programming.

I had to google that as well. It seems to be an agile practice [0] that consist in gathering a developer, a product owner and a QA tester in order to produce acceptance tests using the format given/when/then. [0] http://jonkruger.com/blog/2012/01/04/the-three-amigos/

Who came up with that, given that "three amigos" is a pretty well-known term for Booch, Rumbaugh and Jacobson?

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

#103

Post by mseebach »

3pt14159 wrote: post #92
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…

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.

In theory. In practice, the code will often have corner case behaviours that eludes any of the tests, yet are still important.

As an aside, as I understand it, refactoring was popularised as a response basically to this conundrum - it's a technique for reorganising code without changing its functionality. So you can gradually "rewrite" your two page function without losing the accumulated knowledge.

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

#104

Post by swsieber »

james_morton wrote: post #89
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…

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.

Each hack individually, yes, is likely to be there because of requirements changing.

But collectively, it's likely that one of those hacks is there to account for some edge case that's not intuitive and will be missed on the rewrite.

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

#105

Post by slx26 »

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…

I agree with other responses to this comment. Ugliness might have had a reason, ok. It's important to understand that. The question is whether it has a reason to stay. And here we find the usual balance between the effort it takes to maintain ugly code and the effort it takes writing new one. On another point... I understand calling that "accumulated knowledge". But that's knowledge accumulated very badly. You want to accumulate knowledge? Write tests when needed, comment them when needed, add comments when needed in the comment. That's accumulated knowedge too, and you are actually making it way easier to transfer, which is definitely one of the most important parts. If you were already doing things right, that's another story, but in general, if you look at code and your brain goes "what the..? no, please, why did you... T_T", there's probably a need for a rewrite.

EDIT: I think it's also important to mention the value in rewrites, specially on your own code. Spend a lot of time thinking how to make your code simpler, easier to follow, cleaner. That will help you write much better code in the future. A lot of people would benefit from this if they tried. Writing code that works is simple, writing good code is very hard. And rewriting code teaches a lot of the second. When you are learning, rewrite a lot. When you think you know what you are doing but someone suggests to rewrite (and you know they are good programmers too), at least listen.

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

#106

Post by fsloth »

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…

Actually, what that piece underpins is not that you shouldn't do rewrites, but that you shouldn't do that with the expense of the developer resources of your legacy application, you shouldn't put your old product "on hold" for the period of the rewrite, nor should you pretend that you are modifying the old product, but that rewrite effectively always results in a new product, and you shouldn't except that you can hotswap the new product with the old one.

The age old maxim "sell old products to old customers, and new products to new customers" works pretty well here as well.

How to rewrite the product if all your experts are tied up in the old product is a different question entirely.

For example of industry that seems to be in perpetual rewrite is the gaming industry. But they don't rewrite the old games, the develop new products using partly the existing concepts and software modules.

This product based view also tells you something: when in business, you should never do a rewrite out of purely technical aesthetic reasons, but because of concrete measurable business goals.

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

#107

Post by skocznymroczny »

thecupisblue wrote: post #67
spiritcat wrote: post #46

First day I find the best dev and kick his ass. Gotta set the tone.

Pee on their desk. Establish territorial dominance.

Make sure to get a MX Blue mechanical keyboard, so that everyone is aware of who's doing most of the keyboard mashing around the office.

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

#108

Post by mseebach »

dboreham wrote: post #58
mattlondon wrote: post #42

Earlier quoted context omitted.

+1 for this. Unless you've been hired specifically to help them change their dev practices, I'd go along with what they have until you've got some understanding and reputational-clout to start suggesting such huge changes to how everyone works. Rocking up and on day one start asking people to change their development practices (particularly around branching policy which is something very contentious and/or strict eve…

The fact that process is off in the first place indicates a deeper problem.

In which case the correct answer is to sit tight for a bit until you understand the deeper problem. And then you fix the deeper problem, and then you fix the process.

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

#109

Post by lvh »

Latacora perspective, AWS specifically: go install aws-vault. https://github.com/99designs/aws-vault

There are a ton of benefits to aws-vault. Strategically: getting everyone on an aws-vault workflow is step one to eventually making your IAM story great. We'll be publishing some general stuff about how we think you should start cleaning up your IAM story. We have Strong Opinions(TM) on how to get you from "bunch of people have * : * perms with keys they have on disk" to best-in-class, BeyondCorp-compliant temporary perms acquired on trustworthy endpoints.

(FWIW: also undersigned re: start by listening. Latacora starts with an audit too, but that feels like a cop-out answer :))

Post reply on HN