Troubles understanding specification of ticket

[Blaudroid]

Hi there,

 

i am 24 years old and i am doing my apprenticeship in Web Development. I use PHP, HTML, Javascript and SQL on a regular basis every day.

When i first started the apprenticeship i was rather quick and have found solutions to problems way faster than i do now. Now i struggle with understanding the specification of the ticket (we use agile and kanban jira) and i often seem to look in the wrong place for a fix or for adding a new feature. I am mainly in the E-Commerce Branche and we use Shopware as the shop system. Now whenever i get a ticket that i have to solve, i would take literally days for me to find out that i was looking in the wrong place the whole time, and that affects my reputation in the company as a whole. I wonder if some of you have some tips on how i should go about the ticket, what questions should i ask (another big problem, i've been told that i don't give enough information about what i actually want) but tbh i myself don't even know what i want from that ticket... I really love Web Development, i did it as a hobby for a long time, but now that it has become more serious and the expectations are very high to deliver high quality code and not only but communication too has become more more demanding of me.

 

What should i do? What can i do on improving my skills of recognizing what the ticket specification wants? What can i do to improve my "searching" skills for the place in code where the change has to be done? And overall how can i go about communication to the Project Manager or other Developers about what i actually want from them? 

 

You'd be very helpful to me :( i usually find myself not confident enough to say "this is the thing that needs to be changed, this has to be done in order for it to work" because i am not sure if it's true or not. 

 

[Haraikomono]

11 minutes ago, Blaudroid said:

Hi there,

 

i am 24 years old and i am doing my apprenticeship in Web Development. I use PHP, HTML, Javascript and SQL on a regular basis every day.

When i first started the apprenticeship i was rather quick and have found solutions to problems way faster than i do now. Now i struggle with understanding the specification of the ticket (we use agile and kanban jira) and i often seem to look in the wrong place for a fix or for adding a new feature. I am mainly in the E-Commerce Branche and we use Shopware as the shop system. Now whenever i get a ticket that i have to solve, i would take literally days for me to find out that i was looking in the wrong place the whole time, and that affects my reputation in the company as a whole. I wonder if some of you have some tips on how i should go about the ticket, what questions should i ask (another big problem, i've been told that i don't give enough information about what i actually want) but tbh i myself don't even know what i want from that ticket... I really love Web Development, i did it as a hobby for a long time, but now that it has become more serious and the expectations are very high to deliver high quality code and not only but communication too has become more more demanding of me.

 

What should i do? What can i do on improving my skills of recognizing what the ticket specification wants? What can i do to improve my "searching" skills for the place in code where the change has to be done? And overall how can i go about communication to the Project Manager or other Developers about what i actually want from them? 

 

You'd be very helpful to me i usually find myself not confident enough to say "this is the thing that needs to be changed, this has to be done in order for it to work" because i am not sure if it's true or not. 

 

dont be shy to ask questions to your seniors,

thats all the advice I can give really,

When I was your age, and started out working in a big company I always thought that I needed to be always in the position to know everything.

But it turned out, they dont expect much of you at the early stage, try to get confortable with the work enviroment and try to build "teacher/student" relationships with seniors.

Now may probally not the time to do it efficiently bec of the pandemic, but dont overwork yourself for each ticket, take your time

and talk to your colleagues

[lutzee]

Like Haraikomono said, don't feel that you are expected to know everything, you're never going to know exactly where every feature is implemented within a code base.

1. Don't be afraid to ask questions to your colleagues, the best developers spend a lot of time asking questions to understand requirements
2. Following on, there's no dumb questions really, we all have moment where we feel we should know the answer to something innocuous but the answer just isn't there, just be wary of repeating the same questions over and over, make notes, while very analogue a good notebook and hand written notes is a very powerful tool and shouldn't be overlooked. 
3. Its OK to be wrong, in fact its pretty normal to not be correct on things, don't take it personally if you do get corrected, try to understand why you might have been wrong and learn from it, and this leads into my next point
4. Ask for feedback, you should be getting feedback anyway in the form of code reviews (at least I hope you're peer reviewing each others code), but even outside of code reviews you should be asking for feedback, if you're working on a feature ask for some feedback when you've got it in a somewhat workable state, if things aren't right you have the ability to easily change direction, often these first prototypes can help a feature requester understand exactly how they want a feature to work.
5. Try not to work in specifics if you're not sure/confident, "I think this needs to be changed, I believe this is the code causing the issue, I feel this is what needs to be done to make this work", only with more experience will you pick up the confidence of working in specifics, and even then you will make the odd mistake, I certainly do. 
6. If you don't do so already, ask your manager for weekly 1 to 1 meetings and identify a list of skills to work on and provide help and learning opportunities to achieve them

Some further thoughts 

• Its possible that you're getting tickets with not enough information, if its a bug the best tickets have a full set of steps to reproduce the issue, if they don't then ask the reporter to provide this information. 
• "I've been told that i don't give enough information about what i actually want" - You need to spend a bit of time analyzing new features, identify what it is you've been asked to make and make suggestions on how this could be achieved, as you're an apprentice then this should really be done with another developer for the first few times. If you're still struggling with a feature request its possible it doesn't have enough information. In these cases you need to work with the requester to understand the problem, normally fitting into the format of "As a <person/role> I would like to be able to do <thing> so that I can <find out/view/understand/perform task>"
• As for finding things in the code, this is just going to be down to experience with that particular code base. Sometimes some things can help, if you know that the code is outputting a given piece of text for a given system, you could search for that text in the code, if you know that a particular api endpoint has issues you should be able to track down where that endpoint is defined. But often a lot of issues boils down to how good of an IDE you're using is, my personal experience writing in C# using Visual studio with Resharper its easier and faster to dig through an unfamiliar code base because I know the tools I use are really good at searching code. Trying to program using more simple tools like Notepad++ for example would be much harder, and even though Notepad++ is a fantastic text editor it is not an IDE. 

This became a very long response, but I hope its helpful, you're very early in your career, but you'll always be learning new things

[Eigenvektor]

8 hours ago, Blaudroid said:

What should i do? What can i do on improving my skills of recognizing what the ticket specification wants?

In my experience, most tickets are worded badly and/or contain incomplete information. If the ticket isn't clear, ask for clarification. Where I work a lot of tickets (used to be) way too short and not descriptive enough. We've gotten better at writing good tickets, but still far from perfect.

 

The information contained in them was perfectly clear to the person writing the ticket, at the time. The developers they had an hour long meeting with knew what to do. Priorities changed, the ticket went into the backlog and half a year later no one had a clue what exactly the ticket was talking about.

 

This is not the fault of the developer being too dump to understand what is being asked, it is the fault of the person writing the ticket of not making their requirements more clear. When I get an unclear ticket, I ask for more information and in a lot of cases supplement the ticket myself.

 

8 hours ago, Blaudroid said:

What can i do to improve my "searching" skills for the place in code where the change has to be done?

Experience with the code base is the only answer I can come up with. Maybe have a good look at the code as a whole, how stuff is organized and put together. Not in detail, but the overall structure of it.

 

I switched from one internal project to another about a year ago. The code base is huge. Despite being an experienced developer I had a lot of trouble finding where stuff was implemented at first. Don't be afraid to ask more senior people where to go. Now, a year later, I can find my way around the code base much easier because I have a much better grasp of how stuff is organized.

[Blaudroid]

Guys, i want to thank you very much of your answers. I have definetely taken something from them. The idea with the notebook hasn't come to my mind and i will start using one and make notes.

 

 you guys are the best.