|
mewse posted:PC load letter? What the gently caress does that mean?! It's like a Piñata, except that instead of breaking it open to shower sweets everywhere and give all the children stomachaches, breaking it open will shower toner everywhere and give all the adults cancer! 
|
#
?
Nov 23, 2013 02:13
|
|
|
|
| # ? May 10, 2024 19:55 |
|
|
I've seen a book mentioned a few times in these threads for IT management. Anyone remember what it is? Or maybe have one they recommend?
|
|
#
?
Nov 23, 2013 02:40
|
|
|
Volmarias posted:It's like a Piñata, except that instead of breaking it open to shower sweets everywhere and give all the children stomachaches, breaking it open will shower toner everywhere and give all the adults cancer! To be fair, everybody loves cancer 
|
|
#
?
Nov 23, 2013 02:45
|
|
|
What is it about Access that makes every problem look like a database-shaped hole? Today, I had a discussion with one of our project managers about how he wants to solve scheduling problems for his department (of around 10 people) using an ~*:AcCeSs DaTaBaSe:*~. He wants to let people add their own time estimates. He wants to pull information about projects and employees from our existing SQL databases. He wants to ignore the two other programs we’ve already go that do exactly the same thing. This is after he designed an ~*:AcCeSs DaTaBaSe:*~ for another project that is currently overdue about twice over. There were at least three major problems they had to consult me on. I made it clear before he started that Access was the wrong tool for the job, and that I wouldn’t and couldn’t support his little puppy when it poo poo the carpet.
|
|
#
?
Nov 23, 2013 02:50
|
|
|
They've probably used it once before in a previous job a decade ago and it got them their very own 'custom program' for cheap (because the intern did it). They haven't had to deal with the fallout, and as far as they are aware it's a way to make custom software. And custom software will always be better than off-the-shelf because it exactly mimics the current workflow, regardless of whether that workflow is in any way efficient.
|
|
#
?
Nov 23, 2013 03:25
|
|
|
thebigcow posted:The two Toshibas we've had like to give numerical error codes without providing a list of what they mean. It took some searching to find out that 0050 on a fax meant busy signal, everything else meant a line condition problem. This wasn't wasn't quite as bad as a lot of others since we already knew the problem was network connectivity going in, but the other month I was trying to get scanning to an SMB share working and it just kept saying "FAILED." No reason. Not "Path not found", not "Username/password incorrect" not anything about rights issues. Just that the scan job failed. loving thanks, I didn't realize the scans weren't going through before you told me!
|
|
#
?
Nov 23, 2013 04:31
|
|
|
Caged posted:They've probably used it once before in a previous job a decade ago and it got them their very own 'custom program' for cheap (because the intern did it). A huge protect I was on for years got canned partially because it didn't mimic the current workflow because by automating a lot of stuff we kind of made an entire department with a lot of political power within the organization obsolete. Woops.
|
|
#
?
Nov 23, 2013 05:14
|
|
|
I had to explain to some super-aggressive DBAs in a meeting that while I supported their log-scrape witch hunt to discover why oracle poo poo the bed over the weekend, they simply could not forward me 5 pages of /var/log/messages starting 30 minutes before the incident, with dozens of lines they thought "were concerning" bolded and underlined. Lines that included our puppet runs updating various unrelated files on the system and a ntpd restart 25 minutes before the crash. They demanded I explain line by line what each item meant and also provide documentation on everything puppet does so they could examine it for "any possible conflicts". I told them that puppet runs enterprise wide and has been running for over 2 years without issue. I then, sadly, made a cardinal sin: I told them that oracle was simply another application, it was not special, and that while it may have more specific OS requirements like kernel parameters, in general when an app crashes, you need to look inside the app not outside of it. Furthermore, without a foundation in operating systems, I was unable to explain to them the intricacies of common system functions, much like I'm not qualified to evaluate database architecture decisions. WOW, were they not happy. I could have absolutely been more helpful had they not been desperately trying to point the finger at my group for the outage. The idea that someone has access and control over their beloved servers has made them resist automation on many servers for months and months. "Why no you can't just stamp out an oracle server! It is NOT just another app! It requires endless customization and tweaking and DBAs logging in to keep running! Oracle servers are like beloved pets that require care and attention!" Bullshit. Get with the program. You are not special. Welcome to the cloud, motherfuckers. We shoot servers in the head and bring up identical ones every single day. Oracle is no exception. Bhodi fucked around with this message at 07:23 on Nov 23, 2013 |
|
#
?
Nov 23, 2013 06:52
|
|
|
Bhodi posted:Furthermore, without a foundation operating systems, I was unable to explain the intricacies of common system functions, much like I'm not qualified to evaluate database architecture decisions. I wish more of us ("us" being I.S. professionals of all specializations) would get over ourselves and realize that the other specializations all bring unique and valuable knowledge and skills to the table. I'm a developer. I'm not better than the network admins, I'm not better than the DBAs. I just know different poo poo. I couldn't set up or manage a network of any size worthy of the name, virtual or otherwise, and while I'm sure I'll pick up a few things as I get on in years, I'm going to want to continue to trust the network people to do network and the database people to do database. jim truds posted:I work in the pettiest environment. This is the same environment everyone else works in when everyone isn't personally invested in whatever the company is doing (e.g. anything that isn't a startup). It is an environment full of failures and broken dreams, where the only measure of self-worth some of them ever get is getting one up on someone else. They have no power in their own lives. So they must try and take it from yours in any way they can. This was my last boss, which is its own special level of hell compared to just another employee who doesn't have any direct authority over you.
|
|
#
?
Nov 23, 2013 07:16
|
|
|
Bhodi posted:I had to explain to some super-aggressive DBAs in a meeting that while I supported their log-scrape witch hunt to discover why oracle poo poo the bed over the weekend, they simply could not forward me 5 pages of /var/log/messages starting 30 minutes before the incident, with dozens of lines they thought "were concerning" bolded and underlined. Time for you to learn your job. You run puppet/chef? Great. But either you shouldn't be in a position where DBAs are asking you what common systems functions do and their intricacies, or you should be able to answer them. Believe it or not, 5 pages of logs isn't a lot. And if you can't identify what's "concerning", you're no better. It's your job to track down what happened. When Oracle pegs a CPU because it's overflown a 32 bit counter and gettimeofday() is negative, is that an oracle problem? Or is their job to keep the database performing and your job is to keep it running. For better or worse, production databases ARE special.
|
|
#
?
Nov 23, 2013 08:36
|
|
|
evol262 posted:Time for you to learn your job. You run puppet/chef? Great. But either you shouldn't be in a position where DBAs are asking you what common systems functions do and their intricacies, or you should be able to answer them.
|
|
#
?
Nov 23, 2013 08:53
|
|
|
anthonypants posted:From Bhodi's post I got the impression the DBAs were asking questions like "What is the function of #include?" Even (especially) if that's the case, you have to learn the boundaries of your job and what you have to suck up and take sometimes. Explaining and diagnosing systems to someone whose primary duty is "make sure the database performs well, stays up, and handles application needs" is part of that. Oracle may not have crashed because of the system. It may have been the app. But when another team comes to you and says "I'm concerned about XYZ", you need to say "XYS isn't a problem in a general sense because..." Or " isn't a problem in this case because..." You don't get to say "applications crash and you're not special". Learn to get the ball back in their court
|
|
#
?
Nov 23, 2013 09:22
|
|
|
The best response to the DBA random finger pointing: "Please explain to me why X concerns you? What makes you think that?" Their common thing is, "Prove to me that this line didnt cause the outage!" Thats a common thing idiots do. You need to turn it around and ask them why they think it caused the outage. That fixes a lot right there. Explain the "Burden of Proof" logical fallacy to them.
|
|
#
?
Nov 23, 2013 09:44
|
|
|
nitrogen posted:The best response to the DBA random finger pointing: We suffer from the same problem. Our department spends more time proving we're not at fault (and having to figure out what people screwed up) because it's easier for the DBAs to throw their hands up in the air and point at us saying "  this query is taking 100 times longer than usual/this isn't working at all! What's wrong with the network! Prove to us it's not the network!" and it always comes back to them either misconfiguring or making some change and then going " yeah we made <x> change without consulting you, now it doesn't work. THIS IS AFFECTING PRODUCTION."
|
|
#
?
Nov 23, 2013 11:53
|
|
|
My manager hired a guy to a senior developer position without consulting the lead or anyone else in the team, and skipped giving him our standard written test because he was "so good he would have been insulted". Flash forward two weeks and SURPRISE! Guy doesn't know poo poo. Now I'm spending half my days explaining C#/PHP 101 to a guy who's supposed to have 6 years experience and has been hired as at least my equal. Our probationary contracts mean we can ditch him whenever we want, but that won't happen because it would show my manager up for the idiot he is. Newbie also drools when concentrating and won't answer his phone unless prompted. I don't know how none of this came up in interview.
|
|
#
?
Nov 23, 2013 13:05
|
|
|
less than three posted:We suffer from the same problem. Our department spends more time proving we're not at fault (and having to figure out what people screwed up) because it's easier for the DBAs to throw their hands up in the air and point at us saying " Occasionally, just occasionally, this can work in your favour. Like a month or so ago when someone in another department had a problem with integration between a service we run and a service they run. Because of the industry I work in, that means they were able to yell both "this is affecting production" and "this is affecting patient care", and rather than come to me about it they went straight to the guy who is ultimately responsible for both departments and the first I hear about it is when he gives me a terse phone call. I was told to have a solution ready to present to both of them in 30 minutes. The problem? They forgot to clear test data out of their system, which caused conflicts. Congratulations moron, you showed how dumb you are to the guy who has final signoff on all raises and promotions.
|
|
#
?
Nov 23, 2013 14:57
|
|
|
Ghost Cow Goes Boo posted:My manager hired a guy to a senior developer position without consulting the lead or anyone else in the team, and skipped giving him our standard written test because he was "so good he would have been insulted". Flash forward two weeks and SURPRISE! Guy doesn't know poo poo. Now I'm spending half my days explaining C#/PHP 101 to a guy who's supposed to have 6 years experience and has been hired as at least my equal. Our probationary contracts mean we can ditch him whenever we want, but that won't happen because it would show my manager up for the idiot he is. Somebody knows somebody.
|
|
#
?
Nov 23, 2013 14:58
|
|
|
Ghost Cow Goes Boo posted:My manager hired a guy to a senior developer position without consulting the lead or anyone else in the team, and skipped giving him our standard written test because he was "so good he would have been insulted". Flash forward two weeks and SURPRISE! Guy doesn't know poo poo. Now I'm spending half my days explaining C#/PHP 101 to a guy who's supposed to have 6 years experience and has been hired as at least my equal. Our probationary contracts mean we can ditch him whenever we want, but that won't happen because it would show my manager up for the idiot he is. Push hard to get this guy out during the probationary period. Things will only get worse.
|
|
#
?
Nov 23, 2013 15:29
|
|
|
Drighton posted:I've seen a book mentioned a few times in these threads for IT management. Anyone remember what it is? Or maybe have one they recommend? The Mythical Man Month is on the required reading list. Brooks managed mainframe development projects for IBM and took away a lot of useful lessons.
|
|
#
?
Nov 23, 2013 16:43
|
|
|
I know it can be frustrating sometimes, but when you're a sysadmin for internal systems, the folks who use those systems are your customers, and you really should treat them that way. Having an antagonistic relationship with them is only going to make your job harder. Think about how "I'm not qualified to explain these logs, but your database isn't special and it's not our fault it crashed," sounds from their perspective. A better response would be to say "All right, give me some time to examine these," then look over the logs, address the entries they're concerned about, and look to see if there is any actual indication of the problem while you're at it. They aren't looking for you to write a book on how their OS works, they're looking for assurance that those unfamiliar log entries don't indicate a problem. As for not being "qualified" to explain those logs...as a sysadmin, your job is going to involve troubleshooting software, often software that you aren't familiar with. If you don't know what something is, Google it. If you can't (or don't want to) take some failing application that you don't know and sit down and at least attempt to do some basic research and troubleshooting to figure out why it's not working, then the sysadmin field may not be the best career choice for you. Also, the DBAs wanting to know what puppet is doing on their system is perfectly reasonable. They don't care how puppet works on a code level, they just want to know what stuff it's managing/changing/adding on their system, which should be easy to figure out and document for them.
|
|
#
?
Nov 23, 2013 18:19
|
|
|
mllaneza posted:The Mythical Man Month is on the required reading list. Brooks managed mainframe development projects for IBM and took away a lot of useful lessons. Still, it's very useful as a piece of history, and it's a short read. Drighton posted:I've seen a book mentioned a few times in these threads for IT management. Anyone remember what it is? Or maybe have one they recommend? For the former, there's lots of stuff out there on IT Service Management/ITIL, but there's a lot of bad advice in those books as well. Read them, synthesize the methodologies, but pick and choose what works for the environment you're managing and throw away the parts you don't need if they don't pay off for you. If you can still find a copy, grab a copy of The Visible Ops Handbook. It's closer to a leaflet than a book, and you can read it in an hour or two, and it does a great job of distilling out the important points of ITIL while leaving out the red tape that doesn't work (which is 90% of ITIL). Even if you're not in the business of building software, most IT teams can learn a lot from software development methodologies. I'd recommend picking up a few books on agile development like The Pragmatic Programmer and Clean Code. Scope creep is a common problem in infrastructures just as much as in software systems. For the latter, there's more great books written on management and leadership than I'll ever get to read. I'm a big fan of Scott Berkun's Making Things Happen, which is a very casual approach towards project management that I've found to work very well. There's also Bob Sutton's The No-rear end in a top hat Rule and Good Boss, Bad Boss (pick one, there's a lot of overlap in content). I'd also recommend at least one book by W. Edwards Deming, who's one of the most influential forces in management to have ever come from the United States. The New Economics is a good starting point. Vulture Culture fucked around with this message at 18:36 on Nov 23, 2013 |
|
#
?
Nov 23, 2013 18:26
|
|
|
dennyk posted:Also, the DBAs wanting to know what puppet is doing on their system is perfectly reasonable. They don't care how puppet works on a code level, they just want to know what stuff it's managing/changing/adding on their system, which should be easy to figure out and document for them. When they shifted a fact-finding meeting into an impromptu automation grill session, that was pretty much my limit. I could have handled it better, since honestly the hostility doesn't help the company at all, but without personnel changes or someone above us putting his foot down, nothing's going to be resolved and we'll just continue to go back and forth. Neither my boss or the DBA team is willing to budge, and the capacity problems are still far enough out that management can ignore the issue... for now.
|
|
#
?
Nov 23, 2013 19:19
|
|
|
Bhodi posted:The DBA team's position is "We want to own the DBA servers and we don't even want non-dba teams to have logins; we don't even want you to monitor or touch the OS without first going through a DBA review board. When you bring up a new server, you put a request in and given appropriate lead time, we will handle it." This is the standard Oracle DBA stance, honestly. "Provision it, give us a root login, and stay away", and it's hard to break in traditional Oracle shops. You get around this by convincing them that you understand what Oracle needs, that you won't touch tnsnames, ulimits, sysctls, disks, or update any libraries oracle touches without vetting these things in a test or preprod environment then getting DBA approval. They have the stance they do because cowboys have come in and seen "unused" disks (actually mapped to RAC), weird sysctls, asked "why do we need multiple versions of Oracle on the same server" and other 'helpful' stuff the DBAs have had to clean up because they get called because transaction log shipping breaks at 3 AM. Welcome to a large shop, where your team needs to jockey for authority, and everyone else is as well. No matter how well-reasoned and logical your arguments sound to you, theirs also do to them. Nobody thinks they're being unreasonable. Everyone is following best practice. You want to throttle each other. You're going to have to convince someone with pull (their lead, manager, or the team in a meeting) that you're not and they can trust what you say is also what's best for them. Assuaging their concerns about log entries and puppet goes a long way.Rise above.
|
|
#
?
Nov 23, 2013 19:46
|
|
|
mllaneza posted:The Mythical Man Month is on the required reading list. Brooks managed mainframe development projects for IBM and took away a lot of useful lessons. Throwing the Elephant: Zen and the Art of Managing Up is a great book on how to manage your bosses and C-levels. Time Management for Sysadmins is another good one for how to figure out how to manage slices of not enough time. Last but not least, a sales book that should be required reading for anyone entering the job market: The Lost Art of Listening, Second Edition: How Learning to Listen Can Improve Relationships <-- how to use Active Listening to get the information you need, and make others feel good about it.
|
|
#
?
Nov 23, 2013 20:43
|
|
|
poo poo that's pissing me off right now: I used to work in a helpdesk. Now I moved up into a 2nd line voice operations role and my old colleagues from that helpdesk just blindly escalate any ticket my way without doing any kind of information gathering or troubleshooting themselves. And when you call them out on it they just feign ignorance "Oh I didn't know you needed that kind of info".  you lazy motherfuckers.
|
|
#
?
Nov 24, 2013 15:52
|
|
|
Sprechensiesexy posted:poo poo that's pissing me off right now: I used to work in a helpdesk. Now I moved up into a 2nd line voice operations role and my old colleagues from that helpdesk just blindly escalate any ticket my way without doing any kind of information gathering or troubleshooting themselves. And when you call them out on it they just feign ignorance "Oh I didn't know you needed that kind of info". Talk to your boss who can go to their boss and make policy that you can kick tickets back to them if they don't supply XYZ information.
|
|
#
?
Nov 24, 2013 22:05
|
|
|
When you consider how stupidly dependent people are on their cellphones it baffles me how so many lose the loving things. People are texting and Facebooking 24 hours a goddamn day to the point where they will literally walk into traffic while doing so and still they lose them. The president asked me to order him a new one just last week, and now he's lost the current one and can't wait for the replacement to arrive on Tuesday. If it's that important keep track of it. 
|
|
#
?
Nov 24, 2013 23:33
|
|
|
Drighton posted:I've seen a book mentioned a few times in these threads for IT management. Anyone remember what it is? Or maybe have one they recommend? The Prince is a good start.
|
|
#
?
Nov 25, 2013 00:11
|
|
|
Sylink posted:The Prince is a good start. 
|
|
#
?
Nov 25, 2013 00:14
|
|
|
I hate clients who want to talk to you over the phone, so they can later mis-remember things you've said, or claim you said things you didn't. That, or when they want to talk over the phone to discuss horribly complex issues. 
|
|
#
?
Nov 25, 2013 00:25
|
|
|
My favorite is working with a "system admin" who really knows nothing about the software or the resources necessary to make the product work. Spending 3 months making sure that the system works, and then being told after the go-live that they need 5tb of storage on the SAN to backup their data is a royal pain in the rear end.
|
|
#
?
Nov 25, 2013 00:38
|
|
|
Sprechensiesexy posted:poo poo that's pissing me off right now: I used to work in a helpdesk. Now I moved up into a 2nd line voice operations role and my old colleagues from that helpdesk just blindly escalate any ticket my way without doing any kind of information gathering or troubleshooting themselves. And when you call them out on it they just feign ignorance "Oh I didn't know you needed that kind of info". Want to trade? When I get tickets kicked over to me I'm lucky if they're in comprehensible English. EDIT: This sounds like a dig at outsourced call centers, and it isn't. Our guys just can't construct a coherent sentence.
|
|
#
?
Nov 25, 2013 00:43
|
|
|
I'd call you an inbred hick for not quoting Machiavelli, but you did post The Prince, so...  ("It is best to be both feared and loved. However, if one cannot be both it is better to be feared than loved.")
|
|
#
?
Nov 25, 2013 01:01
|
|
|
Sylink posted:The Prince is a good start. If you think your role in management is to be a tyrant, and your goal is to manipulate your workers, then yes. And also De Corpore Politico. But Locke, Hume, and other philosophers who don't advocate being an rear end in a top hat who's out for yourself first are probably better as management primers. Including Marx. Or Machiavelli's Discourses on the History of the Roman Republic (which he considered the ideal form of government). The Prince was actually satire and should be treated as such unless you also consider Legalism a valid doctrine, in which case you should just read Shang Yang. But I don't really want to go into a whole political philosophy segue, so... Can we please advocate cooperative government (Locke, Marx) or pseudo-cooperative (Plato, Aristotle) and either utilitiarian or deontological ethics? Rawrbomb posted:I hate clients who want to talk to you over the phone, so they can later mis-remember things you've said, or claim you said things you didn't. Back on topic: This is why you send an email after the phonecall which says "this is what we discussed, and this is what we agreed upon" so it's down in writing somewhere to CYA when they come back 3 months later and disavow everything.
|
|
#
?
Nov 25, 2013 01:17
|
|
|
|
|
#
?
Nov 25, 2013 01:33
|
|
|
I think he was joking, dude.
|
|
#
?
Nov 25, 2013 01:34
|
|
|
Are these management books an American thing? I've never heard people in my country discussing this stuff. But I may just be living under a rock.
|
|
#
?
Nov 25, 2013 02:45
|
|
|
VLC lets me use the mouse wheel to turn the volume up to 200%. Media Player Classic lets me click anywhere on screen to pause or unpause video. Why can't I just have both!? "Okay you want to watch that movie? Just let me set up WinAutoHotkey so we can both hear the quiet parts and pause on a moment's notice to discuss things." I know that wireless keyboards are things that exist but i like just using a mouse or something like logitech touch mouse. I shouldn't have to bring more to the couch. First world problems.
|
|
#
?
Nov 25, 2013 03:10
|
|
|
Heran Bago posted:VLC lets me use the mouse wheel to turn the volume up to 200%. Media Player Classic lets me click anywhere on screen to pause or unpause video. Most people use the volume controls on their TV and a wireless keyboard like the logitech K400
|
|
#
?
Nov 25, 2013 03:39
|
|
|
|
| # ? May 10, 2024 19:55 |
|
|
Heran Bago posted:VLC lets me use the mouse wheel to turn the volume up to 200%. Media Player Classic lets me click anywhere on screen to pause or unpause video. Pretty sure theres a vlc plugin for that. Still another thing to install I guess.
|
|
#
?
Nov 25, 2013 03:59
|
|
