LOL I see it is your turn to be "that guy". Sorry -- This is not the thread for you.

Spot on - but you would be amazed by how little sense that would make to the owner. I found out after I was hired that he turned down a vendor for this project because they brought a big roll of butcher block paper and started mapping the old database. He said he didn't want to analyze and plan the thing to death, he just wanted to get going. I winced and said, "But... that's what you do!" I tried to explain "agile development" to him. He loved the idea until he realized that I'd still have to do planning and analysis before I started coding. :laugh:

Agreed. That is on the list :/

Excellent response. Thank you.

Thanks -- good food for thought. Teach and train. I see a lot of deep breaths ahead, but seeing this thing work will be very rewarding. I like your suggestion about finding ways to relate to him. We are such completely different people... That's going to be tricky.

I'm looking for advice on how to deal with a problematic stakeholder/boss. If your advice has anything to do with quitting or leaving, save your breath. I'm well aware of that option. I'm interested in hearing ways to salvage the project. I joined a small business whose owner wanted to replace their failing DOS-based ERP with an ASP.NET solution. (Awesome, right?) My boss, the owner, is a 60 yr old, stocky bulldog whose tenacity is at the core of his successful business. Around the office he has the reputation for being a meddlesome teddy-bear. I am the only in-house developer. The biggest problem is that I can't seem to find a way to communicate with the owner. He has yelled at me multiple times for asking questions and drawing diagrams :confused:. He has shut down my attempts to understand the business, making it nearly impossible to put a game plan together. He doesn't understand the process of software development and constantly says things like, "Do we really need to do all that? Can't you just start with the first screen?" "Sure - what do you want the first screen to do?" "Exactly what it does right now?" "But it doesn't really suit the way your staff does business." "Well, we'll change the parts that don't work?" "Ok - How? What parts don't work? How should-" "Look we can just deal with that later. Let's just start building the first screen and go from there." I tried to explain that I need to understand the processes that I'm trying to support before I can 'design a screen'. Exasperated, the owner grabbed a fresh-out-of-college graphic designer in marketing and told her that she would be designing the layout and workflow of the new app. :wtf: A few weeks later I received a mock-up of a giant page with a billion fields and no discernible purpose. The owner loved it. He stopped by and generously asked me if there was anything I'd change. :omg: How would you turn this into a win? Subversively talk to staff, build a plan in secret and slowly evolve the graphic artist's shotgun layout into the more appropriate design by pointing out flaws one at a time? Is it worth the effort? Just wire it up like the owner wants and let the flaws become self-evident?

I remember coding basicscript (like vb) for an old Scantron machine. It had the single worst production compiler ever created. For loops would skip steps... If statements with true conditions would be ignored… My code was filled with "this should not happen…", but eventually I had to be specific just for my own sanity.

I love how you punk know-it-all coders who havent an ounce of business experience jump on disrespect for managers. My job as a manager is to keep the shitstorm of indecision and wildly fluctuating targets from disrupting your pretty little land of unicorns and code. The corporate world just past the tip of your nose could care a smear of crap about your elegant solution that took 4x 2-liter caffeinated days to figure out. They don't get code reviews, buggy compilers, platform quirks, scalability or error trapping. All that blather means to them is more time and money "wasted". I get the joy of "selling" the idea that the prototype demo, while working for the presentation is still 3 months out from production. If you are lucky, we are coders and can empathize with you, but coding is not revenue and revenue is what pays your salary. If you so much as open your mouth to argue that point, I will offshore your job to some guys who turn out shitty, useless code that barely works because that is what everyone above my head thinks they want. :mad::mad::mad:

Doesn't it make things more difficult for you in the long run? How do you start explaining to a layperson why their .docx file from work doesn't open with Word 2003 at home when they can't see the extension?

I can. See the above tl;dr digression about gin. Yours was interesting.

Sage advice... Pssh. Ya junior code snot. I'm glad I'm not the only assembler dork out there. This is the sort of question asked by people who end up designing the compilers you all use.

You bought physical media? From a store? The kind with clerks?? Weeeeird.

Ohhh... Not sure on that one. If you modify that to say your production build contains commented code, then yes.

I agree. Testers cannot test -everything- ... That is like expecting a coder to produce bug free code. In my experience, testers test functions against spec, and then test data/input (boundary conditions, extremes, absence, ridiculous) and call it a day. Unfortunately, this low hanging fruit approach leaves sneaky, subtle bugs like this undetected.

In fairness it really is two different areas of knowledge. As a kid geek in the 80s I had no money of my own, so I coded and tore apart my pc. As an adult, I started my career in PC repair and moved to network support while coding as a hobbyist. I've been a professional coder for more than a decade now and my OS/hardware troubleshooting skills are very dated! I used to constantly rebuild, tweak and overclock, but now I hardly deviate from the basics. As a programmer, having my pc work is more necessary than wringing every ounce of speed from my rig. Without that constant tweaking, troubleshooting has turned from an enjoyable challenge to a bore. I either let someone else do the grunt work, of format and rebuild. There are only so many hours in a day.

Thumbs up. Agreed. Registry cleaners are the cancer surgery of computing. You try to carve out the bad stuff, accidentally cut out some of the good stuff and often introduce problems that kill your computer sooner.

Not that long ago, kneeling chairs were all the rage. My back loved it, but I lost feeling in my shins from the poor design and tired of the strange wrinkling of my pants. Next came sitting on a yoga ball. Again, great for my back, but constantly shifting around and constantly engaging core muscles all day was fatiguing. Rather than waking me up, I found myself leaving my desk more frequently to relax and regain focus. The under desk pedals are useless. Unless the motion is connected somehow to the ability to use your keyboard, there is no impetus to pedal. Also, any sort of precision work while moving is more difficult. Im the sort who paces when he thinks, but cant imagine standing or walking while typing and mousing. I bought a Herman Miller Aeron chair a few months ago. My back is happy, I take breaks to stretch, and I work out elsewhere.

I'll be interested to hear how I should be doing this... but I've got batch files sitting on remote servers that create a quick backup of existing code, deploy code from subversion and sync up secondary servers.

Hey! My first job was repairing those things for the Dept of the Navy :) ... in 1992... in Nashville. Figure that out! LOL

When I saw this thread title, my first thought was: to simulate the real world with an academic project, cut the due date in half, and have 3 other assignments due on that same date. Oh - and one of those 3 assignments is to finish the homework of the guy who dropped the class after the first week. To simulate a project manager, remove every 5th word of the assignment description. If you call your instructor for clarity remove 3 more words. To simulate a tight budget, delete your teacher's email address and phone number. (This simulates the business decision to save money on a project by cutting support and training.) To simulate a marketing meeting, roll a pair of dice. The number that comes up is the number of times you will have to change your clothes while coding. Throw old clothes in a pile on the floor. You don't have time to clean them up