5

I'm fairly new to working as a programmer, at least working as a regular employee in-house for a company. I often become frustrated with my company's management style as they basically just pick out whatever random tasks catches the lead developer's fancy that day, or the day before, and give me the task (with tasks usually lasting less than 1 day). A lot of the tasks I have now are fairly small and are for adding enhancements to a web application, fixing bugs, etc.

I am bothered, however, by the fact that they don't plan ahead so as to give me an written outline of projects a few days in advance so that if, for example, I am rusty on something I can at least familiarize myself with it on my own time or at least have a more relaxed approach to the job so that everything doesn't have to be so reactionary on my part (where I can mull things during off-time over before starting work on them, etc)

I guess I'm just curious if this is the norm or if most development jobs value clearly laid out specifications for tasks and are able to prepare them somewhat in advance. I would be interested to hear anyone's experience / opinions, etc. Thanks

Improve this question
2
  • You may want to clarify what industry this company is. In truth, it depends, companies that aren't programming focused often don't have a programming structure in-place. The methodology for what to program next is often determined on an ad-hoc basis.
    – Bill
    Dec 14, 2010 at 23:40
  • They're a SAAS company, actually they are supposed to be focused on the software but it seems the focus is elsewhere (marketing, selling)
    – programmx10
    Dec 14, 2010 at 23:42

2 Answers 2

Reset to default
3

No, what you have is rather rare in my experience. Scrums tend to allow some flexibility in knowing what is coming up as the sprint has a defined set of work that is to be during it as there are planning meetings where the team decides, "This is what will get done during the next sprint." That does tend to prevent the, "Oh get this done NOW!" kind of dramatics usually and give some bounds on where the focus is during a sprint. Typically, things aren't written out well and so clarifying what is requested and how much time should be spent are a couple of factors to consider with things. For example, some bugs one could spend days getting all the cases covered thoroughly while some may accept the work that can get done in a couple of hours that covers 99% of the cases that will often happen.

To take a devil's advocate position about not knowing what is coming soon, would you really want to be told one thing only to have it changed a few days later when you were just about to start working on it? I mean imagine if you thought you'd get to work on feature X but instead support request Y takes priority and that wasn't reported until late yesterday so there wasn't a lot of time to tell you about this change until now.

Improve this answer
1
  • Thanks, this helps clear it up. I previously did remote work freelance / contract work for a small web dev company where most communication was via email, etc so maybe I got more used to that, where communication was a bit slower and more methodical. Anyways, it would still be nice to have a situation where I at least have a tentative plan going a week or 2 ahead.
    – programmx10
    Dec 14, 2010 at 23:33
1

No. An average task given to me isn't well defined until after I mess with it for a week, for which I need to pry the information out of whoever has it. Even then I feel hazy about what actually needed to happen.

Improve this answer
1
  • I agree. I'm often included on projects as if I was there from the beginning and I understand all the things that aren't explicitly mentioned. I'd prefer to skip all of that and have them tell me what I am supposed to put where. That's what it always boils down to anyway.
    – mj1531
    Feb 10, 2011 at 16:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.