#Am I the bad dev here or is my job toxic?

46 messages · Page 1 of 1 (latest)

elfin ore
#

Hello, I've got myself in a weird situation by taking on a difficult task assigned to me (2.5 sprints ago). In the first sprint, I started the task, but I lost a lot of time investigating how that area of code works (We don't have "dev" documentation for the project), and when I started to implement the feature, I got into a lot of problems. The lead of my team helped me finish the implementation, but there were still obvious problems. Even though the task wasn't working in every case, I created the PR (as my lead suggested) and went through without problems.

After QA started testing the feature, a lot of bugs were found. I couldn't fix them or find any specific fix in the 1st sprint, or in the 2nd (so 2 sprints were failed because of my story). Now I'm in the third sprint, where I still carry this story. Usually, in the daily, I expose my problems, but I might not be so clear when explaining them. My lead in the last few days hasn't had a lot of time because this is the last dev sprint before release and other colleagues in the team have other stories to work on.

I also have to mention that the environment I have to debug in is really clunky and very slow (so it's really frustrating). Currently, I'm remote debugging a debug build on the test machine because I can't replicate the environment on my dev machine.

I'm kind of stuck in this situation, and at this point, I'm not sure if this is only my fault or not. I'm at the point where I've lost all my motivation to work, debug, or do anything about this. I'm really thinking about just resigning because I'm exhausted (to be fair, I'm not sure if I will lose a lot; in the last months, I haven't evolved so much in this role; I'm still in a junior dev role in this team with 3 years of experience, but I guess I'm not that good as a dev either).

LE: sorry for the wall of text 😦

lime patio
#

"Fault" is generally not a useful concept

#

Is it common to encounter situations like this? Exceedingly - it might even be most software engineering

#

How should you approach it? Document time spent doing things that you didn't expect, both for yourself in future estimations and to help inform why the team should spend time fixing those things. Communicate to your stakeholders often and as soon as you know things are going to take longer than you expected, even if you don't know how long. And check in with your manager or team lead: as the task expands, is this still what they want you working on?

elfin ore
#

Thank you for your feedback @lime patio, noted it for myself, as I've met this situation in the past but I guess I haven't learned my lesson

cloud crag
#

at the end of each of those sprints what was the outcome of the retro? did you follow up on the action items?

#

if your team didn't follow up, then how could any improvement be expected?

ruby peak
#

In an extremely similar situation myself and its so tiring

jade otter
# elfin ore Hello, I've got myself in a weird situation by taking on a difficult task assign...

A lot of companies don’t have diagrams or a lot of them hide a lot of things from junior devs. Older devs sometimes sabotage the new comers by misleading and giving half information because it’s just more work for them. A lot of companies really don’t have enough resources to on board new devs. You’ll know if they high turn over rate. A lot of new people coming and going out.

warped tangle
lime patio
#

This is going to depend a bit on your team, but usually in sprint planning meetings you're talking specific tasks/tickets. Whoever runs those meetings will have guidance.

#

Being vague to give yourself "a way out" is the opposite of what you should be trying to do! That's "cover your ass" engineering, and when a company is embroiled in that it really prevents teams from being able to function well.
The thing about software is that it's really hard to estimate how long something will take. That shouldn't stop you from trying, but everyone pretty quickly comes to understand that estimates can be waaaay off. The development processes that we use are built around the concept of needing to adjust as we go.
For someone doing project management (that is not necessarily their title), what they want to know is information on whether the estimate is changing, as soon as possible. Very rarely are there actual deadlines for projects, but how long something will take affects scheduling of other projects, and also the relative prioritization of this one. So they spend a lot of time keeping stakeholders apprised of where the project is and collectively everyone is shifting things around constantly.
If you give vague information intended to protect yourself ("oh, yes, you all thought I was going to get A done but really I didn't promise that") that prevents them from being able to effectively do that coordination.

#

The sort of vagueness that is helpful is giving units of uncertainty, which is what story points are. 1 point is something that you're pretty sure has no hidden surprises in it, but when you get to 3 and 5 pointers you're saying there are unknowns and so the actual amount of time it'll take has a large variance (I tend to interpret 3 points as being like "probably between 2 and 5 days" and 5 points as "probably between like 3 and 10 days", but your company will have its own definitions).

warped tangle
#

hmm...it's kinda tricky you know...as there are basically two things that could happen when I say I'll do task A...one, I complete it, two, it takes longer than I estimated.

#

The reason I was wondering about vagueness is because there have been scenarios where, like say case one, I complete a task A, which is integrating a function in a ML model. My boss, who is from a photographer businessman front end developer background and perspective, will then comment on the results as a whole and point out why it's not up to standard.

For example if I was working on a functionality that make photos more sharper, and gave him a set of 100 pictures results, he would then comment oh but there are camera sensor marks here on this picture, here this picture is stretched, the lines should be straight in this picture, etc basically commenting from a professional photographer point of view on the pictures as a whole, like a photograph connoisseur, rather than comment on the actual functionality results I showed.

That's not even to mention that sometimes, I integrate functionality from research, and it doesn't translate to better results irl (as ML is more experimental in nature), and my boss will complain about why this feature we built doesn't make better result, waste of time and all.

#

Case Two is it takes longer than estimated, like if I integrate a function in a ML model, but the code doesn't work needs debugging, or it doesn't work as expected, then there have been scenarios where my boss is like why's it taking so long hurry up get it done.

#

And three is more ML related, that my boss wants me to get better results (which require more training runs), but also want low machine learning training costs (which means less training runs). So there is a contrast between desired goals and desired use of resources here.

#

So because of these scenarios that have happened in these cases, that's why I use vagueness as an out for when my boss complains and stuff, I can just be like 'I'm working on it'. But yeh I'll try to be more specific.

lime patio
#

Case 2 is normal uncertainty and part of why estimation of tasks should never assume everything is going to go smoothly, unless you have done the exact thing before.

#

Case 1 is either valid feedback on problems with what you've made (and counting on there being iteration would again be part of your estimate), or if it doesn't actually matter that those things happen to the images, then you need to nail down requirements and what's in scope at the start of the task

#

Case 3 is a fairly common pattern as well. You lay out the options (we can spend x time and get these results, or y time and get these, or z and get these) and they get to choose which one.

jade otter
warped tangle
#

ok thanks for the help I'll try to communicate to my boss these things that has been mentioned, about requirements, scope, options, task estimation, and realistic expectations

warped tangle
lime patio
#

Results

warped tangle
#

okay...my boss usually lays out the results he expects...then I suggest to him the tasks to get there...

lime patio
#

Right

#

What you laid out though was that you built a system that (I think) didn't meet requirements: made images sharper, but created other undesirable artifacts. I'm assuming here the requirements are "make images sharper and not worse in other ways"

warped tangle
#

oh, no, make images sharper is one of the subtasks (which I used as an example)...the requirements is a system that can completely or at least majorly replace human retouching process in professional photography...

#

using AI

#

so like for example that system would compose of a lot of functionalities, of which sharp images are one of them...what I was describing was that when I integrated a functionality that would make output images sharper, my boss would then complain about other aspects that are not up to the standard of professional retouching, basically...

lime patio
#

Sure. If you have a path forward that would fix those, you can tell him that. If you don't, then what you've tried isn't working and you have to scrub it.

#

Or do you mean that the problems he's pointing out are not because of the sharpener, but existing problems in the in-progress system?

warped tangle
lime patio
#

Oh, I see. Yeah, lots of firm "x is a known issue and ticketed" and redirecting him. It will probably help to be showing him progress very frequently to help keep him up to date on what's already known, and also showing an issue tracker full of to-do tasks can help as well. Because he thinks he's giving you useful feedback on new issues.

warped tangle
#

ok so having an issue tracker and progress tracker and using it to communicate with him would help then

warped tangle
lime patio
#

You're needing to learn how to be a project manager, because you don't have one and so you get to fill that role

#

If the scope of the project is as large as I suspect it is, really what your boss needs to hear is "hire a CTO and let them build up a team and check back in five years". But I don't know the deets, so maybe it's more feasible than that.

warped tangle
#

hmm...the issue was at the start of the project I visualized this as an image to image translation task...so I've gotten the image to image translation part done...but because of the nature of professional photography, now I realize I also need to get the high resolution functionality, and structural changes functionality in there too, as that's an aspect of it...and my boss is basically unhappy that it's taking more time than he expected...

I'll look to document all these that you mentioned...issues (results based), tasks/to dos (effort based), progress (of tasks), and task estimation (time based)...hopefully that will help with communication and project expectations...thanks for the suggestions I appreciate it...

lime patio
#

This sort of situation happens not infrequently btw, with small businesses: person wants to do X but doesn't realize how huge of a project it is, finds a junior software person who is willing to take on the challenge, and eventually they come to frustration because neither person realized how impossible the task was for the budget they were spending

#

If your boss is trying to like, make something better than Luminar, that's not going to happen with just you. Not because of anything about you, but just it's not realistic

warped tangle
#

from what I know, professional retouchers use Luminar to retouch photos...my boss wants to automate that entire process (taking out the luminar and retouchers) while maintaining the same results standard...

you mentioned not realistic right...so how do I communicate to my boss if I feel like something is not realistic?

lime patio
#

Honestly, it's a tough one, because it's the entire thing your job hinges on

#

That specific question might be a good topic for #communication !

desert stone
#

fwiw @warped tangle it's better to make your own post rather than pull up a several-week-old one to have an extended unrelated discussion in