[french] LE BLOG

Marco Behler's riffs on programming, IT culture and the way software projects are made.

Programmer Job Interviews

There’s still quite a few people out there who think that a question like "how do you effectively sort data structure XYZ" makes for a good, default programming interview question. Additionally there seems to be a never ending rush to find the perfect algorithm question to weed out inapt candidates.

I wonder why we make things so complicated?

If the job is in Business IT, I’d like to know two things:

Domain-Specific Knowledge

Do you (the applicant) have any domain specific knowledge for the job? Do you know, say, how credit card payments work, how ship tracking is done? Know the ins and outs of healthcare regulations? Interestingly enough, I find this point to be most often completely ignored and undervalued.

Job-Specific Programming Skills

If you are, say, applying for a backend developer position, do you know your way around backend programming and databases. Or Web (REST/SOAP/flavour of the decade) services. Or Messaging. Or Security.

More specifically I would love to see a thorough practical understanding, not just regurgitated theory (ACID transaction properties, synchronous vs asynchronous, OAuth Basics).

And I certainly do not care about how you would balance binary search trees or implementing a breadth-first-search algorithm on a whiteboard, if that has nothing to do with the day-to-day work you are going to do.

So how to find out?

There’s really just two ways.

Either we sit together for a couple of hours and build a tiny, running (!) work-related project.

Example: If you are main job is going to be to move data from service A to B, then I’ll prepare a flaky web service for you (random 2xx, 4xx, 5xx response codes, timeouts, delays) and you show me how to consume that service reliably and how you would handle those errors and why.

Yes, practical coding is always resource intensive, but honestly imho the best way of filtering out bad applicants.

Or we have a discussion about practical, real-life problems that you are going to run into.

Here’s a piece of code that will tell you if someone has a thorough understanding of (Java) Spring database transaction handling or if they lied on their résumé stating they have had 15+ years of experience building database applications.

public class Java {
    @Transactional
    public void someBusinessMethod() {
      try {
        doStuffToDatabaseWithHibernate();
        doStuffThatThrowsException();
      } catch (Exception e) {
        logger.warn("Don't worry, can safely be ignored", e);
      }
    }
}

What’s going to happen? Will that database transaction commit or rollback? Why? Is Hibernate going to explode? Has Hibernate got anything to do with it at all? And if you mention the words "UnexpectedRollbackTransaction" or "Marked as rollback-only", here’s an instant job offer with 15% extra!

Finally…​.

Would you ask a ballerina, who’s auditioning for a classical play, to do some hip-hop or west-coast swing moves?

Or better yet, just talk about the best way of doing hip hop move XYZ?

Wouldn’t you simply want to see her dance ballet? Some basics, some advanced moves? Level of technique? Feel for the music? Presence on stage?

Why don’t we do the same when hiring programmers?

Who says that?

A couple of software projects ago I had a colleague from a French-African country. He had an interesting habit, which I have to admit, drove me and a couple of other team members crazy at times:

Asking "who says that?" (or "Oo sezz zat?", with his French accent) whenever confronted with change of requirements or technology/programming discussions.

"We need to be able to scale to X amount of users!" → "Oo sezz zat?"

"We need to use the latest and greatest {programming_language}/{framework} because of {XYZ} → "Oo sezz zat?"

"Let’s {generalise/extend/add feature XYZ} because in {time} someone might need it" → "Oo sezz zat?"

It might be easy to misunderstand this as distrust or as an attack on specific team members. But that’s not what he meant. Instead he wanted the whole team to reconsider the assumptions we made when talking about specific requirements.

Where is the data that says we need to scale indefinitely? Why should {language/framework} XYZ really be the problem to all our cures? Are our current problems technical at all? How can you predict the future?

In software projects, assumptions (correct or not) have the tendency to become unwritten laws. Mix that with a bit of group-think or individual egos and you can easily see a ton of problems that no retrospective with a ton of coloured post-its can solve. Who says that?

You should prototype more

A side effect of strict adherence to methodologies, such as SCRUM, Kanban or your fancy-methodology-of-the-day™ seems to be the endless need for discussion.

Can this really be done? - How should we split this task up? - Should we parallelise our efforts? - How long would it take? - How are we even going to estimate this? - It is going to be simple - No it is going to be damn hard! - It is impossible! - Let’s plan some more! - No, listen to my 500 objections and doubts first! - Shouldn’t we re-prioritize? - Let’s just have one more meeting to clear things up!

What you could do instead is build a working prototype. Be a practical programmer, don’t just theorize. See if you can get something done in a couple of hours.

You’d be amazed to find out what one competent programmer can do in just a couple of hours compared to a team dicussing themselves to death over days.

What’s holding you back?

In my last blog post we talked about the different types of software requirements. But how do you generate them, in the first place? What about practical strategies? How do you find out if you are hallucinating or if you really stumbled upon something the masses might want? And how do you find out about those hidden requirements?

In the last blog posts we talked a lot about dissecting requirements. But there was always one silent assumption: That your users and in turn your boss/client more or less all know exactly what they want.

New Book and Oktoberfest Price Deal

Sorry for no new blog posts last month. I was actually busy preparing a new book :) Here’s the news:

5 Simple Ways To Get More Accurate Estimates

Ugh. Your boss wants an estimate for a couple of new features that your client requested. Problem is, your last estimates were way too optimistic and far off the actual time needed. Talk about deadline pressure, eh? Here are 5 simple ways to not make those same estimation mistakes again.

The Customer Requirements book is finally done!

4 common mistakes developers make when estimating

So, your boss asked you to estimate a new feature. You talked a bit about that feature with your teammates. Then came silence. And a brain strain. But after a while you finally came up with your estimate of "ahem...1..to...2..days".

The Anemic User Story

Ever been assigned a user story which looks like this? (Taken almost verbatim from a real life customer project some time ago)

Hot of the press: Customer Requirements EAP!

As promised, the EAP of my new customer requirements book has arrived exactly on time. The first three (very important) chapters are ready!

Another day in the office. Another day of boss-storms-into-the-room-with-a-crazy-feature-request. You don't even properly listen to his actual feature request anymore:

Announcing [E-Book]: Customer Requirements

Do you sometimes feel like strangling your boss or customer because of his vague and ever-changing software requirements?

Too vague. Too broad. Ever-Changing. Hidden. Underestimated. Overestimated. Sounds familiar?

Now we have reached the most dangerous phase when working with requirements. Remember, we started deconstructing our should be really simple login-box requirement.

9:00 AM, your boss storms into the room and says: „Marketing wants a new fancy login box on our website. Just username/password field alright? And maybe a recovery link. Shouldn’t take more than a couple of days. Gotta go, bye!“

In situations like this, you usually scream on the inside. But this time you stay calm. Because you’ve learnt how to deconstruct.

Are you really sure what makes a programmer productive? Is it VIM instead of Emacs, the latest Haskell web framework or your favourite NoSQL database?

Java developers are flooded with a plethora of libraries and tools for their day-to-day work. We compiled a little list of stuff that we use everyday in primarily business line development (CRM, banking, web dev etc.) and that we can wholeheartedly recommend. There’s also a very opinionated section of people that we’d like to give some props to, if you are not on it, give us a shout ;)

Should you test your ORM mappings?

Welcome back from the summer pause!

[this is actually a post from our mailing list from a month ago. if you are not yet a member, devour it and sign up at the bottom! :) ]

Sooner or later in the lifetime of every actively developed code base one reaches the point where it seems to get harder to iterate. Features take longer to be implemented, short-cuts taken in the past rear their ugly head etc. This phenomena is so common that we techies gave it a catchy name. We call that technical debt.

This post was originally titled "jOOQ : The good (and bad)". But we noticed we not only wanted to talk about jOOQ, but also put it into the bigger picture of the Java persistence landscape. Hence, quite a few words about JPA/Hibernate. As a result, you, the reader, will get a nice comparison of the two. Note: Take this post with a bit of humor :)

Should my tests be @Transactional?

Simple question. The simplest answer to that may be "It depends.".

IT projects, especially medium-to-large sized ones sometimes just feel like house moving projects..Enjoy! :)

Last time in our "Speed Up That Build, now!" propaganda series we tried to show a specific approach using a ram disk to speed up a given build. This time we try to generalize our ideas to give you some additional options on the file system choice. As an added bonus we even try to do proper benchmarking this time. ;)

Maven: Don't just blindly "mvn clean install"

Suppose you have a multi-module Maven project, with a ton of modules, two of them being fancynewtool-db and fancynewtool-rest. fancynewtool-rest has fancynewtool-db as a dependency. What happens if you cd into the rest-module and do a mvn clean compile/test for the first time? Maven will tell you that it cannot resolve the db-module dependency. And now your instinct might be to do a blind mvn clean install in the parent project, because that is just the way Maven works ™.

Older Posts