On God. My days of dealing with Atlanta rush hour traffic and office politics are over.Convenience >>>> status
On God. My days of dealing with Atlanta rush hour traffic and office politics are over.Convenience >>>> status
We were waiting for someone else. I get it though because they "meet" the hell out of these people.If your people are anything like mine, you ain't miss shyt.
shyt, at least 5 minutes of every 30 minute meeting on my calendar is waiting on everyone to join, and half the time it's waiting on the person that is hosting it to join. So then it becomes engrained for shyt to start late, and it turns into a self fulfilling prophecy.What we won't do is perform wildcard searches on names to identify data. What was the point of putting in a true/false flag field if you aren't going to use it? I hate when people go around poor data habits instead of fixing what's causing the issue. If the users aren't doing x, train them hoes or put automations in the system to remind them.
If users keep inputting trash data into the system, you're going to die trying to write exceptions AND keep up with exceptions. This is why companies rarely have documentation because they rarely take time to develop a standard process.
We were waiting for someone else. I get it though because they "meet" the hell out of these people.
What we won't do is perform wildcard searches on names to identify data. What was the point of putting in a true/false flag field if you aren't going to use it? I hate when people go around poor data habits instead of fixing what's causing the issue. If the users aren't doing x, train them hoes or put automations in the system to remind them.
If users keep inputting trash data into the system, you're going to die trying to write exceptions AND keep up with exceptions. This is why companies rarely have documentation because they rarely take time to develop a standard process.
We were waiting for someone else. I get it though because they "meet" the hell out of these people.
Not necessarily at the coding part yet, more like defining the data criteria for a certain metric. The issues we're having is defining the criteria behind potential new clients. They have a flag field; True = Potential New Client or False not a client because they didn't convert to an actual client.are you talking about sql?
give them a stored proc that does it (on a per "key" basis).
they can use that for their queries and that will help them identify the incorrectly set flags and it shifts the work (resource usage etc) back to them.
also means you might be able to draw a line under your participation and shine a spotlight on their inaction.
Not necessarily at the coding part yet, more like defining the data criteria for a certain metric. The issues we're having is defining the criteria behind potential new clients. They have a flag field; True = Potential New Client or False not a client because they didn't convert to an actual client.
The users who input the potential new clients on the front end aren't consistent with using the flags and there doesn't appear to be any automation in place to check/uncheck the flag. Instead, they add "Potential -" to the front of the client name and if they convert, they edit the client name to remove it And it's not just the word potential, could be any combination, hence the wildcard searches.
My suggestion was to automate the front end to automatically manipulate the flag, so the backend definition is clean; Count when Flag = True is better than Count when Client Name like... IMO it's more efficient to clean up the front end where the users are inputting trash than keep coding for exceptions.
Executive VP over at a bank emailed me offering me a position, but it’s not remote. I can’t entertain it
Convenience >>>> status
Not necessarily at the coding part yet, more like defining the data criteria for a certain metric. The issues we're having is defining the criteria behind potential new clients. They have a flag field; True = Potential New Client or False not a client because they didn't convert to an actual client.
The users who input the potential new clients on the front end aren't consistent with using the flags and there doesn't appear to be any automation in place to check/uncheck the flag. Instead, they add "Potential -" to the front of the client name and if they convert, they edit the client name to remove it And it's not just the word potential, could be any combination, hence the wildcard searches.
My suggestion was to automate the front end to automatically manipulate the flag, so the backend definition is clean; Count when Flag = True is better than Count when Client Name like... IMO it's more efficient to clean up the front end where the users are inputting trash than keep coding for exceptions.
If it hits and jobs are slashed, I rather already be at home then to be leaving the office with a box
But when this recession legit hits, how long will remote work last?
Depends on how an organization is setup and if their roles can be sent overseas.
But when this recession legit hits, how long will remote work last?
But when this recession legit hits, how long will remote work last?
I’m saying!!!You better tell the front-end people to learn what a checkbox or a dropdown is and stop letting these users type in their own statuses.