Printable View
Hi
i develop applications for people myself but I'm about to work in software company
and i don't know how they split tasks? and how each one integrate with the work of the others?
what i will do if i stopped at something?will i ask others to get it quickly ?or get it from internet? or what ?
thanks in advance.
As far as getting stuck, normally, people expect you to at least do some investigation yourself.
If it's a solution that can be found via the Internet, most developers would have expected you have already exhausted that method. So if you go up to and bother them to ask 'how do I read Xml into the XmlDocument class?', they'll probably be somewhat suprised if you at least didn't motivate yourself to look at MSDN or other sources on the internet (DevX, CodeProject, VbForums). It takes mere minutes to find an answer if you're good at using the online search engines.
Obviously, if it's something you won't find externally like 'How do I make this in-house component read my XmlDocument?', you will need to ask some developer at your company about it for help - and they will frown if you wasted an entire day attempting to figure it out for yourself when you could have simply asked the guy in the cube next to you. So if it takes more than 30 minutes to figure out - I'd say ask for help.
As far as tasks, how they're divided vary widely from company to company and industry to industry. Most basically, some tasks are assigned by senior developers, some are assigned by project managers, some are 'tickets' assigned by quality assurance departments.
When working on larger projects, normally a source control provider is installed such as (VisualSourceSafe, TFS, or SourceVault, etc). When you are assigned a task, you need to check out the project if adding new classes, or at the very minimal, check out the individual code file if modifying an existing class. After thoroughly debugging your fix or additions, you then check those changes in - and depending on the release cycle of your product - you may need to kick off a staging or production build. In some places that's automated but other places - that's the responsibility of the senior developer or a designated 'buildMaster'. Whatever you do, never check in changes that break the build. If it doesn't build on your development machine, DON'T check the changes in. Otherwise, you'll hear about it soon enough as everyone else's builds will break when they get the latest changes from the vault.
Finally, at some places at the end of the week you get to fill out time sheets that specify what development tasks you worked on or completed on a task by task basis. 'Per ticket#xxxx: Fixed bug in formatter implementation - 4 hrs.', 'Attended team meeting - 1 hr. '. etc.
Good luck and welcome to team development!
Although not a developer i work for a telecoms company as an agent in a 6 man team with only 4 members! How do we achieve targets and come out on top every time with only 4 members?
We are never afriad to ask questions! Our manager has a rule, if you can overcome a problem within 15 mins ask a team member! The 15 minute search shows inicitive after that he see it as time wasting. There is no point stressing over a problem you cant overcome when the guy beside you knows how to get it done.
Any succesful team will always help each other out. I wish you the best of luck in your new job.:)
really awesome
need more to read to improve my experience
thanks in advance.
Also I suggest you buy and read "Code Complete" by Steve McConnell - it is a good grounding for a prtofessional programmer.
I do work for a software development company, and I can assure you that all of the issues have already been worked out by the company.Quote:
Originally Posted by macnux
When you report, they will let you know how things work and flow in their shop and they will expect you to adhere to them.
If you're really unlucky it will be something like these articles I wrote: 10 Ways To Insure Project Failure and Case Study: The 7 Steps of Software Development. :eek:Quote:
Originally Posted by macnux
Thanks for a good laugh and some fond memories (of nightmares).Quote:
Originally Posted by bgmacaw
And, remember: always have Marketing set your programming goals and coding methods - they know the customer's needs better than you do. (And know more ulcer doctors than you do.)
If you haven't read bgmacaw's article on 10 ways to ensure project failure, please do so.
It is very good.
Thanks. :blush:Quote:
Originally Posted by Hack
I guess you can tell that I've seen some 'interesting' projects and managers over the years. For example, I've had the "repeatedly call the person stuck in a traffic jam" thing happen to me not once, but four different times, and I've seen the 'motivational' threats and insults management method used, either on me or somebody else I worked with, well over a dozen times.
Yeah, me too! Thats why is kind of struck home in odd sense. :)
Haven't we all had some of those at some point? I had one job I was going in with 103 degree fever (I had phnomoia). I finaly went to the doc he said either go home to bed for 5 - 7 days or go to the hospital. I jget a call from work the next day (after I call in) from my boss and asks why I can't come in tomorrow, we're going on 7 days a week now.
Good luck, and congrats!
I don't think I could hack it in a professional development studio.
It really depends on the environment... I got lucky, I managed to find a decent place to work, with a great cast of characters. I wont' sugar coat it and say I've had it easy, there's been good times and bad. But I wouldn't trade it for anything at the moment.Quote:
Originally Posted by BillBoeBaggins
I have learned onething about myself working here.... I wouldn't be able to survive the big corporate world.
-tg
thanks for every one
i will read it
This, pretty much, is all I've ever been in.Quote:
Originally Posted by techgnome
Let us know how you make out.[/quote]Quote:
Originally Posted by macnux