Was thinking about moderators, and how users always have plenty of opinions about what moderators are doing wrong, but seems like you see less commentary from the moderators themselves about what it takes to do a good job.
Which is probably true across any situation where there’s a smaller number of leaders and a larger number of people in other roles.
Having experienced it, what does it take to lead a project, be a supervisor/boss, board member, pastor, dungeon master, legislator, etc?
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!
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.
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.
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.
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.
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.
-
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!
I am a product manager.
It’s a great job for someone who cannot focus, since it’s not really one job.
- Communication skills: You need to both gather information from customers, and sell your ideas inside the organization (as well as to customers)
- Technical skills: You need to be able to explain your ideas to engineering teams and understand the limitations / opportunities afforded by the technology you work with
- Business skills: You need to understand the business your product exists in, and ensure that your product serves the needs of your own employers needs (like, supports processes, works well with other products and services). In a B2B context, you also need to understand your customers business.
- Management skills: You most likely need to set goals for other people and design how other people work around your product. This will include areas like HR management, process design, legal etc.
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.
