Defensively? Optmistically?

The Pragmatic Programmers argue that we should program defensively. Basically, they suggest that if your program arrives in an unexpected state then it should stop working instead of doing stupid things.

Others argue to write fault-tolerant code. Say for instance, if you’re creating a financial report from some hundred thousands transaction, you don’t want it to abort just because three transactions were abnormal. You’ll want to send the daily report as usual, and handle the exceptions manually. Continue reading

Advertisements
Posted in programming | Tagged , , , | 2 Comments

How to debug with triggers?

Recently I was working on a Primary Key Violation error. This error was part of a bigger process. This was a well-written process, so it rolled back everything after this error. Although it’s cool for the application, it’s horrible for debugging. I didn’t know what records caused this error.

I had a few hunches, but that’s all. I released a fix based on one of these hunches, but it didn’t work, So I decided, I needed data.
Continue reading

Posted in programming | Tagged , , , | Leave a comment

What do you want to depend on?

I must confess. Sometimes I can see fixes that make a chill go down on my spine. And it’s the wrong kind of chill. It’s the chill that tells me that something is wrong.

What kind of something am I talking about? Usually it goes like this: a coworker explains “So, we filter these messages with these predicates, because based on the business rules…”. And then, a chill goes down on my spine. It’s the wrong kind of chill.

Why is it wrong? Is it wrong to write business logic into our code? It depends. It’s a programming blog, so the answer is always, “it depends”.

Bear with me. Continue reading

Posted in programming | Tagged , , | Leave a comment

How to debug in production

We’ve all seen bugs in production. Sometimes we can reproduce them, sometimes we can’t.

When we can reproduce them, then we fix it quickly. The we do some regression tests to see if we broke anything else. And then we’re done.

When we can’t reproduce it, that’s a totally different story.

Continue reading

Posted in programming, Uncategorized | Tagged , , | 2 Comments

Explaining Recursive SQL queries

Programming has a few concepts that some people just can’t get. According to this post, recursion is one of these.

Usually we learn recursion with examples like the Fibonacci sequence. Here is an example from SO:

function fibonacci(n) {
   if (n < 2) {
     return 1;
   } else {
     return fibonacci(n-2) + fibonacci(n-1);
   }
}

//prints 21
console.log(fibonacci(7));

For non-programmers, recursion is defined like this:

    recursion (n): see recursion.

I presume my readers are programmers so no need to explain this. However, we’ll analyze this so we can refer back to this when we check the SQL recursion.
Continue reading

Posted in programming | Tagged , , | Leave a comment

Clean Code in Transact-SQL

I’ve been working with legacy code in Transact-SQL. This is a great opportunity because I still got a lot to learn about SQL, especially about the procedural extensions. All this legacy code lets me experiment with constructs I haven’t even heard about. I can identify patterns and antipatterns. I can draw conclusions and uncover better ways to do the things we’ve been doing.

It’s really rewarding to be a beginner in this industry.

Continue reading

Posted in programming | Tagged , , , | 3 Comments

What can we learn from arrogant bosses

I believe, everybody encountered an arrogant boss through her career. An arrogant boss is somebody who… Well, someone who looks like an arrogant boss to me, he might be fine for you.

Nobody is perfect, not even the managers. There are some kind of personality flaws that I can hardly tolerate while it might be fine for others. Also, there are personality flaws that I tolerate well, while others can’t handle it that well.

The fun fact is that we can even learn from this kind of bad experiences. Continue reading

Posted in programming, soft skills | Tagged , , , | Leave a comment

Please, don’t give me a chance

You need a developer

So you’re a manager at Xyz Inc and you want to hire a developer. Along the process you’re interviewing me. During the interview you find out that I know only a little about the core technology you’re using. Moreover, you don’t like my personality.

Still, you think I’m competent. Oh, by the way, there’s a shortage of java developers. You’ve been searching for the right candidate for months but haven’t found a solid developer. What now? Continue reading

Posted in programming, soft skills | Tagged , | 2 Comments

The stupid developer

This story is about a stupid developer.

Once I had to write a complex SQL query so we can extract denormalized data from the database. This complex query had to deal with tree-like data structures and I’d never done anything like that before. So I asked Google and ended up with the CONNECT BY statement.

Another developer had to review my code. Let’s call him Robert. Hint: he wasn’t the stupid one. Continue reading

Posted in programming, soft skills | Tagged , , , | 1 Comment

The mad hatter antipattern

The hats

We all know this metaphor: we wear different hats at different parts of programming. The classical dichotomy is having one hat for writing code and another for refactoring. If you use TDD, then you have a third hat: the one for writing unit tests. In TDD you change these hats frequently, but still, you are switching only these three.

Is this all? Of course not. We need to read specification, talk to customers or PO-s, negotiate deadlines with project managers. One hat for each. Continue reading

Posted in programming, soft skills | Tagged , , | Leave a comment