Peter is the former President of the New Zealand Open Source Society. He is currently working on Business Workflow Automation, and is the core maintainer for Gravity Workflow a GPL workflow engine.
Developers who are fresh; aka first job, need a proper induction. Typically in my teams they are given small well defined tasks which are not on the critical path. You don't want to overload them, and especially with complex codebases you want to expose them to limited sections rather than everything all at once.
You need to give them a mentor, usually a senior developer, who will act both as a guide and reviewer of their work. After a few months of this they gain the trust of the team to be able to tackle more complex user stories independently.
I know someone fresh to the industry feels like they want to prove themselves, but software isn't about being a superhero. What matter at the end of the day is meeting the needs of users and delivering value to the business. The success factor here isn't in crazy hours or being a technical supergenius, but rather being able to work with users and clients to address their needs.
Welcome to the tar pit.
Yes I agree. A proper induction might help alot especially to have a guide helping you out with new things and reviewing your work. But a start-up with fewer members can't afford to particularly assign a senior dev to guide/mentor newbies as they already have a lot on their plate.
I knew before joining that ill have to learn alot of new things, some with guidance and some without.
Peter is the former President of the New Zealand Open Source Society. He is currently working on Business Workflow Automation, and is the core maintainer for Gravity Workflow a GPL workflow engine.
Just be aware that often startups exploit the good will and enthusiasm of developers. Having the odd crunch day where you need to do long hours isn't nessasarily a bad thing, but when it becomes the norm it is most certainly not cool.
Throwing a fresh developer at a problem and expecting a solution in a single day is pathological. I've spent a career cleaning up the mess left behind from this kind of thing. joeyoder.com/PDFs/mud.pdf
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Developers who are fresh; aka first job, need a proper induction. Typically in my teams they are given small well defined tasks which are not on the critical path. You don't want to overload them, and especially with complex codebases you want to expose them to limited sections rather than everything all at once.
You need to give them a mentor, usually a senior developer, who will act both as a guide and reviewer of their work. After a few months of this they gain the trust of the team to be able to tackle more complex user stories independently.
I know someone fresh to the industry feels like they want to prove themselves, but software isn't about being a superhero. What matter at the end of the day is meeting the needs of users and delivering value to the business. The success factor here isn't in crazy hours or being a technical supergenius, but rather being able to work with users and clients to address their needs.
Welcome to the tar pit.
Yes I agree. A proper induction might help alot especially to have a guide helping you out with new things and reviewing your work. But a start-up with fewer members can't afford to particularly assign a senior dev to guide/mentor newbies as they already have a lot on their plate.
I knew before joining that ill have to learn alot of new things, some with guidance and some without.
Just be aware that often startups exploit the good will and enthusiasm of developers. Having the odd crunch day where you need to do long hours isn't nessasarily a bad thing, but when it becomes the norm it is most certainly not cool.
Throwing a fresh developer at a problem and expecting a solution in a single day is pathological. I've spent a career cleaning up the mess left behind from this kind of thing.
joeyoder.com/PDFs/mud.pdf