InsideTech

I work for a Manufacturing company and the systems I develop are being used by the people who work on the shop floor. Long story short I have to develop software that is easy enough for them to use so that they do not make a mistake, and these are the same people that can't figure out why they number pad keys aren't working properly when numlock is off, or why they can't print to a printer that isn't plugged in.  On top of that I also have to struggle with my boss who feels that windows updates are pure evil and not a one computer in the entire company, aside from my own, is completely up to date with the latest security patches and/or hotfixes. On top of all that every time someone runs into a problem even if it's user caused it's immediately my fault because I could not forsee the issue during development.

If learned one thing that has saved me countless hours of arguements, "Never argue with and idiot, they'll drag you down to their level and beat you with experience."

 wow, I feel almost a divine intelligence in comparison... good stories.

jrdptrs says ...

...I also have to struggle with my boss who feels that windows updates are pure evil and not a one computer in the entire company, aside from my own, is completely up to date with the latest security patches and/or hotfixes....

Looks like its time for a new job. :D

My Sympathy is with the Programmers.

I've installed the latest updates for Windows and all my development tools, I've never had problems programming.

I hope you can move on to work with more competent people.

sbeidha says ...

My boss always gives me projects without any requirements. I take hours and days to understand what they want and try to build it. After all the hard work once I complete the work, he keeps coming up with new things saying it doesnt meet their requirement than I have to redo everything again. I hate this job !!!!

You need to create a solution document and get your boss to approve it before you begin work on the project.  This document should,

1. summarize the project goal/objective


2. capture the high level requirements (these are usually business and functional requirements, not technical ones)


3. capture your boss's assumptions


4. define the project scope (what is included, and more importantly, what is NOT included)


5. enumerate the detailed requirements, assumptions, risks and risk mitigations (this is where the technical requirements go)


6. present the estimated project timeline


7. present the estimated effort (who is contributing, and how many hours)

I don't know about your organization, so perhaps some of these details (#6 and #7?) can be omitted.  Sure, this looks like a lot of extra work up front, but you benefit in several ways: (a) the total effort is reduced; (b) you are protected from scope change because the requirements are documented and approved; (c) your job satisfaction increases even if your boss is a loser because you have a much better measure of your creative output; and (d) you have a detailed record of your accomplishments, which is good for performance reviews and resumes.

If you are really lucky, you can get your boss to provide #1-3.  Negotiaition comes into play in #4, and #5-7 reflects your planning and design work.

For most technical people, project management stinks.  However, it is well worth the aggravation once you get hip deep in the project execution, and can save you a LOT of grief come delivery time.

Yes Moldy01....I've heard it as Design Specifications also. It will not only help you justify the steps that you take, but keep away major headaches when dealing with the Quality Assurance/Testing teams, if your place of work has one outside of the main developers. Or if those aren't things you have to deal with, it can at least help you learn how to streamline the development/progrmmaing process for future endeavors.