OP here. I just threw this together to have a little fun on a Friday morning. I knew I wasn't alone, but it's still nice when you guys remind me how much I'm not. It seems like there are two worlds for programmers these days: never having enough time to crank out that which must be built and dealing with alternate human reality in some institution.
These were just the tip of the iceberg. I'll probably have a bunch more next week.
Some specific feedback:
georgemcbay: When different stakeholders don't agree, I've learned 3 things: 1. You rarely make progress. 2. The only way to get them to agree is to put them in a room together and don't leave until they do agree (That's one time when you DO need a meeting). 3. My boss rarely understood (1) or (2). He was just worrying about his personal likes/dislikes. It's tough enough to convey this in a serious piece, but obviously a lot tougher in a light piece. Thanks for the feedback.
RyanMcGreal: I enjoyed Dilbert until the stories started striking too close to home. They became too real to be funny. Sad but true.
veyron: Actually, this company used 6 digit Ticket numbers. I shortened them for clarity. Remember it's a sequential numbering system, so that's the number of tickets since the beginning of time, not currently open tickets. Sadly, a typical meeting:
Joe: How are we doing on 112182?
Fred: I don't have that Ticket.
Joe: Oh, maybe it should be 112128.
Mary: No, that's in Ron's group.
Fred: I must have written it down wrong. I mean the MJC Project.
John: The MJC Project is on hold.
Joe: Sorry, the MCJ Project.
Mary: Who brought a laptop?
Sue: I did. I'll search for MCJ.
Fred: No, you'll get 500 tickets. Search for Joe Smith, open.
Sue: OK, here it is. Ticket #118128.
edw519: Kill me now.
EDIT: I am NOT making this up. Five minutes ago:
Customer: I called you 10 minutes ago but you didn't answer.
Me: I was here. Sometimes the IP phone doesn't ring.
Customer: Why? Is it raining there?
edw519: I know it's just for fun ... but on two occasions I've heard that I.T./I.S. bosses are purposely chosen NOT to be computer savvy because the otherwise operations cost too much. CEOs want good enough not perfect. This might create interesting team dynamics or sunk a project. I wander if there is a number which happens more often?
Here's my favorite personal story. I was a consultant, brought in on a project on-site at a client's location. This is my first day, and I'm meeting the VP of Marketing.
VP: We need to get these Cognos reports up and running.
Me: Hmm, ok. What can you tell me about these reports?
VP: Mostly that we need them up and running.
Me: Who uses these reports?
VP: Not sure. Ask so-and-so.
Me: What information is on these reports?
VP: Look, let's not get buried in details. We just need these reports up and running, mmm-kay?
I like that: "Test-first requirements analysis." A bit like shooting a monkey into space in an uninsulated tin can to see if there are any problems with that.
Oh man, these almost hit too close to home to be funny. True story below.
Me: So, just to remind you, I'm going in for surgery on Saturday. They're removing a gland from the side of my neck, so the recovery time will probably be three or four days.
Boss: Will you be back in the office on Monday?
Me: Probably not. Like I said--
Boss: --When will you be back?
Me: The recovery time is three or four days, so hopefully Tuesday or Wednesday.
Boss: Will you be taking any meetings on Monday?
Me: I will probably be bed-ridden, and I won't be able to speak.
Me: What time do you think you'll be home?
Wife: Um, well, first I need to do x, and then I need to go
to y, which will probably take an hour. And then I might
swing by z.
Me: So what time do you think you'll be home?
I am not a boss, but quite opposite. But often find myself answering the same way. And later just putting myself into boss's position find that this was not the best answer. Straight and simple yes/not/[number]/today/now/tomorrow much better. Reserve informal talk to a lunch with boss.
Bosses seem to hate being forced to reason out the answer, even if it should be readily apparent from what you said.
If you're annoyed and want to annoy them back, you can do the reasoning for them to point out how simple it is, e.g. "three days from now is Thursday" or "not being able to speak would make meetings useless, therefore I will not be able to take any."
ts not a second its closer to several minutes of back and forth. 2 min times 40 enteractions a day, is almost hour and a half of bosses time you wasted.
theres a reason why communication needs to be more concise, more summary, aggregated as it moves up hierarchy.
also as boss i trust you with details. i usually dont need to hear them.
Fair, but the backstory is that I'd told my boss about the surgery (he'd asked about the particulars) about three dozen times prior to that conversation. Some of the seemingly extraneous info ("removing a gland from my neck") was added here, per very slight artistic license, to convey information to the readers that was actually mentioned in previous conversations.
That's funny, but he may have meant you should not put off homework til the last possible day or minute, or just this kind of thing can come up and scuttle it. If the teacher literally assigned it at 3pm, due next day, then a few hours later you're electrocuted, that's understandable. But if it was assigned a week before, and it would have only done a few hours to do, it's much less so. Because stuff comes up. If it wasn't random electrocution it would be random something else. And keep in mind the same teacher probably hears lots of excuses, some real, some made-up, all the time. I imagine it gets frustrating for them, and their empathy wanes away. Cops have a similar effect.
jes5199's wiktionary link says that "Strictly correct usage is to reserve electrocute and electrocution for fatal electric shocks". Do you have a source?
Looks like I was misinformed. However, the Wikipedia entry for electrocution (http://en.wikipedia.org/wiki/Electrocution) does mention that the choice of definition varies from dictionary to dictionary.
It’s perfectly rational to hate meetings. But if you hate meetings, you should not be a Boss. In our business, part of the Boss job is going to meetings in order to protect your team from insanity.
If you hate something that is a core part of your job... This is a recipe for unhappiness. Now, I do not enjoy many of the meetings I attend. But I do enjoy some, and I get satisfaction out of doing the meeting part of my job well.
All that being said, I’m pretty sure I’ve said those exact words myself: “I hate meetings.” So yeah, it’s reasonable for a Boss to say those words. But not to believe them 24/7/365.
"But if you hate meetings, you should not be a Boss."
I disagree. If you cannot tolerate meetings to the point where you avoid them, you shouldn't be a boss. But if you hate meetings -- be a boss. Be my boss. Because I want a boss that only calls me into meetings when it is absolultely necessary.
Oh, I hate dragging you into meetings. That’s why I go, and that’s why I make sure that they are productive enough that we don’t need to have ridiculous conference calls with ten people on each side that range from grand visionary pronouncements to discussing individual tickets with developers :-)
Hah...you only think like that until you're a part of every meeting. That's really the issue. There are good meetings that I need to and should be a part of. Then there are the other 90% of my meetings that are a complete waste of my time.
Maybe, but getting organizational buy-in -- and preemptively clearing potential political damage to the project -- is part of the job, especially for 'the boss'.
The boss might not like it, but it's part of the job. And pretending that all meetings are terrible does not solve the problem. That's just a technical knee-jerk response to pretend that people problems will go away on their own, or that negotiations don't need to happen because it involves 'one of those meetings'.
And if it's part of the boss's job -- which negotiating peer buy-in is -- then it's not really appropriate to go around complaining to subordinates about how he hates doing his job, especially when doing that job protects the technical work his team will be doing.
Exactly. The truth is, no-one points a gun at your head and promotes you. The only people who become managers want to be managers, or they'd turn it down, or quit and go find another tech job.
I couldn't disagree more. In day-to-day programming life, having people want to invite your boss to a meeting instead of you is practically the only upside of having a boss at all.
Me: The program was written with 3 SQL selects
inside a loop. It ran OK when we had 500 parts.
Now that we have 10,000 parts, it runs real slow.
Boss: I don't understand.
I could say "true story" here... with a twist. Saying "I don't understand" is basic social engineering & management 101. The boss actually understood every single word and implication in that statement, he just wants to buy some time to decide silently on the best answer. Saying "I don't understand" puts the pressure on the dev who is lead to believe it's his fault and needs to think of a better description, maybe less technical and more to the point to express the problem. While the dev reformulates, the boss has finished thinking of an answer and can give it instantly. In the end, the dev has managed to express a problem with "simple" words, and the boss has proved he has great skills at solving problems once they are reported in the correct form.
I hated my boss when he did it to me, but I have to admit I used this in turn countless times when I became "the boss", to the point it's become a private joke in my former company, anyone saying "I don't understand", whatever their position, instantly got thrown balls or clips in their face.
Whenever people ask me questions I will throw back the "I don't understand", and mean it. Sometimes their questions are inane and I really don't have an answer for it, but many other times the biggest issue is that people aren't giving me a clear view of what they want when they are asking me.
"What is it you are trying to accomplish?" is usually my second question after "I don't understand". Hopefully I can find out what exactly they are trying to accomplish and what they have now to help them.
Well, as much as I agree with you from a personal perspective, I'm afraid it is part of your job to manage your boss, just like it's part of your job to build your team, build yourself, build your product, build your users and build your customers.
Anyway I walked out due to interlocutor stupidity exactly once:
Random guy that one of ours helped (for free) a year
before barges in and asks to talk to the manager,
someone points him at me.
Guy: I *demand* to talk to you about what someone from
your team did last year. It's bad.
Me: Sure, I'm not familiar with the story as I took
charge only last month, and I'm in a pinch for some
urgent business. Your thing looks urgent too, let's
schedule an appointement at noon.
Guy walks out mumbling to himself.
Noon - the following are EXACT QUOTES:
Me : So how can we help?
Guy : you guys did this last year. We can't use it.
Me : what's the problem? Did something new come up?
Guy : I think the problem is that whoever did this is
incompetent.
Me : woah, I didn't expect I'd have time for lunch
today.
/me walks out, goes to superior, tells story, the next
day the guy in question gets shelved.
"I don't understand", eh :P, well, allow me to expand then, my English level isn't good enough to get my point across in a couple sentences.
- The guy barges in uninvited as if all hell broke loose and goes directly to the tech manager instead of passing through our customer service. Bad manners.
- When I patiently and openly ask him about the nature of the issue, I expect a bug, a missing feature, an accident, something that I can fix. The only fix this guy has in mind is me firing my "incompetent" dev.
- Labelling someone in my team as incompetent, without any names, means labelling me an incompetent, regardless of whether I was in charge back then. Helping him would be equivalent to taking the blame and would put me in a position of inferiority. Over something we basically did for free as a favor. One full year ago.
Best case scenario: for a full year he was in front of his product and raging over the dev's incompetence without telling anyone => incompetent product owner
Worst case scenario: something came up in the recent past which makes our product dangerously unfit under these new conditions. The best move at this point is to ask for improvements & fixes, workarounds or alternatives, or request through the chain of command to have us all replaced if it was really that bad. He simply ignored all that and thought he would solve the situation by barking baseless insults at my face => incompetent manager.
What the guy did was the professional equivalent of Trolling. I did what I usually do, I squelched him, sent a mail to abuse@theguy.com, told my system to filter him out, and moved on.
There was a very long pause. He then found his words and asked how it was possible for me to finish a project (that would have normally taken 8 hours) in 30 seconds.
I had approached a previous similar project with a heavy focus on re-usability. The skeleton just needed XML added to customize it. And that could be added quicker than workers could get to that section requiring it. After that he actually asked why I had done that without permission.
Me: Because you wouldn't have been able to understand it. And because of that you would have said no.
I have an innumerable number of examples from this guy. I could start my own PHB cartoon. He kept his job because loyalty is often more valued than competence. (And in his case loyalty meant routinely fudging timesheets and not paying the grunt workers their full pay.)
I had transferred from a satellite branch to the main branch. I stayed a year under this doofus out of loyalty to the manager from the satellite branch who had recommended me. I quit at exactly 1 year. Contracted for them for 4 more months and oh was I glad to be gone.
Several months after I left I made some friends who used to have the doofus in their social group. He was ostracized and no longer welcome because he had stolen money from coats and purses piled onto a bed at a get-together.
I was also responsible for training my two replacements. I recommended that they not keep one of them. They did. After I had left this other guy managed to do a "rm -rf" on the primary SCO UNIX server that dispatched work to everyone. He also managed to improperly rebuild a RAID array on a W2k3 server and wipe everything. He also...
Wait. I feel the PTSD kicking in. Needless to say, it was a very dysfunctional work environment.
wow, yeah. every now and then i realise that no matter how dysfunctional my previous jobs have been, there have been other people who had it far worse.
It's actually pretty foolish to do this, if you want to keep your sanity in the future. If it takes you 30 seconds, they will most likely expect it that quickly in the future, even if it's not possible.
Except that these are normal aspects of their job. Not liking the sight of blood is a normal human response too, but shouldn't be if your career choice is butcher or surgeon.
Yeah, I know a lot of these hit close to home, but on the emails - you've never been a boss.
1 - Get 1300 emails a day (not an exaggeration) - 8 am
2 - Get 50 emails from executives who basically want to fire you OR someone who works for you and you have to act fast to stop the bleeding. - 10 am
3 - Get another 400 emails that are related to an ongoing discussion with managers on your level who are trying to stick your department with more work/blame/responsibility without letting you in on it. React at lightning speed to ward off evil. 2 pm.
4 - Attend many, many meetings in which executives will try to blame you, other managers will try to blame other managers, and long, tedious initiatives are discussed in hushed tones. Fight urge to nod off/strangle people/demand clarity. Pay attention because in six months one of these hapless bastards will claim everyone agreed to something preposterous in the meeting. - takes place: Every available minute. Including lunch, because "that was the only time everyone had available for some reason."
5 - Developer says he CC'd you on several emails related to the XYZ system and is baffled as to why you aren't completely up to date. Don't tell him that at 10 am the CEO was demanding he be fired (from a cannon). 6 pm.
Hmm, while I agree that it can be hard to keep on top of you emails in that kind of volume, if you're a boss, and you're bothered enough about being kept up to date on a project, perhaps some email rules that filter emails about that project into a seperate folder so you can see, quite easily that there are emails about that project, might be a good idea?
I occasionally get similair situations to this at work, which is why I request read receipts. Makes it even more satisfying when an account manager is having a go at you for not emailing them something and you point out they sent you a read receipt for it, they just obviously didn't actually read it. My account managers hate my read receipts :)
What you don't get here (and he didn't really spell it out because I guess it seems obvious once you're in that position) is you don't have time to (nor should you even want to) follow every email thread about every project that you (should, theoretically) already have complete faith that your employee is successfully executing. If you need an update, you just want an update (hey I noticed Bill's getting a little antsy, here's the status of project 127: "status") not to find and trace back through a discussion of x y and z aspects of implementation or marketing or whatever.
Bingo - you have to trust that the people working for you know what they are doing. This means going to meetings and being belligerent with other managers at times as they try to claim your people are screwing everything up, without even checking with your people. You always defend first, never call anyone out by name and never let any other manager talk derogatorily about your employees. Part of your job is to protect the people who aren't there to defend themselves.
This also means that if your developers drop the ball, you're screwed. You can't possibly know if someone is sticking bugs in the code as they race for a deadline, but when the system misses deadline because of it, guess who's responsible?
Doesn't help when you stick up for a dev for weeks or months and then they burn you by introducing shoddy code or not testing thoroughly, and their response is 'well I sent you a bunch of read receipt emails, so those browser bugs I introduced aren't my fault - you should be paying attention'.
This experience is why I work so hard to back up my boss or lead when I'm just a developer on a project.
2000 emails a day sounds like a profound lack of organization. What kind of company is this?
I like how you feel you protected the developer even while he was criticizing you for not doing any real work. That sums up a lot of big co. work relationships.
I dislike parts of javascript and moan about it, doesn't mean I shouldn't be a programmer.
I've been a manager before and didn't have constant meetings. Most decisions actually get made in hallways or between a couple of you casually chatting after everyone else has gone home in my experience. I avoided meetings when I feasibly could and tacitly approved of the same attitude in my team too.
This! I wouldn't want to hear my doctor complain that surgery is icky or that listening to people talk about their aches and pains is tedious. Managers complaining about management tasks is not good. All of the managers I've had were once engineers. For a couple of them it was all too obvious that they still much preferred engineering work over management work, and they were not the best managers I've had, to say the least.
Well, of course, that would change the meaning. He can be so terse with words because many of us can fill in the blanks that these bosses have the wrong attitude about things.
This really happened to me in the last month. I was contracted with a company that has a contract to build a company for a bigger client with customers.
PM: We need you to fix a bug. One of our client's customers couldn't complete the form.
Me: What error did they get?
PM: I don't know, but it's very important we fix this.
Me: Do we have steps to reproduce it?
PM: No, can't you just fix it?
Me: Did they retry the submission process?
PM: I don't know.
Me: Does it happen often?
PM: Just this one customer as far as we know.
Me: Well, do we at least know when it happened so I can find it in the logs?
PM: Sometime last week. Look, this is really important to the client, can you just make this top priority? We want it fixed ASAP.
The "bug" has not been fixed because the devs still don't even know what the error is. We had another high-priority bug shortly before this because the client didn't understand that something wasn't allowed according to the access rules in the spec they (theoretically) helped write.
I'm not calling you a liar, but I'm skeptical about stories like this. I can't even fathom any scenario in which someone more intelligent than a cucumber could behave in this manner. How does this PM manage to get and maintain any job at all, let alone one that requires the ability to understand software development process and constraints?
I once thought as you do that this story or the hundreds of others like it were just exaggerations or failed comic sketch scripts. I once couldn't even comprehend where the humor came from in Dilbert.
Then I worked in government, health care, and big business as an employee and a contractor which allowed me to the great opportunity to meet these very people. This type of behavior is particularly common in companies that like to see managers move around so they can get experience in many parts of the business. In many companies it is actually regarded as a plus to supervise technical people without understanding anything about the technical process or some failed programmer becomes a manager.
It wasn't a PM or anyone technical, but I can confirm that people of "cucumber" intelligence do, in fact, exist in management and that I have personally met them and been ready to tear my hear out during exchanges like:
"We had an error!" "What error?" "Who cares? Fix it!"
In an unrelated note, I think I'm going to start calling such useless reports cucumbers.
I've lived through many bug reports like this, mostly from very non-technical PM's who think that their power is derived from being the single point of communication between the client and the developers. Its a sad and bizarre game of telephone.
It is the bosses who don't understand things but just want things get done. Consider their role as the pressure amplifier. They just increase the pressure, I meant priority, of the problem when the clients scream. They drive the process. They don't solve problem.
How long have you worked in software and which companies have you worked at? I'm asking because these PMs tend to come from smaller companies whose main job isn't IT related. In a lot of these places, the "IT Director" is the CEO's friend or family member, and the IT department is simply a holding area to keep them out of trouble.
I've worked in software for roughly 14 years, and I've worked almost exclusively for startups during this time. I understand the concept of nepotism, so I get your point - I guess my question is not really "how do these people keep their jobs" so much as it is "how do these people even exist?" The notion that a conscious human being could behave in the manner described is unfathomable.
It's probably because you've been in startups all this time. Try working in manufacturing instead and you will no longer have trouble believing that these "cucumber" people walk among us... and work in management.
Headdesk moments like these can be irritating, but if you pay attention when your boss says stuff like this and learn to communicate with them on their terms (e.g. communicating through subject lines where possible for this boss) you will see a world of difference in the ease and efficacy of interacting with them.
One month ago:
me: Hey, everything is alright with project X?
boss: Yep, perfect.
Next monday, employee call me.
employee: Can you walk me through the code.
* me explains everything*
employee: Ok, just to let you know you are fire.
me: :-/ Why?
employee: Boss will call you
me: ok
next day, boss don't call
I write an e-mail
No answer
Another email 6-7 hours later
Boss: Sorry, I'm really busy. Calling you tomorrow
*Tomorrow*
no call
*next day, for a week*
no call.
I go to the office to talk to him.
boss: I have a meeting, I have to run. I'll call you when I get back.
And he still haven't call me back, and I have no idea why I got fired.
As surprising as it may seem, this is far more common than you might think. Welcome to the club (ie. Real World)! Now, that you know how to spot a liar:
Me: This vendor software you purchased is not going to scale well on EC2, it needs physical hardware to work well.
Boss: Well, we don't have time to go purchase physical hardware and get it racked. That'll take 3 months.
...3 months later...
Boss: This stuff isn't scaling, we need to all come in over the weekend to work out the kinks with the production servers.
Me: Purchase some hardware and get it racked. EC2 just isn't working out.
Boss: I can't. I already sold our executive team on the cloud and we don't have room in our budget for hardware.
A lot of places rent out physical hardware, meaning you won't have to buy it. It might take more time if you have specific needs, but some providers can deploy hardware in minutes.
Agreed. I knew his 3 months excuse was a straw man argument but I wasn't in IT so I couldn't argue against it.
The truth came out only after another 3 months of failed scaling when we found out that he'd oversold the benefits of cloud based scaling to the nontechnical leadership.
Boss: You did great this year. I'm giving you a 2% increase.
Me: I hate you. I quit.
Boss: Then I'll give you a 4% increase.
Me: I still hate you. I still quit.
Had the same situation years ago - fought tooth and nail to even get a review - by the time they gave me one I was accepting a position elsewhere and the 2% they offered was a joke.
It's exceedingly rare to get a huge raise just for doing the job you were hired for. The best place to demand dollars is in the interview. Inside a company your best bet is to clearly delinate role changes, and make your demands parallel to that change. Don't ever fall for the "do the higher level work now, get the raise later".
Worth pointing out that this varies case by case. I can't speak with more than a single data point, but the only company I've been with has seen both pay rises (decent ones) and title bumps be rather fluid, and they've never actually happened at the same time. And yes, started off on a shit salary, now it's great - without any single huge change in what I'm doing, just gradual changes.
Really? I have had 3 jobs in my 7 year career as a developer. In each job, I have always given 110%, solved every problem given to me, and been 'the guy' who can fix things quickly when they break.
I'm a PHP developer by trade, recently our iPhone developer quit. I learnt Objective C in 2 weeks and am now maintaining two large iPhone apps as well as doing my PHP duties as a senior dev.
I have never asked for a raise, in my first job I started on 30k and was on 80k in 1 year (new zealand dollars). In my second job I started on 40k pounds and was on 50k in 6 months. In my current job (been here 3 months) I'm looking at a 20% pay increase in the next month.
Never asked for a raise. I just shine and get the karma back.
Your experience will vary from company to company - while my initial post mentioned the company that I had to fight to get a review at, I later on worked at a company for over 4 years where I was given a yearly raise that exceeded the percentage cap that was in place - I was appreciated and they made sure to show me. Every company and every boss is different - it's great when you work for the good places.
I've never had to ask for raises either, but I honestly think that's more likely to be a sign that I'm underpaid for what I do. Not that I'm ungrateful to my boss for fighting to get me them.
It is rare, but it happens. At least one entire team at microsoft recently received $60k+ raises (salary increases -- not one time bonuses) because google started poaching team members.
Now nobody on the team can justify leaving since they are paid so out-of-whack with their actual market value.
>Now nobody on the team can justify leaving because they are paid so out-of-whack with their actual market value.
You can't reason like that. The market value is simply the price the customer is willing to bear. If Microsoft can bear an $60k per year increase to hold onto these engineers, then that's their "true" market value. In other words, they're getting paid exactly market value right now, and they were getting horribly underpaid before.
Side note: This misconception about "true market value" is probably the number one reason as to why engineers are underpaid. If the person on the other side isn't challenging your price, you're lowballing yourself.
It's not necessarily their true market value - it's just their value to Microsoft at that particular time.
If the project that they're working on is strategically important, and any disruption is unacceptable, it might be in Microsoft's best interests to pay them well above their market rate to ensure nobody quits. But the same engineers in another part of the company may not have received raises at all.
On the flip side, Google may be willing to pay above market value in order to take valuable assets away from their direct competition in key areas.
Just because one company in one circumstance pays them a certain salary, it doesn't mean that's their true market value, unless they could get the same rate elsewhere if they quit tomorrow.
Agreed. Most companies realise the disruption caused to a project when key staff leave and paying an extra 10K, 20K or even 60K passes a simple cost-benefit analysis - but only during that project.
Personal experience: I was one of about 5-6 people who actually knew what they were doing on a 50 person, 3 year project at a large company when I got a much better offer from a much better company. I called the HR manager in good faith to see if they would match it, but he didn't want a word of it (nearly hung up on me, in fact). That was until he was told by my boss that I'm needed on a critical project. Not only did he call me back and talk to me, the CTO of the company (who never spoke to me before) spent an entire hour with me, ignoring his constantly beeping phone, convincing me to stay. As flattering as that was, I knew by then that they only did this because of the critical project and took that into account in making my decision.
I still decided to quit. The "critical project" was cancelled two weeks later (for unrelated reasons).
This is a tangent, but I have yet to work at a company where the review process had anything to do with performance, and even less to do with adjusting pay based on that review. And managers seem to love saying "Yeah, I thought you did really well, and I can give my input, but it's [VP three layers up the chain] who has the final say in these decisions." Thanks, boss.
Most bosses would love to give you more money if you're really doing a good job. Which is in fact, most likely, the reason why they're not allowed to do so.
Well as someone who has done a lot of reviews, i had my guidelines to follow for raises and bonuses, if a member of my team wanted more, they was nothing i was able to do other than bring it up the ladder and put a good word for the guy if i think he deserves it.
"Directive 595 is as follows: 'Not null constraints give lack of flexibility, more costly evolution, inhibit the use of the database acting as a service to applications and make it an inhibitor to evolution.' As such, please remove from all production databases." To find out how this ends: http://thedailywtf.com/Articles/Directive-595.aspx
I keep running into DBAs and data architects that keep trying the "we don't need foreign keys" argument. I always ensure they lose that argument (and stuff gets better, amazing!).
Though in all seriousness, what alternate universe are these people crawling out of?
That and the types who call their j-random database a "data warehouse".
I would be very interested in knowing how you manage to win that argument. The only sure way I know of is in a post-mortem after a major data corruption disaster, so if you can suggest a less dramatic angle of attack I'd love to hear it.
This guy's experience was almost entirely with front-end technology (pretty much just JSP's actually), and it showed in almost every engineering decision he made. The sad thing is that, there is an argument to be made for denormalizing data and not using foreign keys. That argument is not "they don't buy you anything."
I worked in a bank for a minute or three. Big one. The production databases ran without foreign key constraints enabled for performance. In the development environment, however, all constraints were strictly enforced.
Boss: "This new feature is similar to one that's already in another program, so you can just copy that code. You can do that in a couple of hours, right?"
Me (coining a metaphor): "The fuel distributor in a Pratt & Whitney Turbojet engine will not work in a Norelco Electric Shaver, even though both can be used to cut grass."
When you combine gross underestimation of effort with the re-prioritization cycle, you get a monster that probably destroys millions of hours of productivity every year around the world. As soon as it becomes clear that the project won't get done as early as expected, the boss re-assigns you to a new priority. What would have taken 4 weeks to do 3 projects now takes 4 months and only results in the completion of one.
My favorite. Back in the mid-90s I consulted on a Lotus Notes project at a major company. We built a prototype and started showing it various VPs who would be using it.
One of the VPs was really terribly with a mouse. The tutorial was as much about the basics of navigating a GUI as the application itself.
Afterwards I asked the project manager "What does that guy do? He doesn't seem to know anything about computers."
Where X is something seemingly simple. What makes it more frustrating is that it is often very difficult to precisely describe why it is that X involves so much unintuitive complexity.
Also
"The users don't care about how it's developed"
Except that code quality defines the readability, maintainability, and often-times performance (deeply coupled code can make optimisations very difficult, for example) of an application both during development and afterwards.
Me: No, what I just talked about is a multi-month endeavor.
The reasoning behind this is probably formed from a multitude of influences. Executive desire, manager's attempts to look good, and a complete lack of comprehension of what building software is about all rank high on the list. The one I, for the life of me, cannot understand is why programmers insist on pushing the "I can hack that together in 48 hours" mythology. Surely it has had an effect on the management psyche and influenced the mental math used to conclude that the maximum time it should take any feature to be developed is fourteen days.
- Did someone fire the boss for those?
- Did you quit your job and started a new one?
imho, famous last words should sound like: "I will not leave it nor depart it until I am buried in the ground." (rough translation) Mubarak 10th of Feb on TV.
PS: The most famous last word to quit a job in Germany is: "Ich habe fertig", you should note the wrong grammar here.
My own "never have I been so glad to leave a job" story:
Me: I think it's time for me to move on. To be quite honest, I see no potential for advancement here and I'm being expected to work dozens of hours of unpaid overtime each month. As we've discussed previously, my hourly rate is already low compared to industry standards and my experience level, and you've told me that the funds simply aren't available to rectify that. I sympathize with your position, and I wish everyone here nothing but the best, but that still doesn't change the fact that this job simply isn't paying well enough to cover my expenses.
Boss: I wish I could talk you out of it, but if that's really what you want to do, I can't stop you... but honestly, I don't think you're good enough to make it anywhere else.
It was my first job out of college. I was, however, a fair bit older when I graduated and did have a few years of experience freelancing, but this was my first time working in a corporate environment.
The whole company culture was one of distrust. We would be told in meetings, for example, that the we were to lie to the sales team about product details and were regularly encouraged to infringe on copyrights when doing design work.
The ethics were a huge part of why I left the company as well, but it wasn't a battle I was going to win. I'd tried before and failed, so at that point, I just didn't bring it up.
At my last company (I quit a little over a year ago), we had a newsletter with a nice opt-in system setup (I set it up during my time there). 5000 active users I think and 30,000 users that had opted-out.
Well, at one of my last meetings, my boss yelled at me and told me that we were "leaving money on the table" by not sending emails to the opt-out list.
I explained to him exactly why it was a bad idea to email these people, but he didn't want to listen. Within a day we were permanently banned from our email provider.
My boss wanted to sue the mail provider for "disrupting our service". I've had so many terrible bosses that don't know how to run a proper business, I wonder how they make any money in the first place.
That's a fair point, but I'd still expect anyone to understand the part about how it ran fine under a test load, but now runs very slowly under a much larger load.
A non-technical boss managing technical employees can lead to problems. It is rare to have a non-technical manager who 1) knows what they know/don't know, and 2) can effectively manage a technical team.
I've read a few of Scott Adams' books, and he's mentioned that he has intentionally tried to put some absolutely ridiculous scenarios in his comics that could never happen... only to have readers e-mailing him and asking if he'd worked at Company X, because the exact thing had happened to them.
Do you really work at a place where everything is so impersonable that it is all referenced by project number or was that used to obfuscate your clients in this example?
None of the comments surprise me to be honest, I find that managers have come from no background to instruct people on a technological level and are taken on for simply their management ability.
Referencing things by number is pretty common, I think, a lot of places use a Jira system where each ticket has a number and its often used for all development related tasks.
Our projects do carry a reference, it is usually prefixed by the department handling it and a number but when we have production meetings they are all referenced by the client and the job in hand.
I don't think I would like to work at a company where it was just a number, I like it being personal, it would feel more like a machine with just numbers or references
yeah, I agree its a bit weird, at the company I work for people usually just resort to describing the issue when talking about it (when not in front of a computer), rather than reference the number, but jira ticket numbers are frequently passed back and worth to refer to specific tasks.
EDIT: "I find that managers have come from no background to instruct people on a technological level and are taken on for simply their management ability."
If true, that is a sign of a very unhealthy company.
It's a tradeoff. Some of my worst managers were former programmers; some of my best came in through some side door. Management ability--real management, as in getting people to get along and get the job done, not as in making Gantt charts and chanting buzzwords--is essential, and it's really rare to find it combined with technical skills.
It's not rare in the Silicon Valley. Most managers in successful companies here are what you'd consider rare. Managers without real management ability don't last long here.
And are they also good engineers? That's the hard part; the kind of obsessive focus usually required to be a good geek tends to impair the social skills required to be a good manager. Not always, I admit, but usually.
I did work in Silicon Valley, but not for very long; and it was in the late 90s, at Netscape, so my experience was probably atypical.
Humorous, however the following is actually a semi pet peeve of mine :
Boss: I'm really upset that no one has updated me on Project 127.
Me: I cc'd you on all 9 Project 127 emails I sent this week.
Boss: I haven't had time to get caught up on my email.
Depending on the scale and structure of the company / department, getting "caught up on emails" can range from "completely reasonable" to "fundamentally impossible".
For example, at a previous job we received no less than 250 work emails daily and often more. Needless to say, simply being CC'd was not a guarantee the recipient would be up to speed on the contents of said email string.
Mgmt: We need to replace this system ASAP!
Me: What does it do?
Mgmt: We don't know.
Me: Who knows?
Mgmt: Maybe this girl.
Girl: I'm too busy to talk, but make sure nothing breaks.
I did end up writing a replacement system. What I found out was all the people who were 'too busy' to talk or email me back with information suddenly responded when I took down their part of the system as I worked to replace it. I've never had to do a worse project and I'm happy it's over.
One of them mentions a shutdown from Amazon because they ship too many orders late. That rang lots of bells for me, because it sounds like IT at an independent fulfillment company, which will usually have its own web store and sell through many other companies besides Amazon.
432 projects are a lot to you? Imagine your boss is someone who reacts to every business challenge and opportunity by creating a new project. Imagine that every vendor you ship for has re-invented EDI, without ever having heard of EDI, and it was designed by one of:
A) Someone they found on Craigslist
B) A kid they hired who doesn't comprehend how you can write a program without wrapping it between <% and %> and loading it in a browser
C) A guy who thinks he's a programmer because he once wrote an Excel macro
Their mechanisms can be so bizarre that you can't really support them by configuring an existing fetch-n-post, or Extract-Transform-Load system. You just have to fire up Visual Studio and write Project 433, AKA "Overstock.com Is Tripping On Acid And Now Requires That We Convey Order Status Via Modulated Carrier Pigeons".
Some of the weirdest I've been asked to support:
* Moving the order file between different subdirectories on their FTP server to convey status (ie: we log into their FTP site and issue a MOVE command on the file to put it in the /shipped folder). Did I mention that each file contains multiple orders?
* We have to implement a SOAP API to _their_ spec and expose it on the public internet for them to call at-will to send orders and query for status.
* CSV wrapped in XML, but it's CSV with a sub-delimiter because one of the columns has to be treated like an array to convey the status of each line-item.
* Orders that come in an Excel file, but they never order or name the columns consistently from file-to-file.
Oh joy. Sounds like dealing with telco billing. On one side you get excel tariff files which change in random ways every month, on the other you get silly billing data. Can you imagine ITSP getting an itemised bill for a month of calls from upstream provider? I think it was 3 rather large boxes filled with printouts. Still not sure why that happened.
I once worked for a company where our tech chief made various hacks to FreeBSD to allow it to have very large number of groups and users could belong to a lot of groups. This allowed each project to have a gid, so that people working on a particular project could belong to that group and the file permissions can be set accordingly. The company would have hundreds of projects per year, and this was used for many years. This was fine until Linux and NetApp technologies were being introduced, it did not play very well with the hacks to groups.
i can really empathise with the "start the year off right" commenter - my last boss (ceo of the company) once insisted on several long phone conferences during the christmas break, so we could "hit the ground running" when we returned. he was a firm believer in permanent-crisis mode.
Pretty funny list, but this seems like a case of poor management of expectations. It shouldn't be your job to explain why things matter (as in 'Boss: What difference does that make?'), but sometimes that's reality.
Here's a set of slides on taking control of poor communication situations and learning to efficiently keep managers in the feedback loop. Sometimes it doesn't work out ('Boss: I haven't had time to get caught up on my email.'), though it's certainly a start.
One Sunday I got a call from a help desk guy involving an application I had worked on. This was the first call I had ever gotten about this app. I am pretty sure I was last on the contact list
PM calls me 10 minutes later and says we need to discuss my level of commitment, Says I have been shirking my duty and letting everyone else handle support.
All I could say is that it was the first call I had ever gotten, maybe bump me up on the call list.
He didn't know there was a call list they followed in sequence, still I should have been doing more.
If my comment is not relevant, then why is this post at the top of HN?
It is my understanding that the post depicts the irony that those who do not understand are put in charge.
I should not be explaining my comment, but downvoting without a counter argument makes no sense to me. It is the equivalent of responding to an argument or statement with "I don't agree"
#1. It's unlikely that the boss is deciding on SOPA.
#2. Your comment does not contain any particular insight on SOPA or shitty bosses. It's just a repetition of the meme about SOPA. SOPA awareness is important, but you have not contributed to it.
#3. As a joke, your comment is not particularly funny.
I did not read it as a take on "shitty bosses" but as someone reporting to who had no idea about what he was supposed to be in charge of.
". As a joke, your comment is not particularly funny."
A very subjective statement.
Thanks for taking time to reply. I still reiterate that downvotes in a discussion forum serves little purpose. If a statement is offensive, flag it. Don't downvote into oblivion and try to censor anything that goes contrary to "the official position".
These were just the tip of the iceberg. I'll probably have a bunch more next week.
Some specific feedback:
georgemcbay: When different stakeholders don't agree, I've learned 3 things: 1. You rarely make progress. 2. The only way to get them to agree is to put them in a room together and don't leave until they do agree (That's one time when you DO need a meeting). 3. My boss rarely understood (1) or (2). He was just worrying about his personal likes/dislikes. It's tough enough to convey this in a serious piece, but obviously a lot tougher in a light piece. Thanks for the feedback.
RyanMcGreal: I enjoyed Dilbert until the stories started striking too close to home. They became too real to be funny. Sad but true.
veyron: Actually, this company used 6 digit Ticket numbers. I shortened them for clarity. Remember it's a sequential numbering system, so that's the number of tickets since the beginning of time, not currently open tickets. Sadly, a typical meeting:
EDIT: I am NOT making this up. Five minutes ago: