Or to put it another way, if you push everything into the AI, then you going to become entirely dependent on those people who can keep the AIs running...

If you only have the one or two production systems/databases, and you're having to do this more than a couple of times each year, then you could certainly benefit for improving your tooling.

But if you've inherited a large number of production systems, each with their own local database instance. Then implementing new tooling will be a long process that you might not be able to get Management to agree to.

When I have to touch a production database, I usually use the following steps:

0. Follow your organisation's Change Processes (i.e. if you need to put in a change request and get approval then do that)

1. Snapshot the server itself (VMs are great for this)

2. Backup the database (just be careful not to leave that backup anywhere open, and remember to clear it up when you no longer need it)

3. Write the SELECT version of your SQL first (If you need to delete a record from the userSessions table with an ID of 123, then start by writing

  SELECT * FROM userSessions WHERE id=123;

  DELETE FROM userSessions WHERE id=123;

6. Run your SQL

7. Do all your sanity checks to make sure that production is working as expected.

8. If it does go wrong then you have more ammunition to use when trying to convince Management to spend some resources on improving your tooling for these sort of changes.

For example a team that couldn't write a new encrypted messaging app without AI, gets an AI to write them one. How do they check that the code is actually secure? Writing encryption code is very hard to get correct, in fact most humans can't get it right, and if you don't understand the intricacies of cryptography then you'll never pick up the mistakes the AI makes.

Back in the day I used to have a desktop running, with applications, in just 512KB. Getting that memory upgrade to a full 1MB was amazing.

My favourite response from one of a suppliers who hadn't implemented rate limiting was "Please stop, you're making our database cry" :D

I recently fitted one on my F91-W and it certainly makes a difference, but it's not going to make the light brighter like some of the other LED mods people have done.

Walking the board feels a bit awkward and slow at first, but after a few weeks you find that it takes very little time. It certainly works well for us.

From my point of view the power of automation for recurring tasks is less to do with time saved, and more to do with making sure that it will get done and be done the same way every time.

Bonus tip: log the outputs of automated tasks when they run, but only send out notifications of errors - that way you don't train staff to ignore the notifications from the task just because they see it every time the job runs, and instead seeing a notification from it is rare, so they know they need to investigate.

It's not uncommon to feel the way you are during the second and third years - my advice is to recognise how you're feeling and then work out how to push forward (which is what you've already started to do).

My advice for how you can compete with large research projects full of postdocs is, don't try to. You're not in competition with them, you are doing your own research. It might be in a tiny niche area, but it's your area and it's new knowledge.

* The Tusks of Extinction by Ray Nayler (Short, but a great read)

* The Incandescent by Emily Tesh

* The Armchair Universe by A.K.Dewdney (First read this one many years ago, but I've been reading it again)

* Final Orbit by Chris Hadfield (third book in a series, so you'd want to start at the begining with The Apollo Murders)

In the past I've heard that some banks put a decimalisation layer on top of their existing business logic, that would translate between the old Pounds, Shillings and Pence currency, and the new decimal currency. I wonder if there are any banks out there which still have Pounds, Shillings and Pence at the heart of the computer systems.

With the way Stashes are implemented, you don't have to worry about someone accidentally pushing a branch up that was really just some changes they wanted to store temporarily without messing up the repository's history.

With the way Tags are implemented, you don't have to have an agreement with all your colleagues about how a branch should be named to represent a tag. You also don't have to worry about how you have named the branch you're working on that will add support to your current project for it's own concept of tagging.

At the end of the day I had a Perl script that used a regex to extract each top level element in the XML, which it then could attempt to parse. If the element parsed correctly then it was put in known good file and if it didn't parse then it was put in it's own separate file. Luckily there was only a handful of those invalid XML elements, which I could fix up by hand and then stitch back into the known good XML file.

a) I can ignore it until I have time to look at it

b) You can see who else has already been involved in the conversation - seeing a fellow team member being involved can help avoid falling for situations where someone is trying to work around one of your colleagues who's already told them they can't have what they're asking for.

c) The chat message is from an individual, so you only get their interpretation of what's happening - if there's an email thread then there's going to be multiple people involved, each with their own perspective.

Comments URL: https://news.ycombinator.com/item?id=44721401

Points: 1

# Comments: 0