Me: *hours of coding, develops a feature*
Code: I'm working..
Me: Oh good.. will monitor you for sometime.
Code: Ok, I'm done. I'll stop working now.
Me: WTF

Me: *sits for hours to solve bugs*
And when almost done,
VPN: Someone's having a good day, I'll disconnect you now.
Me: WTF

Me: *tries switching on/off VPN couple of times..*
When it starts to connect,
WIFI: Oh wait!! It's my turn to bid goodbye now. Have a nice day sir
Me: Of course !! The wifi

Me: *restarts router/ troubleshoot etc*
When wifi says connected...
Battery: Good job with wifi.. I'm down now..what you gonna do?
Me: Are you fucking kidding me???

Me: *connects charger, wait for laptop to switch on*
Windows: Updating....
Me: *jumps out window*

It's maddening how few people working with the internet don't know anything about the protocols that make it work. Web work, especially, I spend far too much time explaining how status codes, methods, content-types etc work, how they're used and basic fundamental shit about how to do the job of someone building internet applications and consumable services.

The following has played out at more than one company:

App: "Hey api, I need some data"
API: "200 (plain text response message, content-type application/json, 'internal server error')"
App: *blows the fuck up

*msg service team*

Me: "Getting a 200 with a plaintext response containing an internal server exception"
Team: "Yeah, what's the problem?"
Me: "...200 means success, the message suggests 500. Either way, it should be one of the error codes. We use the status code to determine how the application processes the request. What do the logs say?"
Team: "Log says that the user wasn't signed in. Can you not read the response message and make a decision?"
Me: "That status for that is 401. And no, that would require us to know every message you have verbatim, in this case, it doesn't even deserialize and causes an exception because it's not actually json."
Team: "Why 401?"
Me: "It's the code for unauthorized. It tells us to redirect the user to the sign in experience"
Team: "We can't authorize until the user signs in"
Me: *angermatopoeia* "Just, trust me. If a user isn't logged in, return 401, if they don't have permissions you send 403"
Team: *googles SO* "Internet says we can use 500"
Me: "That's server error, it says something blew up with an unhandled exception on your end. You've already established it was an auth issue in the logs."
Team: "But there's an error, why doesn't that work?"
Me: "It's generic. It's like me messaging you and saying, "your service is broken". It doesn't give us any insight into what went wrong or *how* we should attempt to troubleshoot the error or where it occurred. You already know what's wrong, so just tell me with the status code."
Team: "But it's ok, right, 500? It's an error?"
Me: "It puts all the troubleshooting responsibility on your consumer to investigate the error at every level. A precise error code could potentially prevent us from bothering you at all."
Team: "How so?"
Me: "Send 401, we know that it's a login issue, 403, something is wrong with the request, 404 we're hitting an endpoint that doesn't exist, 503 we know that the service can't be reached for some reason, 504 means the service exists, but timed out at the gateway or service. In the worst case we're able to triage who needs to be involved to solve the issue, make sense?"
Team: "Oh, sounds cool, so how do we do that?"
Me: "That's down to your technology, your team will need to implement it. Most frameworks handle it out of the box for many cases."
Team: "Ah, ok. We'll send a 500, that sound easiest"
Me: *..l.. -__- ..l..* "Ok, let's get into the other 5 problems with this situation..."

Moral of the story: If this is you: learn the protocol you're utilizing, provide metadata, and stop treating your customers like shit.

Dev: “Ughh..look at this –bleep- code! When I execute the service call, it returns null, but the service received a database error.”
Me: “Yea, that service was written during a time when the mentality was ‘Why return a service error if the client can’t do anything about it?’”
Dev: “I would say that’s a misunderstanding of that philosophy.”
Me: “I would say it’s a perfectly executed example of a deeply flawed philosophy.”
Dev: “No, the service should just return something that tells the client the operation failed.”
Me: “They did. It was supposed to return a valid result, and the developer indicated a null response means the operation failed. How you deal with the null response is up to you.”
Dev: “That is stupid. How am I supposed to know a null response means the operation failed?”
Me: “OK, how did you know the operation failed?”
Dev: “I had to look at the service error logs.”
Me: “Bingo.”
Dev: “This whole service is just a –bleep-ing mess. There are so many things that can go wrong and the only thing the service returns is null when the service raises an exception.”
Me: “OK, what should the service return?”
Dev: ”I don’t know. Error 500 would be nice.”
Me: “Would you know what to do with error 500?”
Dev: ”Yea, I would look at the error log”
Me: “Just like you did when the service returned null?”
<couple of seconds of silence>
Dev: “I don’t know, it’s a –bleep-ing mess.”
Me: “You’re in the code, change it.”
Dev: “Ooohhh no, not me. The whole thing will have to be re-written. It should have been done correctly the first time. If we had time to do code reviews, I would have caught this –bleep- before the service was deployed.”
Me: “Um, you did.”
<a shocked look from Dev>
Dev: “What…no, I’ve never seen this code.”
Me: “I sat next to Chuck when you were telling him he needed to change the service to return null if an exception was raised. I remember you telling him specifically to pop-up an error dialog ‘Service request failed’ to the user when the service returned null.”
Dev: “I don’t remember any of that.”
Me: “Well, Chuck did. He even put it in the check-in comments. See…”
<check in comments stated Dev’s code review and dictated the service return null on exceptions>
Dev: “Hmm…I guess I did. –bleep- are you a –bleep-ing elephant? You –bleep-ing remember everything.”

<what I wanted to say>
No, I don’t remember everything, but I remember all the drive-by <bleep>-ed up coding philosophies you tried to push to the interns and we’re now having all kinds of problems I spend waaaaay too much time fixing.
<what I said, and lied a little bit>
Me: “No, I was helping Nancy last week troubleshoot the client application last week with the pop-up error. Since the service returned a null, she didn’t know where to begin to look for the actual error.”
Dev: “Oh.”

Online tutorial pet peeves
————————————

My top 10 points of unsolicited ranting/advice to those making video tutorials:

1. Avoid lots of pauses, saying “umm” too much, or other unnecessary redundancy in speech (listen to yourself in a recording)

2. If I can’t understand you at 1.5 - 2x playback speed and you don’t already speak relatively quickly and clearly, I’m probably not going to watch for long (mumbling, inconsistent microphone volume, and background noise/music are frequent culprits)

3. It’s ok to make mistakes in a tutorial, so long as you also fix them in the tutorial (e.g., the code that is missing a semicolon that all of a sudden has one after it compiles correctly — but no mention of fixing it or the compiler error that would have been received the first time). With that said, it’s fine to fix mistakes pertinent to the topic being taught, but don’t make me watch you troubleshoot your non-relevant computer issues or problems created by your specific preferences (e.g., IDE functionality not working as expected when no specific IDE was prescribed for the tutorial)

4. Don’t make me wait on your slow computer to do something in silence—either teach me something while it’s working or edit the video to remove the lull

5. You knew you were recording your screen. Close your email, chat, and other applications that create notifications before recording. Or at least please don’t check them and respond while recording and not edit it out of the video

6. Stay on topic. I’m watching your video to learn about something specific. A little personality is good, but excessive tangents are often a waste of my time

7. [Specific to YouTube] Don’t block my view of important content with annotations (and ads, if within your control)

8. If you aren’t uploading quality HD recordings, enlarge your font! Don’t make me have to guess what character you typed

9. Have a game plan (i.e., objectives) before hitting the record button

10. Remember that it’s easier to rant and complain than to do something constructive. Thank you for spending your time making tutorial videos. It’s better for you to make videos and commit all my pet peeves listed above than to not make videos at all—don’t let one guy’s rant stop you from sharing your knowledge and experience (but if it helps you, you’re welcome—and you just might gain a new viewer!)

Windows troubleshooting:
- Works on my system, therefore it's not an issue.
- Must be a hardware error.
- Obviously it's just cheap hardware.
- Have you tried turning it off and on again?
- Here's some obscure error code that leads nowhere.
- Have you tried "sfc /scannow"?
AS IF SFC IS A FUCKING SILVER BULLET!!!
- Our Indian support chap from answers.microsoft.com will help you.

RRRREEEEEEEEEEEEE!!!!!!!
Solution: quietly weep and reinstall your system.

Linux troubleshooting:
- There are good quality log files.
- You can run the program from the command-line and read both stdout and stderr from it.
- You can usually run the program with high verbosity options to help you track down the error.
- Even daemons can have their commands spawned from a dedicated shell, to see why they failed.
- Usually it's a configuration error and you can easily edit the configuration file.
- More often than not, the program will tell you why it failed.

Solution: usually easy to find.

I fucking love Windows. Because you know, it's so easy to troubleshoot and the support is so great!!!

So I just found out that my colleague who I often have to work with does not use a debugger to troubleshoot any bugs at all. Actually, he does not even run or test his code locally either with prints or something similar. He just commits java code directly on bitbucket, no source control, without making sure it compiles and then he runs a CI provided by devops that takes 4 freaking hours to run because he bloated that shit up somehow.

I suggested politely to help him find a more efficient approach and to use my hardware setups for speeding up his work because I assume it must be pretty painful to work with, but he just refused.

That and those "seniors" with 10 years Linux development XP in the embedded field who don't know basic commands like ls, cat and touch and code in notepad.

Fucking me, who the hell am I working with and can someone please end me?

Biggest challenge I overcame as dev? One of many.

Avoiding a life sentence when the 'powers that be' targeted one of my libraries for the root cause of system performance issues and I didn't correct that accusation with a flame thrower.

What the accusation? What I named the library. Yep. The *name* was causing every single problem in the system.

Panorama (very, very expensive APM system at the time) identified my library in it's analysis, the calls to/from SQLServer was the bottleneck

We had one of Panorama's engineers on-site and he asked what (not the actual name) MyLibrary was and (I'll preface I did not know or involved in any of the so-called 'research') a crack team of developers+managers researched the system thoroughly and found MyLibrary was used in just about every project. I wrote the .Net 1.1 MyLibrary as a mini-ORM to simplify the execution of database code (stored procs, etc) and gracefully handle+log database exceptions (auto-logged details such as the target db, stored procedure name, parameter values, etc, everything you'd need to troubleshoot database errors). This was before Dapper and the other fancy tools used by kids these days.

By the time the news got to me, there was a team cobbled together who's only focus was to remove any/every trace of MyLibrary from the code base. Using Waterfall, they calculated it would take at least a year to remove+replace MyLibrary with the equivalent ADO.Net plumbing.

In a department wide meeting:

DeptMgr: "This day forward, no one is to use MyLibrary to access the database! It's slow, unprofessionally named, and the root cause of all the database issues."
Me: "What about MyLibrary is slow? It's excecuting standard the ADO.Net code. Only extra bit of code is the exception handling to capture the details when the exception is logged."
DeptMgr: "We've spent the last 6 weeks with the Panorama engineer and he's identified MyLibrary as the cause. Company has spent over $100,000 on this software and we have to make fact based decisions. Look at this slide ... "
<DeptMgr shows a histogram of the stacktrace, showing MyLibrary as the slowest>
Me: "You do realize that the execution time is the database call itself, not the code. In that example, the invoice call, it's the stored procedure that taking 5 seconds, not MyLibrary."
<at this point, DeptMgr is getting red-face mad>
AreaMgr: "Yes...yes...but if we stopped using MyLibrary, removing the unnecessary layers, will make the code run faster."
<typical headknodd-ers knod their heads in agreement>
Dev01: "The loading of MyLibrary takes CPU cycles away from code that supports our customers. Every CPU cycle counts."
<headknod-ding continues>
Me: "I'm really confused. Maybe I'm looking at the data wrong. On the slide where you highlighted all the bottlenecks, the histogram shows the latency is the database, I mean...it's right there, in red. Am I looking at it wrong?"
<this was meeting with 20+ other devs, mgrs, a VP, the Panorama engineer>
DeptMgr: "Yes you are! I know MyLibrary is your baby. You need to check your ego at the door and face the facts. Your MyLibrary is a failed experiment and needs to be exterminated from this system!"

Fast forward 9 months, maybe 50% of the projects updated, come across the documentation left from the Panorama. Even after the removal of MyLibrary, there was zero increases in performance. The engineer recommended DBAs start optimizing their indexes and other N+1 problems discovered. I decide to ask the developer who lead the re-write.

Me: "I see that removing MyLibrary did nothing to improve performance."
Dev: "Yes, DeptMgr was pissed. He was ready to throw the Panorama engineer out a window when he said the problems were in the database all along. Didn't you say that?"
Me: "Um, so is this re-write project dead?"
Dev: "No. Removing MyLibrary introduced all kinds of bugs. All the boilerplate ADO.Net code caused a lot of unhandled exceptions, then we had to go back and write exception handling code."
Me: "What a failure. What dipshit would think writing more code leads to less bugs?"
Dev: "I know, I know. We're so far behind schedule. We had to come up with something. I ended up writing a library to make replacing MyLibrary easier. I called it KnightRider. Like the TV show. Everyone is excited to speed up their code with KnightRider. Same method names, same exception handling. All we have to do is replace MyLibrary with KnightRider and we're done."
Me: "Won't the bottlenecks then point to KnightRider?"
Dev: "Meh, not my problem. Panorama meets primarily with the DBAs and the networking team now. I doubt we ever use Panorama to look at our C# code."

Needless to say, I was (still) pissed that they had used MyLibrary as dirty word and a scapegoat for months when they *knew* where the problems were. Pissed enough for a flamethrower? Maybe.

Should a developer really have to be a jack of all trades? I write code, but at work I feel like I am always getting pulled into sysadmin debacles. I am not a sysadmin or an ops person. I am a developer, not a systems guy.

If you want me to be a systems guy, then train me to be one. You hired me to write code, not to troubleshoot shitty IBM Application Servers.

Our website stopped working. A coworker said her guess from an error she saw in the logs was that it might have something to do with a bit of a commented line in .htaccess taking itself out of comment and into code due to a specific set of characters the line contained. I looked at .htaccess and thought “Nah, that can’t be it.” and proceeded to troubleshoot pretty much everything but that. After 30 minutes my coworker opened the file and fixed the comment and all was well. I felt stupid because on our team I’m supposed to be the expert that figures out stuff like this.

Still dealing with the web department and their finger pointing after several thousand errors logged.

SeniorWebDev: “Looks like there were 250 database timeout errors at 11:02AM. DBAs might want to take a look.”

I look at the actual exceptions being logged (bulk of the over 1,600 logged errors)..

“Object reference not set to an instance of an object.”

Then I looked the email timestamp…11:00AM. We received the email notification *before* the database timeout errors occurred.

I gather some facts…when the exceptions started, when they ended, and used the stack trace to find the code not checking for null (maybe 10 minutes of junior dev detective work). Send the data to the ‘powers that be’ and carried on with my daily tasks.
I attached what I found (not the actual code, it was changed to protect the innocent)
Couple of hours later another WebDev replied…

WebDev: “These errors look like a database connectivity issue between the web site and the saleitem data service. Appears the logging framework doesn’t allow us to log any information about the database connection.”

FRACK!!...that Fracking lying piece of frack! Our team is responsible for the logging framework. I was typing up my response (having to calm down) then about a minute later the head DBA replies …

DBA: “Do you have any evidence of this? Our logs show no connectivity issues. The logging framework does have the ability to log an extensive amount of data regarding the database transaction. Database name, server, login, command text, and parameter values. Everything we need to troubleshoot. This is the link to the documentation …. If you implement the one line of code to gather the data, it will go a long way in helping us debug performance and connectivity issue. Thank you.”

DBA sends me a skype message “You’re welcome :)”

Ahh..nice to see someone else fed up with their lying bull...stuff.

When your non-programmer boss asks how exactly some code/bug was fixed.

"You sure? I mean, alright... "

It's not like every time something doesn't work right, this will be the fix. We're not going to have a conversation in the future where you help me troubleshoot something by remembering parts of this conversation.

Sorry I'm on my computer during the meeting but I can multitask I swear!

(I can definitely write code and troubleshoot with other devs on Skype, while you're talking)
I never said I was listening to you though! Lol!

Just came back from vaccation yesterday. During sprint retrospective today I hear my team was having trouble dealing with the API layer (which was mostly written by me). Suggestion was a session where I sit and explain the application to the team ,which I have no problem with.

One of my teammates asserts that it's written in such a way that "only the person who wrote it can modify it".

Agree to disagree but whatever. This thing goes through code review everytime I push changes to it. If there was a problem I don't know why he's just discovering it 6 months into the project. I assure you there's no rocket surgery going on. The problem is that I have been doing everything on that side of the project and nobody was curious enough to give it a read sometime. In fact I dont think anything needed to change while I was on vacation, they just didn't have me to troubleshoot every problem for them like usual 😤

1) Never be afraid to ask questions.

There are so many instances of situations where assumptions have been made that shouldn’t have been made, resulting in an oversight that could have been rectified earlier in a process and wasn’t.

Just because no one’s asking a question doesn’t mean you’re the only person who has it.

That being said, it’s really important to figure out how to ask questions. Provide enough context so that the audience for your question understands what you’re really asking. If you’re trying to troubleshoot a problem, list out the steps you’ve already tested and what those outcomes were.

2) When you’ve learned something, try to write about it. Try to break it down as though you were explaining it to a child. It’s through breaking down a concept into its most simple terms that you really know that you understand it.

3) Don’t feel like you have to code *all of the time*. Just because this is what you’re doing for a living doesn’t mean that you have to make it your life. Burnout is real, and it happens a lot faster if it’s all you do.

4) Find hobbies outside of tech!

5) Network. There are a number of great communities. I volunteer for and am a member of Virtual Coffee, and can vouch for that community being particularly friendly and approachable.

6) Don’t let a company pay you less than industry standard and convince you that they’re doing you the favor of employing you.

7) Negotiate salary. Always.

8) If you’re a career transitioner, don’t be afraid to talk about your previous work and how it gave you experience that you can use in programming. There’s a whole lot of jobs that require time management, multi-tasking, critical thinking, etc. Those skills are relevant no matter where you got them.

9) If it takes a while for you to get a gig, it’s not necessarily a reflection on you or your abilities.

10) Despite what some people would say, coding’s not for everyone. Don’t feel like you have to continue down a road just because you started walking down it. Life’s not a straight path.

Trying to troubleshoot this busted ass code for a client. Meanwhile, my wife is in class and my two daughters are blowing chunks.

Staring at devRant isn't fixing anything either. Lol

When I hit the endpoint from Postman it works. When I hit the endpoint from my application that pushes data to the endpoint it doesn't work, returning a 404 status code. I KNOW the endpoint is there and operational and that both Postman and my application have the same endpoint configured, letter for letter.

So lost. So confused. What the hell is going on.

I decide to install Fiddler to monitor the traffic to see if I can see anything helpful.

I initiate the request again from the application and immediately see that the request size is huge. BAM. It immediately hits me, the payload to the endpoint is too big and the server is "rejecting" it with a 404. I post a smaller request with the application and it works fine.

Yay, saved by Fiddler.

Why does the endpoint default to 404 in such scenarios. The definition of 404: "the client was able to communicate with a given server, but the server could not find what was requested"

In my case, the 404 returned was a red herring. I understand that the substatus code gives more information on why the 404 was returned, in my case the request size being too big, but 404 in general feels like the wrong status code to return because the endpoint IS there. It made me troubleshoot the wrong thing.

Thanks, IIS.

Argh fuck you Microsoft for blocking my precious mail server. I can't believe that you were the only one. Even google accepts my mails with every fucking test passed...

Oh and not to mention that in the no delivery report you are referring an error code which is not present on the linked troubleshoot page. Thank you once more, you piece of shit.

Should have listened to the articles about why I don't want an own mail server...

I learned very quickly that magic globals are baaaaad.

I mean, it's easier than using a queue for passing data between threads, right?

I was assigned a task to troubleshoot some buggy code. I am a developer and I don’t know how to get started. Does anyone else experience this kind of anxiety? Where you’re asked to apply your skills and suddenly your brain just shuts down and you feel like you know exactly nothing? I’m older than most coders in my field. Onset of some kind of brain disorder?

How was I able to fix this bullshit report generator task?

Simple bitch. I am that fucking good. Matter of fact. I am more than good. Sit the fuck down and listen.

That fucktard you have over there acting as a faculty member teaching kids about code and security? Blame that bitch for the horrible code that was NOT working since he wrote that with absolute disdain for software engineering and without taste or finesse.
Yeah I was able to troubleshoot his monster of an app. His ass is the reason why people hate php, giving the lang and community a bad name and shit.

Pleased to meet you btw.

I am Alex. Your new rockstar.

To my manager: i got it babe don't worry. I'll be your huckleberry.

I am out.

Watched 2 different vendors struggle to get something going.

I stayed quiet during both meetings, the first, was a misconfiguration error on their project code. They were tailoring the product that they sold my institution, I could see the simple error: key-value settings on one of their json files (it is a dotneto app)
I don't get paid to troubleshoot the code for an external company, so I was silent, knowing full well this would take longer to get done, needless to say, I had originally advised against purchasing this product but was not listened to, very well then.

The other was a configuration issue on the side of a different Java based product, there were some strange XML configuration entries, some other project files that made little sense, but again: quiet.

Department head is concerned about the delays that this might cause and will still not ask if I am willing to help since he knows I A) was against this product purchase from the get go and B) knows DAMN well I will say that I don't get paid to troubleshoot the issues that third party vendors charging us over 100k of product "worth", they wanna spend the money on "enterprise" shit that does not work,they can deal with their own shit programs.

Morale of the story: money moves people. If there is no bling in my account: then I ain't doing it.

Now, I do get paid well for what I do, and for that I do bust my ass, for everything else: there is mastercard.

A file that I had copied from the company network drive into my own. VS Code to edit the content according to a tutorial provided. IDE doesn't work with the given file, dependencies not resolvable, so let's troubleshoot. Open the file in question inside the IDE, the file contents are those from the tutorial?? Turns out I didn't edit the file on my own system but on the network drive. At least it wasn't a critical file. 🤦

These goddamn fuckers who every week spam people because their CI or code is broken. Apparently it's more important than other projects. Douchenuggets send an email and CCs the whole department and all the bosses and basically says "It's all broken, the whole company needs to work on this asap, it's possibly x other person's fault".

Then when you try to troubleshoot it because bosses want it fixed, the dumb pieces of fuck made a bug in their code that they could have easily fixed if they took the time to troubleshoot themselves instead of panicking like jackasses. Or better, have good tests and actual error handling.

I swear some day I am gonna get into a fistfight I started because of this bullshit.

In my first few months of my first dev job, I written this fragile piece of code in, trigger warning, PHP that sent out email reports to my clients. It was a two men team, and we have no clue about TDD or how to do unit testing for such code. We would just run that piece of code manually do send out dummy emails to ensure things were working.

One day the code broke. I was told by my boss to fix it. Spent the entire day trying to fix but couldn't get anything done. Finally at around 7pm my boss came by and asked why is it I couldn't get it fixed. He helped me troubleshoot and fixed it. And subsequently told me "c'mon man you're better than this."

It turns out that he changed a part of a code that was supposed return an array of strings to an array of objects, adding a second attribute that wasn't even in use.

So what that meant is that he changed a piece of working code, to include a property he didn't need, committed and push to production without even manually testing it. AND TALKED SHIT TO ME.

That was the day I learned git blame and began my journey on TDD.

I'm currently migrating one of the companies services from technology A to an B based solution...
Today I had to remotly troubleshoot an error occuring somewhere on our client's backend application, that wans't enabling us to register any given webhook to our endpoints...
We finally gave in and looked up the data packets using a sniffer only to find that the only difference was that in the A technology project our staff ended up returning a Status Code plus the respective Reason Phrase, in our newest version we only send the HTTP Status Code... Guess who wasn't aware of HTTP 1.1 RFC consideres the Reason Phrase optional and an unecessary overhead??? God dammit... In simple terms...

I love it when someone wants you to troubleshoot an issue but will not give you a test user account to test with. So you have to sit with a user or talk with them over the phone while you troubleshoot. I'm literally elbows deep in the code and database, but you won't give me an account for security reasons. Ok, that makes complete sense.

Found another gem in the code-base I've been given to troubleshoot.

Let's call recv(), get the TLS encrypted message, and then call BIO_write() and SSL_read() instead of offloading it to OpenSSL.

'Tech debt' is the word that every CEO hates to hear during roadmap review.

Instead, talk about how certain part of the code will drastically slow down future development, make it more difficult to troubleshoot, and reduce engineering happiness overall.

Scarily relatable