|
If you're specifically trying to evaluate how microservices would work for you it actually makes sense to purposefully go overboard with it. A single microservice won't do a very good job of exposing you to the downsides of having to deal with coordinating a whole bunch of services, but you also don't want to start by porting over a bunch of big critical things, so a small thing split into far too many pieces is a good first test. If they actually think it's good design, then you have a problem.
|
#
?
Jul 12, 2016 19:04
|
|
|
|
| # ? May 10, 2024 05:20 |
|
|
Knowing when and where to draw the line is basically the holy grail of software development. I'm not surprised that they don't know how to do it.
|
|
#
?
Jul 14, 2016 03:17
|
|
|
Pollyanna posted:Knowing when and where to draw the line is basically the holy grail of software development. I'm not surprised that they don't know how to do it. I've also noticed that playing into that is the fact that literally everything is a tradeoff in software. It's important to weigh the pros and cons, especially long term, but how many people either misjudge them or just don't consider it at all?
|
|
#
?
Jul 14, 2016 18:50
|
|
|
It's a fair point that they proved something. They wanted to see if they could break the monolith using microservices, by targeting a specific and common customer service task. The scale of the problem becomes evident in that each task is self contained in terms of user experience, but spiders out through a huge dependency tree that ultimately modifies a huge object in session. There are 28 such tasks, so you could naively extrapolate that around 80-90 services would be required to replace them all, including some shared services. They did say they want a maximum of one hop out to keep the dependencies as light as possible, but I'm not sure how that works in practice because it's very easy to slide down the slippery slope of "one more dependency" that DI frameworks can lure you into. My issue is that they are trying to solve the problem of being a big monolith means that it is a bad system, but replacing it with something that is conceptually identical, with the same constraints as when it was first built 8 years ago. Except this time it's lots of little services instead of lots of little classes. I see the benefit of microservices from a scaling and resiliency point of view, but I think that the problems are more nuanced than blob of code == bad. Cancelbot fucked around with this message at 19:42 on Jul 14, 2016 |
|
#
?
Jul 14, 2016 19:19
|
|
|
Developer has a task to sort some items. The rules for sorting are slightly complex because we're sorting on a fraction n/d where n or d can be a positive integer, 0, infinite, or unknown. There are 6 rules clearly spelled out, that if followed will give the desired order. She's been at this for 4 days. I just got a bizarre question something like "I'm done, but I'm getting -2.5 > -3.5" in my order. WTF. There are no negative values here. I just looked at the code. There's at least a hundred lines trying to pre-calculate some sort of absolute value for each item that can then be sorted on. Real mental gymnastics for turning those rules into a value. me: you should be able to encapsulate all this logic in a comparator function that you pass to the sort function 10 minutes goes by. dev: ok, Will check with this. I think this poor person just hit their head against the wall as they realized their solution is dumb and would probably never work. So torn between spending more time mentoring and getting my work done.
|
|
#
?
Jul 19, 2016 14:45
|
|
|
We had a discussion yesterday afternoon on what to do about one of the engineers on our team. Specifically, that he's totally useless and slowing us down. He's the type of person that can't really do anything without being babied through it, even though he's supposedly a specialist in the type of work he's doing (CSS, Javascript, etc.) He tends to introduce more bugs than he fixes, has been taking my coworker aside all day whenever he's working on something, and isn't very rigorous about making sure his poo poo works. I don't want to promote a silo culture of "please stop talking to me", and it's perfectly fine to ask questions - it's just that he doesn't have enough experience to figure things out on his own, especially not any basic poo poo like git or Rails. The rest of the team wants him out, and I feel a little bad saying that I'm neutral on him staying or not - he doesn't really bother me even if he sucks at his job. This isn't the first time he's had trouble on a project either, he's been taken off a previous one for the subject being way out of his league/competence. One thing that did bother me a little bit about the discussion was that his personal interests and personal projects were used as ammunition against him. One engineer brought up his mentioning of his self-developed apps and projects as an example of how he doesn't care about the work he's doing and only focuses on what he wants to do. That worries me - this is the kind of red flag that people talk about but no one has actually encountered, where personal interests and development are instead taken as "you aren't doing your work so gently caress you". Is it actually such a bad thing to have personal projects like those? It makes much less likely to talk about my own stuff with my colleagues from now on. Regardless, we're probably going to be losing an engineer soon. On the plus side, a whole bunch of suits showed up yesterday to have a presentation/meeting on how to transform the digital development team, so everything's totally on the up and up, right?  we're totally all gonna be let go lmao
|
|
#
?
Jul 20, 2016 13:50
|
|
|
Pollyanna posted:I feel a little bad saying that I'm neutral on him staying or not - he doesn't really bother me even if he sucks at his job. Him sucking at his job makes your life more difficult, either directly (cleaning up his broken poo poo) or indirectly (co-workers stressed out and tense from cleaning up his poo poo). You should care.
|
|
#
?
Jul 20, 2016 13:53
|
|
|
If you are good/great at your job then talk about your side projects if you want. If you suck at your job then yea maybe don't talk about your side projects.
|
|
#
?
Jul 20, 2016 14:11
|
|
|
Ithaqua posted:Him sucking at his job makes your life more difficult, either directly (cleaning up his broken poo poo) or indirectly (co-workers stressed out and tense from cleaning up his poo poo). You should care. Yeah, that makes sense. If he's messing with the rest of the team, he's messing with me, unfortunately. I feel pretty bad about this, but he's just not experienced/smart enough to contribute positively to the team effort. KoRMaK posted:If you are good/great at your job then talk about your side projects if you want. This is what I figured is the actual, real case. It makes sense, just from a social-perception point of view.
|
|
#
?
Jul 20, 2016 14:28
|
|
|
Yea, keep social-perception involved in your decision making.
|
|
#
?
Jul 20, 2016 14:29
|
|
|
Is this a case where he does poo poo work but his personal apps are good? If this is the case I guess this is a classic case of being unmotivated. Though I guess it's irrelevant if his personal apps are good, because he's doing a lovely job no matter what so no big loss to you either way.
|
|
#
?
Jul 20, 2016 14:55
|
|
|
I have no idea whether or not his personal apps are particularly good cause I've never really used them, and the styling/design I see seems to be pre-baked framework stuff. That said, when he asked me to help him with a Flask project of his, he couldn't figure out how to make an endpoint render more than two kinds of an element on a page, so I really don't think his projects are actually any decent. I sure as poo poo wouldn't hire the guy for something I was making, anyway.
|
|
#
?
Jul 20, 2016 14:58
|
|
|
You need to be clear to under-performers about your concerns as directly as possible while showing examples of what you'd like to improve and when expectations weren't met. If you hear mostly excuses instead of promises, you should probably get the papers ready to fire the guy because it's an attitude problem that won't be fixed or may be fixed temporarily but regress back to business as usual. I've fired under-performers before and my only regret is that I didn't fire them sooner. Who cares if someone's side projects are good anyway? They're not working well with you, that's kind of important. In fact, if someone does better work on the side than with your team, that is actually worse in a way.
|
|
#
?
Jul 20, 2016 17:33
|
|
|
Pollyanna posted:Regardless, we're probably going to be losing an engineer soon. On the plus side, a whole bunch of suits showed up yesterday to have a presentation/meeting on how to transform the digital development team, so everything's totally on the up and up, right? You haven't been paying attention. He's going to be promoted to manage your team.
|
|
#
?
Jul 20, 2016 18:15
|
|
|
Could the talk about personal projects also be one about *how* he goes about his work? We have a guy at work who tends to grab a task off the board, disappear into a hole for half the sprint, then finally pop up with buggy, poorly patterned, buggy-as-all-hell code. I spend a ton of time cleaning up after him, because he's very much the 'personal project' sort of person, loves talking about the random toy he's playing with this week, and it reflects in his work. Every single week it's a new framework, a new style guide, a new library, a new whatever and some side project he did with it. So he will come in and just blindly start replacing libraries with new versions with breaking changes and then leave it to the rest of the team to clean up in his wake when a pile of regressions get introduced.
|
|
#
?
Jul 20, 2016 20:20
|
|
|
Cuntpunch posted:Could the talk about personal projects also be one about *how* he goes about his work? Ew, oh my god. Why do you guys enable that behavior?
|
|
#
?
Jul 20, 2016 21:00
|
|
|
It's one thing if someone can make stuff work with new libraries and refractors but breaking stuff that used to work isn't cool. Cofounder of a company I was at before literally refactored half the codebase a week before a release against the engineer's wishes, but we all had some faith and he's the cofounder after all. He fixed half our bugs at the same time and we all just sat slack-jawed at how it worked now. But he wouldn't have tried if we had no tests.
|
|
#
?
Jul 20, 2016 21:27
|
|
|
KoRMaK posted:Ew, oh my god. Why do you guys enable that behavior? Management reshuffle means the new boss doesn't understand the team dynamics yet. He's got the contractors with him(because he'll spend 8 hours a day with them dealing with their "could you please show me how to write functions? ok great, could you please check that in for me?") and I'm outnumbered for the time being. The fact that we regularly have "oh hey I just blindly updated a nuget package because Nuget packages are 100% safe to update by major versions and wait what do you mean ASP is delivering assembly binding errors....uhhhh sorry I'm busy looking at stuff can you please fix that?" isn't really understood very well yet. It's a matter of time, since he got kicked off a different project to join ours because he consistently tended to go "two week sprints mean I can deliver to QA at 2PM the day before the sprint ends!", and he's doing the same thing again. But really wants to push the issue with management to argue about how he is doing *all* the work for the project and he thinks that's unfair. Except that everyone pretty much knows he goes "oh I'm working so hard I'm putting in 4x9's!!! ok it's 10AM on a Friday by guys can't OT!" as he rapidly checks in all his work and suddenly there are bug reports within 30 seconds of anybody looking at it 
|
|
#
?
Jul 21, 2016 02:26
|
|
|
Cuntpunch posted:Management reshuffle means the new boss doesn't understand the team dynamics yet. He's got the contractors with him(because he'll spend 8 hours a day with them dealing with their "could you please show me how to write functions? ok great, could you please check that in for me?") and I'm outnumbered for the time being. The fact that we regularly have "oh hey I just blindly updated a nuget package because Nuget packages are 100% safe to update by major versions and wait what do you mean ASP is delivering assembly binding errors....uhhhh sorry I'm busy looking at stuff can you please fix that?" isn't really understood very well yet. I think it's time to add some branch permissions to the repo.
|
|
#
?
Jul 21, 2016 02:37
|
|
|
Cuntpunch posted:Management reshuffle means the new boss doesn't understand the team dynamics yet. He's got the contractors with him(because he'll spend 8 hours a day with them dealing with their "could you please show me how to write functions? ok great, could you please check that in for me?") and I'm outnumbered for the time being. The fact that we regularly have "oh hey I just blindly updated a nuget package because Nuget packages are 100% safe to update by major versions and wait what do you mean ASP is delivering assembly binding errors....uhhhh sorry I'm busy looking at stuff can you please fix that?" isn't really understood very well yet. Easy solution. Accidentally wait until 10:00:01AM code:"Weird you checked in before you left? We didn't see anything, well just merge latest and push now QA is all ready for you!"
|
|
#
?
Jul 21, 2016 02:44
|
|
|
So at work the pages are modular; there are a bunch of headers that are attached to pages before the body. One of them is called [...]NoScript as it's a version of [...] that doesn't use JavaScript. ...the only things it's attached to use JavaScript very heavily. In fact they're some of the heaviest users of JavaScript in the whole thing. They're also some of the only pages that only use one type of JavaScript. Others have multiple, conflicting frameworks crammed together.
|
|
#
?
Jul 21, 2016 03:31
|
|
|
spacebard posted:I think it's time to add some branch permissions to the repo. It's funny you should mention branching! We have *constant* issues with merge issues while working in a single branch. We're on TFS, and the team doesn't compulsively Get Latest and then *review* the diff before checking in. So especially when two different devs have added files, we just have stuff randomly get dropped from the project, etc. Dude's solution? Clearly every single dev should create a brand new branch every single sprint for every single slice of every single story they're working on! More branches, less problems! 
|
|
#
?
Jul 21, 2016 13:09
|
|
|
Cuntpunch posted:It's funny you should mention branching! Never dealt with tfs, but In the git world, that's very normal.
|
|
#
?
Jul 21, 2016 13:11
|
|
|
Gounads posted:Never dealt with tfs, but In the git world, that's very normal. TFS (TFVC for the spergs) does not play nice with this strategy.
|
|
#
?
Jul 21, 2016 13:14
|
|
|
Cuntpunch posted:It's funny you should mention branching! This is sadly rhetorical, but why is this a technology problem? Why not roll back the changesets of people who do this and fire people who don't look at the things they check in? Nope, clearly the answer is branches and unit test guidelines with code coverage percent thresholds, instead of just not hiring morons.
|
|
#
?
Jul 21, 2016 13:29
|
|
|
Bruegels Fuckbooks posted:This is sadly rhetorical, but why is this a technology problem? Why not roll back the changesets of people who do this and fire people who don't look at the things they check in? Nope, clearly the answer is branches and unit test guidelines with code coverage percent thresholds, instead of just not hiring morons.
|
|
#
?
Jul 21, 2016 14:12
|
|
|
Bruegels Fuckbooks posted:This is sadly rhetorical, but why is this a technology problem? Why not roll back the changesets of people who do this and fire people who don't look at the things they check in? Nope, clearly the answer is branches and unit test guidelines with code coverage percent thresholds, instead of just not hiring morons. It's cheaper to hire morons. There's also a shortage of programmers on the world in general so good luck getting the best ones. Sometimes you just have to make do with what you can get.
|
|
#
?
Jul 21, 2016 18:13
|
|
|
You don't even need the "best" ones for the majority of projects out there though, to be fair. The base level of competency to not create massive cost overruns far greater than the value you supposedly added is higher than most non-tech companies are willing or even able to bear.Gounads posted:Never dealt with tfs, but In the git world, that's very normal.
|
|
#
?
Jul 21, 2016 19:12
|
|
|
The worst part about being in a SVN workplace is that you can't convince them to adopt git and branching because they all think branching is too difficult after years of using SVN.
|
|
#
?
Jul 21, 2016 19:37
|
|
|
It's been more than a decade since I last used svn, but, now that you mention it, bad memories are coming back.
|
|
#
?
Jul 21, 2016 19:38
|
|
|
If I had to work at a place that used SVN, I would checkout the SVN repo into a Git repo and work in that.
|
|
#
?
Jul 21, 2016 21:13
|
|
|
return0 posted:If I had to work at a place that used SVN, I would checkout the SVN repo into a Git repo and work in that. Until the git repo explodes because they're storing gigabytes of binary files in it too.
|
|
#
?
Jul 21, 2016 22:44
|
|
|
return0 posted:If I had to work at a place that used SVN, I would checkout the SVN repo into a Git repo and work in that.
|
|
#
?
Jul 21, 2016 23:07
|
|
|
Replacement for me is at training until next week and I was asked to go back to my old project and work on a importer. I spent all day yesterday setting poo poo up again to actually work on the old project. Super productive!
|
|
#
?
Jul 22, 2016 15:03
|
|
|
Pollyanna posted:We had a discussion yesterday afternoon on what to do about one of the engineers on our team. Specifically, that he's totally useless and slowing us down. He's the type of person that can't really do anything without being babied through it, even though he's supposedly a specialist in the type of work he's doing (CSS, Javascript, etc.) He tends to introduce more bugs than he fixes, has been taking my coworker aside all day whenever he's working on something, and isn't very rigorous about making sure his poo poo works. I don't want to promote a silo culture of "please stop talking to me", and it's perfectly fine to ask questions - it's just that he doesn't have enough experience to figure things out on his own, especially not any basic poo poo like git or Rails. The rest of the team wants him out, and I feel a little bad saying that I'm neutral on him staying or not - he doesn't really bother me even if he sucks at his job. This isn't the first time he's had trouble on a project either, he's been taken off a previous one for the subject being way out of his league/competence. You're not a manager yet, right Pollyanna? Was this discussion had with engineers from all levels?
|
|
#
?
Jul 22, 2016 19:07
|
|
|
Doh004 posted:You're not a manager yet, right Pollyanna? Was this discussion had with engineers from all levels? No way I'm not a manager. This was between our entire product team (2 mid-level engineers, 1 senior) with our direct manager.
|
|
#
?
Jul 22, 2016 20:10
|
|
|
Pollyanna posted:No way I'm not a manager. This was between our entire product team (2 mid-level engineers, 1 senior) with our direct manager. Ouch. Not a fan of that at all. Performance related discussions should be handled on a 1:1 basis and not in a group environment like that. That doesn't mean issues with said co-worker shouldn't be raised, but should be done in private with one's manager (or one level up if the manager is the problem). It would then be up to the manager to go talk to people individually to get more information and hear out opinions in order to determine next steps.
|
|
#
?
Jul 22, 2016 21:46
|
|
|
I don't like it either, but the manager really just kinda got cornered by the rest of the team some afternoon, so it wasn't exactly planned. Either way, it's a good way to start getting paranoid about whether the company talks about you the same way. 
|
|
#
?
Jul 22, 2016 22:02
|
|
|
Pollyanna posted:I don't like it either, but the manager really just kinda got cornered by the rest of the team some afternoon, so it wasn't exactly planned. Either way, it's a good way to start getting paranoid about whether the company talks about you the same way. Manager should have said this isn't an appropriate platform for this issue and killed it at that point.
|
|
#
?
Jul 22, 2016 23:44
|
|
|
|
| # ? May 10, 2024 05:20 |
|
|
Hughlander posted:Manager should have said this isn't an appropriate platform for this issue and killed it at that point. This. Really poor decision making on their part.
|
|
#
?
Jul 23, 2016 04:00
|
|