How to program by coincidence – five techniques to ruin your programming carrer

No idea what I’m doing

The Pragmatic Programmer book popularized a term: programming by coincidence. According to the book, it means that you write code that you don’t understand. So it works but you don’t know why. Consequently, if when it fails, you don’t know why either.

I used to believe that the only use of this term was to insult your coworkers. Saying “You’re programming by coincidence.” literally means this meme.

I don’t believe that anymore. I discovered a couple of techniques that help smart programmers like yourself to program by coincidence. I’m sharing them with you for $200. Here they are:

1. Copy and paste

This is a classic one. Whenever you find a problem, then google it. If you find a page, copy the code and paste it into your IDE. See if it works.

If you see two lines of code, you will have the urge to look up the idioms in the API docs. Don’t do that. Just add the code and see if it works.

More advanced users can copy code from the current code base. This is very useful because you can copy tens of lines of code. You can keep deleting stuff until it works.

Pro tip: you can paste SQL code to a jdeveloper connected to the production machine.

2. Ignoring stack traces

What do you do when your code fails? You have a stack trace that doesn’t fit into the screen. Ignore it.

Never ever read the stack trace. You can read the first line if absolutely necessary. So you’ll know see whether it’s a NullPointerException or just AnyOtherException.

If it’s a NullPointerException, just add some null checks. Otherwise you can tweak a loop index. Or paste something. Or comment out a method.

Do whatever you have to do to make the exception go away. That something can break a feature – but hey, that’s somebody else’s problem.

Pro tip: never ever learn, how to read an exception.

3. Ignorance is bliss

Don’t learn the frameworks you use.

If you don’t learn your frameworks then you can think out of the box. Say for instance, you can paste JPA queries into your jdeveloper, then complain that this SQL doesn’t work.

You shouldn’t learn your version control systems either. Just find a good UI that helps you to get by. When you really messed up, somebody will help you clear up the mess.

4. Confidence

When you don’t know how a framework works, then you can guess. You can call these guesses assumptions so you’ll sound smart. The trick is that you never ever need to test your assumptions. Just say aloud what you think and program accordingly.

If your assumption fails then blame the framework. It’s difficult to understand, isn’t it?

5. No automated tests

You shouldn’t write unit tests either. Unit tests give you quick and accurate feedback. Unit tests could tell you which method does what.

Pro tip: if you have to write unit tests, then make them long. It can be more complicated than the code its testing.


Yes, it’s sarcasm. If it hurts then probably you need to revise your practices.

Unless you’re a beginner. It’s OK for a novice programmer to make these mistakes. Just try to get over them in a couple of years.

More antipatterns

Did I miss an antipattern? Please let me know in comments.

Posted in programming | Tagged , | Leave a comment

Preparing too much for a job interview

Everybody agrees that we should prepare for a job interview. We shouldn’t be shocked by questions like “What’s your five greatest weakness?” or “What’s your salary target?”. Refreshing our memories about frameworks that we haven’t used for years – that can be useful too.

On the other hand, if you need to prepare for a month or so – that looks too much for me. Maybe you’re trying to cover too much. Maybe you want to sell yourself as more expert than you actually are. E.g. learning trick questions and answers in a language you hardly used – it’s cheating. Continue reading

Posted in soft skills | Tagged , | 2 Comments

Lessons learned from the IoC framework comparison.

In the previous posts I compared a few IoC frameworks.

It was an interesting journey to write the prototypes, then the posts one by one. I also learned valuable lessons from comments and questions. I’m trying to summarize them below.

XML still has an advantage

XML had a big hype a couple of years ago. Now people mostly hate it. Still, it has something on its side: Using XML for DI config, it’s extremely difficult to mix configuration and code logic.

So you’ll have a declarative configuration, and that’s good. On the minus side, this configuration will be difficult to maintain. I.e. it’s hard to read and it has no compile-time checking.

You can choose this with Spring and Java EE.

Constructor injection is ugly but safe

If you have constructor injection, then you can make sure that your beans are always fully configured. So you have one less thing to test.

In an ideal world you have good unit test coverage anyway. So you can switch to setter or field injection. These big constructors are ugly. They make testing difficult too.

Again, in an ideal world, your beans are well-factored and they don’t have that many dependencies. In an ideal world you have lots of small classes and everybody in your team can deal with it. Pun intended.

You can choose this with Spring and Guice.

Java configuration provides compile-time check.

If you build your beans with java then you’ll have a strong compile check. I.e. the interfaces and the implementations will always match. Your constructors parameters will be in the right order too.

In an ideal world you have good unit tests for this. But we already covered that 🙂

On the other hand, this approach requires some discipline. Otherwise you just add a little logic here, a little there, and you have a nice spaghetti configuration. You don’t want that, I suppose.

You can choose this with Spring and Guice.

Annotations have a caveat

It’s really nice to add annotations to your code. It makes development easy because you don’t need to check the separate configuration files during development.

There is one problem though: with framework-specific annotations, like @Autowired, you build dependencies on the framework. You effectively break the Hollywood Principle.

If you’re sure you won’t replace your framework, you’ll be fine. You can enjoy how easy it is to embed metadata into your code. Otherwise you’ll need another approach.

You can choose this with Spring. It’s mandatory with Guice and Tapestry-DI.

Your insights

Did I miss something crucial? Did I bad-mouth your favorite feature? Please let me know in comments.

Posted in programming | Tagged , , , | 2 Comments

Dependency Injection frameworks

If you want to deeply understand a concept, then you need to see several implementations. This is why I created the following slides.

Based on the feedback, I’m kinda alone with this mindset. Anyway, I hope you find them useful.

Posted in java, programming | Tagged , , , , , , | 1 Comment

Practical introduction to dependency injection

In the previous post we checked whether the template method pattern is an alternative to the dependency injection. There we saw the simplest dependency injection solution, without any framework.

Just to recap, this is the fizzbuzz class:

public class FizzBuzzManualInjection {

    private final FizzBuzzNumberProvider numberProvider;
    private final FizzBuzzTextProvider textProvider;
    private final FizzBuzzPrinter printer;

    public FizzBuzzManualInjection(final FizzBuzzNumberProvider numberProvider,
        final FizzBuzzTextProvider textProvider,
        final FizzBuzzPrinter printer) {
        this.numberProvider = numberProvider;
        this.textProvider = textProvider;
        this.printer = printer;

    public void doFizzBuzz() {
        numberProvider.getFizzBuzzNumbers().forEach(num -> {
            final String msg = textProvider.getFizzBuzzText(num);


And this is how we can configure it:

public class Main {

    public static void main(final String[] args) {
        final FizzBuzzNumberProvider numberProvider = new FizzBuzzNumberProvider();
        final FizzBuzzTextProvider textProvider = new FizzBuzzTextProvider();
        final FizzBuzzPrinter printer = new FizzBuzzPrinter();
        final FizzBuzzManualInjection fizzBuzz = new FizzBuzzManualInjection(numberProvider, textProvider, printer);



Consider this graph:

One object creates another

One object creates another

Node a represents a object that creates two other objects, b and c. They create other objects to the bottom of the graph.

Suppose you want to inject a new collaborator to node j. Well, then you have to go through the path a-c-g-j and modify all the constructors.

Is this something you’re likely to do when the deadlines are close?

Then consider a flat tree hierarchy, like this one:


There is a main node that instantiates a framework. The, the framework creates every other object. If they need references to each other, then framework will inject them.

So you want to add something to node j? Well, all you need to do is to change the configuration of your framework, tweak node j a little, and you’re done.

Is this something you’re likely to do when the deadlines are close? I guess not. So let’s take a closer look at a few frameworks. Continue reading

Posted in Uncategorized | 4 Comments

Template Method or Dependency Injection?


Dependency Injection used was always something very mystical to me. Until I learned what it’s really about.

I’d like to share this revelation with you. So let’s take an easy problem and solve it in couple of different ways.

Continue reading

Posted in java, programming | Tagged , , , | 1 Comment

Learning Tapestry, the Inversion of Control Framework

The framework

I recently started to use Apache Tapestry for work.

Tapestry is a web component framework with ambitious goals. E.g. it’s a web component framework that’s easy to extend. Also, it gives you the ease of development of scripting languages within the java ecosystem. Moreover, it provides an Inversion of Control (IoC) container with nice aspect-oriented features too.

This is my learning log: I completed the official tutorial. Then completed an in-house tutorial that shows how tapestry and the other moving parts fit together in our application. Finally, I read the Tapestry 5 book.

Earlier I wrote about its component and scripting parts. Here I’ll dissect its Dependency Injection parts

Continue reading

Posted in java, programming, web | Tagged , , , | 4 Comments

Learning Tapestry, the component framework

The framework

I recently started to use Apache Tapestry for work.

Tapestry is a web component framework with ambitious goals. E.g. it’s a web component framework that’s easy to extend. Also, it gives you the ease of development of scripting languages within the java ecosystem. Moreover, it provides an IoC container with nice aspect-oriented features too.

This is my learning log: I completed the official tutorial. Then completed an in-house tutorial that shows how tapestry and the other moving parts fit together in our application. Finally, I read the Tapestry 5 book.

Here I’ll dissect the components and the scripting parts.

Continue reading

Posted in java, programming, web | Tagged , , , , , , , | 1 Comment

How to give an interactive presentation

A presentation

A month ago I gave a talk in the office. The talk was a JavaScript survival guide for java programmers. You can see the slide show below.

I decided to give an interactive presentation: people could interrupt me with questions and I answered them. Also, we could go deep in one topic while we could skim another – whatever the audience wanted. I really like this format because this way I can teach something that’s useful for them.

However, I didn’t do anything like this for the last couple of years. Some things worked out well while others just didn’t. I’d like to share my experiences with you.

What went well

Declaring it interactive

First of all, I declared that this is going to be an interactive talk. Then I asked an open-ended question: what’s wrong with JavaScript? Then we checked whether their answers were on the slides. This little intro warmed us up so people were asking questions whenever they wanted to.

Basically, that’s it: you declare that it’s going to be an interactive session. Then you ask some questions. Finally, you must listen to the audience.


I had a few slides and lots of example code. I prepared at least 3 times as much material as we could cover. I also tried to ask myself tricky questions, then looked for answers. It was really useful: I could talk about anything they wanted me to. This is what you expect from a presenter, right? However, when you teach what you learn and you give an interactive talk, this can be difficult.

You need to prepare for presentations. I guess you already knew that. The point is that you need to prepare a little more for an interactive talk.

Example code

I already mentioned example code. Still, this is worth its own paragraph.

We all know that a live coding is cool. Or not. When you are not an expert of the field then odds are that it’ll be boring. E.g. it’s not that engaging to watch others looking for typos.

I found it worthwhile to write lots of code-chunks days before the presentation. You can put them on the screen any time you want it. Here you can find my example code.

Similarly, if you want to refer to an external tool like QUnit, it’s worth to save the URL in a txt file.

Lessons learned

Unfortunately, some things didn’t go well. Here are the lessons I learned.


It’s obvious that before the presentation you need some time to prepare the environment: checking the projector, etc. The lesson for me is that I need more time than that. Here is a checklist:

  • Are the slides visible?
  • Is the command prompt visible too?
  • Can I handle the smaller screen?

Minimizing distractions

When you give an interactive talk about programming, then you need several things: slides, browser and a text editor. Also, you must go back-and-forth between them. It doesn’t really help when you have several other things open, like an IDE or browsers with work-related tabs.

I gave this talk to my colleagues during office hours. They knew that I was working before the presentation. They also knew that I was going to work after the presentation. Still, I should’ve turned off every unrelated process. At least switching between browser and editor would’ve been easier.

More slides

It’s really, really cool to run code during the presentation. But that’s somehow not that concrete. When you project things to the wall, people will just forget them. It’s important to show some of the real thing on the slides too.

I hade only nine slides or so when I gave the talk. So I had to improvise a lot. Also, I had nothing to publish after the talk. I had to seriously pimp up the slides before uploading them to slideshare.

Ending it

When you give a good talk, you can expect to make people curious. That’s a good thing. However, it isn’t necessarily a good idea to go on with the details right after the presentation. First of all, you might be exhausted. At least, I was. Also, they might ask very deep questions that you just didn’t prepare for.

So giving an interactive presentation doesn’t mean that anything can happen. You can (and should) set clear borders. E.g. you prepared for 30 minutes, so it’s over.

You can also moderate a conversation after the presentation, just make sure everybody understands what’s happening. Otherwise things can become a bit unfocused – and this is not the impression you want to give.

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

The top people fallacy

Everybody wants to work with top engineers, right? It’s good to work with smart people from whom we can learn a lot. Hopefully, we can learn so much from them that others will consider us as a “top engineer”. So, when a head hunter approaches us with a possibility to work with “the top minds of the city”, we should say yes, right? I’m not so sure about it.

What’s wrong with top engineers?

There’s nothing wrong with them. They are smarter than anybody else. Seriously, it’s okay to advocate it all the time. Pun intended.

I’m skeptical about “top people” as a company value. Why is this so? I already worked at several companies that only hired ‘top people’. Even at a company that did the outsourced development, people were sure that they were smarter than the client. Just by definition there cannot be so many top people.

open space

lots of top people

OK, it’s ironical. But really, what’s wrong with the top people notion?


Once I was working at a small consultancy where people were experts of a certain java technology stack. As a journeyman I asked simple question like these, like this one: “As far as I know this construct should work – but it doesn’t. Do you know how to make it work?” They answered like this: “Well, what does the standard say?” We looked at the standard, and realized that none of us know from the top of our heads how we could make that thing work. This was something that an expert didn’t want to admit.

Another one: “What do you think about the Effective Java book?” They sent me book reviews. I explained that I wanted their opinion. Then they said they just haven’t read the book. Again, this shouldn’t be difficult to admit. E.g. amazon has 24k hits for java books. It should be OK to miss some of them.

Becoming an expert – it’s a valid a career path. However, declaring ourselves infallible, well, it only makes us ridiculous. It’s also a great risk to the impostor syndrome. There are lots of tips on how to get over it.


It’s difficult to have a teammate who thinks he always right. They tend to stick to their decisions, even when they, um, misjudge a situation. They tend to blame others, e.g. for misunderstanding their code, doing unnecessary changes, or whatever. It’s never easy when people keep criticizing us.

A boss with this sort of personality can things even worse. He can claim credit for the things while putting the blame to their subordinates. He can effectively kill any kind of innovation just because it wasn’t their initiative. Some people are okay to work for this sort of person. Others, including me, have just too much ego for that.

Arrogant developers and arrogant managers can slow down the business. These are the day-to-day difficulties which make progress a bit more difficult than it should be. However, arrogance on the sales side can even be disastrous. E.g. imagine a situation when an expert of technology X just cannot fix the problem of client Y because their application is too complicated, involving technology Z. This is a difficult situation where a consultant has difficult choices. These are the ones I can think about:

  1. Blame the customer for writing bad code, and burn lots of man-hours try hard to fix the problem.
  2. Explain the situation to the customer and work together with somebody who’s good at technology Z too. Customers domain experts should be welcome too
  3. Say no to the job, and help the customer finding somebody else.

Once I saw this, on the consultant side. I explained the problem to my boss who chose alternative #1. We billed them a lot, however, they never ever reach out to us for help. Probably this decision was necessary for short-term survival. Otherwise, alternative 2 and 3 would’ve paid off better in the long run.

Nice people

Sometimes nice people are referred as losers on whose backs you can climb higher. I disagree with this point of view. It’s possible to support others while protecting ourselves. Being nice makes it easy to cooperate with us. Helping others does a lot for us when we’re looking for advice. This seems so obvious to me that I find it difficult to explain why.

Maybe this will help: people don’t like to be taken advantage of. So when we see somebody who’s ready to pay the help back (or forward) then we find that person worthwhile to be helped. I know this sort of explanation is a bit cynical. But in this context wasn’t about helping the poor and the downtrodden. This give-and-receive approach is totally OK in a group of colleagues who work for a common goal.

The choice

So, given all other are equal, I rather work with nice people than top people.

Fortunately, these two groups are not mutually exclusive. I’m just cautious about companies who attract “top people” because they will attract lots of narcissist too. When interviewing to such companies I’d ask lots of questions about teamwork.

Posted in programming | Tagged , | 1 Comment