4

Here's my current situation:

  • I am a junior PHP developer since almost 2 years, previously only QA

  • Never got a proper introduction or overview, still often encounter code/entire projects I've never touched before

  • Got great feedback at first

  • Recently I'm told my progress is lacking

  • Coworkers sometimes react snappy or mock me when I ask questions, giving me the impression that I shouldn't need to ask questions anymore and am not allowed to not know things

  • Whenever I take a more complex, 'hard' task I usually need quite a bit more than the estimated time. Nobody has given me trouble for it so far, but I feel like this means I'm not a good dev?

  • Often task descriptions are vague or straight up incorrect, and I am expected to remember verbal discussions that directly contradict the story descriptions. I am bad at remembering verbal things, which is why I rely on notes and written story descriptions a lot, but they are often unreliable as changes in requirements are not documented. I feel like rather than expecting me to remember all these verbal agreements we should work on better documentation instead. Am I wrong?

Basically, where should I stand as a junior dev with almost 2 years job experience - am I lagging behind? Is it a problem that I still need to ask questions regularly, and take more time than others?

closed as off-topic by sf02, IDrinkandIKnowThings, scaaahu, gnat, mxyzplk says reinstate Monica Jul 12 at 13:12

This question appears to be off-topic. The users who voted to close gave this specific reason:

If this question can be reworded to fit the rules in the help center, please edit the question.

  • Great edit you did there :) pruning my comments – DarkCygnus Jul 11 at 20:47
  • Have you tried taking a notepad to write these verbal discussion notes down? Suggested a Wiki ? – Smock Jul 12 at 16:09
7

Is it a sign of me being basically 'too dumb' if I still need to ask questions after almost 2 years?

Not at all. But it sounds like you're asking the wrong questions.

I asked an experienced coworker if he could give me a quick introduction.

That's beyond vague, and sounds like you haven't even tried to figure it out.

If you asked me to give you a "quick introduction" to the codebase I'm working on at the moment, I wouldn't know what you really meant, nor where to start. If you distracted my current train of thought with that question, I could indeed become a bit frustrated and just want to go back to what I was doing ASAP.

However, if you came at me with the following:

Hi berry, I'm looking at the getStringDescFromOpacity() function in CompanyUtils.php (line 137) while doing (x task) and noticed there's no explicit type declaration set. Can I add a string type declaration here, or is there something I'm overlooking?

...then I know exactly what you mean, I think "hmm, good point", and I can respond quickly with any potential things to watch out for. I don't need to second guess what you mean, or worry I'll spend half an hour formulating a response that's not going to help you in the slightest.

Was his response rude? Sure, quite possibly. But he's also likely got tight deadlines to work to, lots of projects on the go at once, lots of other commitments, and feels frustrated that he could just do the whole thing himself in less time that it took to give you a "quick introduction" to the codebase.

...struggling with vague and incorrect details in the story description, which my boss then snaps at me for because 'we talked about doing it differently'...

...yet here sounds like the perfect opportunity for a really good, focused question to clarify a clear requirement, and you're passing it up because you can just guess at the answer.

I can't imagine if you phrased a clarification on a requirement (or even just a confirmation of your approach) in a clear, concise way to your boss, that you'd get shouted at for it. (If you do, go work someplace else.)

Wordy, vague questions though that don't show much research effort - well, they tend to frustrate even the most patient colleagues eventually, and I suspect that's why you're getting some of the responses you are.

  • Hi, thanks for the answer! In this case I was asking the coworker to give me a quick general overview about a code project I hadn't worked with before, as I could find basically no documentation. I probably should have tried on my own first, but I thought it would go faster if I get a quick general introduction from someone who worked with it a lot. As for the requirement thing, basically the story said to do things one way and apparently we talked in the sprint meeting about doing it another way but noone edited the story. – yeaitsme Jul 11 at 20:21
  • 3
    @yesitsme But as per my answer, what you mean by a "general overview" is very unclear. I could spend hours giving you an overview of what I think is a codebase's most important bits, then find out that your task doesn't involve working on them in the slightest. It's always best to dive in first, documentation or no documentation, then ask specific questions if you get stuck (even if those specific questions are simple ones.) As to your second point - that comes down to making sure you take detailed notes in meetings and confirming in writing afterwards. – berry120 Jul 11 at 20:32
  • @yesitsme Getting a guided tutorial from an expert on something you haven't looked at before is generally faster... for you. For the person giving the tutorial, it's all a loss-- they are trading time getting their own work done in order to transmit that information to you. I think that's the issue. Without specific questions, there's no precision on what the other person should tell you or what you must know. – Upper_Case-Stop Harming Monica Jul 11 at 20:33
  • I see, you all are probably right that I should try myself first in the future and only ask when specific issues arise. – yeaitsme Jul 11 at 20:34
1

often task descriptions are vague or straight up incorrect, and I am expected to remember verbal discussions that directly contradict the story descriptions. I am bad at remembering verbal things, which is why I rely on notes and written story descriptions a lot, but they are often unreliable as changes in requirements are not documented. I feel like rather than expecting me to remember all these verbal agreements we should work on better documentation instead. Am I wrong?

While much of your question is unanswerably vague and general, this at least is something you can act on.

Unsettled requirements and contradictory information are not good things, but they are also challenges that virtually every project and organization struggles with - they are reality you cannot avoid, but instead need to learn to manage, correct, and overcome.

So when you receive oral instructions which seems to contradict the project documentation, the best thing to do is to start by writing up a summary of what you believe you've been asked to do, and then share this with the asker or project owner to try to get it adopted (or itself corrected) and incorporated as a change into the project documentation. Depending on how the documentation itself is managed, you may be able to directly make or propose changes there, or you may just have to develop a collection of supporting memos or notes, ideally in a place (project wiki?) shared with the other developers and stakeholders.

The idea is to pass your interpretation of the evolving requirement back to the person who requested it, and confirm both that your understanding is what they want, and also that other parties don't already see a serious conflict between that goal and some other goal.

Worst case, if you can't document changes anywhere else, you could in desperation even put it in the code itself, ie

/* Although the project specification called for this function to return
   x in the situation of y, discussion with DPS on 6/11/19 indicated that
   it really needs to return z, and so for the time being has been made to
   do so, with the original behavior retained in commented form.
*/

If you encounter pushback or anger at your initiative in trying to document the evolving changes to the requirement in order to achieve enough clarity that you can act on them, and this becomes a roadblock to your ability to make assigned progress (rather than just an uncertainty in an area that is not yet assigned to you for specific action) then that would be when you start to realize you are may be in an unhealthy environment.

Be patient with project leadership too: one of the things to remember is that making decisions about what the code should do tends to be a much harder part of the overall task than banging out the code to implement that decision. You shouldn't be constantly stuck busy-waiting for answers, but you may also at times have to switch task while some thorny aspect of the design is being worked out, or pitch in and help reach a collective decision about the best path.

-1

Sounds like you are working in a toxic environment.

Asking questions is not a crime. At most places it is welcome. Just make sure your questions are organized and not continual.

Produce a quality product.

Don’t let these people distract you. However you might want to start looking for another job.

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