For some reason this is a benefit of the doubt *******s gets. He must be useful, otherwise why would they keep this dickface around? It's the just world fallacy, I guess.

In truth, most places are total wusses about firing people. It usually takes months or years before someone who really ought to get fired really does, whether it's incompetence or personality problems. This is, sort of, why everyone is so picky about hiring, because they worry about making mistakes and not being able to get rid of someone. Jokes on them, it's almost impossible to predict which people you're interviewing will be hard to fire.

this is bizarre. how long was the build broken for? are you allowed to just checkin code without any reviewing it? also, cant you test locally before checking in?

oh, so your code was fine but you didnt do the build correctly? you guys dont have build scripts or automatic build processes on the server? lol, I would be so lost.

No, i suggested what i thought was a fix in the comment thread, quickly realized 10 mins later i needed to change something else or everything would break, and then removed my comment. About 15 mins had elapsed because i had to take a phone call in between the post and realizing my mistake.

The “bug” was in a build script that was meant to be shipped to the consumer. The dev was complaining some object file wasnt being cleaned in some sub-sub-directory and “possibly others” but i ran multiple different searches through the main folder and could only find one.

I realized the .sh script wasn’t calling the folder with the garbage file’s make clean target. So i suggested adding the line to clean it.

But, in the makefile for that folder, its clean target had an errant line that deleted an entire folder for no good reason. So i had to remove that too, but commented before I realized this error.

so you didnt actually checkin code and break this on the server? you just offered a fix that would have broken it? that doesnt count.

it doesnt count until you enter in code and it gets elevated to the server and breaks either dev/QA or production. I checked in code that used ngrx reselect but didnt account for undefined scenarios properly and if the user went to a certain page with a certain type of account then the whole app would just stop using and lock up.

if I had to count the amount of times I offered a code fix that would break something then lol.

Can't even break the build properly? Maybe you don't have what it takes to be a Real Engineer (tm) :P

technical project manager*

FWIW, I'm sure I don't have enough context to know what's good advice or not, and you should trust your own judgement. That said, if there's one thing I think has made the difference in my career (about 18 years worth) it's been a willingness to dive into stuff I don't understand and figure out how to understand it. And my first "real" programming job involved getting tossed off the deep end into a C code base that was pretty far over my head at the time, although I was reasonably proficient in C. My most recent gig has involved getting dropped off the deep end into Angular, although I suppose I was way more prepared now. But still 18 years later it's still the case that I start a new project and have to learn something I've never seen before as I go. I think you might surprise yourself, as long as there is someway to experiment and try things out. You might get further than you think.

Now, you maybe have different goals than I did -- I was never in any doubt about the fact that I wanted to be a programmer, whereas my impression is you're more tentative. But I think there is something to be said for just going for it. You seem afraid to make mistakes (re: the build story) but I make mistakes all the time and so does everyone else you work with. It's not a big deal. #YOLO imo.

ya lol at not making mistakes. I practice error driven development.

I fixed that issue today, everyone on my team told me that the makefile was a disaster bc it was written by an intern like two years ago.

Had a retrospective with my team today and I think they liked the process because they wanted to do another one. They seem kinda desperate for some structure.

I brought up the major interruption that happened and they said it’s semi-regular and we all agreed we couldnt really do anything about it, so i suggested shortening the sprint to reduce the effect of interruptions.

They told me my prioritized backlog looked pretty spot on too, so i’m catching on. Felt way better today, yesterday felt like **** to me for some reason.

That's good to hear.

Going full internet armchair psychologist, I think you let the toxic guy really get to your self-esteem. It is easy to lash out at your surroundings when you feel threatened and are made to question yourself.

I cannot stress it enough. **** that guy.

maybe i was just projecting my own insecurity onto my interaction with him, but something really felt off about it.

pretty sure my other read on him is right though. and i'm not actually sure how much he really contributes. going to try to stay neutral for a while so i don't get biased, but meh.

i told my team i was a little intimidated by him when they asked me why i didnt submit a pull for my fix, and they said i shouldnt be but seemed to understand

No, I said do/ask for work. In and of itself, rereading man pages is not work.

You don't go to med school to become a nurse. You are (academically) qualified to be a developer yet you're a PM.

well, that's been discussed before, my real role is more like an engineer, and since titles don't seem to matter at all at this company whatsoever, it seems like inevitably i will be doing developing.

the issues are complicated - like i said, i don't feel qualified to really fix or look at anything. I am proud of tackling that makefile issue though after my initial embarassment. there's one thing left i need to figure out about it so i'm sure i can kill a day or two on that.

i also still don't really believe I'm that good at programming, issues that take most people 1-2 hours can take me 4-6. I think my overall quality is better but things tend to take me an extremely long time because I get hiccupped by minor stupid things.

like i killed an hour last night on my webserver because some script wasn't running when i ran a page and i thought it was something wrong with a query so i dove down that rabbit hole and realized way later that i was on the wrong html page the whole time. that kind of moron stuff i'm really susceptible to.

I read that and think "Oh, so you're normal."

Here's the thing, there are a whole lot of people out there that don't think they're good at programming and get thrown off by making "stupid" mistakes. My career is going really well and I don't need to worry at all about proving myself - and I still have self doubt and get stressed when I start a new project / technology and have to learn everything from scratch. There's always the "I don't know what I'm doing and I'm going to look really stupid to other people as I figure this out". But then I learn, figure **** out (while occasionally looking stupid) and at some point its all fine.

So I know its no use telling you not to worry about things like this, but hopefully its useful to know that you're not special - the vast majority of people have self doubts like this too. The important thing is to not let them keep you from doing stuff and learning.

One other thing, you need to not do things like delete your comment about the Makefile. It's fine to post half thought through ideas / or suggest something that wouldn't work. It's a really bad impression though to hide your mistakes. Own them and learn from them.

I sometimes need to deal with production problems in the middle of the night by myself. I generally just stream of consciousness style write out what I'm seeing, thinking and doing into the slack channel even though I'm just talking to myself and it's a lot of:

"I'm seeing error message X, I bet its because of reason Y"
"Oh, that doesn't make sense because if it was Y we wouldn't get past stage Z"
"Oh, I was wrong. We would get past stage Z."
...

And so on. Its useful for people to see how you think and build on your ideas or point out where you're wrong. If everybody just waits until they're 100% sure of what they write problems are going to take way longer to solve and a lot of useful knowledge isn't going to be shared.

The stupid things that kill time now are going to make you much more productive in the future when you've been bitten by them before.

Jmakin - Of course you're not good at programming. You never dealt with real world problems, where there's no designer (professor) behind the problem. It's better to admit that you're not good and proceed humbly and cautiously, then to write substandard code and think you're awesome. It's going to take months of practice before you get good/better.

Sent from my SAMSUNG-SM-G925A using Tapatalk

What is your title?

Technical project manager

Wait, was this always the case? IIRC, when you got the offer and explained what you would be doing, a bunch of people mentioned that sounds like a project management position rather than a software engineering position and you seemed insistent that it's a software engineering role. Or is this a temporary thing and you'd be switching to a software engineering role when you go full-time? Am I misremembering things? Either way, this makes a lot more sense given the kinds of work you've been doing.

I thought it was a developer position with a ridiculous job description?

This is been discussed Ad frickin nauseum

It’s definitely more this