User Woes (1 Viewer)

mdnuts

Registered User.
Local time
Yesterday, 21:52
Joined
May 28, 2014
Messages
123
I have to agree with Gemma - it's not your database if you developed it on the company's dime.

jdraw has put some fantastic information there. Design documentation (including release info), users guide, admins guide, quick guide. Comment the heck out of your code and only tested and approved iterations are for public consumption. Any playing, designing, developing is done elsewhere (which you have already).

With applications that have moderate use, I tend to have it backup the data side of it at least daily. Then use that backup for any design, play, testing. That data set you could offer to the supervisor to play with since it's probably fresh enough for what they need.

I bet if you hand you design documentation over it will do several things. Alleviate any legitimate concerns on what if you leave, it crashes, etc. and serve to discourage casual play. If you take it to a setting like jdraw suggests to gain buy-in by stakeholders it'll just boost your visibility.
 

slike

New member
Local time
Yesterday, 18:52
Joined
Feb 27, 2014
Messages
2
As for my resume, I am an accidental database developer and am self-taught so I feel like my options are limited...

Fear not.... I started my career -- such as it is -- in the same manner. I started my first job out of college as a "temp" secretary at a big bank, then found myself in a huge accounting consultancy for 12+ years, and now I'm at a utility company. Before too long I found myself creating tinkering with small Access databases to run simple administrative tasks. Twenty years later I am still working in Access, and now several other platforms, including Oracle, SQL Server, etc. as well as Crystal Reports, etc., and I do lots of visual basic, javascript, whatever it takes. I do lots of automation, have found companies that appreciate my skillset; and learned to channel my energies and efforts into projects that will actually be valued by my company. As a matter of course, I work diligently to document everything I can think of about any tools that I create or with which I am working.

Keep your chin up. Look for companies that actually appreciate your skillset and might be willing to take a chance on a newb. Lots of companies like to hire "temps" or "contractors" first for a 6-month try-out period, then you get hired full-time. That's how I arrived in my current role.
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Yesterday, 20:52
Joined
Feb 28, 2001
Messages
19,384
One factor to consider is the size of the company vs. the size of your department and the cost of a new hire. When doing a cost-benefit analysis, you have to point out that the cost of hiring another maintainer vs. the cost of single-point-of-failure risk is a legit issue, particularly if you put it in relative terms.

However, there is another way to approach this. If they company doesn't want to hire another person, see if they might be receptive to hiring a services provider for a part-time developer with certifications and other skills - and a way to control costs by limiting the hours this person would work. The laws that talk about who owns the s/w would still apply, not to mention that the contract could specify ownership explicitly to eliminate all possible disputes later. Further, hiring a services company means that THEY are the ones who provides for the employee's human resources overhead - insurance, benefits, retirement contributions, etc - and those fees can be easily enumerated to make comparisons possible between company A, company B, or a new hire in your own company. This lets some unimaginative bean-counter make a decision and feel good that for once he/she had something useful to do... (whoops! Did I just insult bean counters everywhere...?)

We run into this with the U.S. Navy now and then. It isn't that the s/w is badly written or that the person supporting it can't do the job. It is the risk factor, the "bus factor" (though in my personal case, I would prefer the "lottery factor"... :D ) We are not allowed to "roll our own" unless it is something that more than one person on site can maintain, and we are also not allowed to purchase software off-the-shelf unless the vendor in question has the ability to assure product support according to complex rules of contract availability.

As to the boss who has this cockamamie idea to get involved in the database, see if a little constructive rump-kissing might persuade her that her skills are so much more useful as a manager. Then let her come up with the idea of hiring an entry-level data analyst to do the queries. At least you might have a chance for THAT person to be trainable. It's all in how you play the politics.
 

Users who are viewing this thread

Top Bottom