Live data from Hacker News

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

news.ycombinator.com

191–200 of 293 posts

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

#191
post #170

Earlier quoted context omitted.

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

And, I get it. Different strokes for different folks.

I've worked on more than just crud apps. And at this point, with the front-end/back-end false dichotomy, nobody works on simple crud apps anymore. Single page js frameworks have made interaction design so bloated, it's kind of a little bit awful.

But the real loss of traction is in third-party services, authorization and inter-departmental warfare over favor and jurisdiction. Who's on top? Who tops from the bottom?

Y'all have your way, and I have mine. Getting up at seven in the morning, to commute to a nine o'clock stand-up that goes nowhere, and does nothing is a waste of my fucking time. Grooming sessions? Planning sessions? Retrospectives? When the fuck am I going to get a chance to sit and fucking think?

Oh, this is supposed to be an eighty hour work week, isn't it?

Look, my setup works for me. Just add an option to disable agile/scum.

https://xkcd.com/1172/

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

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

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

I wholeheartedly agree with what you said. There is a time and a place for leaving legacy code alone. I also know from first hand experience some things are just too far down the hacky rabbit hole and you just gotta cut of the dead stuff and start over sometimes. But on the other hand, the only times I've done that in my career the code was written in a very anti-pattern style pretty much against all language guidelines and had hidden side effects everywhere. It was a mess to figure out how some features worked so I just rewrote some features in 1/10th of the time it took the original maintainer to piece in similar bug fixes in the legacy code.

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

#193
post #120

Earlier quoted context omitted.

This is such a great thread.

No it's not. Please don't turn HN into a joking competition. There are other websites for that.

Jokes are fine IMO, low effort referential "jokes" are the problem

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

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

I think using "never" should be considered an exaggeration or embellishment, or else clearly disclaim that rewriting code given the existing needs of the business (including the existing code base) is different from writing brand-new code "from scratch".

Here's why: I saw a comment in some thread about machine learning yesterday that I think is a good analogy in some cases for what you describe. The comment essentially said that a "never re-write" policy leads to "overfitting" the code to the problems of the past and therefore less flexibility in implementing both fixes for issues and new feature development.

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

#195
I job-hop a lot in corporate environments (mostly Fortune 100), doing DevOps for legacy systems/teams rather than coding. As such, I don't push for anything when I first arrive.

It can take a while to understand how all the moving parts interact, both technically and organizationally. The systems in question are sometimes responsible for tens or even hundreds of millions of dollars in business, and critical corporate functions. Wading in with "Hey, I know more than you, stop doing that and do this instead" is the short path to sudden emergency downtime for production systems! And that's knowing they hired me because I'm the expert and know more than them.

So there will be processes that are really, really stupid. Slow, inefficient, maybe completely dysfunctional. But if they work, they work. Fixing/replacing them means interactions with other processes that can be very difficult to pull off. Process is usually a Big Ball of Mud Antipattern at the point I'm brought in, and fixing anything in the Big Ball of Mud is a challenge.

As for legacy apps... yes, built with antiquated technology, often poorly implemented, with a lot of uncertainty and fear. Change is really scary. What to do about this stuff depends on what the long-term vision for the product is. Is it in maintenance mode, or under active development? Is there a plan to replace it? Is there a realistic plan to replace it that has working results and a viable schedule? Generally, the best thing to do is leave the scary ugly thing alone. It was probably done pretty well back in its day.

Where I usually find myself making progress early on is finding things that are broken due to communication problems. One team says one thing, the other team says another, and everyone is mad and nothing gets done. Often, it's just a matter of rephrasing things to both teams, to find common ground and a way forward that everyone wants.

So really, my expertise isn't cool tech. It's being a good communicator on the engineering rather than the management side, someone with both development and operations experience who can speak to the concerns of both sides, and has seen similar problems in other organizations (big organizations like these usually have 10+ year people in key positions, who have no idea how the rest of the industry works anymore).

So yeah, the first thing I push for? Learning the lay of the land, so I can start charting paths.

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

#196
Auth. If you can stomach it, back it up with a real directory service. JumpCloud is a great way to do it. It's free up to 10 users. You can use it with Google Hosted Apps as your user backend. You can set it up in 10 minutes. It has TONS of features, you probably won't look at them all once you can use it as an SSO/LDAP provider, you can forget about all that until you need more. Also you can easily replace it with something self hosted if you grow to the point of needing to do something else.

Determine if you need organization level RBAC (Role Based Access Control). Does your app need to have account managers at the customer level? You probably know from the outset if you'll face this problem. It's a big pain if you get someone to implement your product somewhere, then they lose that person and they have trouble accessing their account. Not that you can't provide support to solve it, but the legal side can get tricky and no matter what you lose face with the customer over the frustration. DockerHub messed this up IMO and that's why they haven't added it, because it's too complicated to add now.

You can easily have a simple SSO layer on top of it so your super admins come from the LDAP(or other) and user/customers are a separate DB in your existing app. It can be really expensive to add complex auth or change how it works later, but a stitch in time makes it easy to grow and adapt. This helps tremendously for DevOps, deployment security, managing things like white label licenses, and a host of other things.

Once you have it, it keeps you from writing terrible solutions to dance around having things like user account profiles. API keys if you need to offer them become easier and control of important assets are much less scary. Also you are ready to implement things like IAM management or whatever to keep track of deployment keys before you end up with a giant pile of security holes. JumpCloud offers a pretty turnkey IAM integration for AWS and others.

After that, getting paid. Figure out how to take money as fast as possible with the least friction. If you have auth and the ability to take money easy, pivots come a lot easier too. Since you have proper auth, things like subscription management becomes an easy reality without leaning on 3rd party vendors. Though just using stripe for that can be good enough, still you'll need to tie it to accounts. Especially if it's enterprise.

Something I've done recently that is now a part of my "get started fast" kit is automated DNS and TLS (via letsencrypt) with kubernetes. Might not be for everyone, but now that I'm on the other side, I'm not going back. I can tie a feature branch deploy via helm chart to it's own DNS endpoint defined as the host in the config, protect the ingress via LDAP, and make sure QA has an endpoint to review that won't be interrupted until the ticket is closed. One command and it's deployed and secure. Also this enables devs to deploy their own workspaces for effortless experimentation without disrupting dev/staging/prod, which shouldn't be used as sandboxes for features or QA IMO.

* http://www.jumpcloud.com

* https://www.keycloak.org/

* https://github.com/kubernetes/charts/tree/master/stable/exte...

* https://github.com/kubernetes/charts/tree/master/stable/cert...

* https://github.com/kubernetes/charts/tree/master/incubator/k...

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

#197
post #34

I go from git to SVN. It's just easier for me to work with and once the team gets used to it, it's a win-win.

So as soon as you get a new team, you make them stop using the thing they are comfortable with, so you can use the tool of your choice.

Man, that's such a dick move.

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

#198
Joining a new company is like starting a new life, which doesn't seem to happen many times in a life time. It is like you are being given another opportunity to start fresh. First thing then to do is gain respect, learn the culture. It is going to be uncomfortable for a while, so it is important to keep the opinions under check. Let the actions speak more than words. Remember that every design issue is a choice made by someone else to the best of their abilities. Finding a way to move forward without making too much splash automatically unlocks the doors. There will be lot of things to implement and you will find a way and while doing so you will learn a lot.

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

#199

Earlier quoted context omitted.

VPN?? For what?

Not parent, but generally to be able to do remote work. Production goes down and you're not at the office (1h travel)? Now even a 1min fix will cause 1h + 1min of downtime.

So is your cloud in the office then?

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

#200

Earlier quoted context omitted.

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

"Daily standups" are morale killers.

Would you mind expanding on this? I'm interested how your experience with them differs from mine.
Post reply on HN