|
Right now our company is getting a hard on for value stream mapping, but I don't get why they are repeatedly trying to apply manufacturing principles to software engineering? I'm not saying software is un-plannable or the processes cannot be improved. But tickets/build artifacts/whatever isn't "inventory", we aren't building 10,000 widgets an hour. If they want to compare it to manufacturing; then it's a weird shop where every customer that comes in orders a very specific customisation every two weeks that only serve to make your widget ever larger as time goes on. There's definite & clear processes where value stream mapping/lean manufacturing does fit; oddly enough it's the dumb easy-to-automate poo poo, but no we also have to do it as a one size fits all map that applies to stakeholder requests. I've seen one teams value map and their prioritisation lead time is over 12 months because these things wildly vary based on stakeholder mood, current pressures, is it windy, etc. It is not a manufacturing process. Cancelbot fucked around with this message at 13:22 on Jan 19, 2019 |
#
?
Jan 19, 2019 13:19
|
|
|
|
| # ? May 25, 2024 05:11 |
|
|
That's often the result of someone higher up the food chain not understanding the difference between software development and manufacturing.
|
|
#
?
Jan 19, 2019 16:37
|
|
|
My coworker got an MBA and told me that the entire program was based around manufacturing and industrial line theory. I don’t think it has adapted well to making software but then again neither has software engineering.
|
|
#
?
Jan 19, 2019 16:41
|
|
|
Cancelbot posted:we aren't building 10,000 widgets an hour. Well there's the problem. You need to be faster!
|
|
#
?
Jan 19, 2019 16:49
|
|
|
It may make more sense to compare to manufacturing when it comes to site requests than the process of making the factory that processes the request itself. I think a lot of management wants to try to do a thought experiment to compare management of software to manufacturing (because that's where a large bulk of the body of knowledge of Taylor and Deming went to) but I think it's more important for management to also be creative and innovative. Otherwise, you can't expect results to be any better. I think I've seen this approach done more with managers that have almost no experience in software themselves and are intimidated a bit. Therefore, anyone I've seen try to push to me toward practices built around delivering tickets like they're on an assembly line I presume are unimaginative, predictable, and likely to fail at projects that are not fitting that criteria (many projects are that boring though, to be fair, and applying old, well-known processes can work somewhat). The work that we do in software engineering is a lot closer to the work of a factory manager 60 years ago, not a factor worker 60 years ago. Hence, Deming's worker-manager model is much closer toward what we should be aiming for. I have yet to see a single innovative software company built on Taylorist principles (the ones that seem to do ok that way are... gosh, hardware companies where defects are extremely hard to correct once shipped comparatively). Most experienced in software know that really tight, accurate feedback loops are critical and focus upon deployment speed with solid testing to deliver new features reliably. At the end of a sprint per Agile practices, you should be deploying your software to production - the goal is working software in the hands of customers ASAP, which may be a bit wonky for b2b companies compared to b2c companies. For some more happy thoughts, here's a good (long) discussion on what good Agile looks more like with successful projects, why schedules are complete BS, and the neat things that happen when you abolish estimates. The benefits of "good" Agile primarily seem to be there when your company is more in exploratory modes versus a company that is behind and just trying to catch up (the state I've normally seen failing companies - spending too much time on meeting a standard feature by competition versus setting a standard feature). It also seems to neglect a massive backlog of seriously debilitating technical debt (keeps you from deploying to a real-world like environment more than once a week) that also seems to be common with companies that took the reins from engineers and started assigning - welcome to Taylorism again but in a smaller company setting that can't afford the overhead of so much management.
|
|
#
?
Jan 19, 2019 17:22
|
|
|
i disagree completely that inventory is irrelevant to software development. every ticket, every design, every bug and every line of code is inventory. every unclosed ticket is a thing that has to be evaluated, investigated, tracked and prioritized until it's closed. every design or specification is a thing people invested time for no benefit until it's acted upon. every bug is a drag on your software quality, your ability to push out new features and your reputation. most importantly, every line of code is inventory until it's delivered to an end user is some manner talking about software as inventory is by far the most effective way to get non developers onside when you preach the importance of focus and discipline and quality control. when you frame it as not just misspent time but something which is going to require more time in the future unless it's discarded or acted upon it makes it obvious code isn't free
|
|
#
?
Jan 19, 2019 21:49
|
|
|
Cancelbot posted:Right now our company is getting a hard on for value stream mapping, but I don't get why they are repeatedly trying to apply manufacturing principles to software engineering? I'm not saying software is un-plannable or the processes cannot be improved. But tickets/build artifacts/whatever isn't "inventory", we aren't building 10,000 widgets an hour. If they want to compare it to manufacturing; then it's a weird shop where every customer that comes in orders a very specific customisation every two weeks that only serve to make your widget ever larger as time goes on. I like to use some of that vocabulary (particularly inventory) to refer to work where the output the value delivered by the work is withheld until long after the work completes. This is usually by one or a combination of:
I agree it's not a great fit in terms of the solution space, but there's an argument that the same principles apply. Here's a (long) read that does a decent job of articulating my feelings: https://apenwarr.ca/log/?m=201712.
|
|
#
?
Jan 19, 2019 21:58
|
|
|
necrobobsledder posted:For some more happy thoughts, here's a good (long) discussion on what good Agile looks more like with successful projects, why schedules are complete BS, and the neat things that happen when you abolish estimates. The benefits of "good" Agile primarily seem to be there when your company is more in exploratory modes versus a company that is behind and just trying to catch up (the state I've normally seen failing companies - spending too much time on meeting a standard feature by competition versus setting a standard feature). It also seems to neglect a massive backlog of seriously debilitating technical debt (keeps you from deploying to a real-world like environment more than once a week) that also seems to be common with companies that took the reins from engineers and started assigning - welcome to Taylorism again but in a smaller company setting that can't afford the overhead of so much management.
|
|
#
?
Jan 19, 2019 22:28
|
|
|
No estimates is great and lots of engineering orgs could benefit from the hard focus on prioritization and consistent delivery that would require. Alas, the world does not revolve around engineering and a business absolutely needs to coordinate timing of things, which means some level of scheduling and estimates. For example, a big marketing push for a product around Christmas absolutely requires coordination from engineering and the ability to rely on estimates of some sort. Or good luck getting more investment when the plan given to your board on getting a product to market is the equivalent of a shrug of your shoulders. Needing that coordination across parts of a business means no estimates is not reality. Do you need down to the week or even Sprint estimates? No. But I think an engineer saying they don't do estimates is a good way to make themselves irrelevant or even unpromotable in a company.
|
|
#
?
Jan 20, 2019 01:11
|
|
|
return0 posted:I like to use some of that vocabulary (particularly inventory) to refer to work where the output the value delivered by the work is withheld until long after the work completes. This is usually by one or a combination of: This is all excellent and fits my current situation exactly. Going to be explaining it this way to the CEO this week that his constant fuckery and changing gears every day is our leading cause of backlog and production woes.
|
|
#
?
Jan 20, 2019 03:08
|
|
|
Not advocating anything in particular, just a point of reference for what is possible and the intent of grassroots agile rather than Corporate Agile that keeps getting maligned in this thread. I think I’m mostly just venting about my own management pretending to do Agile when what they really want and need is waterfall - because if we don’t get certain features out within so many months, the company will fold against the incumbents that are primarily winning in a “mature” market because we are all competing for RFPs, not for actual products being objectively better (the harsh, sad reality of enterprise on both sides - death by committee and bullet points of BS).
|
|
#
?
Jan 20, 2019 03:10
|
|
|
after years, i unironically believe that the only really great benchmark for whether you're doing grassroots agile is if the workers have seized materially the means of production and basically humiliated and emasculated the management
|
|
#
?
Jan 20, 2019 03:12
|
|
|
necrobobsledder posted:Not advocating anything in particular, just a point of reference for what is possible and the intent of grassroots agile rather than Corporate Agile that keeps getting maligned in this thread. I think I’m mostly just venting about my own management pretending to do Agile when what they really want and need is waterfall - because if we don’t get certain features out within so many months, the company will fold against the incumbents that are primarily winning in a “mature” market because we are all competing for RFPs, not for actual products being objectively better (the harsh, sad reality of enterprise on both sides - death by committee and bullet points of BS). We lost a client (a smaller yet probably our most demanding) recently due to not being able to live up to their ridiculous expectations. Expectations that were set by management saying yes to everything despite having other commitments to clients who bring us 10x as much revenue. The work involved a lot of research because it was a totally new thing than we'd dealt with before, and also we (the engineers) hadn't seen it before the aforementioned expectations were set. It took longer than management and the client imagined it would (emphasis on "imagined"). The takeaway from the executives was that we needed to make stronger commitments to dates. No mention of adjusting timelines on all of our other poo poo, naturally. Sure, let's overcommit ourselves to death, sounds good to me.
|
|
#
?
Jan 20, 2019 10:13
|
|
|
Che Delilas posted:We lost a client (a smaller yet probably our most demanding) recently due to not being able to live up to their ridiculous expectations. Expectations that were set by management saying yes to everything despite having other commitments to clients who bring us 10x as much revenue. The work involved a lot of research because it was a totally new thing than we'd dealt with before, and also we (the engineers) hadn't seen it before the aforementioned expectations were set. It took longer than management and the client imagined it would (emphasis on "imagined"). Everything I don't understand is easy.
|
|
#
?
Jan 20, 2019 15:50
|
|
|
Che Delilas posted:We lost a client (a smaller yet probably our most demanding) recently due to not being able to live up to their ridiculous expectations. Expectations that were set by management saying yes to everything despite having other commitments to clients who bring us 10x as much revenue. The work involved a lot of research because it was a totally new thing than we'd dealt with before, and also we (the engineers) hadn't seen it before the aforementioned expectations were set. It took longer than management and the client imagined it would (emphasis on "imagined"). 
|
|
#
?
Jan 20, 2019 16:03
|
|
|
It’s a sad truth that there’s a lot of bad clients out there that will sink your company by monopolizing your time and resources strangling growth and innovation. It’s seductive as a struggling start-up to take a deal for millions and live a little longer, but I think it’s a form of indentured servitude and a false business. Most of those companies are offloading their technical debts and cost centers onto you where they couldn’t find success but still need it for some reason or another that’s not terribly strategic but just required. A lot of people are familiar with Apple’s abuses of vendors, but this is common everywhere. Blame your board of directors if you wind up with such clients - if they are connected they know they signed a deal with a Higher Demon and if they didn’t know they were ignorant and should be fired for such poor due diligence anyway.
|
|
#
?
Jan 20, 2019 17:08
|
|
|
Already working on it, for that and other reasons which I've posted about in one of these threads. necrobobsledder posted:It’s a sad truth that there’s a lot of bad clients out there that will sink your company by monopolizing your time and resources strangling growth and innovation. It’s seductive as a struggling start-up to take a deal for millions and live a little longer, but I think it’s a form of indentured servitude and a false business. Most of those companies are offloading their technical debts and cost centers onto you where they couldn’t find success but still need it for some reason or another that’s not terribly strategic but just required. A lot of people are familiar with Apple’s abuses of vendors, but this is common everywhere. Blame your board of directors if you wind up with such clients - if they are connected they know they signed a deal with a Higher Demon and if they didn’t know they were ignorant and should be fired for such poor due diligence anyway. Yeah, this client has been a boat anchor around our necks and we should have started saying no to them years prior. I actually think we'll be much better off without them in the long run since we'll be able to devote much more time to our actually large clients. A pretty large set of features that I'd been working on for them are going on the back burner (i.e. the garbage) until product can find a way to sell them to one of our other customers (i.e. never), and I honestly couldn't be happier to be dropping all my hard work on the floor.
|
|
#
?
Jan 20, 2019 21:22
|
|
|
necrobobsledder posted:Blame your board of directors if you wind up with such clients - if they are connected they know they signed a deal with a Higher Demon and if they didn’t know they were ignorant and should be fired for such poor due diligence anyway. Does your board review your deals or do diligence on them pre-sales? I’ve only done that for deals with a strategic component (exclusivity, investment, that sort of thing). Given the expected time commitment of a director, I would hope it would be an untenable bottleneck.
|
|
#
?
Jan 20, 2019 23:19
|
|
|
Subjunctive posted:Does your board review your deals or do diligence on them pre-sales? I’ve only done that for deals with a strategic component (exclusivity, investment, that sort of thing). Given the expected time commitment of a director, I would hope it would be an untenable bottleneck.
|
|
#
?
Jan 21, 2019 04:32
|
|
|
necrobobsledder posted:Most boards only meet maybe quarterly and demand a few hours from each member, but those few hours should include reviewing items like "we have a deal that can triple company revenue" and if the first question isn't "what's the catch?" they're derelict in their duty, period. Yeah, my experience is with quarterly meetings or less. I would have been disappointed if people were waiting on deals for the board to approve, but that would be the case regardless schedule. If the CEO asked I’d give them my opinion, certainly, but there are a lot of companies out there who can write a multi-million dollar contract, and it’s not at all certain that any of the 1-3 outside directors for a small company have knowledge of a given one’s vendor practices, or can find out to high enough fidelity to be useful. Is this something that you’ve regularly seen good boards able to do for small companies? What’s your experience been with the practice, like what sorts of things do they find out? I’m not sure it feels like governance, and I don’t think I’ve heard “evaluation of vendor behaviour of large clients” described as part of the board’s responsibility, in the general case. I can’t find my copy of my board member course materials or I’d check there. It’s an interesting question! Subjunctive fucked around with this message at 05:19 on Jan 21, 2019 |
|
#
?
Jan 21, 2019 05:15
|
|
|
The way I’ve seen it work is that larger deal sizes take a while to go through and so the board will know how it’s going, and ask questions about how it’s going. At a previous company, I overheard a meeting where someone discussed a customer deal the board had discouraged because they had previous dealings with that company and wanted no part. There’s a few articles that Ben Horowitz wrote that describes something similar (basically about avoiding toxic employees and customers) and him being my CEO for a while I know it’s not complete fluff unlike most blogposts out there that serve as just self promotion material.
|
|
#
?
Jan 21, 2019 06:20
|
|
|
Sure, I’d ask questions about the progress of a deal that was itself determinant of the year’s financial results, but that’s not the same thing as the board having a duty of diligence with respect to potential clients’ practices, whatever the size of that client — this was your position earlier, no? I would expect the CEO to be responsible for finding that out, because it’s an operational matter. Certainly they should consult with board members and advisors and so forth to see if they have any information, but if the board members don’t then it’s on the CEO to find some other way. Practice seems to bear that out: I get mail from CEOs asking for insight on potential partners and large clients, but the only ones I get from board members on this topic are to connect me to the CEO at the CEO’s request. I’ve never talked about toxic customers with Ben, but I have with a friend/partner at his firm (the lesson of “chasing the cheque” was frequently retold at the company Ben, my friend, and I worked at in the 90s), and I don’t think any of them would believe it to be the board’s responsibility. If you’re still in touch with him, I’d love to know his thoughts!
|
|
#
?
Jan 21, 2019 06:33
|
|
|
the talent deficit posted:i disagree completely that inventory is irrelevant to software development... That's a fair enough point. I can see value in classifying things as inventory in order to identify the bottlenecks; the whole "ready for QA" rears its ugly head from time to time. I think I find a lot of my gripes about it come from management failings to grasp these issues or convey them in a way that actually applies to what is going on. "Do a value stream map!" without reasoning or being happy with ~12 month lead times from the backlog give the impression they're playing buzzword bingo rather than seeking out the root of these issues. return0 posted:I like to use some of that vocabulary (particularly inventory) to refer to work where the output the value delivered by the work is withheld until long after the work completes... This is also a good read, and I'll take a look at the video posted by necrobobsledder. bob dobbs is dead posted:after years, i unironically believe that the only really great benchmark for whether you're doing grassroots agile is if the workers have seized materially the means of production and basically humiliated and emasculated the management 
Cancelbot fucked around with this message at 15:36 on Jan 21, 2019 |
|
#
?
Jan 21, 2019 15:34
|
|
|
There was a meeting today to reorganize the dev teams and a position for scrum master opened up. I volunteered. I'm sure y'all are going to tell me now why this was the worst decision in my life.
|
|
#
?
Jan 21, 2019 18:35
|
|
|
Why would you tell a fish water is wet?
|
|
#
?
Jan 21, 2019 19:45
|
|
|
Subjunctive posted:I would expect the CEO to be responsible for finding that out, because it’s an operational matter. Certainly they should consult with board members and advisors and so forth to see if they have any information, but if the board members don’t then it’s on the CEO to find some other way. Perhaps more concrete examples are helpful in explaining my harsh criticism of a group that seldom gets attention. In the early 2000s would it not be important for a board to strongly caution tech CEOs on deals with Microsoft knowing the embrace, extend, extinguish situation? Strange, a number of companies got caught that way, even large companies like Sun - is there no responsibility by governance? Heck, did a bunch of corporate boards support the Microsoft anti-trust suits in hindsight? Ginni Rometty's strategy has theoretically resulted in rather disastrous shareholder loss for IBM presumably because the strategy takes so much time to execute, but she is still there while HP's CEO seat has rotated much more frequently - why? The stock prices look like the opposite company's given just this info, too. The board, including the CEO, is the primary reason to finger as the difference given similar structure, IP, relationships, culture, and market position. Their commitment - much like my toxic customer assertion above - has an impact upon the company's share value (sans the technicals making up the base share value) - is there something materially different between choices of strategic business relations and a business strategy from the perspective of governance in their contributions to the interests of shareholders? Outside tech, are we to absolve the actions and inactions of executive boards of companies that contributed to the financial crisis in 2008 because they are arguably only "part" of the problems? In what fairness I can give, just like our dysfunctional teams described in this thread, even these people are fallible in their groups despite the best intentions and systems we've tried and therefore we can only blame everyone together besides the uninformed and with least oversight, which the board is arguably last on that list of a company's stakeholders. Hence, I have trouble finger pointing elsewhere - nothing personal implied but moreso my summations of a system I've seen repeated among several companies in crisis that I've been unfortunately a part of that seems considerably different from my successful situations but similar businesses operationally. Mike Tyson's observation is right for groups of people I think - everyone has a (business) plan until they get punched in the face. My corollary is a lot of normally smart people seem to think picking up the first person from the bar is a good decision when they're in a long dry spell - somebody has to see that train wreck coming. Carbon dioxide posted:There was a meeting today to reorganize the dev teams and a position for scrum master opened up. I volunteered.
|
|
#
?
Jan 22, 2019 04:29
|
|
|
necrobobsledder posted:Make of it what you will, and take it from rageaholic me here - try to keep a good attitude, find what you've opened up a road to, and things will work out better than if you let the bad things sink their fangs into you. Just don't expect to become a better engineer this way; it really doesn't help. I can't lie to myself that pointing stories or knowing requirements analysis better has any bearing on whether I'll do it better - I can just say how likely it'll suck with more confidence, yay for estimates? A QA engineer was my scrum master years ago and he's been a good director of software by all accounts in the years since. Yeah I was just making fun of the cynicism that seems to live in this thread. I'm happy with my choice. And if it turns out I really don't like it, my work is chill and I can easily go to my manager and tell them I want to be a full time developer again.
|
|
#
?
Jan 22, 2019 07:54
|
|
|
Carbon dioxide posted:I'm sure y'all are going to tell me now why this was the worst decision in my life. Good things can happen. The first thing I did when I became scrum master for my last team was abandon scrum (well, sprints at least... and story points, which, while technically not part of scrum usually come as package deal for all those doing paint-by-numbers Agile).
|
|
#
?
Jan 22, 2019 08:18
|
|
|
A good scrum master is like a force multiplier for the team and is a respectable role if you are good at it. The last one I had was extremely competent, it was far more then the organization deserved. He had a way of never getting in the way but also make any problems disappear . But the one I had in the team before that was one of the most useless people I've ever met in my professional career, and was the main reason I think 99% of non-technical "agile" resources are morons. e: I'm also of the opinion that if your entire organization is actually working in an agile way then a scrum master isn't required. To me it feels like the ~modern~ scrum master role is only really valuable when you have some agile product teams trying to deliver within a traditional, structured/waterfall organization. Xik fucked around with this message at 09:08 on Jan 22, 2019 |
|
#
?
Jan 22, 2019 09:05
|
|
|
Getting better at estimating is becoming a better engineer. Cost is an essential component to the engineering process, from comparing possible approaches to identifying trade-off points related to reliability or performance targets, to letting the organization determine if a given thing is worth building or not. It’s also what underlies decisions about how and when to address technical debt of various types, and build/buy thresholds. Anyone can say “this can be built in an indeterminate period of time for unspecified development and operational cost”, ignoring rare mathematical impossibilities, but outside of large consulting shops, government, or the MIC most of us can’t get our internal or external customers to bite on that — and we wouldn’t be providing a good service if we did. I think many organizations do things that work against good estimation, and also use estimates in unhelpful ways, but consistently better estimates are a powerful tool for an engineer or team.
|
|
#
?
Jan 22, 2019 12:45
|
|
|
I stand by my assertion that better estimation does not make you a better engineer but is like code coverage - provide confidence intervals, not make said tests more relevant or thoughtful. An engineer that causes more work through sloppy code or attitude that happens to meet an arbitrary process built around estimates doesn’t make the engineer superior to one that delivers despite the flaws of the process at long-term thinking and harmonious, realistic design. Ted delivers tickets on time and knows how long a feature takes, Jenny grits her teeth out of politeness and has to deal with his PR that messes with her dependent libraries half-way through the sprint. Ted keeps doing that crap while pulling rank in sprint reviews where teammates observe this and says “she should communicate better what her needs to deliver are.” At the end of the quarter Ted gets a good review from management for delivering tickets he works on routinely while Jenny looks like she is under-delivering and estimating worse for tickets she leads. This is not a fable - this thread is full of it. Why is Ted a better engineer than Jenny? All workers are force multipliers, some are in different places than their skills matrix is optimal and perhaps with the wrong group. But being a good worker and a good engineer are different skills in often contradictory roles.
|
|
#
?
Jan 22, 2019 16:08
|
|
|
necrobobsledder posted:An engineer that causes more work through sloppy code or attitude that happens to meet an arbitrary process built around estimates doesn’t make the engineer superior to one that delivers despite the flaws of the process at long-term thinking and harmonious, realistic design. That's fine, I don't think anyone is saying otherwise. I'm saying that mutatis mutandis better estimation is part of better engineering. I am not saying that good estimation is a replacement for any other engineering standard of competence. I would rather have someone who writes lovely code but can estimate costs in time and other factors than one who writes lovely code with unknown costs. I would rather have someone who writes great code and can estimate well than one who writes great code that is surprising in cost. I would rather be the former engineers than the latter, as well. I'm surprised that this is controversial. Estimation is not purely a local exercise. The more senior the engineer the more I expect their estimates to include things like "would require us to translate some new strings and update screenshots in docs" or "will need to recertify if we touch this module" because I expect them to have more understanding of and responsibility for the whole-system impact of their work. Junior people should be getting help with their estimates because I don't expect them to be learning to estimate more than their own time and interference with other areas, really. Where Jenny's (or whoever's) estimates are off by an uncomfortable or disruptive amount, she and the rest of the team including management need to look at why, and decide if it represents an impairment to work that needs correcting, or a factor that is acceptable and needs to be included in future estimates. (And communicated to the rest of the team for their estimates, in the latter case.) Ted should be looking for interference with Jenny's work if he is indeed more senior, helped to improve, and managed out if he can't correct his behaviour. I don't see how the conduct of an obviously-misbehaving person is relevant to whether estimation capability is valuable in an engineer. I've had to deal with "keeps breaking other people's poo poo" both in peer engineers and those reporting to me, and it's been correctable in almost all cases. In the other two that I can recall, the disruptive person was fired.
|
|
#
?
Jan 22, 2019 16:28
|
|
|
Estimation as a value is not what sparked me but a question of priority and correlation with competing skills for career engineers. If it’s that important we should be able to learn it somehow besides the inefficiencies of trial and error across projects or temporarily lobotomizing ourselves by taking scrum master roles and PM courses. Instead, grinding leetcode problems to find a company with better, more skilled / experienced management is the optimal action beyond even mid-career stages as a rule. A more experienced engineer can provide scoping and estimation more reliably and accurately, but nobody’s checking that fundamental skill in an interview or when referring each other.
|
|
#
?
Jan 22, 2019 19:09
|
|
|
Xik posted:A good scrum master is like a force multiplier for the team and is a respectable role if you are good at it. The last one I had was extremely competent, it was far more then the organization deserved. He had a way of never getting in the way but also make any problems disappear . But the one I had in the team before that was one of the most useless people I've ever met in my professional career, and was the main reason I think 99% of non-technical "agile" resources are morons. You're right. Our PSM (scrum master) trainer said, only semi-jokingly, "the end goal of any scrum master should be to make themself unneeded". One of the main aspects of being a Scrum Master is teaching both your team and your company about what Scrum actually means, and then make your team as self-organizing as possible, so you only need to help out during conflicts and such.
|
|
#
?
Jan 22, 2019 20:07
|
|
|
Che Delilas posted:Got a similar thing the other day from a partner. To be vague, their software calls our software's API, and they were seeing errors in let's call it Scenario 3. Scenario 3 was working before they versioned up their code, but neither side has great instrumentation so we hadn't pinned down what the root cause was, fine. Then they sent us an email to the effect of: Posted this two goddamn weeks ago. My boss and at least two other people had been working on it off and on, huge email chain bouncing back and forth every hour, nobody on the partner's side willing to budge or do any goddamn work at all (like say, instrumenting their own poo poo?). I finally got a chance to try some things and figured out what was going on. Surprise, between their brand new code and our unchanged API, guess whose fault it was? They had to stop pretending after I took a video of how to cause the problem and exactly what their code was doing and sent it to them. Yeah I debugged their outsourced garbage fire of a web site for them (again) after they refused to (again). Boy my boss couldn't praise me enough. Literally, because "enough" would have involved fighting for a raise better than CoL, rather than just giving me an attaboy.
|
|
#
?
Jan 25, 2019 10:10
|
|
|
I'm pissed at the cheapskate no-prize but I do have to say incidents like this give me a pretty big ego boost. Reminds me that yeah, I actually know what the gently caress I'm doing, and motivates me to find a company willing to pay me as if this level of ability were difficult to find and cultivate.
|
|
#
?
Jan 25, 2019 10:16
|
|
|
necrobobsledder posted:Estimation as a value is not what sparked me You should try reading your posts; I don’t think they say what you mean, if that’s the case. Che Delilas posted:willing to pay me as if this level of ability were difficult to find and cultivate. I in no way mean to say that your abilities are not valuable, nor that they are trivial to develop, but I think a big part of the difference is also in this piece: Che Delilas posted:willing to budge or do any goddamn work at all Which, to be clear, we managers should also pay for.
|
|
#
?
Jan 25, 2019 11:04
|
|
|
Che Delilas posted:find a company willing to pay me as if this level of ability were difficult to find and cultivate. It won't become clear to your boss that it's hard to find your level of skill until you quit, unfortunately. Then a bunch of other people will quit, too, and maybe whoever's too depressed to leave will get a raise.
|
|
#
?
Jan 25, 2019 17:16
|
|
|
rt4 posted:It won't become clear to your boss that it's hard to find your level of skill until you quit, unfortunately. Then a bunch of other people will quit, too, and maybe whoever's too depressed to leave will get a raise. I actually think his hands are tied by dumb under-budgeting. I told him at the beginning of the year what I am looking for in terms of compensation and how unsatisfied I was with the current state of things, and in general did everything but put up a flashing neon sign with an ultimatum on it. I'm not privy to his discussions with executives but he seems to play pretty straight with us lowly engineers. Doesn't change a goddamn thing - they could find the money I'm asking for considering they have more available than they have had in years, but they're rolling the dice hoping they land on "complacent worker" instead. They had their chance.
|
|
#
?
Jan 25, 2019 18:37
|
|
|
|
| # ? May 25, 2024 05:11 |
|
|
Che Delilas posted:Boy my boss couldn't praise me enough. Literally, because "enough" would have involved fighting for a raise better than CoL, rather than just giving me an attaboy. A year ago I was only making 60k (that has changed significantly now in my favor). My boss knew I was pissed. His boss knew I was pissed. Their response was to take me to lunch and tell me how much they value me. I responded if that was true, they would pay me what I was worth. They did, thankfully. But it was so insulting to be taken out to lunch and have the gist of it be "plz don't quit, we value you. Sorry we pay you poo poo. Excuse me while I expense this lunch." Management that needs a kick in the rear end to pay their employees their worth is so dumb. I was lucky that they were willing to make it right for me. But as a bonus, while I was pissed I did nothing for two months, so it was nice to get paid to do nothing for that long.
|
|
#
?
Jan 25, 2019 18:46
|
|
