Coding Problems That Google Can’t Solve For you (and how to solve them instead)

Coding Problems That Google Can’t Solve For you (and how to solve them instead)

60% of programmers use Google for 70% of their work – I am 89% sure those numbers are correct. All kidding aside though: Google is a large part of programming, but there are plenty of errors that it can not help you with – those are why we still have jobs that are often times interesting even.

So after some odd years of stressful programming in various systems I have seen things, felt the despair, seen the light, spent nights fixing bugs that shouldn’t have been mine to fix – good times. Let me share with you some of the error types that can occur where google and StackOverflow won’t be able to lend you a hand – or mark your question as duplicate.

Masked errors

Let me show you a quick example:

try {doThing();}
catch ex as Exception{
    logMessage("an error occurred");

This looks not-good on first glance, but you might even think that it’s a good idea to do error checking and even reporting here – not knowing how much harm this causes.

The problem here isn’t even the non-descriptive error message (seriously, spend a minute to explain the source, the error, ideally one ID or identifiable data!) – no, the real problem here is that this custom error message masks the output and stacktrace you would get without even doing anything.

Now you will never be able to tell whether the error actually occurred at that spot or whether it may be far down the line, three or four function calls into that doThing() method. You’d be better off just doing nothing here – this one line of code could take you hours in fixing a production problem down the line.

How to solve: You need to take a look at the source code and probably search for the error message – hoping that it was not passed up the chain from an imported third-party library. Things like that happen. Once you identify the point in code where the error is thrown you need to dive in and understand what’s happening there. Ideally you can easily refactor problems like this, push that fix (or test locally if possible) and now you can take a much better look at that error.

From there on out you’ll be left with the regular debugging steps, taking a look at variables, return values, you know it. Really the biggest problem here is understanding when something like this happens and then identifying the root cause of the confusion – after that it gets much easier.

Infrastructural problems

Google can not help you with your company’s infrastructure. This can obviously become a huge issue, but even on a smaller scale it is something that nobody can really help you with. The biggest problem here comes from obfuscation, you can’t really go on StackOverflow and ask them to fix things that are clearly company secrets.

How to fix: Depending on the problem you have two options: Rewrite large parts or writing an interface of some sort. So let’s say you had one tool that can only put out xml data and another one that can only consume json data (a really simple use case) – then you could write a tool that takes one and converts it into the other, probably with a database table in between for serialization.

Related  Cool Things You Can Build With Python As Soon As You're Out Of Tutorial Hell

Internal error codes

I am a big fan of custom error messages that tell you what happened, where and probably also why – but you won’t be asking google to help you with the actual fixing.

So there is a clear line: If you create whole new exception types (like say a contractNotFoundException) that is great, it’s immediately more descriptive than the default „object reference not set to an instance of an object“). If, on the other hand you double down on this and overload existing exception types you quickly end up with error codes that serve no one and are even detrimental.

How to fix: Have custom exceptions also print the stack trace or error code of the original one – that is just one line of code where you declare that custom exception type.

Lacking or missing documentation

The only thing worse than missing documentation if you ask me is „malicious documentation“ where you can clearly tell that a programmer was forced to write it by his boss and did a great job of doing a bad job. This is far more common than you would think, nobody likes doing them and many feel like they are hurting their own job security.

So then you end up with documentation that either isn’t useable at all or can even be worth than figuring things out for yourself when you think you can rely on what’s there. I had to deal with everything from old login data, wrong casing in urls, all kinds of legacy problems like outdated certificates, signatures, log data that masked the real errors – the works.

How to fix: Ignore documentation where needed, update it where possible, try to understand the code yourself before even looking at documentation. To understand code you need to find the entry point and then branch out from there – or you may be able to do a full-text search across the code base.

Convoluted code

I once became the sole maintainer of a system that was one large class of c# – a good 3,000 lines of code. Inside that code were commented-out portions that needed to be uncommented whenever you switched from test to production.

You can imagine how easily you can mess something like that up – and of course it happened all the time, to me as much as my predecessor.

This whole thing became much easier to deal with after we rewrote it in parts, used some classes, functions, error checking – what an improvement.

How to fix: Take the time to rewrite messy, convoluted code – even just a little bit helps. Sort variable declarations and database mappings alphabetically, extract logic into their own functions, remove duplicate code or long stretches of //mightneedthislater type of code.



No Comments Yet!

You can be first to comment this post!

Post Reply