Fog Creek Software
Discussion Board




Run, Run as fast as you can!

At a recent interview for a position in an IT department, not a software company, I was asked why global variables are bad.  I stated that they clogged the global variable scope and pretty soon it would be difficult to keep track of what variable served what purpose and you would end up with two variables that did the same thing in different places.  I was informed that I was wrong and that the answer was that it is difficult to keep track of the value of the variable.  I stated that it was relatively easy to track the value of any variable given that they were using VB you simply had to set a watch on the variable and step through the code.  I said modern debuggers make it easy.

At the end of the interview I found out that the lead developer was hired in the 1997-1998 time frame and does not have an education.  The company does not use source code control and does not use bug tracking software.  These are supposedly on the 'list of things to do when we get time' and it would be 'difficult to allow everyone to enter bugs'... whatever that means.

The project manager could not describe what a typical day was like.  Instead he said that there were no typical days and that I should get used it (obligatory laugh..bleh)

Now I've accepted positions like this before and they have NOT turned out to be good jobs.  Instead they were basically cluster f**** with everyone doing everthing.

I just have a bad feeling about this place.

I guess I'm wondering if I was right or wrong on the global variable thing and would you take a job like this or would you:

Run, Run as fast as you can.  You can't catch me because I'm the Gingerbread Man.

The Gingerbread Man
Friday, July 09, 2004

Above all, I would look at the job market. While the place you described is definitely not a good place to work, I'd pay attention to what other alternatives you have.
Maybe the right answer would be to grit your teeth, count to ten and play along until you find something better.

RP
Friday, July 09, 2004

Global variables make unit testing difficult.  They do write unit tests there, right?  Take the job and quietly improve the process there:  http://www.joelonsoftware.com/articles/fog0000000332.html

grunt
Friday, July 09, 2004

We're suppose to develop software, not change the world.

RP
Friday, July 09, 2004

Don't set your goals that low, RP.  Why bother living then?

grunt
Friday, July 09, 2004

I metioned unit tests and the only thing the lead developer could understand (besides a blank look) was 'testing with live data' before going live which is not exactly the same thing IMO.

The Gingerbread Man
Friday, July 09, 2004

Honestly if you are persuasive enough and have a good political streak, this can be an ideal situation - it would be relatively easy for you to dramatically improve the process (and not just by saying "Gee guys we should do XYZ", but rather by actually doing something such as a bug database and saying "Hey guys, take a look at this and see if it might work here"). This is the sort of gig that catapults people into executive positions.

However there was one point that I found interesting:

"At the end of the interview I found out that the lead developer was hired in the 1997-1998 time frame and does not have an education."

Firstly, does not have an education? Did the guy/gal drop out in kindergarten? More likely what you really meant was that they don't have a formal computer science education.

Even presuming you meant that, I still don't get what the point was - your observation that they have horrible practices was enough without what could best be described as a pot shot. If you think that there is an accurate correlation between formal computer science education and software development practices (especially for someone doing this for at least 7 years), then I would have to say that your experience in this profession has been vastly different than mine.

John Beyessian
Friday, July 09, 2004

Global variables cause close coupling (apologies for the unintended alliteration), and they pollute the global namespace. While you didn't use those terms exactly, I think your explanation covered the bases.

Ask if the software/project manager's position is available. :-)

Derek
Friday, July 09, 2004

I say, it depends how open you think they are to new ideas.

If they appreciate your experience and more process-oriented perspective, you could make a lot of difference quickly. 

If they seem stuck in the ad-hoc mode of programming, you're likely to get pretty frustrated.

As a side note, I've worked in a number of small organizations with ad-hoc practices, and it can be satisfying.  Small organizations are often very customer-focused, and the management layers are thin.  The trick is to bring in process improvements that are quick hits, e.g. have high impact on quality and deliverability without adding a lot of extra work.  Bug tracking is a good first step.  Revising the testing process is another.  Source control is much trickier, as everyone has to buy into it for it to be effective.  (and it adds a lot of overhead for those not used to it).

Will
Friday, July 09, 2004

Great place. You're told you're "wrong" on a question that is basically a subjective value judgement.

By "not having an education" I take it to mean that this developer/lead is completely amateurish and has never transcended his limitations. I agree. Some non formally educated developers work hard, learn, and are prodigies. Others never get it, wallow in their ignorance, and use it like a badge of honor.

The guy who interviewed you is a dumbass. And that company accepts flagrant mediocrity. It says a lot that an idiot like that is utilized for interviews.

If you didn't realize all of this, it might work for you. Because you do realize how amateurish the place is, it will be hell.

Avoid.

Bored Bystander
Friday, July 09, 2004

I didn't mean to imply that not having a CS degree makes you a poor programmer or anything or the sort.  What I did mean to say was that I could tell by talking with him that he didn't have a degree.  I don't mean this to be good or bad or that he was in any way a bad person or a bad programmer.  However it has been my experience in the past that people hired during that time frame who are in the position they are in because of their "time with the company" generally aren't as accepting of new ideas as someone with a degree is.  I guess a degree and the knowledge it brings helps you look at things in a different light so-to-speak.

The Gingerbread Man
Friday, July 09, 2004

> I stated that it was relatively easy to track the value of any variable given that they were using VB you simply had to set a watch on the variable and step through the code.  I said modern debuggers make it easy.

Trying to understand what he was saying, I reckon he meant that if it's global then it can be changed from anywhere.

I don't want to use a debugger to know what the code is doing: I want to know by reading the source code.

If it's a private member variable, for example, as opposed to a global variable, then I know that it can only be changed from inside the methods of that single class.

Christopher Wells
Friday, July 09, 2004

G-Man:

If they are not using source code control, then local variables are the least of their problems.  If the project manager cannot describe a coherent approach to software development, then he should be ashamed to call himself a project manager. 

Christopher Wells’ post is a great answer to your original global variable question.

I would take the job if you are as good as you think you are.  I took a job where chaos reigned and I had a ball implementing a disciplined approach to software development that included project planning, testing, documentation and source control. 

Eavesdropper
Friday, July 09, 2004

I agree Christopher but I still don't believe that I was blatantly wrong as he suggested.  Already in this thread there have been 3 reasons given for not using global variables.

1. They clog the global namespace.
2. The value can be changed anywhere making it hard to read and debug the code.
3. They make unit testing difficult.

I'm sure there are more.  I guess I was a little flustered being asked that question.

The Gingerbread Man
Friday, July 09, 2004

> I agree Christopher but I still don't believe that I was blatantly wrong as he suggested.

Yours was one of several okay answers.

Sometimes interviewers are confrontational like that to see how you react to confrontation ... or maybe he'd be like that with you even outside an interview, I don't know.

> I guess I was a little flustered being asked that question.

Interviews are stressful.

Apparently one of the better words to use in an interview is "Hmmm...": it gives you time to think, and makes you appear thoughtful rather than hasty.

> I was informed that ...  I stated that ...

I hope you showed good listening skills by saying "Yes, you're right", before you then going on to contradict or argue against what he was saying (as you did just now when you started with "I agree Christopher but...").

By the way, it *is* (sometimes) possible to overcome a bad interview impression (if you want to) by following up with the interviewer afterwards, to thank them for the interview and to explain or say anything that you weren't able to say during the interview.

Christopher Wells
Friday, July 09, 2004

"Honestly if you are persuasive enough and have a good political streak, this can be an ideal situation "


Good point. Note, however, that if you improve things you won't be able to take much credit.

If the entrenched power system (read: manager, etc.) knows that you'll get credit for improving things, they are likely to resist your efforts.

You can:
a. Get things done
b. Get credit

Pick ONE.

Mr. Analogy
Friday, July 09, 2004

Getting them to use source code control will be a fun challenge. If your experience is like a past position I had, in the 18 months I worked there, they went from having no SCC to buying a box which sat on a shelf.

The chaos you describe is very common in the programming business. It is one of the things that has to change for the industry to mature.

If you need a job, take it. If you have one now, I suggest you follow your gut feeling on this one.

Peter
Friday, July 09, 2004



Actually, this position might be bad in the short term but it offers some possibilities for some *serious* resume enhancing...

(This is what I'm doing now, so hang on for a ride.)

I work in an office where we do have source control, but it's rarely used.  There is (was) not bug control.  There is zero project management.  There is almost no collaboration between the 12 developers/designers.

Of course, in the highly fluid environment, I've been able to institute some things without permission and then start getting others involved.

The first thing was better source control.... Subversion was deployed and now we're just trying to figure out how to export everything from VSS into it.

The next thing was bug control/tracking.  I started with a simple Access database with some reports.  Then, I deployed Mantis and have been using it now for about a month to track bugs & requirements and integrated them with my Access reports.  Now I've added a few other users at their own requests after I brought some nice reports to meetings and logged things while in meetings.

I've now deployed dotproject and started creating my project plans and personal scheduling with that.  I figure after a couple weeks, it will spark others' interests..


Now, on my resume, I can list yet another organization that I've deployed Source Control, collaboration tools, Project Management, Bug Tracking...

Feel free to drop me an email for further ideas.

KC
Friday, July 09, 2004


Oh, and Unit Testing (TDD) is on my agenda...

KC
Friday, July 09, 2004

Good advice Christopher.  Those are things I have to work on, listening and not being confrontational (not questioning everything everyone tells me).  I used to be so good at that but it seems I've got a short fuse as of late.

The Gingerbread Man
Friday, July 09, 2004

"Sometimes interviewers are confrontational like that to see how you react to confrontation ... "

Also sometimes they're basically interviewing their replacement, like when higher ups say they're too busy and need to get someone to help... so they actually resent you.

Mr. O
Friday, July 09, 2004

Mr. Analogy - I respectfully disagree with you.  If you are smart enough to get things done you should be able to figure out how to get the credit. 

That being said there are some situations (like a small family business or a completely apathetic corporate structure) where not matter how good you are you won’t be able to get the credit or even effect change for the better.  However, most organizations are results/profit driven (even government agencies have to create results to keep their funding) and this does give you the opportunity to contribute and be rewarded for that contribution. 

I believe that if you are achieving results but are not getting the credit for those results then you are not doing your job and you will be among the first to go when cuts are made.

Eavesdropper
Friday, July 09, 2004

Eavesdropper -

apparently you've had nothing but Dream Jobs.

It's not always easy (or even ADVISABLE (ie in the current economy)) to go head to head with your direct boss, which is often necessary to get credit for things you implement (ie, raise the visibility of said project over his head).

muppet from madebymonkeys.net
Friday, July 09, 2004

i wouldn't work at such a place. especially the part of a bug tracking system. even if they had a spreadsheet that tracked all issues, then that would be better.

regarding source control. where i'm working now it is very manual and we are not using any real software. but, we do have a build concept, etc. it works, but isn't automated.

don't do it!

Patrick
Friday, July 09, 2004

" If the project manager cannot describe a coherent approach to software development, then he should be ashamed to call himself a project manager. "

HAHAHAHAHAAHHHAHA!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Most of the Project Managers I have worked for are managing client / server, web & web service applications and only know COBOL programming techniques on the mainframe.

They wouldn't know if a XML doc bit them on the butt!!!!!!

How are they project managers then??? Simple: Corporate Politics

Gen'xer
Friday, July 09, 2004

In my experience Project Managers are those who were never any damn good at development but better than average at schmoozing the bosses.

old_timer
Friday, July 09, 2004

Gen'xer -

do you work where I work?  :)

muppet from madebymonkeys.net
Friday, July 09, 2004

Muppet-I agree with you that you should never go “head to head” with your boss or anyone else higher than you on the food chain.  That is a no-win situation for you.  My point is that you do have to learn how to make sure that your efforts get visibility up the food chain or you are not doing your job.  I never said that this was easy, so I am not sure where you are coming from with the Dream Job crack. 

Apparently KC is doing that at his company and I applaud his efforts. 

Eavesdropper
Friday, July 09, 2004

Eavesdropper -

If you have a way to get visibility for yourself with no direct channel to upper management, I'd LOVE to hear your wisdom.

muppet from madebymonkeys.net
Friday, July 09, 2004

Volunteer for high profile projects that make your boss look good without him being directly involved.  Those above him will think he was smart for putting you on the project, and they'll think you are talented for getting the job done right.  If your boss balks at it, explain that you know he's really busy and overworked, but you'd like to help out with a project as important as this one.

Aaron F Stanton
Friday, July 09, 2004

Muppet-No problem, just read “How To Win Friends and Influence People” by Dale Carnegie.  It is a timeless classic for a reason.  It is filled with the type of wisdom that you are looking for.  That would be where you should start, but there are a lot of other great authors and books out there.  Remember success is a journey not a destination…

Eavesdropper
Friday, July 09, 2004

"Mr. Analogy - I respectfully disagree with you.  If you are smart enough to get things done you should be able to figure out how to get the credit.  "

Eavesdropper-

It's not that it takes skill to get credit. It's that everyone in the organization is dividing thier time b/t GETTING THINGS DONE and GETTING CREDIT.

If you're splitting your time between the two, and everyone else is putting 100% into getting credit (playing politics), it's difficult to win that game. I've seen it happen and heard from an uncle at the FAA.



I'm not saying it's impossible to get credit, I'm just saying that if you try to improve things and YOU think you'll get credit, then everyone ELSE thinks so too... and they'll block you at every turn so that you can NOT implement what want.

FOCUS ON PROFIT?
Yes, the COMPANY cares about profit, but your boss might not give a rat's ass about that.  And even if s/he's evaluated on profit, crafty bosses (who spend thier time doctoring the books instead of managing) know how to play that system.

My wife's old boss at a hospital couldn't care less about productivity. They'd juggle the numbers to make it look however they liked.  The boss cared about LOOKING GOOD. And she knew how to juggle the paperwork to make herself look that way.

Mr. Analogy
Friday, July 09, 2004

I guess the key is to try to align your bosses' interests with yours.  Try to arrange things so that helping you means helping themselves, and hurting you means hurting themselves.  Some people will hurt you (and thus themselves) out of spite when they realize you've put them in this position, but many will just take the easy road and help you instead, as long as they clearly understand that by doing so they actually will be helped in the process.

Aaron F Stanton
Friday, July 09, 2004

+++My wife's old boss at a hospital couldn't care less about productivity. They'd juggle the numbers to make it look however they liked.  The boss cared about LOOKING GOOD. And she knew how to juggle the paperwork to make herself look that way. +++

Does your wife work where I work? ;)

muppet from madebymonkeys.net
Friday, July 09, 2004

This discussion has turned into overly idealistic theorization about "intrapreneuring" within a company and helping it despite itself.

I've lived with several hack shops as clients. Hack shops suffer from mediocrity at all levels, and extreme disorganization in the "cognitive landscape" - IE, how people there see the company and their jobs within it.

Basically, in hack shops, nobody with political power believes that order and focus are possible. When you talk to someone like this about source code configuration management you might as well be speaking Swahili. Even if they are crushed by the burden of dealing with revisions and conflicting versions, they will simply refuse to believe that these tools are for *them*.

When those right up to the ownership level believe in the "lean and mean" crap and the party line of "we don't have the time or money to get organized", then in order to survive it politically you need to hang your professionalism in the closet and strain, grunt and sweat needlessly just like the idiots around you.

I'm not advocating this. What I'm saying is that most crappy workplaces are like that because the management is afraid of succeeding and doesn't believe that it can or should do better.  You're not going to improve them - instead they are going to drag you right down to the gutter with them.

Avoid.

Bored Bystander
Friday, July 09, 2004


I *just finished* my six month review about 15 minutes ago...

My boss actually said:  "how the hell did we do this before you got here and deployed this!?"

My response:  "you didn't."

I managed to get a 5% raise out of the deal, so I consider it a success.

My next evaluation in 6 months will be after completing 2 *major* projects, so I'm shooting for 8%.

KC
Friday, July 09, 2004

KC - congrats!  Very cool.

Bored Bystander - Yes, many places are sadly mediocre.  They are willing to endure continuing misery to save the pain it would take to eliminate the misery.  The key is to tie their short term pain/pleasure to their long term detriment/benefit.

You can't do it just by whining about how the place sucks.  (I found that out the hard way.  Can't do it by mocking it, either.  My mistake.)  You have to make it look like you are working within their system completely, like you are being totally subservient to their insane whims.  I didn't do that...and after being canned (along with about 150 other people),  I am now much happier someplace else.

Aaron F Stanton
Friday, July 09, 2004

"When those right up to the ownership level believe in the "lean and mean" crap and the party line of "we don't have the time or money to get organized", then in order to survive it politically you need to hang your professionalism in the closet and strain, grunt and sweat needlessly just like the idiots around you."

Yes, and I'd also like to add, in business terms, why it's not worthwhile to try and cure this particular virus.

Basically in such a shop, one is guaranteed to be forced to "take ownership" of any number of problems.  Much more so than when working at a company where business processes (and therefore the business itself) has "ownership" of problems, rather than individuals.

More ownership implies more risk.  Therefore one should expect a return appropriately proportional to that risk.

But nowhere in the employment contract, is there a clause that guarantees such a return on risk-taking.  It's nothing but a wild shot in the dark.  One could spend months at a shop setting up a source control system--for which you'd likely be solely responsible, at least in the beginning--and still recieve the very same salary in the end.

I just think this "intrapreneurial" attitude is based in bad business sense.  It's relying on the good human nature of the owners to reward virtue, rather than a business agreement that's been laid out.

Yes, employees should go above and beyond their call of duty to help their companies.  Absolutely that is one way to recieve recognition in an organization.  But keep it within reason:  beyond a certain point (especially something like setting up source control on an organization-wide level), you're just doing a contractor's job for free.  And you risk being fired if you screw up--that's the flip side of ownership.

Just as a side note, I think most companies--especially small ones, and regardless of overall competence--do a remarkably poor job of rewarding their employees' ownership stake in the company's business processes.  To do so, I think, would be too much acknowledgement of the technical person as a driving force in the business; and most of us don't have the good sense to bargain for appropriate payment.

indeed
Friday, July 09, 2004

But...then again, Bored may be right.  I knew what was wrong, knew that I was smart enough to fix it, and yet was never given the opportunity to work on anything that truly could have put my brain to use.  The job I had I literally could have done when I graduated from 8th grade.

I think I have to agree...avoid places like that unless you enjoy being a mindless drone.  The fact that you recognized the fact they were wrong and why means not only will you hate it there, you will probably be despised as well.

Why the 180 on my stance?  Well, Bored's description fit my last job to a T and I hated it there.

Aaron F Stanton
Friday, July 09, 2004

Aaron,

"I think I have to agree...avoid places like that unless you enjoy being a mindless drone.  The fact that you recognized the fact they were wrong and why means not only will you hate it there, you will probably be despised as well."

Or you could take it as an opportunity. An opportunity with the risk (as has already been said) that could get you fired if it all works out the wrong way. But, in that case you would have learned more I guess that on a job where everything is already 'in place'.

To take advantage of that opportunity you have to use your brain a bit more than you had to when you were performing mere programming tasks, but there coulde be a pot of gold at the end of the road (own experience).

I'd say, just like John Beyessian at the top of this thread said,  this would probably be the ideal working place (at least for me, at least at this point in my carreer).

- Jilles Oldenbeuving

Jilles Oldenbeuving
Friday, July 09, 2004

The consulting mensch Gerald Weinberg has stated in one of his books ("The Secrets of Consulting) the following consultative rules, which actually apply to ALL situations in which you're being hired to solve client problems:

Don't fix their problem unless they asked you to.

and,

Don't fix their problem unless they're paying you to fix their problem.

(I am not looking at the book itself, I am paraphrasing to the best of my remembrance, but the original is quite close.)

**EVERY** honking time I've flouted these rules, I have lived to regret it.

I have lost business and customers by not respecting the client's inalienable right to choose to be a self destructive stupid ass.

In the context of the idealistic but doomed theories of "intrapreneurship", you're wasting your time unless you work as the natives work...

Bored Bystander
Friday, July 09, 2004

"Don't fix their problem unless they asked you to.
and,
Don't fix their problem unless they're paying you to fix their problem."

Agreed! Darn it!

Dennis Atkins
Saturday, July 10, 2004

That "don't fix their problem unless asked to" is really only relevant for consultants.  As an employee, their problems become your problems and you will have hell until they can be fixed.

But of course, the best thing would be to not work for them in the first place.

T. Norman
Saturday, July 10, 2004

Is "intrapreneurship" a spelling mistake or a neologism?

Stephen Jones
Saturday, July 10, 2004

neologism - it's the latest meme that's making the rounds.

Means acting like an entrepreneur, taking risks, investing in the work, and so forth, but instead of doing it for yourself, you do it for the man, hoping that he will bless you with a pittiance of a raise, or perhaps in the case of Microsoft, reduce your benefits less than he had origially planned lest they eat into his obese bonuses and stock option valuation.

Dennis Atkins
Saturday, July 10, 2004

T. Norman, the principle still applies. As an employee it's best for your job longevity to only work on the problems that are considered valid and worth solving by your employer.

Now, if you're given a blanket fiat to do whatever needs to be done to solve problems, that is a different kettle of fish. In the context of this discussion, the lean, mean, poorly managed small to midsized company rarely has such slack.

That's all Weinberg's rule is saying: don't make yourself look redundant and don't make your client/boss look foolish by talking about and attacking problems that he doesn't see as problems.

Concrete example: a few years ago a client asked me to redesign a billing and invoicing system for them. I talked about installing a server for them, and I was out the door. To these semi technical stupid asses, "server" meant high expense and complexity (they were too stupid, really, to administer a Windows server); they wanted to stay with unstable, unscalable Windows 95/98 for their "server" role computers.

As soon as you step outside the boundary of acting upon the things that your boss deems urgent, you put yourself at risk - no matter how badly the problem you've chosen to attack needs solving.

Bored Bystander
Saturday, July 10, 2004

^

Yep, and that's common sense.  Employers will just see your work as wasting time; doing something you want to do "just for fun" then justifying it retroactively.

Such is the state of the business world these days.

indeed
Saturday, July 10, 2004

*  Recent Topics

*  Fog Creek Home