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.

«‹›5 »

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Pollyanna posted:

Holy poo poo, I�m the main point person on our push to kill off and split up an old legacy system and bring it into our newer stuff, and I am loving it up so badly. Every time I think we�ve accomplished a new milestone some new insight on how the legacy system works or some data relation is clarified and I have to interview/meet with people to determine if what I�ve got is actually what they expect or if I need to change it up. I feel like I�m stumbling over so much poo poo in the way of doing the work. Am I bad at my job?

Hey, so if you're wondering why developers change jobs every couple of years or so, let me give a summary of me at the six year mark of my job.

1. We have a legacy system that has code from the nineties that references IE in it. There are no unit tests, the workstation client itself is over six million lines of C++, registers itself as a windows shell namespace extension, and does all sorts of crazy poo poo.

2. Working on the replacement for this thing is my first project as a developer - the idea is to adapt a codebase used for something else that's only ten years old to replace the twenty year old one.

3. I work on this project for like, let's say, from 2012-2014. It gets canned. The lead developers of the replacement leave the company. I am stuck on a relocation contract and am uninterested in paying back the money, so I stay on.

4. In 2014, we decide that everything is going to be HTML5. I work on the replacement for the replacement client using all this new web junk, which I know nothing about.

5. In 2015, PO decides development is too slow and we should stop writing unit tests for the UI. I complain that some of the features are not feasible with the new architecture and get placed on another project.

6. In 2016, worldwide release. Everyone complains about the performance. Hundreds of bugs about how the system doesn't match the legacy system - bug tracker blows up like Zimbabwe currency. We start thinking about the replacement for the client.

7. 2017 - we start working on the replacement for the replacement of the replacement of the product. This project fails.

8. 2018 - the architect agrees with my 2015 assessment of the problems with the architecture, and we decide to to a replacement for the replacement of the replacement of the replacement of the product. Unfortunately, the HTML5 refresh of the client was successful enough that it was able to pay for a huge monolithic QA team and raises for all the people who made mistakes. Instead of actually having technical standards, now closing bugs in tfs has twenty three required fields, closing user stories requires sign offs from three different teams.

9. After some initial progress, the fundamental problems with the client still exist in the new version. I get asked to work on this new version. I tell them that they can go gently caress themselves (I say the word 'gently caress' in meetings a lot at that company, this is not met with surprise) and the project is going to fail, and ask for a transfer to architecture team instead.

10. I transfer out of my old group, but my new boss has a stroke before it's finalized, so now I don't actually... have a boss. Or assignments (sure I'm supposed to deliver a tumor recognition AI and the replacement for the current architecture sometime in 2019, but it'll have to get in line behind finishing all the quests in the witcher 3). The checks are still coming in the mail. I try to go to the office once or twice a week just for appearances sake and maybe leave the office at seven.

# ¿ Jul 14, 2018 14:56

Adbot: ADBOT LOVES YOU

# ¿ May 12, 2024 00:54

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Boiled Water posted:

Mission accomplished: you will never close anything, tickets closed will go straight to zero

yeah, last year I closed ~1000 bugs in tfs with code fixes for like ~1550. clearly the problem with our process is that there aren't enough fields in the bug tracker. Oh, the best part - let's make them mandatory fields, but make it so if you don't fill out the fields correctly the first time, the bug can never be saved. Let's not talk about workflow, or how certain fields are only valid in certain bug states, or how you can't just move a bug to closed or such and such arbitrary state, you have to change it to the mandated state (e.g. if a bug is active, you can't' just reassign it to yourself, you need to change it to fixed. then deployed, then reassign it to a tester, then mark it 'active' again, then mark yourself as a developer.)

right now I am actively trying to get laid off because I hear it's six months pay and a bonus. I swear to god it wasn't even this retarded two years ago.

# ¿ Jul 16, 2018 14:54

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

wilderthanmild posted:

That was REALLY hard to read. At least the pay wasn't $50k or something. I'm so used to seeing ridiculously stupid job ads followed by ridiculously stupid salary.

140,000 aud is 103,000 usd. That's still pretty lovely for environment described.

# ¿ Jul 18, 2018 22:19

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

spacebard posted:

I mean who doesn�t work on a development team of clowns that are constantly farting, screaming and chucking their managers into crushers as soon as the sprint begins?

agile development is exactly like playing space station 13 except the developers are the clowns.

# ¿ Jul 24, 2018 04:25

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Rubellavator posted:

What do you call a modernization effort that replaces maintainable and performant code/technology with unperformant and unmaintainable code/technology? Cause that's what I'm part of right now.

uhh, i feel like after a certain point, you begin to have five goals in mind

a) get paid
b) don't work on anything unpleasant
c) make users suffer
d) minimize interaction with other teams
e) guarantee project success

Re-implementing something that already exists is great because
a) You get to pick a hot technology that you don't know and get to put on your resume
b) Don't have to deal with requirements issues - with new software, your PO will be like "oh, what if we put the controls on the screen in a different order" and act like that's revolutionary. If you're re-implementing something that already exists, "it worked like this in legacy" is pretty bullet-proof.
c) Users will hate the new system and will either ask you all to roll it back or for endless bug fixes. Fixing these bugs looks a lot like work.
d) Since you already have a system that works, no need to spend a bunch of time in meetings or talking to people about how it should improve, just make it look like legacy.
e) Your project is already successful by definition because it is forced to be - you are rewriting software that was accepted and people pay money for. 90% of software projects fail so most of the time, if you work on new stuff, it's just going to get thrown out anyway, whereas people will probably begrudgingly use your rewrite anyway.

# ¿ Jul 25, 2018 06:37

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

baquerd posted:

Friday afternoon, 12 outstanding PR's to merge in a repo and a half-hour deploy cycle for each because our security team insisted that every build run multiple linters and a dependency vulnerability analysis.

oh, that's easy. don't check anything in. if you just don't check anything in (don't actually say you're doing nothing, just keep saying things like "trying to make fixes to accommodate security team), you can wait for people to realize that there's no product and make the logical connection "why are we paying a security team if there's no product"?

# ¿ Aug 4, 2018 17:26

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

NtotheTC posted:

One of the testers on my team is really starting to try my patience. I'm assuming the issues stem from personality flaws in the first place but they've developed a real "Me vs Them" attitude to being a tester that means when they find a bug in a feature it's time to go find the dev that wrote the feature and talk about how there's a bug in it for 10 minutes while being entirely unable to provide any information on how it was caused, which forces my devs to have to get up and go round to watch them recreate the bug, and then take over the machine to look at the logs/traceback because no matter how many times I explain to the tester where to look all the evidence they can provide is a screenshot of the error in question.

To make matters worse they'll dig their heels in and refuse to budge once they've settled on an idea.

Tester : I've found a bug in ticket-01234
Me: What happens?
Tester : <describes something that isn't a bug>
Me: That's not a bug, do this thing instead
Tester : I'm assigning this ticket back to development because of the bug
Me: Again, it's not a bug you're doing that in the wrong place, read the instructions in the ticket
Tester : Well it's not working the way I expected it to, so I'm assigning it back to development
Me:

I've taken them aside for a private chat and that helped for about a week. I've spoken to the PM and voiced my concerns. At this point I'm looking to get them moved off the team because they're slowing everything down so much. God what I wouldn't give for an experienced tester with some experience in automation at this point.

Generally what I'll do is:
a) Don't assign the tester's bugs directly to your team and waste their time. If a bug doesn't have solid repro steps, on basis of severity
1) If there is nothing at all the work with, just kick it back to the tester with 'can't reproduce. please provide reproduction steps'.
2) If the repro steps are there but either lovely or don't work, give an example set of repro steps that follow the directions as given but don't reproduce the result. Don't try to test around, you don't have time.
3) Once you've confirmed you can reproduce the bug - update the bug with non-moronic steps, and give it to your team.

Another thing you can do is teach the tester how to use tools other than screenshots. Don't make the assumption that stuff like repro steps, etc. is explained by their department at all - a lot of these people are liberal arts majors or recent college grads that were literally hired off the street by some contracting company making fifteen bucks an hour, it's entirely possible that they were given zero training. You should explain what you want to see in a bug if you want good results.

1) If it's a webapp, maybe it'd a be a good idea to capture fiddler logs.
2) Does your product have logging? Where are the log files created? If you see a problem in X area, where should you get the logs? What would the developers be looking for in the log file?
3) How is your product configured? What configuration settings are pertinent to your product?
4) Maybe try getting a video of the bug with camtasia studio... (this is the easiest way to improve the quality of a QA defect report)

Another thing you can do to get the tester on your side is to just show them how to build the product and where the source code is and walk through how to debug and how to get stack traces etc. I would only do this if the tester is becoming a problem because the smart, motivated ones will probably just leave and become developers, the slackers will just be content to churn out one or two well-researched bugs a day with great stack traces that are easy to fix, but can no longer be trusted to click all the buttons like a superstitious person, while the stupid ones will get lost and cowed and lose their self-confidence (but at the same time the Holy Knight of Quality Assurance escutcheon might lower just a touch, you can always dream.)

Trying to teach people things generally gets them on your side. If you go into the interaction just trying to be nice and polite and soft serving everything, they'll think you're being condescending and blow up the bug tracker.

# ¿ Aug 5, 2018 16:31

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Munkeymon posted:

Yeah, I thought I remembered someone hating on it. I really just need a grid that can highlight and collapse rows and columns (but with a bunch of arbitrary rules of course!). No cell editing or anything like that.

one of the worst software projects i was involved in was someone trying to use kendo ui to put a list of studies on a web page. the project went so poorly that our division was banned from using javascript ui frameworks for years afterwards (this was luckily in 2012 so not much harm was done) because the new architect got sick of people blaming kendo ui for not being able to do stuff. i somehow suspect that it was our fault rather than the kendo's fault, given that we had a critical mass of the stupidest developers i have ever personally known or worked with when they were trying to get that poo poo to work, but i was working on a completely different insane utterly doomed component at that time and couldn't attest personally to it sucking.

# ¿ Aug 8, 2018 12:07

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

New Yorp New Yorp posted:

Can't you unit test your JS instead of relying on UI tests? In my experience, trying to do any UI testing more extensive than smoke testing is a recipe for disaster.

at least one thing i'm liking about the angular cli tooling for .net core is that
a) template comes with both the unit testing with karma and the e2e with protractor working right out of the box, and it's pretty easy to swap in 'real' controllers for the production environment.
b) conforming with angular means that your developers actually have to make components for the UI anyway, so in principle, you should be able to write the UI tests at the angular component level, and you should be able to just write a test controller for hosting the individual components and write component based tests using protractor.

i don't really believe in the external qa-style selenium tests because it feels gross to write tests that have to find your log-in page, click log in, and then manually click a link to test whatever you're writing automated tests - what I like about angular + protractor is that protractor is a wrapper for selenium that understands angular.

a) I can use TestHost (https://docs.microsoft.com/en-us/aspnet/core/test/integration-tests?view=aspnetcore-2.1) and the integration test framework of .net core to make my own authorization middleware that I use for the purpose of the tests - I can make it so it will just bypass the login page and log in as an arbitrary user if i don't care about testing specific users, or log in as a specific user by, say, providing the username/password in the header and having the authorization middleware create an identity. I like this framework because I might want to test with a real database and real data, but don't necessarily want to log in every single time.

b) For pure unit tests, I can unit test angular UI side using karma - with angular cli, it's easy to stub out the api calls because the way it works is if you make an api call, it will be routed to the .net controller if available, if not, the request will be routed to angular, so it's pretty easy to set up fake controllers for the purpose of unit tests. I'm not a super huge fan of the pure unit tests for UI, I'll generally only provide these for documentation.

c) Protractor is pretty good - it's built on top of selenium, but it understands angular directives/models so it's usually less code than pure selenium. i'll generally stub out the authentication layer using the testhost, and run the protractor tests against the version of the project hosted by testhost. Navigation is a lot better because angular guides the devs into making everything components, so generally every individual component will either have a url (or it would be easy to make one).

The cool thing about angular cli for .net core is that it'll just make a working project with all this protractor stuff - you'll have to add like a testhost project, and the authorization middleware is a one line thing.

(I don't actually have a boss or assignments at my job so I've been 'updating my skillset' for like three months now).

# ¿ Aug 10, 2018 14:12

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Keetron posted:

For reasons unknown to us, we are assigned two products but no PO, only another teams PO who drops by now and then and we have no manager or teamlead. So basically, we nurture these products, refactor where we feel it is best and develop the features that make sense to us or where the sometimesPO says: "Sure go ahead". I do not think this utopia will last a long time and honestly, a bit more direction would be nice too. But the lack of management helps with the "set your own hours".

oh yeah, that happens when no one cares about your project and they don't have anything else better for you to do. the less experienced of you may experience "fear" in such a situation, but realistically if the company were either well run or people were paying attention, you would not be in that position in the first place - it's a way better position than working on something important and failing at it for your career, because realistically, they're not going to promote someone who is actually responsible for something useful. don't rock the boat and a re-org may happen eventually.

# ¿ Aug 11, 2018 20:46

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

smackfu posted:

In my new role, every three months we have a big planning meeting where every team commits to the features they will be developing and what sprint they will do each story. If your team doesn�t meet your goals for each sprint and the overall quarter, you are raked over the coals.

Somehow this is called agile.

did you guys know that the notion of scrum being agile is an anachronism? scrum was actually codified in 1995 and existed in the early 1990's. the agile manifesto was signed in 2001.

if you sit through eliassen group training meetings on agile, they'll bring up agile and they have this whole oral history of the signatories of agile etc, who are liked to the signers of the declaration of independence visually in the graphics. suddenly, there is a switch to this scrum, which existed before the agile manifesto and whose only relationship with agile is seemingly that agile is a cool word that people are willing to pay a bunch of money to look like.

my working theory is that the scrum consultants happened upon a cia backdoor / pattern of mind control implanted by high school civics class that was intended for cia use in case of emergencies, and that's how it began to spread.

# ¿ Aug 17, 2018 14:25

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Fellatio del Toro posted:

I always put incorrect expected values the first time I run tests just to make sure it can actually fail

yeah, so when your test passes despite that, it's a real mindfuck. it's happened to me a bunch of times (usually something like = instead of == or something along those lines, much better to use the api than to write the comparison yourself in most cases)

# ¿ Aug 21, 2018 16:04

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Rubellavator posted:

Re: documentation

I'm currently trying to figure out how some old code works so. The code is well-commented but most of the comments are longform descriptions of the function names. I'm currently trying to figure out why the default implementation of this condition class only cares about comparing the first values of two lists. It isn't a bug cause that is literally the purpose of the class as given in the comment, but the why is missing and I am totally loving confused.

The why is so important and usually not something apparent from self-documenting code and is usually left out in comments too.

Yeah this is why I hate loving linters that bug people about comments.

Whenever some stupid rear end in a top hat puts on a linter that enforces "every method should have a comment", the codebase becomes 90%

code:

/* 
* getAbstractFactoryWaterfallInjectorVisitor<T>
* @param {string} factoryInjectorSite
* @param {boolean?} force
*/
public Observable getAbstractFactoryWaterfallInjectorVisitor(FactoryInjectorSite site,  bool defaultBehavior, Function callback ) {
   ....
}

And look what we've accomplished, a plain text text comment indicating... what the types of the function parameters are (often out-of-date). loving brilliant. (BTW the answer isn't to have the linter parse the comments and verify their accuracy, that is the epitome of useless busy work)

# ¿ Aug 28, 2018 20:44

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

BaronVonVaderham posted:

There was an argument in retro today: Devs have had nothing to do for almost a week because of an abrupt change of priority that invalidated our project and there was nothing written up about the new one we're supposed to shift to (wasn't supposed to happen for months). One dev brought this up in retro saying, "Well, we should just grab some of the infinite bugs in the backlog or that we've noticed on our own. Or start on stuff for next sprint and get ahead of the game."

There was major pushback because THE POINTS! THE POINTS WON'T BE ACCURATE! We won't "capture" that work that way!

What I heard: "But guys, you can't just do WORK without me facilitating it....otherwise why am I here?!"

Exactly

It made my realize how top-heavy we are.....we have FIVE layers of management: Team Lead, Feature Teams Manager, Scrum Masters/BAs, Engineering Manager, Technology Department Manager (/CTO). We're a bit shorthanded on devs, we were outnumbered by people whose entire job is justifying its existence (and QA sides with them, since it makes their jobs easier).

It's just gotten to such a ridiculous point now.....we're literally blocking productivity for the sake of a process that is supposedly helping increase productivity? This is insane to me. Also, once again, arbitrary 2 week sprint deadlines being eliminated would take care of 90% of the problem here since we could just constantly move on to the next thing and keep moving. We're down to like 4 actual coding days in a 2 week sprint thanks to a growing "code freeze" period (QA demand).

I've just given up, though. Whatever, gently caress it, you want to pay me to read or go take a nap, that's your choice I guess.

honestly the key to handling this scenario is to just pretend that scrum and story points don't exist. don't go to the meetings, don't go to the grooming, figure out your assignments through side channels. the only thing showing up for meetings will do is make you seem available and motivated - this is bad for your career because if you're too available, you'll end up working on stupid bullshit, and if you seem too motivated, you might end up a manager in this horrible environment. it's a religion, it dies if people stop showing up.

Bruegels Fuckbooks fucked around with this message at 17:00 on Aug 30, 2018

# ¿ Aug 30, 2018 16:57

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Bongo Bill posted:

Scrum predates agile.

scrum was invented in the mid-90's, agile manifesto was 2001. i don't think there is a real relationship between agile and scrum - the answers i've gottten on the relations between scrum/agile range from "scrum is a subset of agile" or "scrum is an implementation of agile", but these fail the sniff test as they are anachronisms. if we evaluate the goals of scrum vs. the agile manifesto, if anything, they are either opposed or unrelated (e.g. scrum is a process/tool, whereas agile values individuals and interactions.) agile is being used as a smokescreen by this scrum bullshit.

# ¿ Aug 30, 2018 23:29

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Murrah posted:

I wanted to post a really long post but thought against it.

Anyways I genuinely have really bad 'imposter syndrome' (like, as in, when you are an actual imposter ?? like when your coding skills appear to have gone backwards on the job rather than forwards? except for doing particular, in house custom 'busy work'. The isolation of working remotely has set in really bad I probably should make an appointment to talk to someone even.

i do a lot of projects using new libraries etc at work to keep myself up to date, even if the project doesn't exactly call for it. you might not be able to get away with it for every project, but it definitely makes the 9-5 go by way faster.

# ¿ Sep 1, 2018 16:21

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

smackfu posted:

The other complaint I�ve heard about just doing items in a queue is that business owners want to have a date when something will be done, so they can plan rollout and marketing around it. Saying that it will be done when it�s done doesn�t get much love.

it's rarely the coding that is the problem for me. like, in isolation, if i'm given a project with clear enough requirements that i don't have to keep asking for more information, and clear enough architectural direction, i can generally predict completion times to within a couple of weeks.

what generally screws up my estimates are:
a) incomplete requirements or knowledge of requirements
b) having multiple concurrent projects and being inappropriately context shifted
c) unforeseen/foreseen technical/architectural issue

"when it's done" for me is a slightly better way of saying "i have no idea." I will always have an issue raised and an explanation for why I can't give an estimate, but generally if a situation is completely hosed, I won't even pretend to give estimates. this is to head off people asking every single hour/day when the problem will be fixed. i am perfectly happy to give estimates on projects with solid requirements, acceptance criteria, and technical direction, in an environment without heavy context switching.

# ¿ Sep 1, 2018 17:08

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Che Delilas posted:

Yeah, if I don't know why the business wants me to build something, I'll build exactly what they ask me to build. Sounds like a good thing except what they say they want is generally not what they actually want or need.

It's not minor either. It can be on the level of, "We need you to build a machine that will shove people headfirst through this plate glass window." "...why do you want people shoved headfirst into a plate glass window?" "We need to get people into our store so they'll buy things!" "How about I build a door."

god drat i have had this conversation so many times that it's painful.

# ¿ Sep 2, 2018 15:40

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Xik posted:

Its hard to laugh at mongo (which they deserve) when that bug report is just so embarrassing.

it's funny because they actually were running coverity and you know, that mike guy in the bug report who was "born a tech writer" has a degree in computer science from princeton, so you'd think between the combination of those two things you wouldn't get a bug like that

# ¿ Sep 10, 2018 13:28

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Bongo Bill posted:

My belief is that relations are not objects, so if you're using an ORM to manage things in a way that lets you treat relations as objects, you'd better be getting some really powerful magic to make up for the pain you'll experience at the parts where things don't quite match up.

Can you give a more specific example of what you're trying to say?

# ¿ Sep 13, 2018 23:58

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

My Rhythmic Crotch posted:

The way I'd explain it is: if the ORM is writing your sql for you, what do you do when you have a performance problem? (Throw hardware at it, rather than tune or restructure!) Or requirements change and now you need to do something that probably should be done in sql, but don't know how? (Write a ton of crusty, slow application code rather than use a join!)

for performance tuning,
step 1 - does everything has the proper indexes? what's going on in the profiler?
step 2 - how many rows are being returned by the query, and how many are expected to return? Is the query really "slow" or is it just returning hundreds of megabytes of results and IO bound? Can we paginate the results (maxrows + offset)?
step 3 - is the data correctly modeled? did somebody gently caress something up with cardinality? do we need everything that is returned in the query?

orm by itself can't solve the above issues, a human being is going to have to make a judgement call there.

# ¿ Sep 14, 2018 12:53

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Ape Fist posted:

You are a hiring manager whose also a dev. You can hire one of these people:

Person 2: Is extremely good at syntactical recollection, writes clean and efficient code which compiles nicely most times through repetition, but absolutely can't grasp design structures or really any of the theory outside the 'local scope' of what he's working on.

I would never voluntarily hire a #2 but it's really difficult to know who those are before hiring them. Most of my day to day work is cleaning up after their messes.

# ¿ Sep 16, 2018 00:38

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

ultrafilter posted:

Both people are the right match somewhere. I'd hire the first one and make one of their performance goals to write cleaner code, but there are a lot of groups where the second person is a better match because they just need to churn out features as fast as possible to keep their customers happy.

Maybe just to clarify, but here's why I don't like #2s:

1. Since #2's don't know what's going on in the system, they'll re-invent the wheel. Without guidance, they'll come up with their own data access layer, own localization, own UI frameworks. If you ever wonder why you have multiple places in the system that do the same thing, it's a #2's fault (this can be mitigated with code review)

2. #2's are usually not great at debugging problems in other people's code - if they're somehow forced to use code written by teams for whatever reason rather than doing their own thing, if there's a problem with that component, instead of either debugging the component or at least engaging the original developer, they'll either get stuck, or try to work around the problem themselves (which won't fix the problem for everyone else.)

3. Sometimes, developers get tasked with developing a component that's a stupid idea - e.g. if you're developing application software, why are you writing your own identity server or SSO server? If a #2 is tasked with creating a component, that component is going to exist, and they're going to write it, god dammit, regardless of whether or not an open source MIT licensed solution exists, or whether the original project was a loving stupid idea. Sometimes the winning move is to write no code (agile/scrum on paper take care of this by breaking down requirements into user stories that have user facing requirements, which tends to mitigate these kinds of mistakes) Oftentimes #2s solve these kinds of problems by writing a bunch of code that shouldn't exist and making the system itself depend on that code that shouldn't exist in the first place.

# ¿ Sep 16, 2018 15:58

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Keetron posted:

You described 95% of the India based coders I worked or experienced.

I've worked with a lot of off-shore developers. What I've found is that Indian developers will generally be pretty gun-shy about saying "no" or confrontation in general, and this is probably a function of the conditions of their employment. I would say most of them aren't true #2s because they will take the effort to understand the system and use existing apis, but they won't say no when morons tell them to implement something stupid (they are generally paid by the hour, so it makes perfect sense.)

# ¿ Sep 16, 2018 18:17

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Ape Fist posted:

Week 4 of my new role as Front End Lead and let me tell you about my sadness.

We have 3 front end developers. Me, one other senior, and a Jr. We need another 3, at minimum. The other senior's nose is bent out of shape because I've come on board and taken over, and has basically mentally checked out. He's buried himself in a project and won't move. There are over 150 outstanding front end issues of varying complexity and severity spread across 5 projects. I've been here a month and I still don't fully understand how our horrible loving tech stack works. (ASP.NET MVC + EPISERVER) We have 2 projects which are about to start and one "starter template" which is being built which all projects thereafter will use. Additionally we've taken on stewardship of a legacy webforms project and today I had one of the architects from the project on a call telling me we needed to change a section of the front end to javascript because, and I quote, "They don't like the way the screen reloads when you click a link. Modern websites don't do that anymore so just do some javascript stuff in jQuery to sort it out." He wants an entire corner of their site rebuilt with SPA-like functionality but doesn't want us to use Angular or React because" they're too big and too much work. This shouldn't really take more than 5 days."

Jesus take the loving wheel.

looks like a job for captain iframe, defender of the lovely webapp!

# ¿ Oct 1, 2018 19:41

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

clearly my current project, which consists of copying the code off of github and checking it into tfs vc, is a winning strategy.

# ¿ Oct 22, 2018 21:07

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

TheReverend posted:

Hey!

My current job (big non technology corporation that has some software products) is undergoing restructuring.

I've been the "team lead" for a scrum team for a while now.

I'm still technically a "developer" in the HR system but they are telling me that once they sift out all the red tape I'll have myself a proper title and even more exciting, (hopefully) a bigger check.

Does anyone have any ballpark estimates for this type of salary? The usual suspects like Glassdoor didn't help much.

If it helps, I live in the southeast (USA).

christ man you're gullible. do you still believe in santa claus too?

# ¿ Oct 23, 2018 00:26

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

The Leck posted:

I think I need some reassurance that there are places that test their code outside of just poking around in the UI manually. I've been through a few employers now who gave great sounding answers to questions about their automated testing in interviews and then had zero tests in practice, at least on the stuff I've worked on. This then leads to confrontations with management about how I'm too cautious and should just take some risks, and the obvious response that with no safety net at all, I have no idea what I might be breaking outside of what I'm working on.

While automated testing is a useful practice, it's not a silver bullet. Good automated testing requires designing your product to be testable, being able to run the tests, making the tests actually test something useful, and having the tests produce useful results. Not all projects are worth the effort it would take to automate the testing. The problem is that there is enough of a bias towards automation and emphasis on it as a best practice that no one will ever say "no, we don't generally write automated tests, you can do so if you want" in an interview for fear of seeming out of touch. It sucks. I work in an environment with automated tests written by both developers and QA engineers, and it's kind of a pain in the rear end to do anything without some computer yelling at you because you're doing the right thing now as opposed to the test that formalizes the wrong way of doing something.

As for breaking poo poo - even with automated test suites, you're going to gently caress poo poo up. If there are tests already, I'll fix them up and add my new scenarios, and I'll shoot code reviews if I'm working in a component I''m not familiar with or not sure about something, but I generally prefer to break poo poo quickly without agonizing about it. I mean, if they really cared about the code, it would've had tests anyway, right?

# ¿ Nov 4, 2018 17:11

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

xiw posted:

I say 'agile is a set of techniques we can choose from to make us more effective'and what gets heard is 'agile is a set of buzzwords we can use to tell our customers we are cheaper' and they're not quite the same thing

People preaching agile made me understand dadaism.

Paul Feyerabend posted:

A Dadaist is utterly unimpressed by any serious enterprise and he smells a rat whenever people stop smiling and assume that attitude and those facial expressions which indicate that something important is to be said. A Dadaist is convinced that a worthwhile life will arise only when we start taking things lightly and when we remove from our speech the profound but putrid meanings it has accumulated over the centuries ("search for truth"; "defense of justice"; "passionate concern"; etc. etc.)

# ¿ Nov 9, 2018 14:22

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Vanadium posted:

Can someone sell me on RSpec-like testing where you don't write tests with asserts, you write specifications of behaviors and try to make everything sound like an English sentence by doing lots of method chaining? It looks really goofy and distracting to me but it's apparently what everyone does in Ruby?

ruby developers like the smell of their own farts.

# ¿ Nov 15, 2018 01:40

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Aaronicon posted:

"I don't understand why we can't just embed this Angular app in a frame inside [insert large React product]".

I mean yeah technically I could do it, but have you considered gently caress you, no I won't.

anyone who's like "oh, let's just put something complicated in an iframe" hasn't been doing web dev for very long.

# ¿ Nov 27, 2018 08:05

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Xik posted:

Or they've been doing it too long

i could write a book about things that can go wrong with putting spas in iframes. it'd go like:
chapter 1: wtf is document.domain=document.domain
chapter 2: omg something went wrong in an iframe, how do i get the breakpoint to hit?
chapter 3: onbeforeunload doesn't fire in an iframe, what do I do
chapter 4: trying to figure out when the iframe is loaded
chapter 5: handling localstorage events in iframes
chapter 6: oh gently caress which frame is the code in my event handler running
chapter 7: it's loving webdev just put everything in a try catch.
chapter 8: don't embed pdfs and videos using iframes, use embed/video tags you stupid motherfuckers
etc.

# ¿ Nov 27, 2018 09:05

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

LLSix posted:

My current employer puts everything in "popups" that are just an iframe inside a div.

I spend more time fighting bugs that must have existed since they started doing this 15 years ago than I do on anything else. My current headache is that querySelectAll run on the parent dom doesn't appear to search inside iframes.

i've seen crazy bullshit like people trying to make context menus and dropdowns using iframes (if you hear the term "iframe mask" from a developer, you should take away commit privileges).

# ¿ Nov 30, 2018 19:58

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Captain Cappy posted:

I've asserted dominance at every job I've had by never showing up to status meetings.

i have a scrum at 9 am every day. I used to optimize for getting to work roughly on time over calling into the meeting, but it turned out that going "yesterday I worked on this bug, today I'll work on that bug" over the phone and showing up to the office at 10:30 is more desirable than physically showing up to the office at 9:05 but not going to the meeting.

# ¿ Dec 14, 2018 14:39

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Good Soldier Svejk posted:

I had a (supposedly) senior dev on my team tell me today to just fix up his pull request because its "wasting too much [his] time" to figure it out.
I've spent the last few days walking him through a ticket that would've maybe taken an hour or two for me to write in spite of the fact that I am the dev lead for three teams and spend most of my time in meetings and basically with a mandate to not write critical path code.
I don't understand how developers can have this attitude and thrive in the professional world.

have you tried abuse in situations like these? i never run into these problems anymore but it's amazing what dropping a "are you loving stupid" while being otherwise professional can do.

# ¿ Dec 18, 2018 01:39

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Good Soldier Svejk posted:

I definitely don't solely blame him because no one makes it that far in a career without being enabled by some spineless folks along the way but the question is how much I can dress him down without him going to his leadership (he's a sub-contractor)

i've fired dozens of contractors for less egregious offenses than what you're putting up with.

# ¿ Dec 19, 2018 00:26

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Keetron posted:

Indians don't celebrate Christmas. Why India? Because it caused a fuckup.

if I had a nickel for every time offshore was like "yeah, we're taking friday off" because of some random indian holiday, I'd get an additional buck a year. they also take our holidays off as well at my company and i think stuff like this is probably why.

# ¿ Dec 28, 2018 19:21

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

SAFe is like chickenpox but for engineering divisions. One day you'll be in ordinary useless scrummerfall, the next day your inbox is full of diagrams like the ones posted in the thread and your calendar gets booked full of training conducted by consulting companies. Usually clears up in about three months or so, except you'll have a bunch of meetings named after SAFe buzzwords.

# ¿ Jan 17, 2019 00:51

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Rocko Bonaparte posted:

So what you're saying is I should go see my doctor if SAFe persists for longer than three months, right?

much like other kinds of herpes, SAFe is a lifetime infection, with flare-ups and remissions. alcohol can help deal with the pain.

# ¿ Jan 18, 2019 02:07

Adbot: ADBOT LOVES YOU

# ¿ May 12, 2024 00:54

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Subjunctive posted:

How many times do you get to bypass the hooks before you�re fired?

i think if you're motivated enough to continually try to bypass the hooks, you automatically get certified as a scrum master. we should make it so you skip gated checkin, it automatically buys you one of those certificates in the person's name.

# ¿ Feb 2, 2019 20:08

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

«‹›5 »