When is one ready for corporate America

[tt1611]

Bizarre heading for a topic i know but i was wondering if i could get your general ideas and thoughts. Yes I know access vba is a huge programming tool and one learns daily (trust me i know this only too well). Yes i also know requirements vary from company to company and from programmer to programmer but all other things being equal using what experience you have, when would you say one was ready to work professionally developing access databases.

By this question i mean what wouldyou list as the minimum functions and requirements (techincal know-how) needed to develop large scale databases.

I have been working with Access for the last 3 years developing mid level databases, connected to backends (SQl Server and most recently Oracle).
My apps are workable and have aided in storage and reporting but i still feel like I am not quite there yet especially when it comes to moving to the next higher level up. I am now being contacted for jobs based on experience I have highlighted in resumes and worried that on hire, I might get stuck...is this normal or am I right to say i would always learn on the job ("get your foot in and everything else will work out" are the words someone once told me).

what are your thoughts?

 

[Galaxiom]

Good developers are always out of their depth. They just need be strong swimmers.

Database design and programming is something of an art. It is healthy to always feel like you are still a learner. Some developers stagnate precisely because they work on "always having done it that way" without being able to get outside the box and contemplate different techniques.

As far as I can tell there is always a "next level up". I have lost track of how many times I have nudged open a small window of curiosity only to find a new world of unexpected functionality particularly the integration with Windows itself. LDAP and WMI are two worthy of mention.

One cannot really "know" enough. The scope of the subject is too big.

It is not so much about remembering functions, arguments and enumerations. It is more about systems analysis and then being able find what you need to know to implement your strategic solution even when you don't know exactly what you are looking for.

The skill is in being able to come up with the right combination of keywords and then put the information into the context of your experience. I often try to think from the perspective of how it might be done and usually it puts me on the right track.

As for remembering stuff, I still pull up the MSDN pages for even quite ordinary methods unless I can get fluke them on the first try. Try automating MS Word and you will quickly abandon all hope of remembering the syntax properties and methods of its objects.

And remeber there are no where near enough high level developers and most business are happy to get someone who is willing to give it a try at an affordable salary. Just make sure you keep developing your skills and qualifications because they rarely want to pay what you are eventually worth.

 

[tt1611]

Thank you for your very insightful work Galaxiom. The scary thing is jumping in on the risk (just like opening a business). I accept that there is so much more to do and learn. Honestly I have not got into integratiing Access with Windows yet but this will be something I will be looking into as my current solution grows in size.

Systems analysis like you have rightly mentioned gives room for several ideas in the programmer's mind. Ultimately I guess the goal is to deliver a solution (regardless of how you get there).

Thank you again. Maybe others may wish to comment on this point.

 

[gemma-the-husky]

the problem is sometimes the other way. corporate anywhere (possibly fuelled by protective IT departments) look on access as a "problem child", and often aren't happy committing important processes to a "toy" system.

in practice, I woulds have thought access performs as well as any other methodology, and probably better than most, and gen deliver robust resilient systems.

It HAS to, as you don't want to be spending all your time supporting (unpaid) a defective system. You have to write apps that work, mainly without issues, for an extended period of time.

good luck.

 

[Galaxiom]

Most people who bag a programming technology do so to divert attention from their own inadequacies. They explain that a "proper" sophisticated solution requires a much more advanced approach, moving the goalposts right off the field and so far beyond the grandstand that nothing ever happens.

Any tool in capable hands can be enormously powerful. VBA lacks for nothing when the developer knows how to use it. VBA might not be at the helm but it is certainly in the Windows wheelhouse.

Access really is a very efficient rapid development platform. The "Powered by Micosoft Access" in the status bar is what the wankers really don't like.

Is not unlike making a cake from a packet mix. It still tastes great but there is no kudos when the diners see the box in the bin. Fortunately the proof is in the pudding.

 

[DCrake]

When approached by anyone to create from scratch an idea they have that will make their life easier be it delegation or computising an existing manual process being carried out in the workplace, I always talk to the proposed client about a system specification.

These specifications have three main topics

Feasability, affordability and socialble.

Feasable: Can the idea be actually turnined into an application
Affordability: Can the client afford it
Sociability: will the end user want to use it.

Many a time managers dream up, what they consider is a fantastic idea to improve efficiency, they jot it donw on the back of an envolope and say "This is what I want..." What they have not considered is; will my staff want to use it and will it improve "Their" efficiency.

If you go down the route of providing a system feasability report you should always charge the client for it with the proviso that the cost will be offset against the final cost. This stops the client from touting your system spec to other potential developers.

Also this report acts a brainchild for highlighing to good and bad aspects of the spec which can be relayed to the client.

Get this signed off by the client with an agreed development cost based on the contents of the report, then if at a later date they cheange the goalposts you have ammunition for charging extra for the revisions.

This also provides an insight to the client how professional you are and how you have interpreted their ideas onto paper.

 

[Galaxiom]

The importance of the system spec cannot be underestimated. Consider the debarcle with the Queensland (Australia) Health Department Payroll System.

This blew an absolute fortune in a futile attempt to adapt a payroll system that was designed for nine-to-five employees to a complex arrangement involving shift work, penalty rates and allowances. It was a dismall failure and they are now preparing to compound the woes with $200 million "fix" on top of advice from two Canadian payroll experts brought out for two weeks at a cost of $350,000.

They still have not addressed the fundamantals.

 

[sportsguy]

depends upon the size and age of the company. I fill in with access where the oracle and SQL server programmers take forever, their queue is full, or I need this in a trend by month for 36 months, whereas the transactional programmers dump monthly transaction reports, and programming three years will take too long, with limited server and manpower.

Look for analytical type opportunities or marketing/ sales as well as essbase automation.

good luck, and that's where I am though overqualified in my job and grossly underpaid.

sportsguy