Working in Development: Leaving sounds like a great decision.

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Working in Development: Leaving sounds like a great decision.

«‹›434 »

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

New Yorp New Yorp posted:

I'm not a fan of either approach. Code review isn't the place to be ascertaining functional correctness -- that's what unit tests, integration tests, and QA/UAT testing are for. Code review is to catch obvious mistakes, style issues, horribly inefficient algorithms, etc.

There is a QA process happening in parallel in either example as posed here. Not being "production ready" means that features added there aren't necessarily complete. There must not be any regressions, but the new code--if it's scooped up in a release--isn't advertised to end users and isn't normally accessible. There might be some special flags to turn them on for a target user requesting a particular feature.

# ? Feb 1, 2018 21:25

Adbot: ADBOT LOVES YOU

# ? May 12, 2024 14:37

Hughlander: May 11, 2005

Rocko Bonaparte posted:

I'm looking for some opinions on the scope of commits going into code reviews.

We have a lot of plugins and a common task is to make one. There are two ways I see to manage this from a code review standpoint:
1. Get the single commit that implements all requirements of the plugin, end-to-end, in one hit. Spin around on this with feedback and patches until it's set. When it's finally accepted, it's considered production-ready. The master is generally considered production-ready. The developer might make that initial single commit from a series of topic branch commits squashed together. They will also probably have to rebase the source a few times while this all is churning.
2. Get a sequence of commits for the plugin representing major "thoughts" towards fulfilling the plugin. This may still come from personal, squashed commits, but less of them. There will be more unique reviews but the reviews themselves would be shorter. When accepted, they aren't necessarily regarded as release-ready. Master is not considered production-ready. There is a mechanism for separating works-in-progress from production. Architectural work-in-progress code is "dark" in master until feature-complete.

Right now we're doing #1 and it's leading to reviews taking over a week sometimes, and also sometimes resulting in architecture (not plugin) changes that are so large that the reviewers can't really make sense of them any more. I'm looking at #2 as a greener pasture that might be just as bad.

If it's large and architect changing like that a hybrid is usually the best approach. A series of commits in a single review that walk through the steps and can be viewed independently or as a whole as up to the person doing the review. Prior to merging this can be a final squash or not depending on local taste, but I'd rather not squash personally. It looks like in both 1 and 2 you're saying that one commit = one code review. That doesn't need to be the case. I can have a code review of 40 commits and do a diff from master to the last commit and get the whole view, or I can dive in and look at individual commits if I get lost, either way though I'm going to comment on the whole thing not on the individual pieces of it since that's what will become master.

# ? Feb 1, 2018 21:38

muon: Sep 13, 2008; by Reene

#1 sounds awful. It's impossible to meaningfully review huge changes. Reviews should be about fulfilling one part of a functionality and ideally be ~100 LoC so that a reviewer can actually fit the change in their head.

# ? Feb 1, 2018 22:24

Taffer: Oct 15, 2010

Portland Sucks posted:

edit: To be honest you don't want to be needed. You're working under bad management if anyone is full on needed. How can you take a vacation if you're needed?

This has been a really hard one for me. I tend to work at small places and therefore am often needed, which has come with lots of problems. Few people can directly help me on problems, because few people means little overlap, and everything is critical all the time which means if I leave everything breaks or stops. At my current job I was spiraling into extremely bad burnout due to this problem, I had to sit down with my bosses and say basically "either I take a long vacation right now or I have to quit, I'm losing my mind". So right now, I'm on a vacation - my first one in over 2 years.

It's been a really hard lesson to learn but I think I have finally learned it. I'm never going to let myself get in that position again. To anyone else who is dealing with a similar situation, please make regular vacations non-optional, no matter how much there is to do. I had the same problem Pollyanna did where "open vacation" meant "not now, it's too busy", which really meant "never". Gotta force the issue.

# ? Feb 1, 2018 22:36

Portland Sucks: Dec 21, 2004; à¼¼ ã¤ â_â à¼½ã¤

Taffer posted:

This has been a really hard one for me. I tend to work at small places and therefore am often needed, which has come with lots of problems. Few people can directly help me on problems, because few people means little overlap, and everything is critical all the time which means if I leave everything breaks or stops. At my current job I was spiraling into extremely bad burnout due to this problem, I had to sit down with my bosses and say basically "either I take a long vacation right now or I have to quit, I'm losing my mind". So right now, I'm on a vacation - my first one in over 2 years.

It's been a really hard lesson to learn but I think I have finally learned it. I'm never going to let myself get in that position again. To anyone else who is dealing with a similar situation, please make regular vacations non-optional, no matter how much there is to do. I had the same problem Pollyanna did where "open vacation" meant "not now, it's too busy", which really meant "never". Gotta force the issue.

Yeah, I don't really get how Polyanna both screens for employers who make her feel like they need her and also complains about companies that don't want you to take vacation. Lots of mismatched expectations up in here.

# ? Feb 1, 2018 23:26

Blinkz0rz: May 27, 2001; MY CONTEMPT FOR MY OWN EMPLOYEES IS ONLY MATCHED BY MY LOVE FOR TOM BRADY'S SWEATY MAGA BALLS

Pollyanna posted:

Which is perfectly fair - I�m more thinking of this in terms of how truly a company needs me. For example, at one place I interviewed with today, I dug into exactly what the company needed in terms of head count, skill set, etc. Their response was that they don�t really need an engineer, though they have wants in terms of skill sets and soft skills - they�re aiming for doubling their user base and everything dependent on their next round of funding and that may pan out, but in the short term i.e. now it didn�t seem like they were hurting for a new engineer or anything yet. That made me a little nervous, since there wouldn�t be anything clear to point to when asking the question �why did we hire her?� and makes me feel more superfluous than I am comfortable with. If I get hired, I want to know that I am needed.

Stop interviewing at startups. Go apply for a programming job at the MBTA if you want to do something interesting with good job stability.

e: https://angel.co/massachusetts-bay-transportation-authority-mbta/jobs/117785-software-engineer

Ffs they even ask for Elixir and Phoenix. Weren't you going on a while ago about learning Elixir?

# ? Feb 1, 2018 23:52

Skandranon: Sep 6, 2008; fucking stupid, dont listen to me

Portland Sucks posted:

Yeah, I don't really get how Polyanna both screens for employers who make her feel like they need her and also complains about companies that don't want you to take vacation. Lots of mismatched expectations up in here.

She's insecure but doesn't want to follow the advice of "get a decent job and stick with it for a few year so you can grow up", thinking she can somehow skip it if she finds the right place or solicits enough advice from SA. Neither of which will happen.

# ? Feb 2, 2018 00:13

Pollyanna: Mar 5, 2005; Milk's on them.

Blinkz0rz posted:

Stop interviewing at startups. Go apply for a programming job at the MBTA if you want to do something interesting with good job stability.

e: https://angel.co/massachusetts-bay-transportation-authority-mbta/jobs/117785-software-engineer

Ffs they even ask for Elixir and Phoenix. Weren't you going on a while ago about learning Elixir?

I did interview there. It was close, but they went with someone more senior.

# ? Feb 2, 2018 01:04

CPColin: Sep 9, 2003; Big ol' smile.

In stark contrast to my previous job, where I worked four months and nothing made it out to Production, I already have stuff in Production here, after about three weeks. One of the changes I made was to get rid of the asynchronous behavior when this web app tries to send an email, because the surrounding code always marked the email as having been sent successfully, even when the asynchronous operation ultimately failed. I made this change because, while verifying a different change on Test, I noticed the mail server password was wrong in the configuration.

It was wrong on Production, too. I don't know how long, because the logs only go back to the start of this year. So somebody's been clicking "Send Email" for an unknown length of time and been being told it succeeded, without any emails actually having been sent.

The reason the operation was asynchronous? "To make interactive, individual sends snappy (at the cost of some reliability)." I took it out and emails send in under a second on Test and Production. Whee!

# ? Feb 2, 2018 02:00

Volmarias: Dec 31, 2002; EMAIL... THE INTERNET... SEARCH ENGINES...

Hughlander posted:

If it's large and architect changing like that a hybrid is usually the best approach. A series of commits in a single review that walk through the steps and can be viewed independently or as a whole as up to the person doing the review. Prior to merging this can be a final squash or not depending on local taste, but I'd rather not squash personally. It looks like in both 1 and 2 you're saying that one commit = one code review. That doesn't need to be the case. I can have a code review of 40 commits and do a diff from master to the last commit and get the whole view, or I can dive in and look at individual commits if I get lost, either way though I'm going to comment on the whole thing not on the individual pieces of it since that's what will become master.

This is the approach that I like, although it's difficult to pull off at times. It did give me a new appreciation for the magic that could be done with git rebase -i though.

# ? Feb 2, 2018 04:09

Ither: Jan 30, 2010

How do you guys feel about the following?

code:

Foo.getCollection().add(item)

It feels wrong to me.

# ? Feb 2, 2018 08:33

Shy: Mar 20, 2010

What's wrong with it?

# ? Feb 2, 2018 08:40

SAVE-LISP-AND-DIE: Nov 4, 2010

Ither posted:

How do you guys feel about the following?
code:
Foo.getCollection().add(item)
It feels wrong to me.

It's lazy and makes testing a nightmare; The code calling Foo is now tightly coupled with Foo's internal structure.

In my current code base we have a horrific data access abstraction that can only be used like that (google "Law of Demeter" for real reasons why it's awful).

code:

var foo = new Foo();
TopLevel.FooRepository.Insert(foo);
TopLevel.Save();

I showed a senior team member how to use a mocking framework so we could stub out calls to the database. He ended up with a mock class that had the most arcane levels of bullshit I've ever seen. It took days to write. It deserves a merciful death, but senior team member refuses to do the right thing. Now my team think tests are difficult to write, so they don't bother.

Do you see what happens when you write Foo.getCollection().add(item)? DO YOU?

# ? Feb 2, 2018 08:54

Cancelbot: Nov 22, 2006; Canceling spam since 1928

Yeah at minimum "add" should be a method itself that deals with the logic of inserts internally to the object. If you need to expose the collection in some way (e.g. when you add and a UI has to show the new list) then make it a readonly collection on a getter.

code:

Foo.add(item)
Foo.getItems() // IEnumerable if you're C#, Iterable for Java

There's then more patterns after this, such as explicit Command/Query objects;

code:

FooRepository.add / update / delete
FooView.getAll / getById / getByParam

And the logical and insane conclusion is a purely functional representation where each insert copies the original object with the new item in the copy, leaving the original alone :v:

I once made a "functionally pure" shopping basket this way as part of the Potter Kata:

code:

public class Checkout
{
    private readonly IEnumerable<string> _items;
    private const decimal ItemPrice = 8m;

    public Checkout()
    {
        _items = Enumerable.Empty<string>();
    }

    private Checkout(IEnumerable<string> items)
    {
        _items = items;
    }

    public Checkout Scan(string item)
    {
        return new Checkout(_items.Concat(new List<string> {item}));
    }

    public decimal Total()
    {
        return _items.Count()*ItemPrice;
    }
}

[Test]
public void GivenTwoOfSameItemThenPriceIsDouble()
{
    var total = new Checkout()
        .Scan("HP1")
        .Scan("HP1")
        .Total();

    Assert.That(total, Is.EqualTo(16));
}

# ? Feb 2, 2018 09:33

Ither: Jan 30, 2010

Shy posted:

What's wrong with it?

You're modifying a variable using a getter, which at the very least, makes it harder to debug.

That's what I was doing when I stumbled upon to that gem.

# ? Feb 2, 2018 09:37

Keetron: Sep 26, 2008; Check out my enormous testicles in my TFLC log!

Massive rant was incoming but I cooled down.

Short version: we have a Development branch and a feature branch for a pretty big epic so it has been open for a few months now. Yesterday someone finally, after these months, did a merge Development -> featureBranch to keep the second up to date. The part I work on has some big differences as for both the work continued. Because it was a list of so many items, he clicked "Accept Theirs" in the merge window for this entire module, commit this to the featureBranch and pushed to remote. The whole module was broken of course, so I wanted to do a revert but I cannot as git push --force is disabled for everyone by this same developer as "the people in this team are not proficient enough at git to have such a dangerous tool available to them".

I lost all day fixing that poo poo working around his bullshit merge. The only good thing was that I was WFH so I was not fired for cursing out my colleagues. Considering I walk away from this place in a week anyway, that would have been fun tho.

# ? Feb 2, 2018 10:48

Xarn: Jun 26, 2015

Pollyanna posted:

If I get hired, I want to know that I am needed.

So, I am fairly sure you also posted complaints about management desiring too much from jr. dev and planning badly so there are crazy deadlines. If that was not you sorry :v:

Good management should hire people preemptively, because people need time to ramp up and become productive. This means that when you are being hired, you are not actually needed, because ideally the management is hiring you because they expect more dev work to be there in the next quarter. This means that there is no crazy pressure to perform right now, but also that there is no need for you, because there is enough time to interview and select for more people.

There are exceptions, generally consultants and senior level people are someone who can ramp-up quicker and who you look for when there is crunch, but as long as you are jr. programmer you are not, and should not be, needed.

If by needed you meant something more along the lines of "they have long-term plans for me", then that's obviously different, but still, it will be more of a "we have long-term plans for a jr. programmer", not "we have long-term plans for Pollyanna"

# ? Feb 2, 2018 10:51

leper khan: Dec 28, 2010; Honest to god thinks Half Life 2 is a bad game. But at least he likes Monster Hunter.

Keetron posted:

Massive rant was incoming but I cooled down.

Short version: we have a Development branch and a feature branch for a pretty big epic so it has been open for a few months now. Yesterday someone finally, after these months, did a merge Development -> featureBranch to keep the second up to date. The part I work on has some big differences as for both the work continued. Because it was a list of so many items, he clicked "Accept Theirs" in the merge window for this entire module, commit this to the featureBranch and pushed to remote. The whole module was broken of course, so I wanted to do a revert but I cannot as git push --force is disabled for everyone by this same developer as "the people in this team are not proficient enough at git to have such a dangerous tool available to them".

I lost all day fixing that poo poo working around his bullshit merge. The only good thing was that I was WFH so I was not fired for cursing out my colleagues. Considering I walk away from this place in a week anyway, that would have been fun tho.

Revert creates a new commit and could be used in that situation. Reset, push �force could not, and that�s not a bad thing necessarily.

Not clear what your problem was.

# ? Feb 2, 2018 13:34

Hughlander: May 11, 2005

leper khan posted:

Revert creates a new commit and could be used in that situation. Reset, push �force could not, and that�s not a bad thing necessarily.

Not clear what your problem was.

^^^
Git revert HEAD
Git commit �amend -c �No dad gently caress you�
Git push origin develop

# ? Feb 2, 2018 14:23

streetlamp: May 7, 2007; Danny likes his party hat
He does not like his banana hat

this is totally a healthy and productive career move

# ? Feb 2, 2018 15:18

leper khan: Dec 28, 2010; Honest to god thinks Half Life 2 is a bad game. But at least he likes Monster Hunter.

streetlamp posted:

this is totally a healthy and productive career move

If �not paying� means no salary but two digits of equity; unironically maybe correct.

# ? Feb 2, 2018 15:42

spiritual bypass: Feb 19, 2008; Grimey Drawer

Edtech is dumb as hell, just read a book

# ? Feb 2, 2018 16:11

streetlamp: May 7, 2007; Danny likes his party hat
He does not like his banana hat

im a developer at a university and yes, its extremely dumb. loving awful poo poo

e: guessing off where he is, its basically a full time internship for an adult prolly

# ? Feb 2, 2018 17:05

Pollyanna: Mar 5, 2005; Milk's on them.

Doesn't NPR regularly run articles on how edtech has continually shown itself to be a scam and grift vehicle?

# ? Feb 2, 2018 18:12

Vulture Culture: Jul 14, 2003; I was never enjoying it. I only eat it for the nutrients.

Rocko Bonaparte posted:

I'm looking for some opinions on the scope of commits going into code reviews.

We have a lot of plugins and a common task is to make one. There are two ways I see to manage this from a code review standpoint:
1. Get the single commit that implements all requirements of the plugin, end-to-end, in one hit. Spin around on this with feedback and patches until it's set. When it's finally accepted, it's considered production-ready. The master is generally considered production-ready. The developer might make that initial single commit from a series of topic branch commits squashed together. They will also probably have to rebase the source a few times while this all is churning.
2. Get a sequence of commits for the plugin representing major "thoughts" towards fulfilling the plugin. This may still come from personal, squashed commits, but less of them. There will be more unique reviews but the reviews themselves would be shorter. When accepted, they aren't necessarily regarded as release-ready. Master is not considered production-ready. There is a mechanism for separating works-in-progress from production. Architectural work-in-progress code is "dark" in master until feature-complete.

Right now we're doing #1 and it's leading to reviews taking over a week sometimes, and also sometimes resulting in architecture (not plugin) changes that are so large that the reviewers can't really make sense of them any more. I'm looking at #2 as a greener pasture that might be just as bad.

The main problem with #1 isn't even that code reviews take a week -- that's a big issue too -- but you're waiting a huge amount of time before people are clued in that a developer has gone off the rails and implemented the absolute wrong thing. Do reviews frequently. Look over things frequently, before someone has wasted a week going off track. Doing dark architectural work against is one approach, I guess, and that's cool if you're okay with having dead, unreferenced code floating around master, but also consider doing more frequent code reviews (even informal ones) on your feature integration branches and then doing a final squash down to your master or develop branch.

# ? Feb 2, 2018 18:25

LLSix: Jan 20, 2010; The real power behind countless overlords

Rocko Bonaparte posted:

I'm looking for some opinions on the scope of commits going into code reviews.

We have a lot of plugins and a common task is to make one. There are two ways I see to manage this from a code review standpoint:
1. Get the single commit that implements all requirements of the plugin, end-to-end, in one hit. Spin around on this with feedback and patches until it's set. When it's finally accepted, it's considered production-ready. The master is generally considered production-ready. The developer might make that initial single commit from a series of topic branch commits squashed together. They will also probably have to rebase the source a few times while this all is churning.
2. Get a sequence of commits for the plugin representing major "thoughts" towards fulfilling the plugin. This may still come from personal, squashed commits, but less of them. There will be more unique reviews but the reviews themselves would be shorter. When accepted, they aren't necessarily regarded as release-ready. Master is not considered production-ready. There is a mechanism for separating works-in-progress from production. Architectural work-in-progress code is "dark" in master until feature-complete.

Right now we're doing #1 and it's leading to reviews taking over a week sometimes, and also sometimes resulting in architecture (not plugin) changes that are so large that the reviewers can't really make sense of them any more. I'm looking at #2 as a greener pasture that might be just as bad.

Those both sound pretty unpleasant, but I'd much rather do 2 than 1. More smaller code reviews are both less draining to do, and more likely to generate useful feedback.

Something like 2, but using feature branches so that master remains releasable would be my suggestion.

If you're seeing architectural changes requested in code reviews, that suggests to me that there need to be feature design reviews ahead of time. Especially on any feature long enough to take a month+ to implement, a 10-30 minute meeting to discuss the planned approach and how it fits into the existing framework before any code is written can save a lot of time.

# ? Feb 2, 2018 18:30

Keetron: Sep 26, 2008; Check out my enormous testicles in my TFLC log!

Hughlander posted:

^^^
Git revert HEAD
Git commit �amend -c �No dad gently caress you�
Git push origin develop

Thank you, you made me laugh.

# ? Feb 2, 2018 18:42

spiritual bypass: Feb 19, 2008; Grimey Drawer

Pollyanna posted:

edtech has continually shown itself to be a scam and grift vehicle?

No doubt about it. "Here, buy our computer to learn instead of school" doesn't really work at all

# ? Feb 2, 2018 18:51

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

Vulture Culture posted:

The main problem with #1 isn't even that code reviews take a week -- that's a big issue too -- but you're waiting a huge amount of time before people are clued in that a developer has gone off the rails and implemented the absolute wrong thing. Do reviews frequently. Look over things frequently, before someone has wasted a week going off track. Doing dark architectural work against is one approach, I guess, and that's cool if you're okay with having dead, unreferenced code floating around master, but also consider doing more frequent code reviews (even informal ones) on your feature integration branches and then doing a final squash down to your master or develop branch.

A secondary cultural thing I am battling in the scenarios I gave is that reviews should be for something being basically ready-to-ship. Let's say I do 50 lines to implement one unit of work towards feature X. I am liable to see "-1 Verify this doesn't do X."

TBH I might try doing multiple commits in a review with these guys again. I actually did that awhile ago and they got fixated on the head-most one.

# ? Feb 2, 2018 19:12

Vulture Culture: Jul 14, 2003; I was never enjoying it. I only eat it for the nutrients.

Rocko Bonaparte posted:

A secondary cultural thing I am battling in the scenarios I gave is that reviews should be for something being basically ready-to-ship.

They should, for merges to master.

# ? Feb 2, 2018 19:55

LLSix: Jan 20, 2010; The real power behind countless overlords

Vulture Culture posted:

They should, for merges to master.

Merges to master shouldn't merit a code review. Merge master into your feature branch first, with review, and then merge back to master. That way if some jerk (kind, helpful, productive coworker) checks something into master while you're merging, or more likely, during the review, you can still commit the merge changes and easily pick up the new change.

# ? Feb 2, 2018 20:23

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

rt4 posted:

No doubt about it. "Here, buy our computer to learn instead of school" doesn't really work at all

Neither do those lazy teachers ami rite :bahgawd:

?!

But seriously I'm not at all surprised "replace a teacher with a webapp" is a snake oil pit, but I bet making CMSs to facilitate communication and scheduling is probably good, non-scammy business. Also would bet most of them are trash fires, but honest, well-intentioned trash fires.

# ? Feb 2, 2018 20:24

Ghost of Reagan Past: Oct 7, 2003; rock and roll fun

Munkeymon posted:

Neither do those lazy teachers ami rite ?!

But seriously I'm not at all surprised "replace a teacher with a webapp" is a snake oil pit, but I bet making CMSs to facilitate communication and scheduling is probably good, non-scammy business. Also would bet most of them are trash fires, but honest, well-intentioned trash fires.

Blackboard is the worst goddamn piece of software I have ever used. I'm not kidding when I say that Blackboard was the bane of my existence and made everything far more painful than it had to be. One update added two extra clicks to change grades vs. entering them, so if you make a mistake entering them the first time :rip:

. You would make mistakes all the time because the software would just refuse to recognize that you pressed enter so while you're manually entering grades in because uploading a spreadsheet was far too opaque and painful that I'm still not sure anyone could actually do it, you would have to go back and correct a bunch because rows got misaligned because it didn't recognize that you hit enter.

Blackboard is a loving scam made by awful people who hate teachers and professors and if you can find your way into that market you will have a ton of university IT departments that will ignore you because they're trapped by loving Blackboard and cannot hear the screams of the people forced to use it.

# ? Feb 2, 2018 23:57

JawnV6: Jul 4, 2004; So hot ...

LLSix posted:

Merges to master shouldn't merit a code review.

This just seems like willfully talking past each other. The thing that will somehow, some way merged to master should be reviewed and squashed down to 1 commit.

Quibbling over the precise ordering of those steps, or proscribing precisely when feature branches are rebased relative to master, or a million other little tangents seems unproductive.

# ? Feb 3, 2018 00:01

fantastic in plastic: Jun 15, 2007; The Socialist Workers Party's newspaper proved to be a tough sell to downtown businessmen.

Ghost of Reagan Past posted:

Blackboard is a loving scam made by awful people who hate teachers and professors and if you can find your way into that market you will have a ton of university IT departments that will ignore you because they're trapped by loving Blackboard and cannot hear the screams of the people forced to use it.

Most enterprise software is terrible and supported by a combination of long-term contracts and bureaucratic inertia. Academia must be even worse, since I can't think of anything else that's so exemplified by bureaucratic inertia except the government.

# ? Feb 3, 2018 00:07

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

Well I'm thinking experiment number 1 is getting reviews of in-progress work that doesn't immediately spun onto master. This might be pissing in the wind, but I'll see how people react to me again sending up a review of a few commits at a time not even set up to hit master.

# ? Feb 3, 2018 00:33

Pollyanna: Mar 5, 2005; Milk's on them.

Yeah I kinda refuse to work in edtech. I�ve never seen anything good about it. I�m sure people will get mad at me for that, but I just don�t get a good feeling from it.

# ? Feb 3, 2018 01:54

Blinkz0rz: May 27, 2001; MY CONTEMPT FOR MY OWN EMPLOYEES IS ONLY MATCHED BY MY LOVE FOR TOM BRADY'S SWEATY MAGA BALLS

You're currently unemployed and have been bouncing from job to job where you've never found satisfaction. Maybe don't artificially limit yourself?

# ? Feb 3, 2018 02:21

freeasinbeer: Mar 26, 2015; by Fluffdaddy

Blinkz0rz posted:

You're currently unemployed and have been bouncing from job to job where you've never found satisfaction. Maybe don't artificially limit yourself?

Is Pollyanna unemployed again?

What???

I must of missed something. I thought they just had a bad job again.

# ? Feb 3, 2018 02:49

Adbot: ADBOT LOVES YOU

# ? May 12, 2024 14:37

qsvui: Aug 23, 2003; some crazy thing

I think Pollyanna has settled for enough poo poo jobs and should try to hold out for something that's tolerable.

# ? Feb 3, 2018 02:58

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Working in Development: Leaving sounds like a great decision.

«‹›434 »