Adam Scheller wrote:How about working remotely? Working at home would definitely minimize amounts of stress that would be good for both you and your employer. You speak English, could work for any company in any country, so you wouldn't have to relocate as well.
I am working remotely myself, for about good 4 years, and everything is great. I started as a programmer and got promoted up quite quickly. There are plenty of companies that hire remote workers, especially in IT. It's really worth to consider that option.
Henry Wong wrote:Not from India, so may not be a valid response.
Have you tried avoiding higher stressed positions? Perhaps in the maintenance of a project? I would probably recommend avoiding startups or the finance industry.
Paul Clapham wrote:Here's another issue which I don't know if you meant to ask about: For quite a while your team will not be producing anything useful for the company you work for. So you're going to have to work with your bosses to make sure they understand that and are OK with it. It may be that they thought that they could hire a group of beginners and expect them to be productive immediately, and if so then you need to help them to understand why that isn't the case.
Jeanne Boyarsky wrote:
I'm not clear on where you and they are. If you can't pair in person, can you pair remotely? Being in charge of a bunch of new programmers you can't communicate with synchronously isn't likely to end well.
Jeanne Boyarsky wrote:
Wait. They don't know Java yet? I thought they were inexperienced and not lacking in basic knowledge. Freshers usually wen to university and come in knowing some programming language. If they don't even know Java, you need to talk to your boss. Expecting you to teach them and get a project done is a lot to ask!
K. Tsang wrote:Further to what Jeanne said
1) When you do assign tasks to your team, such tasks should be the use-cases or functions for the site, not different phase of SDLC like testing. That way the person can develop it, test it, refine it... He owns that function. Yet you as the leader is responsible if anything goes awry.
2) Prepare to work on documentation (tech spec, design spec, etc)
3) Ask the team what tools they have used. Research on such tools then decide if they can be used in your project. Relearning/using something that is familiar in the past tends to be quicker than learning something brand new.
Jeanne Boyarsky wrote:Vasmi,
A few pieces of advice:
1) Get to know the team members. What are their skills? What do they like to do? What problems are they struggling with.
2) Carve up the work into smaller pieces. You should be involved in the design. And how to carve up the tasks into manageable pieces. This also lets you know early when something "doesn't work" so you can help/intervene earlier.
3) If you have time, see if you can pair program with each of them. Even if it is just an hour or two a week each, you can help grow their skills.
4) Don't assign yourself any coding tasks. You'll be plenty involved pairing, mentoring, etc.
And yes, Selenium is a great tool.
Campbell Ritchie wrote:I try my hardest to avoid tools like BlueJ. I hate BlueJ.
Tim Cooke wrote:There are a number of structured courses being delivered online for free. Sites like Coursera and edX provide extremely high quality material and have scheduled assignments that are to be submitted online, with deadlines and everything.
Please, please do not. That "hours and hours of theory" form an important foundation for an developer so they understand the choices that are made when creating an application or infrastructure. The last thing this world needs is more paint-by-numbers cargo-cult programmers who have been coached in interview questions.
Having done some basic adult literacy education, I will tell you that preparing someone for the work force takes a LOT of work. Many times they will lack the most basic life skills that most professionals take for granted, like reading a bus schedule, much less the technical vocabulary and mathematics it takes to make a decent programmer.