|
Jaded Burnout posted:I think this is more of a vent than actual advice asking. Oh hey it's 6 months later and we finally got the platform part of this job done just to have the CTO and other business people ask why the hell it took so long and maybe we shouldn't use that tech at all and also there's no money so no more people being hired to the team. I fuckin' told them they were wasting time having me work so far outside my speciality. The new guy told them the same thing when he was working on ops bits. The managers apparently got wind of discontent higher up as much as 3 months ago but never passed it on to us so we kept chipping away at the long term vision without delivering direct business value and now the entire project and team is on the chopping block. Edit: The only silver lining being when I inevitably leave when my contract expires in April I'll do so having been paid to learn kafka and java pretty well. Jaded Burnout fucked around with this message at 08:49 on Oct 8, 2017 |
#
?
Oct 8, 2017 08:43
|
|
|
|
| # ? Jun 7, 2024 01:44 |
|
|
Jaded Burnout posted:Edit: The only silver lining being when I inevitably leave when my contract expires in April I'll do so having been paid to learn kafka and java pretty well. Here is why business will not approve stuff that has no obvious business value.
|
|
#
?
Oct 8, 2017 10:43
|
|
|
Absolutely. The intent was to leave behind a functioning platform and a 3-person team with these skills instead of taking them with me but I guess that isn't happening.
|
|
#
?
Oct 8, 2017 14:10
|
|
|
TL;DR version - need to vent, and need advice on how to deal with a manager that i hate, without losing my mind or my job. I'm getting extremely frustrated with my manager: - He is notorious for not liking work from home, but the company policy is to allow it, so he managed to take what should have been a 2 minute paperwork thing (boilerplate work from home form) and dragged it out for almost two months with all sorts of BS, like promising to get me the paperwork and then claiming that he had forgotten about it, every single time I reminded him, etc. - The framework of the application is a disaster, and it often causes weeks of extra development time to get around the issues - for instance, I recently implemented a simple excel import feature but found that even moderate amounts of data caused the app to take 5+ minutes to save because of its insane caching and change detection system. Other devs have brought up the issue, asking to be able to work on fixing it, and he says he agrees, but that the "powers that be," who don't know anything about software, refuse to let us spend any time on this. We agreed as a team to write up the issues that came up and put them in a shared onenote doc, that he was supposed to set up. This would eventually be shown to the powers that be to convince them to let us work on this. It's been two months and he claims he was not able to figure out how to do this and is now planning on just using a microsoft word doc that he'll throw on a shared drive. This will never happen, of course. - I seem to be working on the most complex and large projects, despite the presence of several much more senior devs, yet he does nothing but nitpick and criticize me over little things. There was once a bug resulting from one of my large enhancements, and a customer needed a sql script to get his DB back up and running, which I sent immediately. However, even though I could have quickly fixed the bug itself, he told me I can't work on bugs since I'm not on the bugs team, so I should just write up a ticket for it, which I did. Then a month later, another customer had the exact same issue and he was angry about it, and I told him that he had in fact not allowed me to fix it. He wouldn't back down and just said things like "well, we have to improve the quality of this, this is unacceptable". He still would not allow me to fix the issue. - He once called a series of meetings to talk about how to improve our Scrum meetings, but every suggestion was met with him stating that since we were already doing things according to the industry standard, we couldn't change it. - The way DB work is handled is basically that the main DBA won't let developers do anything, and he insists he does everything. But the dev is expected to take care of telling him what the ticket is about, and getting him to send back scripts. So he is almost impossible to get a hold of - he once missed 4 straight meetings I had set with him - and he always forgets about everything. I once presented him with a DB design, and he made a change; then, a few weeks later he called a meeting with me to ask me about that same design choice, asking critical questions about it. I told him that in fact it was his change, and he then suggested that we do it the way I had originally suggested. And we just hired a "database developer III" to help him, but this guy can't seem to write even simple CRUD stored procedures. I talked to my manager about all this and he criticized me for not being able to handle the DB team effectively. I could go on and on. The team is trying to be agile after years of waterfall, which has resulted in vague requirements that change and morph over time. And yet my manager is extremely nitpicking when it comes to task estimations. He sent me a very snarky email this weekend criticizing me for having burned a task to 0 hours, and then burning more hours, and demanding that I need to let him know "how many hours are REALLY remaining??". This was because the requirements changed completely several times and are changing again this week, which makes task estimation a total joke. Am I overreacting? I am getting extremely frustrated and don't know how to handle it. How am I supposed to respond to this? In general, I am looking for other work, but in the meantime, how do I not go insane? I also worry about losing my job, since he seems to really have something against me.
|
|
#
?
Oct 9, 2017 04:15
|
|
|
Incompetent management is incompetent. If you NEED the job, stop emotionally investing yourself. If you cannot do this, quit. If this is impossible for whatever reason, let me introduce you to my dear friend Highland Park.
|
|
#
?
Oct 9, 2017 05:09
|
|
|
That's a tough situation to be in, and you have my sympathies. I don't have any good advice for not going insane, aside from venting wherever possible, but I would encourage you to document your interactions with him and get everything in writing as much as possible. Get him to commit to doing something by such and such a date, if you can, with confirmation via email. And then save those emails. Be careful about how you handle establishing this paper trail though; it can easily be viewed as an aggressive action (which it is). It may help to play the helpful idiot -- pretend to forget exactly what was discussed and ask for his confirmation, that kind of thing. Also, if he says that the higher-ups have vetoed something, see if you can't quietly contact said higher-ups and get their opinion on things. That I wouldn't document (indeed, I'd try to do it in person, if your skip level has office hours or similar), since the main point is to get a feel for the politics at the company and whether your manager has the support of his boss. Of course again I wouldn't phrase that as "so I've been having trouble with $boss, what do you think of them?" Make it more like "I see an opportunity for us to improve the product in a way that I think our customers would really appreciate, but my boss has told me that there's some outside factors that I don't know about that make such changes difficult. I'd like to learn more about our business so I can do my job more effectively, yadda yadda yadda..." In short, welcome to politics.
|
|
#
?
Oct 9, 2017 05:20
|
|
|
+1 to documentation. I really regret not documenting some of the crazy poo poo two years ago at my previous employer (though they did eventually get fired, I'm still salty that there's some rather upsetting things they got away with). Whether or not it's incompetence or malice on his part, you are slowly being thrown under the bus. Get your poo poo in order so as to throw him under the bus (except rightfully) when it falls on you. Note that IT will likely be able to render your account inaccessible, summarily confiscate your computer and all company access, or discover if you're forwarding emails from a work address to a personal address, if that's how you document. Printing to PDF and emailing that PDF to/from your personal account is probably the safest (don't save your login; enable 2FA on your personal account if possible as it is with gmail). This will come in handy if you get fired, or when you're negotiating severance.
|
|
#
?
Oct 9, 2017 06:44
|
|
|
TooMuchAbstraction posted:That's a tough situation to be in, and you have my sympathies. I don't have any good advice for not going insane, aside from venting wherever possible, but I would encourage you to document your interactions with him and get everything in writing as much as possible. Get him to commit to doing something by such and such a date, if you can, with confirmation via email. And then save those emails. Be careful about how you handle establishing this paper trail though; it can easily be viewed as an aggressive action (which it is). It may help to play the helpful idiot -- pretend to forget exactly what was discussed and ask for his confirmation, that kind of thing. Yes all of this. I've been in similar situations where it's not easy to document because they won't write any of this down, because as established they'll say things but not do them, including "yes I'll send you an email". In these cases I tend to document it myself by immediately after a call or face to face meeting emailing them with something like "Hi $boss, just to make sure I've understood the timing of the actions that came out of our meeting, [insert list of "I am going to do X by date Y" and "You're going to do A by date B"] Please let me know if any of this is wrong" It's not foolproof because they can claim they never read your email or whatever, but with enough of them that becomes hard to swallow. You might also want to start recording meetings, it depends how much you might trigger him with that. I've found the key is always to phrase all these things as business safety measures. I'm sending this email documenting our interaction (or recording this meeting so I can take notes) to make sure I don't make a mistake and do the wrong thing and make sure I've understood my immediate responsibilities. Wouldn't want to waste company time on the wrong thing. Who could complain about such a diligent worker? It's only when you need ammo to take to his boss that you convert these into a powerpoint called "How my dickhead manager keeps sandbagging and loving up".
|
|
#
?
Oct 9, 2017 06:46
|
|
|
Doghouse posted:- He once called a series of meetings to talk about how to improve our Scrum meetings, but every suggestion was met with him stating that since we were already doing things according to the industry standard, we couldn't change it. You're not overreacting, this is a shitshow.
|
|
#
?
Oct 9, 2017 07:13
|
|
|
Your manager sucks and isn't going to change. He's actively hindering you as well as blaming you for being hindered. This isn't a situation where understanding office politics will help. You need to find a new job, ASAP. It's only a matter of time before you get blamed for something big. In the meantime, try not to rock the boat too much and work on your manager's priorities, even if they are terrible and regressive. You could try going to his superiors (in the way mentioned before), but if the manager is well-liked, it could be that the whole company is run in this stupid way, which further emphasizes that you need to get. out.
|
|
#
?
Oct 9, 2017 12:25
|
|
|
Your manager sucks. At least you don't have my manager though. I was assigned no work for over 24 hours so I picked up a refactoring effort ticket. Made changes to about 30 files in 48 hours. After a mini-impromptu sync with the team my boss suggested we make a new ticket for the story since someone else has been assigned to it, I said fine I'll tag that in my commits from there on out so Jira picks it up and finish it. Turns out he assigned the story to someone else without telling me and I proceeded to work on it for another two days (I didn't get notified since I wasn't tagged on the ticket) and claimed he assigned me a different ticket I was supposed to be working on before sending me a passive aggressive email. I didn't notice because I rarely look at our Jira board because of how much of a mess it is. Management is well aware of my managers toxicity and inability to manage. Two people have straight up left my team giving the reason "I can't work with him" so I'm hoping things get better. Still I'm the new guy compared to him so who will our parent company trust?
|
|
#
?
Oct 9, 2017 14:25
|
|
|
Did you assign the ticket to yourself when you started work on it? Also if he assigned you a ticket and you didn't notice, IMO that is on you for not noticing.
|
|
#
?
Oct 9, 2017 15:58
|
|
|
Steve French posted:Did you assign the ticket to yourself when you started work on it? "Claimed" is the operative word in my post.
|
|
#
?
Oct 9, 2017 16:09
|
|
|
Good Will Hrunting posted:"Claimed" is the operative word in my post. I don't know what the exact specific meaning with respect to JIRA of "claimed" is, but if you had actually assigned it to yourself in JIRA, you should have been notified when your boss assigned it to someone else, no? You said you didn't get notified because you weren't tagged. When I am assigned things in JIRA, I'm automatically tagged and receive notifications of all activity on that issue.
|
|
#
?
Oct 9, 2017 16:12
|
|
|
Steve French posted:I don't know what the exact specific meaning with respect to JIRA of "claimed" is, but if you had actually assigned it to yourself in JIRA, you should have been notified when your boss assigned it to someone else, no? You said you didn't get notified because you weren't tagged. When I am assigned things in JIRA, I'm automatically tagged and receive notifications of all activity on that issue. hmmm Good Will Hrunting fucked around with this message at 14:47 on Oct 18, 2017 |
|
#
?
Oct 9, 2017 16:19
|
|
|
Good Will Hrunting posted:Claimed he assigned another ticket to me I meant. He made a new ticket for what I was working on and instead of assigning it to me, assigned it to someone else. My old ticket that I was working on remained (remains) in progress. Got it; I was mostly asking for clarification because I couldn't quite follow the sequence of events in your original post.
|
|
#
?
Oct 9, 2017 16:24
|
|
|
Steve French posted:Got it; I was mostly asking for clarification because I couldn't quite follow the sequence of events in your original post. Yeah it was strange - plus he doesn't really understand that B is basically a dependency on A, which is why I didn't pick up B in the first place! 
|
|
#
?
Oct 9, 2017 16:29
|
|
|
Doghouse posted:However, even though I could have quickly fixed the bug itself, he told me I can't work on bugs since I'm not on the bugs team, so I should just write up a ticket for it, which I did. I've never heard of a bugs team, that seems like a backwards idea.
|
|
#
?
Oct 9, 2017 16:31
|
|
|
piratepilates posted:I've never heard of a bugs team, that seems like a backwards idea.
|
|
#
?
Oct 9, 2017 16:35
|
|
|
Doctor w-rw-rw- posted:+1 to documentation. I really regret not documenting some of the crazy poo poo two years ago at my previous employer (though they did eventually get fired, I'm still salty that there's some rather upsetting things they got away with). This seems like terrible advice. IANAL but maybe don't syphon company communications to a personal account, especially with the intent to eventually tell the company you've been doing that?
|
|
#
?
Oct 9, 2017 17:21
|
|
|
piratepilates posted:I've never heard of a bugs team, that seems like a backwards idea. You have to admit it's an innovative but natural extension of the more common practice of having separate testing and quality teams.
|
|
#
?
Oct 9, 2017 17:52
|
|
|
Eggnogium posted:This seems like terrible advice. IANAL but maybe don't syphon company communications to a personal account, especially with the intent to eventually tell the company you've been doing that? I keep all my documentation on my work laptop. I don't see a reason to not do this. To me, documenting all of my boss' shortcomings is only dangerous if he finds it and I doubt he's going to have, like, extended private time with my password protected laptop??? Plus, he's costing the company time and resources which equate to cash money - they should care what I have to say (even if it's just echoing what the 3 people on my team who have also complained already said).
|
|
#
?
Oct 9, 2017 17:56
|
|
|
piratepilates posted:I've never heard of a bugs team, that seems like a backwards idea. Programmers who never maintain their own code always turn into terrible programmers. 80% of the time spent programming an application is spent in maintenance, small coding and designed mistakes made during development turn into nightmares later on, and people who never do maintenance never learn what those small mistakes look like. I spent years doing maintenance on a custom PHP CMS. The only thing the main developer learned to do was how to ignore errors.
|
|
#
?
Oct 9, 2017 20:08
|
|
|
Doc Hawkins posted:You have to admit it's an innovative but natural extension of the more common practice of having separate testing and quality teams. The what now?
|
|
#
?
Oct 9, 2017 21:37
|
|
|
"QA? Thing of the past. Turnaround time's too long. Just deploy straight to prod and watch the metrics."
|
|
#
?
Oct 9, 2017 22:58
|
|
|
minato posted:"QA? Thing of the past. Turnaround time's too long. Just deploy straight to prod and watch the metrics." For a large enough application with some measure of fault tolerance there's absolutely nothing wrong with this strategy provided there are rollback strategies and playbooks for system failures.
|
|
#
?
Oct 9, 2017 23:24
|
|
|
I've never worked with separate testing and quality teams but in every company I've been at (which admittedly is only a handful), QA has been a bottleneck. I was very hesitant about continuous deployment but with a decent base of tests (unit/component/integration/end to end) it actually works very well. Like the above poster said, playbooks and knowing what to do when poo poo hits the fan helps, but that's something you should figure out anyway. A devops culture (as in, devs own operations for their lovely code) doesn't hurt either. Pie Colony fucked around with this message at 00:11 on Oct 10, 2017 |
|
#
?
Oct 10, 2017 00:08
|
|
|
Blinkz0rz posted:For a large enough application with some measure of fault tolerance there's absolutely nothing wrong with this strategy provided there are rollback strategies and playbooks for system failures. But the list of caveats I encountered was long. Just a handful: - Suitable for services which can gracefully degrade when faults occur. Not suitable for mission critical services (e.g. a login authentication service). - Metrics measured need to be suited towards catching problems quickly. Thresholds need to be regularly reviewed. - Binary must be cheap/fast to revert. No good if it takes many hours to roll back. - Trunk commit-rate should be relatively low, because reverting due to 1 bad commit will penalize all other devs with independent features in the same build. - Won't catch typos or other rendering issues that look bad but don't significantly affect core metrics. (A QA dept might have caught those kind of things with a visual inspection) - Time to find the cause must be fast. E.g. Is it a faulty A/B test vs a fundamentally faulty binary vs a load issue or poisonous requests? Must find the answer quickly to know if the solution is "revert the binary". Gets more difficult if your deployment ecosystem has multiple versions deployed simultaneously.
|
|
#
?
Oct 10, 2017 00:44
|
|
|
Thanks for all the replies, appreciate it
|
|
#
?
Oct 10, 2017 01:19
|
|
|
minato posted:I worked on a very large system which employed this strategy. Although there's nothing wrong with the strategy per se, there's lots that can go wrong, so I feel it takes a mature team to implement it successfully. We may have different bars when it comes to maturity. I started typing up point-by-point responses, but then I got hesitant; it felt combative and over-confident. My summarized position from a middling number of years in webshit is "tear down every fence over which devs toss things and force them (supportively) to instead be responsible for that poo poo themselves." In most places I've seen, dev responsibilities long since subsumed bugfixes, testing, and "QA," with operations and security being the next hurdles, hence this dev-and-also-ops meme that's been making the rounds.
|
|
#
?
Oct 10, 2017 02:15
|
|
|
Doc Hawkins posted:We may have different bars when it comes to maturity. Yeah, this is the massive advantage to "testing in prod," namely that the person deploying the code has to maintain responsibility for its operation. It tears down a hell of a lot of walls when a jr dev deploys a bug and has to get the whole team together to diagnose and remediate it.
|
|
#
?
Oct 10, 2017 03:55
|
|
|
Blinkz0rz posted:For a large enough application with some measure of fault tolerance there's absolutely nothing wrong with this strategy provided there are rollback strategies and playbooks for system failures.
|
|
#
?
Oct 10, 2017 04:15
|
|
|
I'm onboard with devops, but in practice I've noticed some unforeseen effects by adding devs to the oncall rotations. Dev don't have much experience in realtime bug-hunting or the production environment, and broadly-speaking, they don't want to. Any time invested in understanding it is time not invested in improving their stated focus or working towards their primary perf goals: developing features. This attitude results in oncall rotations where devs act as little more than a PagerDuty router. They do minor triage and fixes, but hand off larger problems to more experienced Ops/SREs who do the bulk of the fault-finding and mitigation. My work also implemented a Google-like "no blame" philosophy when it came to incident postmortems, as that was seen as more likely to avoid political fingerpointing and discourage people from sweeping issues under the carpet for fear of reprisals. But the flipside was that it had the "seatbelt effect"; devs felt safer from consequences so they drove more carelessly. These are both cultural issues, and can be somewhat mitigated with technical solutions. For example, to encourage devs to do QA before merging to trunk, we implemented a commit-hook that warned when a trunk merge was made without reference to any test-run results. But it wasn't a catch-all, because there were many situations where merges were necessary without running tests. Once devs learnt that it wasn't necessary to run all those boring and length tests, coupled with the lack of resource to review and enforce the rules, there was an increase in the number of merges that deliberately bypassed the test runs. I guess my point is that (a) a business needs some sort of QA, (b) if you ditch the QA dept, then you'll find the Devs don't want to do it, (c) you can use technical measures to reduce the friction as much as possible, but it only works to a degree, and (d) ultimately the solution is to inculcate a "QA mindset" in your Devs, which is a Sisyphian uphill battle I suspect many managers don't want to do either.
|
|
#
?
Oct 10, 2017 04:29
|
|
|
minato posted:ultimately the solution is to inculcate a "QA mindset" in your Devs, which is a Sisyphian uphill battle I suspect many managers don't want to do either. This is your problem, yeah. You don't have buy-in from the devs; they see no reason to not write lovely code, and ops is getting stuck with the consequences. You can fix this to an extent with better tooling, by making it easier to run tests and harder to not run them, but you also need your devs to care about the people that are stuck supporting the code they write. One of my mantras is "code that is not tested does not work". It is just shy of universally true. A corollary to this is that sufficiently complex systems are impossible to adequately test by hand; it's too easy to make a change that breaks an unstated assumption that causes an edge case to break -- an edge case that you didn't think to test, but that nonetheless affects 1% of your user base (i.e. a gigantic number in absolute terms / an untenable amount of lost revenue). Consequently, you need unit tests. And functional tests, and integration tests, and so on. You need code that thoroughly exercises the code that you write, and that runs every time someone makes a change, to ensure that the contracts your code offers are not broken.
|
|
#
?
Oct 10, 2017 05:03
|
|
|
necrobobsledder posted:I would say in practice I've seen more organizations that would be better off designing for more fine-grained deployment such as feature flags / toggles, traffic splitting, user-selective routing, etc. before they'll be able to learn how to properly back out a change. I'm a bit of a deployment pedant and would love to see my entire system controlled via a git tag down to byte-for-byte reproducibility in any and all environments, but in most places you're just not going to get anything like that. For sure what you're talking about is the most desirable. We run a repo full of feature flag, thread pool tuning, and org/ip blacklisting/whitelisting properties that feed all of our services. Want to enable that new feature? Flip a false to a true in a yaml file. It's reduced the number of iterations required for engineering by allowing us to tune our workloads in flight and enable product features for internal use before we roll them out to customers.
|
|
#
?
Oct 10, 2017 05:18
|
|
|
Agreed.TooMuchAbstraction posted:Consequently, you need unit tests. And functional tests, and integration tests, and so on. - increased the amount of code changes required to produce a feature, which delayed deployment - were of low utility because they caught few bugs. (But ignored that this was because the tests were low quality: few edge cases, hastily-written & perfunctory) - required significant class refactoring to allow testing "seams" (e.g. supporting mock injection) - were difficult to maintain test fixtures for because the product changed so fast. (e.g. if a test mocks an API request and someone adds a new parameter, all the mock test fixtures may require updating too). So there was a strong incentive to avoid maintained tests entirely and only test with business/technical metrics. This is an anathema to me. I'm a big fan of TDD, dependency injection, and {unit,integration,functional} tests. I'd love to know how to sell that same mindset to devs, given the reasons they had above for not doing that.
|
|
#
?
Oct 10, 2017 05:46
|
|
|
Blinkz0rz posted:We run a repo full of feature flag, thread pool tuning, and org/ip blacklisting/whitelisting properties that feed all of our services. Want to enable that new feature? Flip a false to a true in a yaml file. The caveat is that your alerting needs to be feature-flag aware, because when a request fails it's essential to know what feature flags were enabled for that request. Any change to feature flags needs to be correlated to metrics graphs so you can identify which flag change directly preceded a metrics change. And something we learned the hard way: don't let an overconfident Dev flip a feature's exposure dial to from 1% to 100% on a Saturday night and then go to bed.
|
|
#
?
Oct 10, 2017 05:54
|
|
|
Eggnogium posted:This seems like terrible advice. IANAL but maybe don't syphon company communications to a personal account, especially with the intent to eventually tell the company you've been doing that? Not always a good idea, but god drat it would have been useful to my advantage had I done it.
|
|
#
?
Oct 10, 2017 06:35
|
|
|
minato posted:And something we learned the hard way: don't let an overconfident Dev flip a feature's exposure dial to from 1% to 100% on a Saturday night and then go to bed. This used to happen All. The. drat. Time. until we explicitly created a development on-call rotation and made them responsible for service-related issues. Deploys at 4pm on Friday dried the gently caress up real quick after that.
|
|
#
?
Oct 10, 2017 11:24
|
|
|
|
| # ? Jun 7, 2024 01:44 |
|
|
minato posted:My work also implemented a Google-like "no blame" philosophy when it came to incident postmortems, as that was seen as more likely to avoid political fingerpointing and discourage people from sweeping issues under the carpet for fear of reprisals. But the flipside was that it had the "seatbelt effect"; devs felt safer from consequences so they drove more carelessly. A lot of SRE teams address this by having an "error budget" concept. If the teams burns too much SLO on new feature fuckups early in the quarter, then the SRE tells them they can't have any new major releases until the SLO has a healthy buffer again. This strategy, of course, depends on management not walking into the the room and sputtering "The devs say it's ready deploy it now!!!". A big part of keeping engineering teams healthy is actually human management and not which language is good for writing for loops better faster.
|
|
#
?
Oct 10, 2017 12:32
|
|
