Hire Me $125: Index

As you can see how www.payscale.com evaluates my skills ------------------>
I could and should take much more for my consulting services, than I do.
But I've decided, that you only need to pay me $125 each started hour, and
that's about ½ the hour price, or even more, than other IT-consultants would charge you. I've seen others charge more than $225 an hour!

My IT skills are the following:

1. Creating and compiling Windows programs saved as exe-files with the AutoIt3 editor and compiler.
2. Domain administrator for 6.000 Windows Enterprise computers in Slagelse Municipality
3. Creating vbScripted CapaInstaller deployment packages using CapaSystems Deployment System in Slagelse
       Municipality
4. Creating new vbScripts, or solving your problems with your own vbScripts
5. Creating new command line batch files, or solving your problems with your own batch files
6. Managing and servicing Windows 8, 7 and XP
7. Maybe have a look on my Curriculum Vitae, where you among other informations can find a list of my IT
       qualifications started 1980:

• 148 days with 8 hours a day of IT training courses
• 1.670 hours with 4 hours a day, teaching classes of 20 collegues about IT programs
• Several months with 8 hours a day, doing pilot testing of mainframe systems, specially invited on location
    by the large KMD company, that's among others is servicing all Municipalities in Denmark
• I can't tell you how many "brick thick" english IT professional manuals, I've been studying again and again.
• You can read more about my programming skills in the TryWare menu and ind the PayWare menu

You can hire me in two ways:

1. Pay me $125 for each standard working hour. Pay me before I start working 1 hour. If I've solved your problem after 5 minutes, you must pay me $250
   
   
2. Send me an email with a very detailed description with full IT requirements specification, of what you want me to do for you. Specify your scenario before I help you, and specify how you want your scenario to be, after I've helped you. I will then examine it, and estimate the time needed, to do the job. I will then send you an email with the total amount you need to pay me, and you don't need to pay me more, if my estimated time is exceeded. I only answers emails in English and Danish.
   
   
3. I travel only in Denmark, and if you want me to visit you, I will send you an email about my travel expenses, before I visit you

This is how I always work after evaluating my developing experiences since 1980:

The many years of experience having developed and compiled applications, have confirmed my view of what I, as any other good programmer should always do:

Please please note my own idea #2 and #3 below, and just follow these rules, when you start with a completely new project, and just have been given a contract with requirements specification from the company:

1. Ask the company about a meeting with the CEO/CIO, and the end user, that's supposed to BETA test and use the wanted application, where you are sure that the specification requirements are reviewed with all relevant facts.
   
   
2. IMPORTANT: Don't start scripting the application. NOT even a single line.
   
   
3. IMPORTANT: Write a complete manual to the end user, with all the details, so that it is ready to use after the BETA test, without having to be revised.
   
   
4. Send your user manual to the end user for 1 weeks evaluation and comments.
   
   
5. IMPORTANT: Write the registry keys or settings ini file used to establish the user environment for your application. If possible don't use HKEY_LOCAL_MACHINE or C:\<ProgramFiles>, because many large companies follows Microsofts recommendation about enabling User Account Control and restricting the use of local administrator credentials for their end users.
   
   
6. Write a numbered list of expected info and error messages according to #3 and #5
   
   
7. Only start scripting the application if #1 to #6 is totally finished.
   
   
8. Test your compiled application in relation to #3, #5 and #6, and solve any errors in your application, manual and registry/ini settings file.
   
   
9. Send your application and your (maybe revised) manual for a BETA test to the company's end user with a deadline about evaluating it.

As an example I was told to script an application where different passwords was part of the compiled application, to grant users credentials for different issues.

And if I DIDN'T follow my rule #2 and #3, I would ONLY have written a warning in the manual, about only to use passwords that doesn't change, because otherwise all results of the compiled application needed to be done again, because of the new password(s).

But because I followed my rule #2 and #3, I wrote the manual first, so I decided - before scripting anything - that my application should make a log about which passwords was used to which compiled issues, so if the company needed to re-compile all their issues, they could use my log file, instead of only using their human brain memory.

So if I didn't follow my rule #2 and #3, I would either have delivered a bad solution, or would have needed to rewrite/BETA test the needed changes about the log file in my script and manuals.

1 2