Fog Creek Software
Discussion Board

Style of working

I want to describe my own style of working and see if others are similar or different.
First, I am told to do something, and I try to think of how it might be like something I did before. If it is very different from anything I have done before, I feel lost and confused for a while. (However, I work in an environment where you absolutely cannot admit to feeling confused.)
As I get more involved with the planning and coding, I gradually feel less confused and things start to make sense. At times, I am completely immersed in the project and have the feeling that a lot of things are circulating in my brain.
I find that the confusion stage can be a little scary, since it has to be kept secret here.
I guess what I would like to know is:
Do you go through the confusion phase?
If yes -- do you have to hide the confusion from managers and/or co-workers?
(I used to go around saying "Oh, I am so confused!" until I realized I was the only one saying it, ever).

Dr. Real PC
Wednesday, August 25, 2004


or maybe so
Wednesday, August 25, 2004

Instead of saying "lost" and "confused" try using:

I'm working on the problem...

I'm considering all aspects of the problem...

Give me a while while to go over it and check to see if we have missed anything...

Actively Disengaged
Wednesday, August 25, 2004

I call this the 'easy problem' or 'complex problem'.  Any problem I can immediately see the solution for is 'easy', anything I can't immediately figure out how to do is 'complex'.

So to give a few examples, if someone says "I need this report, but in summary form", I say "Yeah, I can see how to do that."  This is a (really) easy problem.

If someone says "I need you to write a search engine, with a PageRank system like Google has."  That's probably a complex problem, and I tell them so.  Inevitably there is some disorientation/confusion when I try to fully understand what I'm trying to do.

My goal in personal advancement is to learn enough so that the complex problems become easy.  It's the complex problems that are the most frustrating--the easy problems are almost pure joy (or pure drudgery) to complete.

So yes, I think I understand what you mean.


Wednesday, August 25, 2004

i always think that the solution to any new problem is fairly easy at first.  then as i delve deeper into it, i'm often taken aback by how much i've underestimated things...

Wednesday, August 25, 2004

This is an advise I received from somebody I worked with. When I feel confused I should not say:

"I do not know how to do it"

Instead I should say:

"I see so many different ways of doing it, that I am having trouble choosing the best one"

In 99% (ok, 99.3% to be precise, yes I did measure it) of the cases the latter is actually true, not the former.
Wednesday, August 25, 2004

Most individuals will interpret confusion as a sign of weakness. Right or wrong, it's the way most folks see it.

You are a professional, and are paid under the expectation that you know what you are doing, whereas confusion gives the indication that you don't know what you are doing. Again, it may not be right, but it's the way most folks see it.

I have to agree that confusion, in my experience, actually *is* a sign of weakness in most cases that I've seen it -- especially in the situation when no one else is confused by the problem, and moreso in the case where a project is being slowed down or held back by your confusion.

If you're working a project, and all the other developers understand the specs/datamodel/tools/domain/codebase/whatever -- If they fully understand it and they're running with it, but you're sitting back for days/weeks/months/whatever at a time in a "confused" state, then you're obviously holding the team back.

Not that you fit the scenario, but I've worked with at least 3 of these folks in my shop in the past. The confusion sets in, they become paralysed, unable to do anything, they're simply overwhelmed with the most basic of tasks because they're in some kind of confusion induced stupor. 2 of the three no longer work for us (they didn't last long). I have high hopes for the 3rd, however it may not work out in the end.

Some folks, no matter how much they want to be developers (or <insert profession of choice here>) -- anyway, some folks are not cut out to handle the task. You may (or may not) be one of these folks -- only *you* know the answer to this question. Time for some deep soul searching.

That being said, we *all* get confused at times. The issue lies in the frequency of the confusion. If you're *always* confused, you probably aren't cut out to do what you're doing.

In and of itself, confusion is not a bad thing. Slow down, organise, learn, experiment, and un-confuse yourself. Sometimes it helps to slow down and step back and consider the subject of the confusion from another angle. If, however, you're always confused, you may want to consider another way to earn your paycheck.

I want to make sure that y'all don't take this as a flame to the original poster. The fact is, some folks don't have what it takes. I'm *not* saying the OP should give up and that he's not cut out for it. That's up to him (or his boss(es)) to decide, not me.

P.S -- to answer the original questions:
(a) Yes, I do get confused at times.
(b) No I don't have to hide it (I'm the boss <grin>)

Hiding your confusion, is, IMO, one of the worst things you can do. You're either (1) hiding it to give the (false) impression that you are AOK and fully running/up-to-speed -- effectively an intentional lie, or (2) You're too hung up and worried about what other folks will think. Either way, it's professional fraud.

On (2), there's nothing I hate more than to have a meeting, fully explaining the details and asking "does everybody 'get it'", with everybody responding in the affirmative "Yes, we 'get it'. We understand. No confusion here". There's nothing I hate more than someone who states he "gets it", and walks away in a completely confused state, sucking up more resources at a later date in an attempt to get other team members to explain and un-confuse them. That was the purpose of the damned meeting. If you're too afraid to open your mouth, during the *planned*, *designated* meeting -- because you're worried that others will see you as "confused", then you won't be working for me very long. The old saying about (paraphrased) "the only stupid question is an unasked question" is something I take seriously. If you're afraid to look confused, you've got a problem that I can't help you with.

Time for some serious contemplation: Do you have what it takes? If yes, do you want to continue to work for an organization where you have to "hide" the way you work?

Sgt. Sausage
Wednesday, August 25, 2004

I've found that when starting a new project there should be a lot of chatter between all stakeholders before any work gets done.  This helps to get everybody in synch, and if you're confused it's not necessarily because you're an idiot -- it's probably just because you don't yet have enough information to act.  If you're working in an environment where that's not encouraged (or where it's discouraged especially), then your long term options are only to change the process or to change your company, in my opinion.

Sometimes there's a "benevolent dictator" at the head of a project (or company).  He'll have the final say, but he doesn't care about whether or not all ideas come from his head (nor does he take the process of coming up with ideas personally -- "excellence" is not zero-sum to him).  If you have to work under somebody, this is the person to work under (or if you'll be leading, this is the person to be).

Very often, I think, there's a "malevolent dictator" at the head of a project.  This individual does see excellence as zero-sum, and if somebody else does well or comes up with a great idea it's a threat to him (that threat might be real or imagined, depending on the environment he's in).  This person wants to maximize the credit he gets, so he minimizes chatter between stakeholders and avoids consensus.  To him, people who execute "his plans" are devices to be programmed.

Wednesday, August 25, 2004

Mr. Sausage,

>There's nothing I hate more than someone who states
>he "gets it", and walks away in a completely confused

Except that it's often the case that somebody walks away confused without even knowing it.  With many problems, ambiguities don't become obvious until you actually try to execute.  If you think that you can have one single meeting and resolve all possible ambiguities, you're either working on very very very small projects (which don't cover anything new) or you're too far abstracted from the act of executing your plans to recognize patterns of successive disambiguation in software projects.

Just my opinion anyway.

Wednesday, August 25, 2004

By the way, I've got nothing against ambiguity in plans either.  Strategic use of ambiguity is a fantastic thing, and there's nothing I hate more than a plan that says something like "and then we take this XML and put it in the database here, which makes a message pop up saying ..." when nothing about the purpose of the project or generic demarcations of responsibility/requirements are set up.

Sometimes when everybody walks away from a meeting, the people who aren't confused are the dangerous ones -- because ambiguities in code mean undefined or catastrophic behavior.

Wednesday, August 25, 2004

I'm the OP. I was not saying I think confusion is a problem; I think it's natural. If I don't get confused at first then the project is too boring.
But I think everyone hides their confusion here. The boss is well-meaning but unintentionally very despotic. He is also unknowingly very arrogant, and probably thinks he's the best developer the world has ever seen. He has so much confidence he got himself promoted to a position requiring people skills, of which he has not an ounce.
Even a very experienced developer here told me he does not admit to initial confusion. So I decided I can play that game.

Dr. Real PC
Wednesday, August 25, 2004

==If you think that you can have one single meeting and resolve all possible ambiguities

No, I don't think so -- but when a meeting is called, and scheduled, *explicitely* for the purpose of resolving a given single ambiguity (or subset of known issues/ambiguities) , a solution is agreed upon, and everybody answers to the affirmative, then I expect that you understand the issue, the ambiguity, and the resolution.

To answer "yes, I understand" when you don't, is *still* fraud. Just speak the f*ck up, tell us you don't understand, and we'll make sure you "get it" before leaving the meeting. You gain nothing, and drag the rest of the team down, by hiding the fact that you're confused.

Yes, I'll get evil on this one. It's one of my pet peeves. I absof!ckinglutely hate this with a passion. You'll not change my mind on this one.

Sgt. Sausage
Wednesday, August 25, 2004

==>To answer "yes, I understand" when you don't, is *still* fraud.

BTW -- when you run across an individual like this, who habitually does this, then you'll know what I'm talking about. Until you actually feel that particular pain, you'll not see my side of it or understand where I'm coming from.

Sgt. Sausage
Wednesday, August 25, 2004

I just have to comment...

What is this "do anything to avoid showing confusion"?

There can be only twwo reasons:
1. They judge people superficially and would "downgrade" you immediately if you showed a hint of ignorance.
2. You were hired accidentally and are now trying to play a role.

IMHO, a new hire is expected to have some confusion/a lot of interest.

Wednesday, August 25, 2004

In a general case, I really enjoy working with people who say "I don't know" -- it takes a lot of confidence to say and it saves time by getting ambiguities out in the open early.  I realize I'm unusual, but I have much more respect for people who can say "I'm confused" than people always seem to have everything under control.

I've recently become enamored of a phrase that's even better than "I don't know".  Historically (I don't know if this is still true), plebes at the US Naval Academy have been restricted to 5 responses to upper class cadets:  Yes sir, No sir, Aye-aya sir, No excuse sir, and I'll find out sir.  That last one -- "I'll find out"  is wonderful.  Instead of an admission of "failure," it's a commitment to learn.  It gives you a great answer -- "I'm finding out the best way to do this", "I'm learning about the options for that", "I've found out some really exciting stuff and am working on integrating it."

Boofus McGoofus
Wednesday, August 25, 2004

umm ... here is my ideal style when I'm doing everything except playing the customer. I've worked at places where I went out with sales, then I came back as project manager, played spec,requirement write, and wrote and tested the code.

I first work with the client on the big picture. I don't get into details. I try and make it so simple everyone can see what we are talking about. For instance if we imagine a digitized work flow system. (btw, my first request would be to document the existing system if I were digitizing it). We have people who produce documents to be approved, simple. We have documents, simple. We have approvers, simple. We have time, simple. Start big picture. Then break down the layers ... but always keeping each view simple and understandable. That's what I do.

However, more often than not I'm just a developer and there are 5 other people playing all the other roles. I've never met anyone who does it my way. All these other people just want to have meetings and ask the developers when that thing we talked about is going to be ready. Beleive me I get confused at those meetings and I say so. I try and *design* my responsibilities in a big picture way. I always like to repeat to my esteemed superiors what I thought I heard them say. I might even write that down after a meeting and send it out in an email.

And about my other developers? Most of them rarely complain about confusion or maybe it's just such a normal part of their life they don't notice it.  Honestly. I've often asked them after meetings and they are confused but they'll just start building and hope for the best.

BTW, you might want to tell your boss how you perceive him. I too have been described that way but did not realize I was acting so. One cohort said he appreciated me cus now he understood how his girlfriend felt when she claimed he was being an asshole. And then another guy complained. I can get quite passionate but I never really wanted to be arrogant and piss people off (not those people .. I actually liked them). So do consider a talk with the boss, he may not realize his impact.

Wednesday, August 25, 2004

*  Recent Topics

*  Fog Creek Home