After listening to two of our senior devs play ping pong with a new member of our team for TWO DAYS!
DevA: "Try this.."
Junior: "Didn't work"
DevB: "Try that .."
Junior: "Still not working"

I ask..
Me:"What is the problem?"
Few ums...uhs..awkward seconds of silence

Junior: "App is really slow. Takes several seconds to launch and searching either crashes or takes a really long time."
DevA: "We've isolated the issue with Entity Framework. That application was written back when we used VS2010. Since that application isn't used very often, no one has had to update it since."
DevB: "Weird part is the app takes up over 3 gigs of ram. Its obviously a caching issue. We might have to open up a ticket with Microsoft."
Me: "Or remove EF and use ADO."
DevB: "That would be way too much work. The app is supposed to be fully deprecated and replaced this year."
Me: "Three of you for the past two days seems like a lot of work. If EF is the problem, you remove EF."
DevA: "The solution is way too complicated for that. There are 5 projects and 3 of those have circular dependencies. Its a mess."
DevB: "No fracking kidding...if it were written correctly the first time. There aren't even any fracking tests."
Me:"Pretty sure there are only two tables involved, maybe 3 stored procedures. A simple CRUD app like this should be fairly straight forward."
DevB: "Can't re-write the application, company won't allow it. A redesign of this magnitute could take months. If we can't fix the LINQ query, we'll going to have the DBAs change the structures to make the application faster. I don't see any other way."

Holy frack...he didn't just say that.

Over my lunch hour, I strip down the WPF application to the basics (too much to write about, but the included projects only had one or two files), and created an integration test for refactoring the data access to use ADO. After all the tests and EF removed, the app starts up instantly and searches are also instant. Didn't click through all the UI, but the basics worked.

Sat with Junior, pointed out my changes (the 'why' behind the 'what') ...and he how he could write unit tests around the ViewModel behavior in the UI (and making any changes to the data access as needed).

Today's standup:
Junior: "Employee app is fixed. Had some help removing Entity Framework and how it starts up fast and and searches are instant. Going to write unit tests today to verify the UI behaivor. I'll be able to deploy the application tomorrow."
DevA: "What?! No way! You did all that yesterday?"
Me: "I removed the Entity Framework over my lunch hour. Like I said, its basic CRUD and mostly in stored procedures. All the data points are covered by integration tests, but didn't have time for the unit tests. It's likely I broke some UI behavior, but the unit tests should catch those."
DevB: "I was going to do that today. I knew taking out Entity Framework wouldn't be a big deal."

Holy fracking frack. You fracking lying SOB. Deeeep breath...ahhh...thanks devRant. Flame thrower event diverted.

I worked on a greenfield project a couple of years ago. The company had an old solution written in Omnis (heard of it? Yeah, me neither) with an SQL database. My team was to create a completely new web based system... on top of the old database, so the customers could keep their existing stuff.

The dba was an intelligent man, one of the nicest people I've met, and over the course of fifteen years he had made a remarkably terrifying monstrosity of a database. Some years before me they wanted to "future proof" the system and make it "easier to switch to new technologies". So they moved the entire business logic into the database...

I used a tool to create a visualization of said database when we started. It had no views, only tables and sprocs. Look at it! Tables and sprocs are rectangles (well, dots) and any connections are drawn in grey lines. There were no foreign keys, so a tables only visualization only yielded a collection of independent rectangles without a single line.

Now, the stored procedures were bloody MASSIVE. A single procedure that only registered a new interested party and attached them to a property had 2500+ lines and over 150 parameters.

Also, this dba added features and fixed bugs by logging into the respective customers production server and writing SQL.

That database is the stupidest thing I've ever seen a developer do.

In a user-interface design meeting over a regulatory compliance implementation:
User: “We’ll need to input a city.”
Dev: “Should we validate that city against the state, zip code, and country?”
User: “You are going to make me enter all that data? Ugh…then make it a drop-down. I select the city and the state, zip code auto-fill. I don’t want to make a mistake typing any of that data in.”
Me: “I don’t think a drop-down of every city in the US is feasible.”
Manage: “Why? There cannot be that many. Drop-down is fine. What about the button? We have a few icons to choose from…”
Me: “Uh..yea…there are thousands of cities in the US. Way too much data to for anyone to realistically scroll through”
Dev: “They won’t have to scroll, I’ll filter the list when they start typing.”
Me: “That’s not really the issue and if they are typing the city anyway, just let them type it in.”
User: “What if I mistype Ch1cago? We could inadvertently be out of compliance. The system should never open the company up for federal lawsuits”
Me: “If we’re hiring individuals responsible for legal compliance who can’t spell Chicago, we should be sued by the federal government. We should validate the data the best we can, but it is ultimately your department’s responsibility for data accuracy.”
Manager: “Now now…it’s all our responsibility. What is wrong with a few thousand item drop-down?”
Me: “Um, memory, network bandwidth, database storage, who maintains this list of cities? A lot of time and resources could be saved by simply paying attention.”
Manager: “Memory? Well, memory is cheap. If the workstation needs more memory, we’ll add more”
Dev: “Creating a drop-down is easy and selecting thousands of rows from the database should be fast enough. If the selection is slow, I’ll put it in a thread.”
DBA: “Table won’t be that big and won’t take up much disk space. We’ll need to setup stored procedures, and data import jobs from somewhere to maintain the data. New cities, name changes, ect. ”
Manager: “And if the network starts becoming too slow, we’ll have the Networking dept. open up the valves.”
Me: “Am I the only one seeing all the moving parts we’re introducing just to keep someone from misspelling ‘Chicago’? I’ll admit I’m wrong or maybe I’m not looking at the problem correctly. The point of redesigning the compliance system is to make it simpler, not more complex.”
Manager: “I’m missing the point to why we’re still talking about this. Decision has been made. Drop-down of all cities in the US. Moving on to the button’s icon ..”
Me: “Where is the list of cities going to come from?”
<few seconds of silence>
Dev: “Post office I guess.”
Me: “You guess?…OK…Who is going to manage this list of cities? The manager responsible for regulations?”
User: “Thousands of cities? Oh no …no one is our area has time for that. The system should do it”
Me: “OK, the system. That falls on the DBA. Are you going to be responsible for keeping the data accurate? What is going to audit the cities to make sure the names are properly named and associated with the correct state?”
DBA: “Uh..I don’t know…um…I can set up a job to run every night”
Me: “A job to do what? Validate the data against what?”
Manager: “Do you have a point? No one said it would be easy and all of those details can be answered later.”
Me: “Almost done, and this should be easy. How many cities do we currently have to maintain compliance?”
User: “Maybe 4 or 5. Not many. Regulations are mostly on a state level.”
Me: “When was the last time we created a new city compliance?”
User: “Maybe, 8 years ago. It was before I started.”
Me: “So we’re creating all this complexity for data that, realistically, probably won’t ever change?”
User: “Oh crap, you’re right. What the hell was I thinking…Scratch the drop-down idea. I doubt we’re have a new city regulation anytime soon and how hard is it to type in a city?”
Manager: “OK, are we done wasting everyone’s time on this? No drop-down of cities...next …Let’s get back to the button’s icon …”

Simplicity 1, complexity 0.

Attended one of the best meetups ever. To give you an idea how awesome it was..

Speaker took the first ~20 minutes introducing himself.
His intro card deck kept referring to himself in the third person (he is the only employee in consulting 'company'). Ex. "Mr. Smith began his humble career .."

The powerpoint presentation began with him clicking each page, not executing the slideshow (ex. pressing F5).
Finally someone asked "Can you make slide bigger?"

S:"You can't read that?..um..sure...I guess .."
Starts fumbling around the zoom ...
Dev: "No, can you start the slideshow?"
S: "I don't know what you mean...there...I zoomed it, is that better? Now I can't see my notes..just sec.."
<fumbles again with the zoom>
Dev: "No, not zoom, start the slide show, press F5"
S: "Oh...you want me to F5 it...OK..."
<he *clicks* the slide show button>

Finally getting into code, trying to get out of powerpoint ...
S: "How do I get out of this fullscreen?.."
Dev: "Hit escape"
S:"No..um.."
<keeps trying to click on 'something'>
S:"I see visual studio, but its not on the big screen... "
<keeps click on 'something', no one is sure whats going on>
Dev: "Hit Escape to stop the slideshow"
<finally hits escape, then able to put Visual Studio on the big screen>
S: "Ahh...there, I figured it out."

Speaker had no end of making wild/random statements like:
".Net Core is the future of Microsoft, if you're using .Net 4.5...forget it, its not even supported anymore."
"When I was at Microsoft Build, I asked them why not put all the required .Net assemblies in one directory. Looks like with .Net Core, they listened to me" (he was serious)
"I don't use SQL Server Mgmt Studio. Its free and it sucks. I use <insert a very expensive SSMS clone>, its great, you guys should check it out", then proceeds to struggle to open a query window to write some SQL.
"When you use .Net Core and EntityFramework, you have to write your own stored procedures. If a developer can't write stored procedures, he shouldn't be in this business."

I was on the edge of my seat, hungry for the next crazy bat-shit thing to come out of his mouth. He did not disappoint. BEST MEETUP EVER!

Business logic in the fricking database.

1000+ line SQL stored procedures.

What the actual fuck?! 👿

#2 Worst thing I've seen a co-worker do?

Back before we utilized stored procedures (and had an official/credentialed DBA), we used embedded/in-line SQL to fetch data from the database.

var sql = @"Select
FieldsToSelect
From
dbo.Whatever
Where
Id = @ID"

In attempts to fix database performance issues, a developer, T, started putting all the SQL on one line of code (some sql was formatted on 10+ lines to make it readable and easily copy+paste-able with SSMS)
var sql = "Select ... From...Where...etc";

His justification was putting all the SQL on one line make the code run faster.
T: "Fewer lines of code runs faster, everyone knows that."

Mgmt bought it.

This process took him a few months to complete.

When none of the effort proved to increase performance, T blamed the in-house developed ORM we were using (I wrote it, it was a simple wrapper around ADO.Net with extension methods for creating/setting parameters)

T: "Adding extra layers causes performance problems, everyone knows that."

Mgmt bought it again.

Removing the ORM, again took several months to complete.

By this time, we hired a real DBA and his focus was removing all the in-line SQL to use stored procedures, creating optimization plans, etc (stuff a real DBA does).

In the planning meetings (I was not apart of), T was selected to lead because of his coding optimization skills.
DBA: "I've been reviewing the execution plans, are all the SQL code on one line? What a mess. That has to be worst thing I ever saw."
T: "Yes, the previous developer, PaperTrail, is incompetent. If the code was written correctly the first time using stored procedures, or even formatted so people could read it, we wouldn't have all these performance problems."

DBA didn't know me (yet) and I didn't know about T's shenanigans (aka = lies) until nearly all the database perf issues were resolved and T received a recognition award for all his hard work (which also equaled a nice raise).

What is it with clients who have never even seen a single line of code in their entire lives telling me how long they believe a certain change request should take to code.

I mean, what if I told you that your "seemingly simple enough" change needed an update to 36 class files, 9 oracle stored procedures AND several database schema changes. Also, who the fuck is going to perform a regression test to make sure I didn't break anything? Your Uncle Bob??

Guy I work with: Hey can I borrow you for a minute

Me: sure. What do you need?

Him: so this is a project me an the other dev worked on

Me thinking: Well I know he did it all and sent you the project so don't tell me you worked on it

Him: so we use it to do this and this and send an email to this new account I made because (2 minute explanation)

Me thinking: I don't care. Just tell me what your issue is! I already know what it is and does from what you told me the last time when you showed me. Which took an hour of my time.

Him: so he sent me this code which is called <Descriptive name> and in the method we have variables call <descriptive name> and it returns a <variable name>

Me thinking: You mother fucker! I don't give a shit what your method is named, what it the variable names are, and you don't need to read through every line of code to me! Just from the descriptive name you just said I know what it does! What the fuck is your issue!?

Him: we also have these other methods. This one is called <Descriptive name> which does...

Me: are you fucking seriously going to read me your code line by line and tell me what you named your variables AGAIN!?

Him: and we named this one <descriptive name>

Me: you mother fucker...

Him: and it calls this stored procedure. (Literally opens the stored procedure and shows me) and it is called...which has parameters called... And it is a select query that inserts

45 minutes later after he finishes explaining all 3 pages of his code and his 5 stored procedures that the other dev wrote...

Him: So anyway, back to this method. I need to know where to put this method. The other dev said to put it in this file, but where do you think I should put it in here? Should I place it after this last one or before it?

Me thinking: You fucking wasted my fucking time just to ask where to place your mother fucking method that the other dev sent to you in a project with only 3 files, all less than 500 lines of code with comments and regions that actually tell you what you should put there and 5 small stored procedures that were not even relevant to your issue! Why the fuck did you need to treat me as a rubber ducky which would fly away if you did have one because you didn't have an issue, you just didn't know where to put your fucking code! FUCK YOUR METHOD!

Me: Where ever you want

Him: Well I think it won't work if I placed it before this method.

I walked away after that. What a waste of time and an insult to my skills and really unchallenging. He's been coding for years and still can't understand anything code related. I'm tired if helping him. Every time he needs something he always has to read through and explain his shit just to ask me things like this. One time he asked me what to name his variable and another his project. More recently he asked why he couldn't get his project he found online to work. The error clearly stated he needed to use c# 7. His initial solution was to change his sql connection string. 😑

He should just go back to setting up computers and fixing printers. At least then he would never be in the office to bug me or the other dev with things like this.

One step through the door my wife whips around, a look so disgusted she barely seems human. "What's that smell?" she cries. "It's you! You smell like...like bad code!"

Indeed, I am covered with the scent of the forbidden love child of a man who read half a chapter on if-then statements and then pushed out into the world, earthworm-like, a mangled misshapened gelatinous mass that my employer gave the title of line-of-business application purely out of pity.

For more days than I'd like to count I have been porting a ColdFusion 5 application to .NET. Initially written in 2000 and last touched in 2006, it has a data architecture comparable to Dresden after the second world war. It features a table solely comprised of seven columns of IDs so that joins can be made between other tables lacking a common key. Columns that should be contained within a single table spread out among multiple tables. Single columns containing data that should be multiple columns (with handy flags to separate the subsets). A view with 14 joins that playfully displays unintended results. And so much more spread out over almost 200 stored procedures, views, triggers, and tables on the SQL server, and dozens of additional ADO-like SQL statements within the ColdFusion itself. Fortunately, the application overcomes these issues by having absolutely no data validation while allowing nulls pretty much everywhere.

When I am done this will be a very nice ASP.NET MVC app with at least 150 less stored procs, views, and tables. Auto-generated duplicate entries will be a thing of the past. Pop-up windows that inexplicably refresh the underlying screen to display a different part of the program than the one the user wants will be eliminated. And a UI based on the colors of a Rubik's Cube with usability that Mr. Rubik would find challenging will disappear with only the trauma of using it left behind.

Sadly, this is not my worse legacy code experience. Just the most recent. Just the most recent stench added to a lifetime of bathing in code rot.

So a consulting company was hired to write stored procedures for us. I don't know where they found these guys, but the code was horrible and took ages to run.

We other devs weren't happy at all, but management forbade us to rewrite the code, cause the consultants would've gotten money for nothing then. As a "fix", these guys just reduced batch sizes to a very low amount of rows and management was happy that the procedures were so much faster now and gave their ok.

Fast forward a few weeks (to now). Obviously a reduced batch size means the procedures will run faster, but more often and it will take weeks to load all the data we need.

Result: Management ordered us to rewrite the SPs and we're all torn between laughing and crying.

Old story.

Colleague: "I'm gonna update some tables and stored procedures later"

*phone rings two hours later*

Colleague: "Hi! Just wanted to tell you I accidently dropped all our production databases. Have fun recovering them 😊"

Well shit.

I'm coming off a lengthy staff augmentation assignment awful enough that I feel like I need to be rehabilitated to convince myself that I even want to be a software developer.

They needed someone who does .NET. It turns out what they meant was someone to copy and paste massive amounts of code that their EA calls a "framework." Just copy and paste this entire repo, make a whole ton of tweaks that for whatever reason never make their way back into the "template," and then make a few edits for some specific functionality. And then repeat. And repeat. Over a dozen times.

The code is unbelievable. Everything is stacked into giant classes that inherit from each other. There's no dependency inversion. The classes have default constructors with a comment "for unit testing" and then the "real" code uses a different one.

It's full of projects, classes, and methods with weird names that don't do anything. The class and method names sound like they mean something but don't. So after a dozen times I tried to refactor, and the EA threw a hissy fit. Deleting dead code, reducing three levels of inheritance to a simple class, and renaming stuff to indicate what it does are all violations of "standards." I had to go back to the template and start over.

This guy actually recorded a video of himself giving developers instructions on how to copy and paste his awful code.

Then he randomly invents new "standards." A class that reads messages from a queue and processes them shouldn't process them anymore. It should read them and put them in another queue, and then we add more complication by reading from that queue. The reason? We might want to use the original queue for something else one day. I'm pretty sure rewriting working code to meet requirements no one has is as close as you can get to the opposite of Agile.

I fixed some major bugs during my refactor, and missed one the second time after I started over. So stuff actually broke in production because I took points off the board and "fixed" what worked to add back in dead code, variables that aren't used, etc.

In the process, I asked the EA how he wanted me to do this stuff, because I know that he makes up "standards" on the fly and whatever I do may or may not be what he was imagining. We had a tight deadline and I didn't really have time to guess, read his mind, get it wrong, and start over. So we scheduled an hour for him to show me what he wanted.

He said it would take fifteen minutes. He used the first fifteen insisting that he would not explain what he wanted, and besides he didn't remember how all of the code he wrote worked anyway so I would just have to spend more time studying his masterpiece and stepping through it in the debugger.

Being accountable to my team, I insisted that we needed to spend the scheduled hour on him actually explaining what he wanted. He started yelling and hung up. I had to explain to management that I could figure out how to make his "framework" work, but it would take longer and there was no guarantee that when it was done it would magically converge on whatever he was imagining. We totally blew that deadline.

When the .NET work was done, I got sucked into another part of the same project where they were writing massive 500 line SQL stored procedures that no one could understand. They would write a dozen before sending any to QA, then find out that there was a scenario or two not accounted for, and rewrite them all. And repeat. And repeat. Eventually it consisted of, one again, copying and pasting existing procedures into new ones.

At one point one dev asked me to help him test his procedure. I said sure, tell me the scenarios for which I needed to test. He didn't know. My question was the equivalent of asking, "Tell me what you think your code does," and he couldn't answer it. If the guy who wrote it doesn't know what it does right after he wrote it and you certainly can't tell by reading it, and there's dozens of these procedures, all the same but slightly different, how is anyone ever going to read them in a month or a year? What happens when someone needs to change them? What happens when someone finds another defect, and there are going to be a ton of them?

It's a nightmare. Why interview me with all sorts of questions about my dev skills if the plan is to have me copy and paste stuff and carefully avoid applying anything that I know?

The people are all nice except for their evil XEB (Xenophobe Expert Beginner) EA who has no business writing a line of code, ever, and certainly shouldn't be reviewing it.

I've tried to keep my sanity by answering stackoverflow questions once in a while and sometimes turning evil things I was forced to do into constructive blog posts to which I cannot link to preserve my anonymity. I feel like I've taken a six-month detour from software development to shovel crap. Never again. Lesson learned. Next time they're not interviewing me. I'm interviewing them. I'm a professional.

Three months into a new job, as a senior developer (12+ years experience) and updated an import application.

With one small update query that didn't account for a possible NULL value for a parameter, so it updated all 65 million records instead of the 15 that belonged to that user.

Took 3 people and 4 days to put all the data back to it's original state.

Went right back to using the old version of the apllication, still running 2 years later. It's spaghetti code from hell with sql jobs and multiple stored procedures creating dynamic SQL, but I'm never touching it again.

Today I come across something interresting in SQL Server.

I was optimizing a report query and in the SSMS windows runned in 10 seconds for 3000 rows.

Put it to a stored procedure took me 5 minutes for getting 100 rows.

I was like WTF?

After some research I found out that the problem was that I was using the Stored Procedure parameters in the query.

Created local variables for the parameters and poof... 10 seconds again.

So if you are creating Stored Procedures in SQL Server DO NOT USE THE PARAMETERS FROM THE PROCEDURE. CREATE LOCAL VARIABLES.

Employee: we have 15 years of Stored Procedures

Boss: just because we been doing it for 15 years doesn’t mean we should continue.

Boss coming in clutch.

Today is my birthday and my company as a present will make me work on disgusting legacy code, stored procedures, impossible to debug and convoluted as fuck.
And everything needs to be released yesterday...
Happy birthday motherfucker.

How do you deal with massively poorly-performing and unknowledgeable teams?

For background, I've been in my current position for ~7 months now.

A new manager joined recently and he's just floored at the reality of the team.

I mean, a large portion of my interview (and his) was the existing manager explicitly warning about how much of a dumpster fire everything is.

But still, nothing prepares you for it.

We're talking things like:
- Sequential integer user ids that are passable as query string args to anonymous endpoints, thus enabling you to view the data read by that view *for any* user.
- God-like lookup tables that all manner of pieces of data are shoved into as a catch-all
- A continued focus on unnecessary stored procedures despite us being a Linq shop
- Complete lack of awareness of SOLID principles
- Actual FUD around the simplest of things like interfaces, inversion of control, dependency injection (and the list goes on).

I've been elevated into this sort of quasi-senior position (in all but title - and salary), and I find myself having to navigate a daily struggle of trying to not have an absolute shit fit every time I have to dive into the depths of some of the code.

Compounded onto that is the knowledge that most of the team are on comparable salaries (within a couple thousand) of mine, purely owing to length of service.

We're talking salaries for mid-senior level devs, for people that at market rates would command no more (if even close) than a junior rate.

The problem is that I'm aware of how bad things are, but then somehow I'm constantly surprised and confronted with ever more insane levels of shitfuckery, and... I'm getting tired.

It's been 7 months, I love the job, I'm working in the charity sector and I love the fact that the things I'm working on are directly improving people's lives, rather than lining some fintech fatcat's pockets.

I guess this was more a rant than a question, and also long time no see...

So my question is this:

- How do you deal with this?
- How do you go on without just dying inside every single day?

Should have kept a copy of my best code off of my work computer. That way it wouldn't have been confiscated along with the computer during the layoffs. [sniff] I had some beautiful Stored Procedures I can't satisfactorily remember how to reproduce. 😅

How many of you have started a job and ended up doing something totally different, and how did deal with it?

I was hired to be an SQL Developer, writing reports, views, stored procedures etc, but knew I would be asked to do some work on some internal c# apps.

Roll on almost 2 years and I'm pretty much a DBA in all but name, and the C# app I was supposed to be doing a little work on is now mine, so as well as being the sole programmer, I'm also the product owner, 1st, 2nd, and 3rd line support.

All of this and I've not even had a change in title, let alone a pay rise that reflect the new roles and responsibilities I've taken on.

When they want you to make stored procedures instead of an API... And there's no DBA.

Team Leader(TL): So you finished the sql scripts and stored procedures?
Me: Yep!
TL: And properly formatting the front end to look exactly how we want it.
Me: Yep
TL: Well we waiting on feedback from the boss so i guess you'll have to do the documentation.
Me: I hate documentation, please give me anything else
TL: It's not a lot dude, you can do it.
Me: Didn't one of the intern's and the database admin do it already?
TL: Yes. but you can take both of them and make one complete one.
Me: *You just don't want me to work on my own things you FUCKER* Fine, but don't expect it to be done this week.
TL: It's Tuesday, why not.
Me: Because i hate dcumentation

I FUCKEN. hate! documentation.

We've got a big legacy app which we have to rewrite. The current client applications are only working on XP(!). We have to move the clients to the browser so we can finally get rid of all XP vm-s. The db schema is complex but still 1000+ stored procedures and functions and about a hundred tables with 13 years of data.
So I ask the guy responsible for maintaining the DB code. (he is ~25 years older than me)

me - Where is the source of the database. Which project?
he - Where would it be? It's in the db.
me - So we've got a huge db without VCS, upgrade/downgrade scripts, etc?
he - Yes. I don't get why young developers always want to use shiny new tech like git just because it is cool. It has nothing that an external usb backup drive can't do.
me - VCS has been around since the early 1980's...
he - If you really want, you can put it under git or whatever, so you can sleep better, but I still think it is stupid and a waste of time.

I get that it's hard to keep up, but getting personal...

Day 1 of migrating the entire companies infrastructure to GCE...

Thought It wouldn't be too difficult migrating the db until I found out the 480 triggers and 42 stored procedures are a no go.

I mean I know they right and the db layer should be about storage only - I even remember thinking "This is a bad idea" when I wrote most of them but fuuuck it's going to take weeks to refactor this. :'(

I think I may be someone's wk101soon given how things are going for me.

So I get shipped over to the new offices to do some work. Initially, I was supposed to be updating SQL stored procedures.

That I can handle, well my task is now to build the skeleton project for a web API in core 2.0 using domain driven design and onion architecture which the rest of the team will use.

Okay, I don't have any experience in any of that at all. And god bless the team lead explaining some stuff to me. But it's going to take more than a 20-minute chat here and there for this stuff to sink in.

And being told just to build it how you think it should be isn't great advice when I'm trying to figure out how the systems work.

Every other API project I look at is structured completely different from one another so looking for patterns has failed.

I'm fucking stressed out every bit of information I'm getting on whats potentially happening with my job im getting second hand from people. Because I can't access my emails while off-site something I'm repeatedly flagging.

Every job advert is painstakingly making it clear how out of date my skill set is (or lack of). Evidently, I've been way too lax, and this has been a kick in the bollocks I'm not likely to forget.

If we're being evaluated on performance to see who they'll keep, then I've failed at the first hurdle.

Life lesson for those in education, don't be this knob head here and get comfortable when you land a job. Just knowing about the tech that's commonly used in your field does jack all study it.

Not a structured/meaningful rant and shits probably not as bad as I see it. I've only chewed through one fingernail after all.

Honestly, who could have thought at some point of his life that having all the business logic on the database with 20k stored procedures was a good idea?

When your PM wants you to write Stored Procedures to interface with a data model that hasn't been implemented because "We're agile"😑

What's your thoughts on stored procedures(of DBs)?
What are the pros and the cost you found or perceived?
When they are opportune?
Overusing them more than a programming language is an abuse?

I was introduced to a software started initially by economy\finance people which knew a little bit programming, nonetheless their doing became messy though time and at a certain point hired a team of 4 people(from my company) to deal with it, but the approach of the two programmers to build most of the framework on calling stored procedures or queries makes me want to puke, there are almost no layers of separation of concern in place x_x

I'm searching good resource for learning more about stored procedures in SQL. Know any?

fucking VS2017,

It takes like 1 minute to refresh stored procedures in the server explorer, It is so annoying especially if you need to constantly add new stored procedures.

and dont get me start on DBML at least once a week that shit fucking decided to crash VS2017.

Maybe I need to download more ram 🤔🤔🤔

Learnt a lesson today:

Never try out new hotkeys in a SQL query editor window.

Or if you do, at least make sure it's not connected to anything important :)

I was trying out new hotkeys and accidentally executed a SQL deploy script to rename something in multiple stored procedures in a large system.

Thankfully - so I saw after my heart stopped - it was only our QA db so not too bad, just a couple of devs set back.

Who woulda thought ctrl-l would execute :O

The manager that believed that sharing code was bad. We had a web and a windows client over the same db. No code shared. He'd rather duplicate the code and maintenance than share it. And the BL should be put in stored procedures, 'cause that's so easy to change in-flight...

YGGG IM SO CLOSE I CAN ALMOST TASTE IT.

Register allocation pretty much done: you can still juggle registers manually if you want, but you don't have to -- declaring a variable and using it as operand instead of a register is implicitly telling the compiler to handle it for you.

Whats more, spilling to stack is done automatically, keeping track of whether a value is or isnt required so its only done when absolutely necessary. And variables are handled differently depending on wheter they are input, output, or both, so we can eliminate making redundant copies in some cases.

Its a thing of beauty, defenestrating the difficult aspects of assembly, while still writting pure assembly... well, for the most part. There's some C-like sugar that's just too convenient for me not to include.

(x,y)=*F arg0,argN. This piece of shit is the distillation of my very profound meditations on fuckerous thoughtlessness, so let me break it down:

- (x,y)=; fuck you in the ass I can return as many values as I want. You dont need the parens if theres only a single return.
- *F args; some may have thought I was dereferencing a pointer but Im calling F and passing it arguments; the asterisk indicates I want to jump to a symbol rather than read its address or the value stored at it.

To the virtual machine, this is three instructions:

- bind x,y; overwrite these values with Fs output.
- pass arg0,argN; setup the damn parameters.
- call F; you know this one, so perform the deed.

Everything else is generated; these are macro-instructions with some logic attached to them, and theres a step in the compilation dedicated to walking the stupid program for the seventh fucking time that handles the expansion and optimization.

So whats left? Ah shit, classes. Disinfect and open wide mother fucker we're doing OOP without a condom.

Now, obviously, we have to sanitize a lot of what OOP stands for. In general, you can consider every textbook shit, so much so that wiping your ass with their pages would defeat the point of wiping your ass.

Lets say, for simplicity, that every program is a data transform (see: computation) broken down into a multitude of classes that represent the layout and quantity of memory required at different steps, plus the operations performed on said memory.

That is most if not all of the paradigm's merit right there. Everything else that I thought to have found use for was in the end nothing but deranged ways of deriving one thing from another. Telling you I want the size of this worth of space is such an act, and is indeed useful; telling you I want to utilize this as base for that when this itself cannot be directly used is theoretically a poorly worded and overly verbose bitch slap.

Plainly, fucktoys and abstract classes are a mistake, autocorrect these fucking misspelled testicle sax.

None of the remaining deeper lore, or rather sleazy fanfiction, that forms the larger cannon of object oriented as taught by my colleagues makes sufficient sense at this level for me to even consider dumping a steaming fat shit down it's execrable throat, and so I will spare you bearing witness to the inevitable forced coprophagia.

This is what we're left with: structures and procedures. Easy as gobblin pie.

Any F taking pointer-to-struc as it's first argument that is declared within the same namespace can be fetched by an instance of the structure in question. The sugar: x ->* F arg0,argN

Where ->* stands for failed abortion. No, the arrow by itself means fetch me a symbol; the asterisk wants to jump there. So fetch and do. We make it work for all symbols just to be dicks about it.

Anyway, invoking anything like this passes the caller to the callee. If you use the name of the struc rather than a pointer, you get it as a string. Because fuck you, I like Perl.

What else is there to discuss? My mind seems blank, but it is truly blank.

Allocating multitudes of structures, with same or different types, should be done in one go whenever possible. I know I want to do this, and I know whichever way we settle for has to be intuitive, else this entire project has failed.

So my version of new always takes an argument, dont you just love slurping diarrhea. If zero it means call malloc for this one, else it's an address where this instance is to be stored.

What's the big idea? Only the topmost instance in any given hierarchy will trigger an allocation. My compiler could easily perform this analysis because I am unemployed.

So where do you want it on the stack on the heap yyou want to reutilize any piece of ass, where buttocks stands for some adequately sized space in memory -- entirely within the realm of possibility. Furthermore, evicting shit you don't need and replacing it with something else.

Let me tell you, I will give your every object an allocator if you give the chance. I will -- nevermind. This is not for your orifices, porridges, oranges, morpheousness.

Walruses.

The first company I ever worked for thought it was a good idea to have all business logic in stored procedures "for speed".

It worked. Except when you need to add BC breaking features.

The solution? Keep the legacy code in file do_something.sql and add the new functionality in do_something_1.sql.

It became a sordid game trying to find the highest postfix. My record was 16.

Filtering stored procedures by name in SQL Management Studio. Enter name and press enter. Cursor goes to next cell, instead of submitting.

I do this every single time.

I need advice fellow developers, am I stubborn?

So I lost an argument in my team regarding constant vs variable directly in a method for stored procedure names.

I separated names of procedures into their own StoredProcedureConstants file because it makes it very easy to see all procedures used in a project and refactor their names if necessary. Argument against was that you loose time creating a constant. Am I silly if I am alergic to seeing quotation marks stuff without its designated purpose throughout the code?
Their way is adding var procedureName = "cc.storeProcedureName" directly in a method. I just can't find my peace with it. To me this is a magic string.

Am I being unreasonable?

I could use some advice from some tenured developers... (or anyone with some thoughts)

Long story short, I went to school for business (Trust me... business people bug me too now), but in the last six months of college I didn’t like what I was doing (finance/marketing) so I dove into data analytics.

After graduating I was lucky enough to get a job at a great company doing a little data architecture work, writing lots of SQL stored procedures, managing client databases, cubes, etc... I really enjoy my work, but I recently discovered... Python...

After being introduced to Python from people at work as well as my Roomate, I’ve been trying to dig in as much as possible. I try to read/code at least an hour before work everyday and some when I get home. I love it.

So here’s where I need advice...

What do I need to do/learn to get a job writing Python all day? (Or a majority of my day)

What particular skills may I be missing that I should learn?

What do I need to do to make this happen?! (I love SQL, but damn python is amazing)

Just made a damn fool of myself with a client. I handed off three projects and they had no idea what they were for and neither did I. My boss gave me these months ago. No code comments, no documentation, just some stored procedures they wanted me to actualize.

The best I could offer was to promise the client I would send a description of the projects to them as soon as my boss gets them to me. Fuck. I thought the client would know what they asked for when I showed them, but fuck me, they didn't remember. So embarrassing. 😡😡😡

Not a fan of legacy products which make use of a tonne of TSQL stored procedures, especially when they include a mess of logic, spelling errors, no version control of course, all squirreled away for some unlucky person to find and unpick in years to come.

LINQ queries or stored procedures? I prefer LINQ.
My boss says, if we are using LINQ we must be lazy and stupid.
What do you'll think?

I feel like we we not only 'advanced' various fields by pulling people off some lord of the flies island who only wanted to dance around with a severed pig head in reality and training them, but also depleted and destroyed many essential fields by removing all valid motivators from our environment by spreading so much cynicism and unguided lust for power over others in the absence of any of the unifying beliefs of former generations that the professions are going to implode in the years to come.

so I wasn't very experienced when i went to work some place years back. I'd worked on my own. and I was criticized by their 80k per year team lead as having 'only done some simple things'... when his project didn't work, and par for the course their criticisms were coming from people who took a standard backend on a very large project that actually had been designed to function and something else likely needed fixed, to 'HEY LETS USE LINQ TO SQL APPARENTLY WITHOUT TESTING RELATIVE PERFORMANCE !!!!! AND WE'LL THROW SOME AD HOC QUERIES GENERATED BY MICROSOFT AT OUR SERVER INSTALLATION AND WATCH THE PERFORMANCE 'GAINS' THEN WE'LL BACKTRACK AND PUT STORED PROCEDURES BACK AND GENERATE HOOKS TO THEM LIKE A CLASSICAL DAL. JUST USING LINQ TO SQL'S CONTEXT OBJECT ! HURRAY I HAVE A BACHELORS AND 15 YEARS EXPERIENCE !'

There are so many details to fill in teaching the mindset of how to do things right in the first place is kind of expensive to begin with and you don't necessarily learn that in school working on common comp sci projects in academia. But they should have known better. I'm actually embarassed to list linq to sql on my resume as I think back.

I took over an application that consisted of 4 MSSQL (2005 at the time) databases, hundreds of tables, thousands of stored procedures, maybe a 1/4 of them actual still being used, external links to more than 20 other databases (MSSQL, Oracle and DB2) which all ran from a single "master" stored proc that was kicked off nightly by scheduled job.

The existing documentation consisted of a single word document, about three pages long, describing how to set up the application... on the Sql Server 6 server it had been originally created on two generations ago.

when your db guy made a mistake in the stored procedures and you are finding a bug for 5 days already.. damn! wasted life because of him

Why do some hosting services with MySQL not allow triggers and stored procedures / functions?
Had never tried to use them and now I've done it and deployed a site, I discover I can't create triggers, and that some hosting provider don't allow users to do them... this is a rant but more of a question, as I didn't know and maybe there's lore to it you do know...

"No, the Client doesn't like stored procedures so we have done all our TL parts of the ETL using a bunch of views on top of views on top of views."

Wish I could have been here at the start so I could have pushed back, sigh.

Siiiggghhhh, yet the client is anal about performance and even consistency in SSIS packages.....siiiggghhhhhh but we dont have SHOWPLAN permissions or even sp_who2 access...siiiigggghhhhhh.

If i expanded one of the final views, would be like 1k lines. For the amount of data, we move, there shouldn't be any noticeable processing time but it can take anywhere from 10mins to an hour.

Building a Web dashboard. Stats a day tiles etc.

Boss wants to write sql stored procedures to populate tiles.

Azure dB returns tile list, that maps to angular directive names, use nested angular directive that auto compiles a directive by name, then that directives controller calls a sql query which returns the name of the query to call to receive data, formats the data into charts or lists, builds the tile, places it into a gridster tile array and redirects to new tile pages by UI router state names.

I... I think I have gone too far. What have I done.

Stored procedures + SQLServer 2005

I always try to make problems more ... interesting, fancy, challenging. As soon as it gets boring, my mind is wandering.

Like now, when I wrote like a gazillion stored procedures, connected them to the back end classes, connected them to the new WCF service methods, connected them to the front end ... That's when I try to do anything but work.

From weird set of stored procedures to html to PDF to being a blob in a database ... I mean, sure, but why ... who comes up with that ... and why do I have to make it work

Ok I get it, naming things is hard. But jeez... why would you ever name something ‘the machine’...
Especially when it is just a bunch of sequencially run stored procedures....

Who's that sane to prefer programming with stored procedures than an actual programming language?

I would like to touch that shit only for optimization reasons, but when you have a project being built up without proper ORMs this is the idea that comes out of 'seniors' -__-

i hate stored procedures! wtf!!!

What alternative do you use for EF Migrations?
We are in current stage that it's slowing our build time for 30 seconds, and each month we need to clean them and do the same for the whole pipeline (dev, qa, prod)...
It's way uncomfortable to work with it since we have stored procedures and ef doesn't track them...
What alternative did you chose to use?