|
Not forgetting the Long Weight, a pair of Greased Balls, Sky Hooks and Tartan Paint.
---------------------------------
Obscurum per obscurius.
Ad astra per alas porci.
Quidquid latine dictum sit, altum videtur.
|
|
|
|
|
Shouldn't 3 be the any key? Works especially well on a tablet 
|
|
|
|
|
This message is manufactured from fully recyclable noughts and ones. To recycle this message, please separate into two tidy piles, and take them to your nearest local recycling centre.
Please note that in some areas noughts are always replaced with zeros by law, and many facilities cannot recycle zeroes - in this case, please bury them in your back garden and water frequently.
|
|
|
|
|
I cannot give your company and yourself sufficient plaudits for taking this path. Unfortunately not enough employers have that courage. Mentoring is something I have taken a big interest in.
What background do these recruits have?
Peter Wasser
Art is making something out of nothing and selling it.
Frank Zappa
|
|
|
|
|
I asked about backgrounds etc. almost immediately after being asked to start thinking about putting something together for them. My initial understanding is 18-20 years old, 'A' level educational background, (I believe there is a minimum educational attainment requirement), and they'll be doing 6 months training not on the job but through a recognised provider. My starting point is that they'll be young, keen, probably enthusiastic but a bit wet behind the ears.
When I get a better picture on background I'm hoping to be able to refine my thinking a little further but in general I think a lot is going to be about translating academic knowledge into real world application while teaching good practices.
Rhys
"If you ever start taking things too seriously, just remember that we are talking monkeys on an organic spaceship flying through the Universe"
|
|
|
|
|
Some may disagree but this sounds like a great project. I have dealt with internees that are halfway through a qualification and found them very keen as you suggest.
I always found that giving them real tasks to accomplish as soon as possible was an excellent way to get some momentum.
Peter Wasser
Art is making something out of nothing and selling it.
Frank Zappa
|
|
|
|
|
Start with the important things[^], when the basis is solid, the rest is sure to build up naturally
|
|
|
|
|
Given the fact that I am on Apprenticeship for three years now I might be able to help you out.
1. Networking basics. They will use SQL servers, WPF services, TCP communication and so one - Understanding the Basic concepts of Networking will help them to understand such things easier. I work in Application development, but I am still glad that I learnt the basic concepts of Networking (Subnets, IPv4, IPv6 and so on). Also teach them the basic Network protocols - Http, SSL, TCP & UDP are important basics for every developer.
2. Do not start with Object orientation too early. Start the programming blocks with easy C programs, and show them the limitation of structs - After that, you can make a smooth change from C to C#, introducing classes and stuff like that.
2.1 Even though OOP seems obvious to experienced developers, newbies often have problems until it makes *click* - Some get it faster, some need a bit more time, and some never quite get it. Use the third group to write testcases. Also, add the writing of unnit tests right after they know the fundamentals, and repeat it after every later module (Unit testing specific to webservices, webapps, databases etc.)
3. After the OOP introduction, teach them how to store data in a simple text file - Go over to multiple text files to show them the limitation of textfiles. Afterwards you can make a smooth transition to databases. Start with writing an ERD, and afterwards teach them the SQL basics (SELECT, INSERT, UPDATE, ALTER, JOIN).
4. After they know the DB basics, teach them the webdevelopment things. Best practice here is to do something where they may reuse classes from a client application.
Short example for a programming job / Trainning schedule:
1. -> Write an address management software. Address shall be held in memory (Language: pure ANSI-C).
----> OOP Introduction
2. -> Write the same application in C#. Addresses shall still be held in memory.
3. -> Change the application of 2. to store the addresses into a textfile.
4. -> Write an Item management software for a store. Data is saved to multiple textfiles.
----> Networking introduction
-- -----> Show them examples of TCP communication. Example: Write a simple chat application (Example[^])
----> Database introduction
5. -> Rewrite the app from 4. to store the data into a database.
6. -> Write a web store that uses the database from 5.. Re-use the classes created in 4. & 5.
----> Web service introduction
7. -> Rewrite the application from 5. to use a web service to store data to the database.
Cheers,
Tony
Edit: To make things easier, make sure every of the apprentices has an experienced supervisor for about a year after they ended the initial training scripted above - It will help them a lot while getting deeper into programming (And they do not spend working time on finding ridiculous solutions for easy working time since they just can ask their respective supervisor.).
"Let's see: I'm a white male, age 18-49, I have a loud mouth and a gun... I AM the American Dream." - Me
|
|
|
|
|
Would it be nice to include a small project towards the end of this apprenticeship, which puts to practice all the "fundamentals" they have learnt. Perhaps a set of small tools useful for your company can be built.
|
|
|
|
|
Are you working at a school?
What background do these apprentices have?
Because I believe all subjects except introduction to the company should have been covered already in school.
My list would be:
Introduction to the Company
Company workflow
Company applications and the usage of them.
Company coding standards.
Company applications internal workflow and object structure.
Company database(s)
Or have I misunderstood everything?
Be excellent to each other. And... PARTY ON, DUDES!
Abraham Lincoln
|
|
|
|
|
No, not working in a school, and I'm trying to find out about background but as yet haven't been given a clear direction. I do however agree that all the subjects should have been covered but being in the UK, (and not having that background information), who knows...
At the moment, and in general, my thoughts are to not be too company specific as I'd like to be able to give them the opportunity to think on their feet and apply what they know and what they learn regardless of the environment. I think you're right in they would need to know why some things get done certain ways, why we have coding standards, (and certainly what they are as learning to apply them would be appropriate), and yes having a company focus in those area's definitely gives context which is a great aid to learning.
Rhys
"If you ever start taking things too seriously, just remember that we are talking monkeys on an organic spaceship flying through the Universe"
|
|
|
|
|
We did it in the past with at first a simple throwaway project to let them get known to the framework and the usage of our libraries.
- It starts with some basic things with the framework. The usage of control mechanism like loops, if else, etc.
- Adding Logging
- Adding ErrorHandling
- Adding DataAccess
- Adding Networking
- etc.
After that we give them some small bug or extension for a productive project.
They get an issue from our ticketing backend and receive some other input so they know where to start
This involves:
- Making certain that the application runs fine on their development machine
- Letting them test the application (a bit playing around with the debugger and so on) to get acknowledged to the code base
- Pointing them to the direction where and how they should start solving the issue.
- We give them some time trying to solve it. They are free to ask for guidance when they are stuck. In regular intervals we ask them about their progress and provide further help if needed.
- If the bug is fixed or the extension working, the code gets reviewed and corrected with explanation why something was wrong
- If everything is fine: Show them how to publish it to the test server etc, involving the QA and finally publishing to productive system.
- Rinse & Repeat with a new issue
Things I've noticed:
- Give them time to learn
- Don't let them feel lost! Ask them about their progress ("Fine" isn't progress  ). Let them show you what they've done and correct them if they did something wrong somewhere.
|
|
|
|
|
Make sure the other team members know to give them time as well. Perhaps rotate them around. Give them words of encouragement. I've seen at first hand what can happen to a developer's morale when they've been viciously cut down.
If there is one thing more dangerous than getting between a bear and her cubs it's getting between my wife and her chocolate.
|
|
|
|
|
I forgot the most important thing. You have to tell them the preffered music of the devs. No Justin Biever sh1t and so on. You have to tell them what music is allowed in the office too.
Microsoft ... the only place where VARIANT_TRUE != true
|
|
|
|
|
What we do these days is "learning by doing" - i.e. we give a new developer a real, but low priority task and help them complete it. Then GOTO 10, and after a few iterations they should be able to start contributing.
|
|
|
|
|
I would expect that your apprentices have some background in programming already. Otherwise, you are really going to have your hands full. It might be like fitting a round peg into a limaçon shaped hole.
I always heard that schooling and theory are nice but you don't really learn about programming until you start a real job. I guess I would focus on things that are not taught in school.
How we do things here
* sw dev process
* dev tools
* roles, permissions
* docs, support
* the "maybe someday" dream list
Why we do it that way
* CMM growth and planning
* economics and reality of business
Why everybody else is different
* innovation
* skills vs cost
Your idea for some mini internal projects is a good one. Some favorites are: phone list, bug tracker, time & expense tracker.
Code reviews are a great way of tuning-up a new developer really quickly.
I've seen a lot of developers started-off as testers so they see the evil that can come from mistakes (get them thinking of how to avoid anti-patterns) and organize their thoughts into test plans.
|
|
|
|
|
When I have to teach others to prepare them for the company I always do three things:
1. Keep in mind that they can come with fresh and new ideas.
2. Show them the company, introduce people, explain what we make deeply.
3. Give them an exam that will take more or less one week to be accomplished.
In that exam there are small but important things related to the methodology applied in the company. This is good for two reasons:
- They face real problems and try to solve them in the best way following the rules to solve them.
- Some times (not much but it has happened) they come up with better solutions to the problems we face.
- Being successful or not solving that exam, at least they will understand perfectly what was being asked and why of the given solution.
This is working for me and for the company. 
|
|
|
|
|
Rhys Gravell wrote: Well my employer are looking at taking on a couple of apprentices in my team,
Presumably you mean 'no experience' and not 'no knowledge'.
If so a senior developer must be tasked with mentoring them. Probably for at least 6 months and probably at least with 10% utilization per new developer.
The mentor must be enthusiastic about the task and should probably be reviewed based on the success of the developers.
And when I say "must" in the above I mean exactly that. It isn't an option. Failing at that means that the success of the program becomes solely dependent on the new developers. And that is a really poor way for a company to proceed. Not to mention of course that it will probably fail probably at the 90% level (thus no gain for the cost.)
|
|
|
|
|
Movie Quote Of The Day
I don't give a f*** how long she been dead - the bitch just walked on the ceiling. She ain't staying in here.
Which movie?
|
|
|
|
|
|
The Pet Guide
Microsoft ... the only place where VARIANT_TRUE != true
|
|
|
|
|
Bambi
“I believe that there is an equality to all humanity. We all suck.” Bill Hicks
|
|
|
|
|
How to kill your wife in 40 easy steps?
Every day, thousands of innocent plants are killed by vegetarians.
Help end the violence EAT BACON
|
|
|
|
|
"Killing Your Wife, For Dummies", know available on Amazon 
|
|
|
|
|
Poseidon.
If there is one thing more dangerous than getting between a bear and her cubs it's getting between my wife and her chocolate.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
