Reminder: The terms of service apply here too.
Logo design credit goes to: tubbadu
Programmer:
Don't be a smart ass, write good code that others can improve.
Listen to everyone: others programmers, managers, clients, bosses, etc.
Follow all the procedures, don’t pretend you’re above anything.
Read books because the programming world is changing once or twice a year, and you don’t want to be the guy who is behind the current trends and best practices.
How do you decide which books to read?
I pick either what I find interesting, what is recommended to me or what is relevant at the moment.
Software engineer.
Understand requirements even when they’re not communicated clearly (or when you have to guess and make them up yourself)
Tell an idiot they’re wrong without telling them they’re an idiot.
Write code other people can maintain.
Do you have any favorite ways to tell idiots they're wrong without telling them they're an idiot?
"I've actually tried that exact same implementation elsewhere and it didn't work."
Makes them realize they're not original or as knowledgeable as they thought.
That's a good one!
Ya know a lot of ppl think pharmacists are just about putting pills in a bottle… but in all honesty in the role that I work clinically in a trauma center, I would say what sets a good pharmacist from a mediocre one is being able to catch everyone’s mistakes.
Your fellow pharmacists, techs in the pharmacy make mistakes (150 bicarb in 1/2NS?? lol) (incorrect pre packing procedures and getting kcl w an asa label)
Your docs make mistakes (2000mg q12 vanc on an esrd pt with a bmi of 45 + Zosyn 4.5 q6)
Your nurses make mistakes (y-site compatibility, missing doses, losing meds, etc)
The issue is noticing the problem and taking initiative to fix it. Unfortunately, either by ignorance, not correctly verifying, or just plain laziness can lead to sub optimal care for our patients.
It’s not easy though. I easily go through 500-1000+ orders a day, while calling doc/nurses, double checking techs and other pharmacists work. It can be stressful, and it’s easy to put blinders on and just keep hitting approve, but the pharmacists who look at that 4th 40meq kcl bag of the day for 1 patient without a lab drawn in 18 hours and calls the provider to see if maybe they want to draw a lab before the next admin. Those are the pharmacists doing a good job. This can go for the retail folks too who have to put up with way more shit than I.
What percentage would you say of your peers take the initiative in the way you describe? Is this a teachable skill or an inherent part of someone's personality?
75-80% of the time. All the staff I work with will take initiative at some point, but some do it more/better than others. I have a certain level of trust with some co-workers that I do not with others.
As an example, We have 15ish pharmacists on staff (non-admin) and 25-30 techs... There are probably 5 or 6 pharmacists and 1/3 of the techs, that when I come in (rotating schedule btw) and I see "those people" are working I know I need to buckle down and really scrutinize what is going on.
Now, like I said in the first post, everyone makes mistakes. Including myself. But I think there is a difference between the mistakes and how they are handled.
There is this mentality of "I didn't do it, So it isn't my problem". When really we should be looking at it as an "institution problem", or its everyone's problem! For example, the other day a doc called about starting a bicarb drip on a Hyperglycemia patient. We have a policy on hand to do 150 bicarb in 1L Sterile water. However, this one pharmacist doesn't like using sterile water (because of HYPOtonic concerns), so instead talks the doc into doing a 150 bicarb in 1/2NS (well this makes it a HYPERtonic soln now and the patient only has a peripheral port AND their sodium is already 141)... OK well when it got to the IV pharmacist, they shouldve said WOAH what it going on here! Instead they let it through because another pharmacist did the order and it isn't theyre problem if something goes awry. I would have called out there and said WTH are we doing? this isn't policy! and got it changed.
In the grand scheme, the ordering pharmacist did talk to the phsycian and got the okay, but in the real world physicians are not as infallible as they are portrayed, and our pharmacist gave an inappropriate option for treatment, which the physician trusted was an okay treatment plan. Was the patient injured by a single infusion? no. However, it was a continuous infusion and when I saw the nurse was asking for a refill to start the 2nd dose, I said WTF is going on here and started digging.
Let me say though that this is a national problem, not just my hospital. Also, the things that usually go through when they shouldn't is stupid things that never effect the patient. When it comes to dangerous medications, we have different procedures for checking of orders, or it goes through a specialist pharmacist first (eg: chemo pharmacist, pediatric pharmacist, critical care, infectious disease, etc you get the point). It is more of an annoyance on my part because I usually take the time to fix a problem when I see it, and other will let stuff slide because theyre not the ones who'll get the variance, and it won't hurt the patient anyways.
Just for posterity sakes, if you are curious, what is a "mistake that doesn't effect the patient"?
Example: We have a NICU and those little babies will be put on continuous infusions sometimes like dopamine to improve their cardiac functioning. So, all our NICU orders are standardized to the weight of the baby to determine the size of the order. So let's say that the order calls for 0.06ml/hr. That is 1.44ml/24 hr period. So, we would most likely send a 3ml syringe (to allow for titration). Well when the order is sent electronically to the pharmacy it always come stock as 1ml, and we have to change it to the appropriate size. If it isn't then the nurse will be calling for refills more often than needed based on titration (1ml = 16.6 hour infusion). This is a mistake that is counted towards us.
Is it teachable? sure, pharmacy school rammed it down our throats. However, being short staffed makes people cut corners, and that become the learned state in those situations.
A little off topic but some of your comments reminded me about the HBO documentary "Savior Complex" about a young American woman in Uganda treating babies for malnutrition with no medical training. She was just giving them IVs willy nilly without consulting doctors.
Our hospital pharmacy has a white board for updates and statistics tracking that has a section called "Good Catch." Let me tell you, some of the things I've seen on that board...THANK YOU for sparing us. (KCl labeled as asa? As a critical cardiac care nurse, I am duly horrified.)
KCl labeled as asa? As a critical cardiac care nurse, I am duly horrified.
Trust me, so are we. Typically, the reason for the mislabel is due to the machine that is used for pre-packing from stock bottles. For the most case, standard meds are given their own containers for the machine, but when there was a KCL shortage going around something happened where a standard container was used for a non-standard medication and they didn't make sure the old container was cleared before adding the new medication.
That being said the pyxis pharmacist checking, should have looked at EVERY pre-packed med (100 per batch typically) and see that they all looked correct (eg: no doubles, empties), and would've seen the size mismatch between the 2 meds lol. We have some great techs though and one of them caught it as they were doing their pyxis load.
Love my crit care nurses though! We have 5 ICUs (+ ER/Trauma) and most all those nurses typically have their stuff together, which makes my job much easier, when I gotta call with questions! So, thank you for being on the ball!
I mean my second thought after sheer horror was that I'd definitely notice this baby aspirin is uhhh...a giant horsepill? That would seem very odd. But like on my end what am I supposed to do to verify, lick it? 😂
And we appreciate the shit out of you right back. The number of times we've had something going down and called pharmacy: "Hey I have a stat order for..." to be interrupted with: "It's already verified."
Seriously, thanks for everything you do for us.
I'm a truck driver and it takes constant attention and awareness and an expectation that other drivers WILL try to kill themselves using my truck. It also helps to have a ton of patience, and if you're an irritable person or quick to "road rage" you have no business behind the wheel of an 80,000 lb machine. Just always pay attention and be vigilant, and be safe, not fast.
Do you think the industry does a good job keeping unsuitable drivers away from trucks? What would help?
I do think most companies do a good job and safety is their priority and most drivers have the right mindset. I feel that paying drivers by the mile instead of percentage of the load or hourly is the biggest factor in why drivers try to rush and get frustrated though so if that was an industry wide change I think it would help. Overall I think that unsafe drivers are a very small portion of the workforce but the average person would only notice those few, a polite, safe, driver is mostly unnoticed because they're just doing what you expect.
Network engineer. No one thinks we can do our job because the first thing people do is blame the network.
Yo be a good network engineer you need to be able to troubleshoot everything apart from the network.
Same. But I'm lucky to be in an industry where most people involved are aware of the difficulties that come with running a highly dynamic network with satellite locations connecting in via VPN over vsat.
"2mbit isn't enough? Sure, we can increase it to 5mbit, just sign the purchase order for additional 5000$ per month"
Document every single thing that causes you to change your work plan and who is responsible for said change. Getting the job done is secondary to making sure anything you do can be billed to someone, and you better not do anything that helps the job get done if you can't bill for it.
Construction is fun.
If you had to estimate, what is the breakdown between time spent working and time spent documenting billable activity?
Depends how much fuckery is going on. If other trades are lying about their progress (which happens a lot) then sometimes the whole day is spent documenting instead of working. If everything goes smoothly though it's probably 5-10 minutes of documenting per hour of work.
As a facilities engineer of a newly constructed building...you're god damn right, and it's a good thing too, because I'm the guy who discovers that the reason one of our toilets exploded is because 14 months ago during construction someone went "lefty-tighty" and I wanna know who it was goddamnit.
Gladly pay hundreds of thousands now to save millions later
I have to ask about your username. What is that about?
I like the cold.
I’m an industrial project engineer and I’ve always referred to it as Professional Cat Herding. I get handed a goal (replace some piping, fix a tank, build a new thing, etc) and I have to get the operators input on what they need to run the system easily, I need the maintenance people’s input to make it easier to work on, I need the process owner’s input to make it optimized for production. All of these inputs will change a hundred times as there are always multiple crews/groups with different priorities and a lot of them oppose each other.
Once I have the design in place, I need to wrangle a group of laborers, a crane operator, the scaffold builders, the painters, the electricians, the inspectors and the parts so everyone and everything shows up at the same time to the party. That means meetings to make sure they know what the goal is, training completed to get them on site, lead times on parts sorted out, etc.
When everyone and everything finally shows up it’s mostly just running around like a maniac to make sure work goes smoothly with no injuries or major setbacks by ensuring everyone is communicating well with/through me. Halfway through there will be an internal request to change some aspect of the job and it’ll be on me to weigh the pros and cons of modifying a project mid-way through. These requests are denied 90% of the time, the rest cost a fortune to implement.
So ultimately, what it takes to do a good job is communication, patience, and attention to detail. For larger jobs that interrupt production or maintenance, a well-timed delivery of breakfast burritos helps as well.
Hey, I've worked with guys like you, and the good ones are freakin magicians.
When I come to them with a problem, everyone says "I'll make some calls". The good ones actually do it and follow up.
I asked someone else here a similar question: do you think communication, patience and attention to detail are something that can be taught? And if so how did someone teach you, or how have you taught others?
Facilities engineer here, but also part construction manager since our building is halfway under construction.
A good sense of prioritization. We get requests from dozens of teams and they all say they're urgent. Some of them are, some of them aren't. Learn to ignore the unimportant stuff, and more importantly learn how to tell someone with a fancy job title to piss off.
Communication. A good portion of problems I've solved have been from half-remembered conversations. "Oh, the doohickey is acting weird? I remember John was talking with one of the Doohickeys International designers the other day about a new issue they had, let's go talk to John". But not just office talk, also documentation. Every time you see something or fix something, document it, because it might break again in 6 months and it might be someone else trying to fix it, and you can make their job a whole lot easier.
an eye for details. The difference between "oh wow that was almost a major problem" and "OH GOD WE ARE SO FUCKED" is often someone walking past and saying "huh, that doesn't look quite right"
Remarkably similar to software engineering.
I will add that there is a system widely used in the software world that is genuinely life changing and should be adopted everywhere. We call it "blameless post mortems".
The idea is that, if something goes wrong, it's not the fault of the person who happened to do the thing that caused something to break. It's a problem with the system that allowed that thing to happen in the first place. It gives people the freedom to be wrong without fear of repercussion and for your coworkers to work as a team to solve for this shortcoming together instead of heaping blame on one person.
A pallet of glass bottles fell over when Tony tried to move them with the forklift. Where they stacked correctly? Maybe less flexible packaging would reduce flex. How were the forks positioned when he started to lift? Could we make color coded indicators for where the forks should be before attempting to lift? If the forklift was moving, how fast? Should we have speed limiters installed/adjusted? etc etc..
That's how I always approach complaints directed at my team. "Oh, so and so shouldn't have done that way? Is that process documented? Are the instructions clear?". A lot of the time it's not their fault because they were doing the best they could with the information they had available. Of course the people responsible for providing these documents don't want solutions, they want to bitch.
Generally you are right but it amuses me when the opposite extreme happens. Like a month or so ago I had a client insist I document how the electrician should put wires into terminal blocks. I suggested that they get a new electrician if they couldn't figure out that a screwdriver is the correct tool for screw terminals and that the wire labeled 100 should go in the terminal block marked "100".
Sometimes someone is just to blame though.
Finding a scapegoat is obviously an awful practice, even though many companies do it. But the opposite is just as useless: you end up doing a bunch of mickey mouse bullshit "process improvements" that make everyone's job harder while everyone avoids talking about the fact that Tony should never have been allowed within a hundred feet of a forklift because he's a terrible driver.
Typically in our after action reports we're good at finding both the systemic and human error causes of issues. And the root cause of most issues is not human error per se, just unintended consequences of what seemed a good idea at the time. Which should not be punished (unless someone was just being really stupid). But sometimes an incident is a result of a total failure to do your job - cutting corners, going through the motions without thinking, failing to notice something that's obviously wrong, etc.
Senior IT manager: communicate. Negotiate. Plan. Help people get along. Make good architectural decisions. Know when it's ok to make bad ones without too much risk.
Cardiac critical care nurse: Stay calm.
The more critical a situation is, the slower and more deliberately I move because mistakes waste time. We have a saying "slow is smooth and smooth is fast." Validate and verify everything.
Validate monitoring: Is that heart rate or blood pressure really that high or low? Don't just believe the computer monitor, grab a stethoscope and listen to the chest, grab a manual BP and double check. Does the appearance of the patient correlate with what the numbers say? (ie: does the human being look as sick as those numbers imply?)
Verify interventions: I think to myself "clamp that line, unclamp this line, attach that device, open this lid, engage the safety on this needle" with every action. Repeat out loud to colleagues in the room what you're going to do, then after you've done it, say out loud again what you just did. Especially if you do something out of the ordinary or unexpected.
Like yesterday, we had a patient who suddenly had symptoms of a myocardial infarction ("heart attack"), had some concerning findings on EKG, so we were trying to draw blood labs urgently and having such a hard time that one of the doctors even had a needle trying to help us. I was leaving the room to get more supplies and I took a bunch of trash with me, so I took the 3 seconds to count what I was holding and said out loud, "There are no sharps in the bed, you guys, I have them all," because we were just laying discarded needles (with safeties engaged) on top of the bed blanket.
Two minutes is an eternity when life is on the line. Slow down, don't hurry, do things on purpose, double check what you're doing. That's a lesson applicable to a surprising number of life situations
Your comment about saying actions out loud reminds me of the "pointing and calling" method that Japanese train conductors use.
I'm unemployed so.. I just have to be there 🤷
Well you could still be in charge of a club, game group, volunteer thing etc!
Im in charge of making sure engineers and mechanics/technicians adhere to my company’s current electrical wiring standards.
Memorizing every little detail is almost impossible so its easiest to just have an eye for what’s wrong and knowing where to look for the correct answer
I am a product manager.
It's a great job for someone who cannot focus, since it's not really one job.
Each of these areas is a discipline onto itself. In my case for example, technical skills involves working with mechanical, electrical and software engineers.
Needless to say, you don't get to be very good at any of this. And you shouldn't either. A great product manager is enough of an expert in all of the areas to recognize problems, and set the framework for solving it, but will allow the experts to do their jobs. Focusing too much on technical expertise will make the PM too much of an engineer.
How do you prevent yourself from getting too focused in one area?
Automation engineer. No one likes us and it is impossible for me do my job well, only to do it poorly.
Why is it impossible to do it well?
You are buying a machine that say heats up enough milk to pasteurization temperature to supply a small city for a week. You are dropping about 10 million dollars on this project. Do you really care that the 3k dollar control system has nicely commented code or is it enough that the system works?
Very few customers are buying the products because of the automation. They are buying it for the process. If I make sure the interface looks nice, the code is rock solid, and add in some cute features they might appreciate it but more likely not see the point. Would you buy a car because it integrated well with Siri?
Additionally everyone has a different philosophy of UI and every engineer thinks they are an expert on this stuff. That's why I have one customer yelling at me that the little motor running light should be green and it always has been green while the other insists that it is red and always has been red. Plus the half remembered fixes that no longer matter. VFDs used to require external chokes, they haven't since the mid-90s and yet some concrete guy will insist that they do.
Basically I still get to be a job destroyer but with two hands tied behind my back.