Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
qsvui
Aug 23, 2003
some crazy thing

feedmegin posted:

I mean, I mostly write microcontroller firmware, which end am I working on?

rear end end

Adbot
ADBOT LOVES YOU

Macichne Leainig
Jul 26, 2012

by VG

return0 posted:

Replying to correct an earlier error or provide relevant information is desirable. The bad part is how crap email is.

That’s rarely what happens though. It’s usually someone answering a question that was already answered 5 emails ago and in less detail or less relevant.

I’ve literally seen people ask if a ticket is complete while the status email went out 3 hours ago, but I guess that just means you’re not wrong about email being crap.

Vulture Culture
Jul 14, 2003

I was never enjoying it. I only eat it for the nutrients.

PhantomOfTheCopier posted:

You've identified your problem; now you get to fix it.

Why should the bulk of software design be based on subjective cultural values? Priority of requests can certainly be established via such subjective or statistical measures, but functionality is a matter for objectivity. You're not getting code approved that just doesn't work, independent of what you might claim as your cultural value.

No. Those are called "hacks", "extensions", "scope creep", "making it do something it wasn't designed to do". The bailing wire holding on your muffler is an accumulated p.i.t. trade-off, but it is not "design".

False dichotomy. It could also mean not trying to do those things at all. Maybe those things should be left to other tools better able to do them. I don't tape a hammer to my circular saw to pound nails, and I don't need to make my text editor speak SMTP. I can utilize tools that do those things well.

One of us hasn't passed this way before. I'm not sure which way or where, but I'm certain we've arrived at different places.
I sympathize that you're clearly frustrated with collaborative software development being a fundamentally hard thing, but the best description I can come up with for the engineering philosophy you're boosting is Ayn Rand Development—the idea that if we can just bend reality to be as simple as our mental models of how things should be, we'll get rid of all that obnoxious complexity and everything will work out fine.

Vulture Culture fucked around with this message at 04:38 on Aug 13, 2019

Pollyanna
Mar 5, 2005

Milk's on them.


How do you deal with working with teams that have their own poo poo to do, but their piece of work is blocking something you’re responsible for? Reason I ask is that we’ve gotten blocked a lot recently on something that has to change in another codebase in order to deliver, but the other team simply doesn’t have capacity to do it. I’ve started offering to just do the work for them, since it’s something on my plate and it really needs to get done. Should I feel bad about asking for advice on a totally new (or particularly heinous) codebase when doing this?

God, I wish our team lead knew what the gently caress he was doing.

necrobobsledder
Mar 21, 2005
Lay down your soul to the gods rock 'n roll
Nap Ghost
I've seen this from both sides and the problems came down to failure in communication of expectations. Does the blocking team themselves understand they are blocking someone else? Does management understand this situation? Is there any agreement on... anything in the culture to begin with?

The CYA move in most dysfunctional cultures is for you to have it somewhere in writing that you're not getting the support you need to be successful and to work on the other party's stuff silently and/or with auditability to avoid being seen as a troublemaker. It completely sucks to do it but as long as you only do it once in a while rather than this becoming a pattern it's not a big deal. In some really toxic cultures I've seen trying to do another team's work is considered a move of aggression and you can be directly reprimanded for it.

vonnegutt
Aug 7, 2006
Hobocamp.
If this is a team you're working with often, or depending on for a crucial piece of infrastructure, it's also probably in your best interest to make friends with a few members of the team. Not for any nefarious backchannel deal-making or anything like that, but simply because having a relationship other than "that person who always emails me" will help you in the long run. You can learn things like who assigns task priority, whether they are super backlogged, or other useful things they might not be aware they haven't communicated. Likewise, they can gain context for why your task is important and put a face to a ticket.

Communication between teams at a company can be the biggest hassle. If you are only ever communicating via "official channels", you can miss a lot of important but unofficial chatter - does their team lead promise things to outsiders but never remember to assign them to anyone? Are they hamstrung by some stupid process that means everything has a waiting period of at least 2 weeks before it even gets added into issue tracking?

One of the best work relationships I've ever had was with a member of the QA team. It was an external team tasked with QA-ing work by something like four other teams, so it was always a bottleneck. By going out to lunch with him a few times a month, I learned about how much stress they were under and how they never had context for half the stuff they QA'd, which slowed things down. I was able to rewrite my feature submission descriptions to follow their rubric better, as well as add in some new utilities to bypass annoying manual steps. In return, he had my email address and could ask me about things as he tested, bypassing the horrific multi-week submission - report - feedback loop that was the "official" channel.

Keetron
Sep 26, 2008

Check out my enormous testicles in my TFLC log!

Pollyanna posted:

How do you deal with working with teams that have their own poo poo to do, but their piece of work is blocking something you’re responsible for? Reason I ask is that we’ve gotten blocked a lot recently on something that has to change in another codebase in order to deliver, but the other team simply doesn’t have capacity to do it. I’ve started offering to just do the work for them, since it’s something on my plate and it really needs to get done. Should I feel bad about asking for advice on a totally new (or particularly heinous) codebase when doing this?

What I often do is tell the PO that this thing he wants is blocked by team X and that my guess is that team X is also upto their eyeballs in work but if (s)he the PO could go and talk to the PO of team X to see if there is a possibility to get the blocking task moving, that would be great. Of course, until the PO does that, I cannot move forward on my task so it all comes down to how eager the PO is to get that task done.
Surprisingly, it works pretty well.

Pollyanna
Mar 5, 2005

Milk's on them.


I’m just getting so hosed off that all our work is linearly blocked for days on end by either some other team that’s stretched thin, or some 15-line PR that nobody bothers to review because we have a hosed up code review and deployment process. Sometimes I wish I could go over people’s heads and cowboy this poo poo. It might be better to beg forgiveness than ask permission, but beg forgiveness too much and you get fired for insubordination.

Also we’re mostly the team that memory oles tickets and work from other teams cause my team lead is a mess. Also we’re a team of two people but our work relies on approval by a different team that don’t do the work we do but work on the same codebase and have their own work priorities. Also we’re weeks behind on stuff we wanted to get done because we loving beefed the rollout of a critical feature we didn’t out together acceptance criteria for.

gently caress me.

Pollyanna
Mar 5, 2005

Milk's on them.


Like I poo poo you not, we’ve lost at least half of the time we’ve set aside this week for a tech debt project because no one wants to review a tiny PR but I need to get at least two other people to look at it and yet no one cares and even if they did the change wouldn’t get deployed until Thursday and we’d only have one day to do the rest of the work we slotted for the week.

I hate this process.

Keetron
Sep 26, 2008

Check out my enormous testicles in my TFLC log!

You know, once is coincidence, twice is unfortunate, three times is a trend but this is the how many time you ran into a lovely org?
Or are we biased because this is the only place you can vent?

Pollyanna
Mar 5, 2005

Milk's on them.


Keetron posted:

You know, once is coincidence, twice is unfortunate, three times is a trend but this is the how many time you ran into a lovely org?
Or are we biased because this is the only place you can vent?

The latter. This is a relatively recent change to the org.

Pollyanna
Mar 5, 2005

Milk's on them.


Also, always assume I suck.

Volmarias
Dec 31, 2002

EMAIL... THE INTERNET... SEARCH ENGINES...

Pollyanna posted:

Also, always assume I suck.

The engineer's credo

If you have a PM or PgM, they're often a good person to raise these issues with, since they'll redo their Gant charts etc to move things along. Ultimately, your best solution might be to get donuts and bribe the relevant teams to do what needs to be done.

Lord Of Texas
Dec 26, 2006

If pull requests aren't being reviewed within a day, or more preferably within an hour or two, your company's culture is hosed and needs to change.

PhantomOfTheCopier
Aug 13, 2008

Pikabooze!

Lord Of Texas posted:

If pull requests aren't being reviewed within a day, or more preferably within an hour or two, your company's culture is hosed and needs to change.
Naaa it's because people are posting requests that are five pages long or more, and it only gets worse when requesters don't actually understand what's going on but "My editor did all this refactoring automatically! So it must be right!".

Reviewers start, get interrupted after half an hour, then never bother to return because... What's the point of reviewing that mess?

JawnV6
Jul 4, 2004

So hot ...
Within an hour? That seems like an aggressive goal. I do a lot of review at the beginning and end of the day from the bus. Like are you yanking folks out of meetings after 45 minutes?

Lord Of Texas
Dec 26, 2006

JawnV6 posted:

Within an hour? That seems like an aggressive goal. I do a lot of review at the beginning and end of the day from the bus. Like are you yanking folks out of meetings after 45 minutes?

I should clarify, sorry - the model that my team has set up is that only one developer needs to approve a PR for it to be merged. So the norm for us is to add 4 or 5 people to the PR. Generally that means someone can jump on it within an hour or two, with exceptions of course. We also keep branches and PRs as small as reasonable, just in the last two weeks my team of 5 devs has created, reviewed, merged about 30 branches.

If people are not following continuous integration practices and regularly working off of long-lived branches, resulting in massive PRs, then yeah, 2 hours would be unreasonable and maybe any amount of hours is unreasonable. I dislike giant walls of code just as much as the next person.

Jabor
Jul 16, 2010

#1 Loser at SpaceChem
I'm reading this:

Pollyanna posted:

Like I poo poo you not, we’ve lost at least half of the time we’ve set aside this week for a tech debt project because no one wants to review a tiny PR but I need to get at least two other people to look at it and yet no one cares and even if they did the change wouldn’t get deployed until Thursday and we’d only have one day to do the rest of the work we slotted for the week.

And I'm thinking your process could use some serious improvement if you literally can't do step two until after step one is fully deployed.

Can't you stand up a developer instance of the system, with your change included, and then proceed developing step two against that?

We have a pretty global system where the people reviewing your changes could (in some cases) be in a completely different time zone from you, and working effectively in that environment means you need to be able to "work ahead" a little bit and develop later changes while your earlier ones are being reviewed.

Jabor fucked around with this message at 05:09 on Aug 14, 2019

Hughlander
May 11, 2005

Lord Of Texas posted:

I should clarify, sorry - the model that my team has set up is that only one developer needs to approve a PR for it to be merged. So the norm for us is to add 4 or 5 people to the PR. Generally that means someone can jump on it within an hour or two, with exceptions of course. We also keep branches and PRs as small as reasonable, just in the last two weeks my team of 5 devs has created, reviewed, merged about 30 branches.

If people are not following continuous integration practices and regularly working off of long-lived branches, resulting in massive PRs, then yeah, 2 hours would be unreasonable and maybe any amount of hours is unreasonable. I dislike giant walls of code just as much as the next person.

How do you find that people can maintain any kind of context if a feature is split over multiple pulls / multiple branches / multiple reviewers?

Lord Of Texas
Dec 26, 2006

Hughlander posted:

How do you find that people can maintain any kind of context if a feature is split over multiple pulls / multiple branches / multiple reviewers?

Single responsibility principle and good intra-team communication? Every team member knows what stories are in progress even if they're not the ones working them, and if they don't understand the context of the feature and need to know, they just ask. I'm not really sure how else to answer that. We don't use reviews to determine whether all acceptance criteria of a story is met anyway, static code analysis (whether done by a linter or a human) is a really bad way to assess holistic functionality of a feature IMO.

Keetron
Sep 26, 2008

Check out my enormous testicles in my TFLC log!

Rant: I have been lied to.

When joining this org, I was told I would be working on a team of engineers away by several timezones from the core group. We would be the third team to work on a cluster of microservices with a shared FE but that would be fine, it is a micro services architecture and this is a cool thing. Java 11, SpringBoot2, AWS, real devops, all the hip and happening stuff. There are over to 25 services to maintain by these teams and with us in a different timezone, the idea is that there would be better support coverage for the global users as well as development acceleration, so more features flowing into the system.

The lie is in the microservices. I only code BE but from my FE colleagues I understood that this application was a BBOM or as my Italian colleague likes to say "Spaghetti Code". But no, the BE was different, independent microservices. Working into details on the services for about two or three months, I noticed the following:
- Some changes require multiple services to change.
- Shared library changes require all services to be rebuild and deployed. Shared models containing business logic are in those shared libs.
- Only a few of the services have strict specs to the Rest API
- Multiple services working directly on the same Dynamo repository
- Without knowing all the services, it is hard to make any change to a single as you might unexpectedly cause a change in behaviour of another.

This pissed me off a ton but I have found zen. I will no longer refer to the system as a Microservices Architecture but it will be a Module Organised Distributed Service. Accepting this makes my life easier, now we need to tackle the communication issues that come from having full code responsibility on code that changes without warning from the people half a globe away.

redleader
Aug 18, 2005

Engage according to operational parameters

Keetron posted:

Module Organised Distributed Service.

mods? moooods?!

sounds to me like either a team who needs to be shown how to Microservice Properly (it's not obvious, and in fact i'd likely make many of the same mistakes), or possibly just the way microservices usually end up

Blinkz0rz
May 27, 2001

MY CONTEMPT FOR MY OWN EMPLOYEES IS ONLY MATCHED BY MY LOVE FOR TOM BRADY'S SWEATY MAGA BALLS
Some of that is always going to exist, though. For instance, changes requiring multiple services to change may be a result of changing functionality in an API. You can (and should) version those APIs but now the client changes are dependent on server changes and they both have to be done around the same time to make any progress.

Similarly, having to rebuild the world after shared library updates is a necessary evil of code reuse.

My suggestion? Instead of getting frustrated by it, think about what you can do to make it better. Pick the one thing that you feel is most hindering to progress and advocate for improving it; write up a proposal, get buy in, scope the work, and get it done.

Volmarias
Dec 31, 2002

EMAIL... THE INTERNET... SEARCH ENGINES...

redleader posted:

mods? moooods?!

:argh:

Vulture Culture
Jul 14, 2003

I was never enjoying it. I only eat it for the nutrients.
At my last job, my team had the ability to merge their own changes without requiring signoff on reviews. It was a cultural norm to get them, and we worked hard to drive down the cycle time on reviews (PullPanda helped a lot), but nobody could actually stop the production line by being negligently inattentive.

Riven
Apr 22, 2002
Where I’m from the term is “Distributed Monolith.”

Keetron
Sep 26, 2008

Check out my enormous testicles in my TFLC log!

Riven posted:

Where I’m from the term is “Distributed Monolith.”

Yeah, I am trying to avoid that here due to the negative association the term has.

ultrafilter
Aug 23, 2007

It's okay if you have any questions.


The Something Awful Forums > Discussion > Serious Hardware / Software Crap > The Cavern of COBOL > Working in Development: I have been lied to

Lord Of Texas
Dec 26, 2006

Keetron posted:

Yeah, I am trying to avoid that here due to the negative association the term has.

quote:

- Shared library changes require all services to be rebuild and deployed. Shared models containing business logic are in those shared libs.

If this is true the term "distributed monolith" is 100% deserved.

Queen Victorian
Feb 21, 2018

So, I’ve spent the last two days doing my darnedest to bash a square peg into a round hole after being told I wasn’t allowed to use the round peg I’d already made to fit in said round hole. :v:

The sprint just ended with 2/3 of my stories incomplete and the usual scolding from the lead dev. The reason these two were not resolved was because I had to take the first one back to the drawing board and implement this bloated third-party monstrosity of a data table plugin to render an effectively static table (the API handles all the sorting and pagination and poo poo already so we don’t need 95% of this plugin’s functionality), and then fight with the ugly, overbearing styling to make it not look like crap (the way they wrote the style markup makes it exceedingly difficult to override without putting a bunch of !important flags everywhere). I had originally spent like an hour making a little table render function that utilized a normal HTML table and provided identical onClick output and also looked better. But nope, had to replace it with the third-party shitpile for consistency reasons (also lead dev might have been on a power trip at the time). And I didn’t finish the last one because I wasted so much time refactoring the previous one and couldn’t even start until way late in the sprint, but it’s pretty much fully operational, just needs unit tests and some UI polish. I built it while the previous story sat untouched in code review for an entire day.

I’m in the final days at this job (already signed new offer and handed in resignation) so I’m just venting because this happens every loving sprint - I finish the goddamned thing with (usually) plenty of time, but no one reviews it in a timely fashion and I take the blame for not completing it, with my last full sprint at this company being no exception.

I’ve decided to just not bother with opinions or going out of my way to argue for the best way forward, so I’m doing exactly what I’m told (even if it’s loving stupid and a waste of my time and bad for future upkeep) because I don’t care anymore and next week it won’t be my problem anymore.

At least I can learn from this experience and apply my newfound knowledge of which third-party libraries to avoid and how to not apply them to completely inappropriate use cases to my new company. I’m also going to consider using some of the downtime between leaving the job and starting the new one to make my own loving table component. I actually made a really nice one with D3/Crossfilter/jQuery a while back, with sorting and pagination and filtering and everything, but no one appreciated it and it’ll get obliterated soon because we’re they’re rewriting the front end in React and the recently hired React dev doesn’t understand D3 and the lead dev axed Crossfilter because it competed with his fancy new API queries. Won’t be all that difficult to make something similar with D3/Crossfilter/React.

Hughlander
May 11, 2005

Riven posted:

Where I’m from the term is “Distributed Monolith.”

Sounds like a team I inherited which now has a separate team doing a greenfield rewrite of it as a pure monolithic service.

JawnV6
Jul 4, 2004

So hot ...

Lord Of Texas posted:

I should clarify, sorry - the model that my team has set up is that only one developer needs to approve a PR for it to be merged. So the norm for us is to add 4 or 5 people to the PR. Generally that means someone can jump on it within an hour or two, with exceptions of course. We also keep branches and PRs as small as reasonable, just in the last two weeks my team of 5 devs has created, reviewed, merged about 30 branches.

If people are not following continuous integration practices and regularly working off of long-lived branches, resulting in massive PRs, then yeah, 2 hours would be unreasonable and maybe any amount of hours is unreasonable. I dislike giant walls of code just as much as the next person.

I think this sort of context is necessary when talking about SLA/expectations, especially before decrying alternatives as indicative of "hosed culture". One repo I work with has a similar standard, one approval from anyone is fine, another team carefully selects a limited number of experts and expects to get 100% of them to approve. Both seem reasonable given the circumstances and both teams deliver products.

I also don't understand the rush to make caricatures of alternatives. It's totally possible to wait 2 hours for a 1-line code review and for that review to take hours, things don't have to be "giant walls" to be conceptually difficult and requiring time.

sunaurus
Feb 13, 2012

Oh great, another bookah.

Queen Victorian posted:

I’m in the final days at this job (already signed new offer and handed in resignation) so I’m just venting because this happens every loving sprint - I finish the goddamned thing with (usually) plenty of time, but no one reviews it in a timely fashion and I take the blame for not completing it, with my last full sprint at this company being no exception.

If this ever happens to you again at another company, I think the best way to handle it is to just force your team to go more in depth during backlog grooming, and note down any implementation details that your team agrees upon in comments. The whole "using a library vs rolling our own" question should probably have been answered before you even assigned an estimate to the story.

Man, I've spent about a year now in what I consider to be an actually agile team, and reading your post reminded me just how much I dislike scrum (which is what I was doing in two teams before my current one). I hope you have a better time in your next team.

sunaurus fucked around with this message at 20:12 on Aug 14, 2019

Lord Of Texas
Dec 26, 2006

JawnV6 posted:

I think this sort of context is necessary when talking about SLA/expectations, especially before decrying alternatives as indicative of "hosed culture". One repo I work with has a similar standard, one approval from anyone is fine, another team carefully selects a limited number of experts and expects to get 100% of them to approve. Both seem reasonable given the circumstances and both teams deliver products.

I also don't understand the rush to make caricatures of alternatives. It's totally possible to wait 2 hours for a 1-line code review and for that review to take hours, things don't have to be "giant walls" to be conceptually difficult and requiring time.

The context of my comment was that Pollyanna has consistently brought struggles of getting responses from external teams to approve or even look at pull requests at all. I was too short and pithy with my response and I apologize. I agree with you that not every situation is the same and not every PR can be or should be quickly reviewed.

But, I do think that companies or teams who consistently run into struggles with their PR process should take a hard look and see if they can break down their changes into smaller bites, or change the expectations of who is an "expert" capable of doing a code review. Maybe knowledge silos need to be broken down, for example.

One example, prior to my current team, I've been in situations where the culture was if you submitted a PR that wasn't amazing you got torn to shreds, which made committers take even longer to be "ready to review", which results in larger and more complex PR's, rinse and repeat.

redleader
Aug 18, 2005

Engage according to operational parameters

ultrafilter posted:

The Something Awful Forums > Discussion > Serious Hardware / Software Crap > The Cavern of COBOL > Working in Development: I have been lied to

redleader
Aug 18, 2005

Engage according to operational parameters

Queen Victorian posted:

bloated third-party monstrosity of a data table plugin

was this third-party plugin named after a traditional japanese martial art, or after the chemical symbol for silver?

Queen Victorian
Feb 21, 2018

sunaurus posted:

If this ever happens to you again at another company, I think the best way to handle it is to just force your team to go more in depth during backlog grooming, and note down any implementation details that your team agrees upon in comments. The whole "using a library vs rolling our own" question should probably have been answered before you even assigned an estimate to the story.

Yep, now I know to do rigorous analysis of both the use cases and the library itself and really emphasize that doing this legwork now will save us lots of time and headaches later.

Come to think of it, we were initially going to roll our own component. We planned a meeting, I did some research and thinking beforehand and went in prepared to pitch a plan for building an easily configurable/customizable table that covered all our use cases. However, our new “React expert” dev went ahead and started pitching this library he pulled up on the internet and totally caught me off guard (I thought we were supposed to talk about designing a component and whiteboard and stuff), I didn’t get a chance to speak, and boss agreed to adopt it. All happened within ten minutes.

Then at the next retro, I brought up that we should probably spend more than ten minutes evaluating a giant third party library before deciding to adopt it. Then new dev (who had been vaguely disrespectful and patronizing beforehand) went on a mansplaining tirade about how I need to be accepting of change and try new things and if we slow down and analyze instead of move fast and break things then we will fail and die and ya know, no tech company ever made it big by being careful ever and to get with this picture. It was loving unbelievable. Everyone else either sat there and did nothing or threw me under the bus. Then I complained to the CEO, and while he was receptive and concerned, nothing changed (except increased passive aggression), and then I started seriously looking for a new job (there were other problems and I should have left ages ago but... imposter syndrome).

I almost feel vindicated having had such a poo poo time making this stupid little table with this huge dumb library because it means my instinct was correct and that deciding to adopt it after ten minutes was a bad idea. Still though, I figured we’d just use it for the few big serious data tables we have (where it makes sense) rather than shoehorn it into every remotely tabulated thing in the app (which is why I decided to just roll my own little table - the big third party one wasn’t applicable because it was such overkill. How naive of me).

quote:

Man, I've spent about a year now in what I consider to be an actually agile team, and reading your post reminded me just how much I dislike scrum (which is what I was doing in two teams before my current one). I hope you have a better time in your next team.

Yeah I hope so... my new team seems way more cohesive and everyone in general has vastly better social and communication skills, so I hope that’ll translate into a less lovely process.

The scrum process here sucks for a number of reasons - the lead dev is, uh, pretty robot-like and is obsessed with process and quantitatively analyzing process, so it frequently feels like our contributions are merely regarded as data for his sprint report bar charts and poo poo. It’s also very unrewarding - we get scolded when we do bad, but not praised when we do well (I guess not scolding us counts as praise?). Also no qualitative considerations for anything. My poo poo being done for days but not reviewed before the end? Sorry, not in the done column so you suck at dev once again. Actually, what’s been happening with some of my stuff is that it DOES get reviewed, but it’s so closely scrutinized that I can’t make all the loving changes in time and get them resolved (oh, and we had to make a new rule about resolving merge request discussions - the poster of the MR is no longer allowed to close discussions on their own MR because the new dev had this nasty habit of just marking discussions as resolved without responding or making changes if he disagreed or didn’t want to deal with it. So instead of boss just talking to him and telling him not to be so loving rude, all of us get saddled with this inconvenient rule to prevent the one dude from blowing off MR discussions on his MRs). And then while my stuff is being intensely scrutinized and held up for petty issues, the new dev’s stuff sales through code review. So overall scrum has become an incredibly demoralizing ordeal. And I’m pretty sure all my stories are cursed.

redleader posted:

was this third-party plugin named after a traditional japanese martial art, or after the chemical symbol for silver?

Neither of those - it’s the most generically named one, but not the latest major version because of course not (latest would actually be awesome because it’s now a headless component that no longer forces its horrible pseudo-table UI (the source of most of my problems with it) on you and instead lets you write your own).

Keetron
Sep 26, 2008

Check out my enormous testicles in my TFLC log!

Queen Victorian posted:

(I guess not scolding us counts as praise?).

I am happy to hear you got out of the abusive relationship as the above is never EVER true.

Update from my predicament with the Distributed Monolith and working on the same code with a group of people in non-overlapping timezones: We are going to improve the code where it is plain spaghetti and make it true modular but accept it as a moduled monolith. Asking management about how to deal with the timezone issue basically came down to: just make it work by doing late night concalls.
So my conclusion is to low key go and find another position at another place that fits better with my personal schedule which is: no work after dinner. Anyone hiring in the Amsterdam area?

Keetron fucked around with this message at 06:08 on Aug 15, 2019

tak
Jan 31, 2003

lol demowned
Grimey Drawer

Queen Victorian posted:

Then I complained to the CEO,

Wait what

How big was this company?

Adbot
ADBOT LOVES YOU

Keetron
Sep 26, 2008

Check out my enormous testicles in my TFLC log!

bleh, company internal API is not working as explained in the docs (or what I want to do is undocumented). Now I have to look at the code to see what it does so I can connect to that. Here's hoping I got the correct version.

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply