It sounds like something to bring up at the engineering meeting. You may want to phrase it as "why aren't we being held responsible for our mistakes" or "as part of increasing our transparency and accountability why aren't the teams that introduce bugs responsible for fixing them?" instead of whining about being the new guy and getting the ****ty jobs. You're not wrong but pretty much everyone else you work went through it and aren't interested in hearing about it, suggesting improvements to the development process is a better tactic.

This is a good opportunity to just kill it and fix all those annoying and long standing bugs that nobody has fixed yet. Old bugs are the most challenging because the easy bugs are fixed quickly. Devs bring different skills to a team. Having people who are good at solving tough bugs is very valuable and just as important as adding features.

we track our defects (or bugs) in tfs software.

yes we do unit testing and integration testing. which brings up another problem I have had. a few times I have edited a file and added a little bit of functionality and then added unit tests in the same form as the rest. but upon code review I have been told that the unit tests were all wrong and been told to rewrite them. but I did not write the tests in the first place and only added a similar test to be consistent.

part of the problem is that this stuff is very new to our company and the requirements for testing and formatting seem to change daily. but it is frustrating that it seems that I get tasked with cleaning up files that have been there for weeks and months that I did not even write.

I can keep perspective on this though, despite my bitching. I would much prefer to learn things the proper way and be able to things right. still, it is a hit on the ego to get a checkin destroyed esp when I did not write the code that is getting critiqued.

this all makes sense.

but I am not particularly good at solving these and some of them have indeed been there for many months. mys that team only tracked down and fixed bugs. generally, a customer would call the help line and they would create a ticket. some tickets, that I was assigned had been for over 2 years. lololol at thinking I would solve that. I hated that team and am a million times happier on a dev team.

part of my issue is how credit is given. the story cards are worth certain amount of point. bugs arent worth any. so I am a bit concerned that my efforts to fix these bugs may not be recognized as well as other work.

but ya, Bleh/suzzer is right and has the proper perspective here:

still, when it comes to the Angular/Typescript/Redux, I have just as much experience as almost everyone there and I am likely more capable than many ppl who have been there for 10+ years. In fact, some ppl refuse to work on that part of our codebase.

anyway, thanks for the responses and I will stop whining bc really I have no right to given my situation and where I was prior to this job.

When I first started at business.com, fairly early in my career - as low dev on the totem pole they gave me ADBOSS - this internal sales tracking system that was the most god-awful piece of crap you ever saw.

It was basically a tangled mess of JSPs that went straight to the database. Except at some point apparently someone told them JSPs going straight to the DB was bad. So they moved the DB stuff from some of the JSPs into a dedicated Java class that the JSP loaded. This solved none of the JSP->DB problems, but just made things even harder to debug and deal with. At least you could hotload when it was just JSPs.

You could tell the developers had long stopped caring and were just slapping **** on to be done with it. There was code that all over the place that couldn't possibly be executed, or contradicted itself, that devs were too scared or too lazy to remove. I called debugging it 'throwing die in the water' - because the only way was just to start changing things and see if had an effect on the page.

Anyway I learned a lot from that thing. I learned how not to write an application. I learned that if you're gonna do sloppy code, if you at least keep it simple and sloppy it's not that bad. I learned every application has a point where devs stop caring, and your only hope is to write it as tight as possible (which this wasn't) until that happens. There's probably some other stuff I'm forgetting.

Mostly I learned extreme fly by the seat of your pants debugging. Also every other app I've worked on since has seemed not quite as bad.

I think discussing problems you feel at work, especially in programming is both super important and also incredibly difficult for me. I feel like I mostly end up coming off as whiney, but Victor I have had pretty much the exact same experience before. I would give advice but Im not in a place to since its something I work on all the time too, so I would just say ensure you dont come off whiney or blaming. It doesnt help at all

Ultimately it all comes down to whether your boss needs you bad enough to put up with your crap. The more valuable you are, the more crap you can dish out.

Once you have built something important - then you have leverage. You're definitely more valuable than what they pay you. Your boss knows his life would be hell if you leave. You can make all kinds of demands, refuse to work on stuff, walk around in sweat pants, show up at 11, etc.

Until then your only leverage is being annoying, which only gets you so far.

One of my favorite quotes of all time came from an Iconoclasts episode with Bill Russel. He said his dad told him: "If the man asks you to work 8 hours, give him 9. That way you can look any man on the jobsite straight in the eye, and tell hm to go to hell."

The subtext there is they know you're a good worker and it would suck to lose you. Now add owning an important application - and you're set for life if you want it. But it takes time. Sometimes you have to pay your dues and just wait for a good opportunity to jump on.

I've always looked at work like that. **** you, I'm gonna make myself so valuable you're gonna have to kiss my ass. And in the process I've learned a ton and become valuable to other potential employers.

Wait, you guys are using Angular with Redux?

Something that I think takes a long time to learn is:

"Everything is terrible"

If you don't know what I mean, I guess either it'll come to you in time, or maybe I'm just wrong.

Also it's important to remember a few key lines that I have heard and said a lot
1. "I look forward to your implementation" which is what I tell people when they have Thoughts about how some system "ought to work"

2. "It's a simple matter of programming" which is for whenever someone asks "is it possible for X to do Y?" A subset of this one is when someone asks you "what's stopping you from getting this done by tomorrow?" Oh, nothing, just the rest of my job.

Bug fixes can be a great avenue to show that you know your ****, if you're good at it. Sometimes other developers create bugs that they aren't smart/good enough to understand or fix. Then you swoop in like, bam, got this. Being known around the office as a guy who can fix things other people can't gives you solid street cred.

Good attitude to have.

You can do it for sure. But my guess is you're out on your own when things get weird. Not a ton of support from stack overflow.

Although not much different support level than angular universal - which is almost undocumented and has no innate support for mirroring authenticated ajax calls on the server side (IE - add cookies). To figure out how to do it, I got more from a an old video by the angular js devs than the documentation.

It was like when we first started using jade with node and it would output the entire html as a big string with no line returns - which fails for embedded JS and <pre> tags and maybe some other stuff. They were just coming out with a 'pretty' option to preserve the template line returns. I knew at that point we were still in the wild west.

yes. we just started using it for this new project.

I assume you mean in CS-type jobs? I can't imagine doing something cognitively draining for that long, which is probably why even places don't really go much up over 50-60 hours. I could def see negative returns above ~60.

um can anyone think of an easy way to restart a node process inside of it? Moderators have requested the ability to reboot the server if things are wonky. I can't even begin.

are you self hosting or on heroku or something else? i ask because the feature may be built in depending on where you're hosting.

This also looks relevant: https://stackoverflow.com/questions/...ccurs#19336529

Your hosting provider should be running PM2 or node supervisor. If you want to restart node, just change a file that is being watched.

shouldnt be watching in prod. Pm2 has an api to call restart on a process, would be decently easy to implement a button if you had an admin setup

How would a button on the site fire off though?

Well I guess I can just have the "restart server" button just uh call a function that doesn't exist and then have it crash/pm2 restart it automatically but that seems silly.

http://pm2.keymetrics.io/docs/usage/pm2-api/

Just have a button edit a file and that will restart PM2 (if it's configured to watch that file).

oh perfect duh. I just thought pm2 was linux command line only didn't think to look for a npm package.

We code review diffs, with the option to expand code for context. It's much more efficient, especially in larger files, and solves this problem nicely. If code that is outside your diff gets a comment then the team should create a new ticket to solve that and place it on the backlog, not let you inherit the mess and bloat the size of your original task.

edit:
after re-reading your post I guess the problem here was that you copied the methodology of the old tests, not that they thought you had written all of them. In that case you can kinda blame yourself, you should have written a correct test and ignored the others Either way, if you fix your test I would argue that your task is done and the PR should be accepted. Then create a new task to fix the legacy tests. Which will probably land on you, but hey, at least you get another notch in your belt for fixed tickets.

And btw, not assigning story points to fixing bugs is ******ed. With one caveat. If you you are solving a ticket and it fails in QA and gets a new bug, then i can see the argument for not assigning points to that (the effort is included in the initial task). But any bugs that are discovered after a task is done done should 100% be assigned points.

Victor;

Be blessed that you have programmers who you can trust and chat with, unit tests, bug-triaging, and other tools to make your life easier.

Be careful with the idea of being important and irreplaceable.* There is a fine line between being useful and being a silo. At the end of the day, you get a paycheck, and nowhere does that imply everything is easy, useful, or interesting.

* An old boss shared this story with me. He told one his best employees to start teaching a coworker everything he knew. The employee asked: "Does this mean you are getting rid of me?"

The manager's reaction is a little uncouth, but there is a lesson in that gem.

Excellent post. All these points can be brought up to management in a positive way.

People actually use 'story points' to track productivity and give 'credit' to people?


Victor, I think there's a few things you're missing or should think about:

1. You shouldn't try to own code/features. It's a team responsibility and it should be shared. Just because you built something, doesn't mean you should build everything else related to it. Features should be actively shared for lots of good reasons. Similarly, you shouldn't expect individuals to fix all the bugs/issues they created. It's an inefficient way of development and creates a lot of messed up incentives (similar to using 'story points' to give credit).

2. Careers are built in months/years and not weeks. That doesn't mean you shouldn't address issues, but it means you should take the long view and don't create issues over things that might not be that big of a deal.

3. The best developers from a business perspective generally aren't the best at a particular feature/tech stack - they're the people that can do lots of different things, learn things quickly, and (most importantly) make other developers more productive.

4. I don't find the "I copied other code so I shouldn't be judged for its problems" particularly compelling. There's an argument that consistency is good - and that may be an appropriate response. As in: "I followed what the other tests were doing, lets keep them consistent and we can create a separate story for refactoring everything at once". But there's also an argument that adding more bad stuff should be avoided and that you should start writing stuff in a better way as soon as possible.

It's common for me to give a comment on a pull request that modifies code I wrote years ago that they shouldn't do things the way I had done them and instead do them in some different way. Because I've learned a lot over that time and found where my old approach doesn't work very well / can be significantly improved.

This is one reason that story points for credit is so freaking dumb. Your incentive is no longer to write good tests and learn from team feedback in code reviews.