Why Can’t Senior Programmers… Program?

This post is obviously a reference to the notorious Why Can’t Programmers.. Program?. I was earlier today reading an article about unreasonable assignment for junior programmer interview. In that article the author describe how some of one of his junior friend had to program a linked list in java that is compliant with the List interface during a job interview.

The whole assignment needed to be done in 30 minutes, and required to implement at least 2 classes and 37 public methods. It seems pretty unrealistic indeed to expect this from any programmer, especially from a junior programmer.

But that isn’t what is the most surprising about this article. The author then goes to mention he tried to do the assignment pair programming with another senior developer and they couldn’t get it nailed down in 6 hours. In fact, they didn’t even started the iterator part of the problem. Damn, 2 senior developers can’t do it that much time ? What can be so hard about it ?

And so I tried

I had to see by myself what was so hard about this, so I setup myself to do the assignment and see how it goes. It was understood that I had tight time constraint, so I had to blast through the spec getting all the methods do what they are supposed to with less than a minute each to get it by the time limit.

For reference, we are implementing the List interface and the ListIterrator interface.

Hopefully, most methods are actually quite trivial, and, without constraint on the complexity, I could do heavy code reuse. For instance, the addAll method will repeatedly call the add method, which is O((N + M) * M) while doing something in O(N + M) wouldn’t have been too hard. The documentation is also nice enough to provide you with all you need, even sometime sample code for complex condition.

Needless to say, I couldn’t get it done in 30 minutes. I needed 35. I would not recommend to use the result of these 35 minutes of intense coding in production. The complexity is high, allocations too frequent but overall, it works™. If I were to use that code, which would be stupid to boot, because Java already provide a linked list implementation in its standard library, but if I were, I would surely improve the test suite, fix the algorithms that exhibit high complexity and make the code more readable.

To my shame, I skipped retainAll, by choosing to throw an UnsupportedOperationException, which is valid per spec.

What to do during the next 5 hours and 25 minutes ?

As I expected, the assignment was way too complex for the time given, but I’m fairly confident that I can achieve some quality implementation in less than 6h by now. To boot, improving complexity, then, getting the gava test suite make sure all of it passes.

Which lead to the question: How come two senior developers can’t get it done in 6 hours ? The industry I work for is full of mysteries, and this is one of them. While I agree with the author sentiment on whiteboard interview to some extent, I may have some insight on the reasons why he never passes them. Sorry buddy.

Truth be told, pair programming, test driven development, denigrating recruiting practices and ruby on rail sounds very good on a blog, but all of it is no more than playing buzzword bingo if one can’t get shit done.

A good interview question ?

Asking to implement a List is a bad interview question. Its too long, and won’t give much signal, and don’t have a reachable first goal within the 30 minutes.

Ideally you want to have a question with an relatively easy answer, but on which one can improve. For instance, a problem with a relatively easy solution of high complexity. Various heuristics can be added and/or discussed to make it perform better.

The interviewer can get signal pretty quickly because there is an easy answer and discussion can follow on how to improve. The problem is open ended, which allow good candidates to really show how far they can go. It also allow for discussion between the interviewer and interviewee, the kind of which help to asses how one works.

Implementing List is tedious, with many corner cases, certainly not doable in 30 minutes and does not allow for much discussion between the interviewer and interviewee.

Don’t do that. Unless you want your candidate to suffer.

Especially for a ruby on rail position…

Save pixels in your Gnome Shell

I love Gnome Shell, but was bothered by the amount of pixel wasted in its interface. The title bar of window is quite large, and the activity bar is always present. A maximized window still is unable to use a significant amount of pixels in the top of the screen.

This is a major pain on small screen, but even on bigger screen, MOAR pixels for my app is better. After all, the role of my desktop is to allow me to manage my apps in a convenient way. It has to be as discrete as possible.

Using a set of extensions, I was able to achieve the merging of the activity bar and the title bar for maximized window, but recently one of these extensions stopped working and the configuration of the whole stuff was quite complex and unappealing. So I created Pixel Saver, an extension that save brave pixels !

Pixel Saver

The goal is simple : merge the title bar and the activity bar when a window is maximized, in the most natural possible way.

To do so, Pixel Saver do not require any configuration, it fetches the configuration of your title bar and adapt itself accordingly. It is easier for the user, and produce a nice result. Activate the extension and it works !

The title bar is completely gone and integrated to the activity bar.

The extension integrate title bar’s buttons in the activity bar, and change the title of the application menu to reflect the title of the maximized window. Really, nothing more need to be said.

That is Awesome ! I want to install it !

Follow the guide :

git clone https://github.com/deadalnix/pixel-saver.git
cd pixel-saver
# copy to extensions directory
cp -r pixel-saver@deadalnix.me ~/.local/share/gnome-shell/extensions
# activate
gnome-shell-extension-tool -e pixel-saver@deadalnix.me

Easy ! I hope to get it soon into gnome extension’s website.

A bug report ? A pull request ? Go on the Pixel Saver github’s page !

Happy Pixel Saving !

Type-safe tagged unions in the D programming language

A tagged union

Sometime you have some data that can be of type A or B. Very common use cases include decoding various file format or network protocols, communicate with memory mapped devices, some processing that can return an A or a B depending on its result, and many more.

To resolve that issue, it is common to use a union. A union is a aggregate where all members share the same memory. It is very handy, but use it wrongly and you end up badly messing up your memory. I’ll demonstrate in this article how to make this safe in D.

Continue reading

A story about optimization, LLVM, and the SentinelInputRange

Developers want code that runs fast and users do too. However, it is easy to fall into the trap of early optimization; this story shows that even in non-trivial cases, modern compilers can do wonders. On the other hand, the myth of the “sufficiently smart compiler” is still very relevant. The best way is to look at what is actually generated for an example and that is what I’ll do in this article. Enter the SentinelInputRange.

Continue reading

Visitor pattern revisited in D

OOP is known (or should be known) as a behavioral abstraction. It nicely solves a vast variety of problems, but enforces on the programmer an abstraction that doesn’t fit every problem. The fact is, you sometime need objects as data abstractions and not behavioral abstractions.

This is commonly the case for tools that manipulate code. A parser typically returns an AST that will be processed. The processing can be compilation, code formating, code analysis, and basically any other use related to source code manipulation.

Following regular OOP principles, manipulations have to be implemented by the AST node classes. This is a problem, because it prevents any 3rd party developer tool to reuse an existing parser and AST. The known solution is to use the Visitor pattern, which allows to dispatch in our code according to the AST node’s type.

The Visitor pattern has many known problems, to the point that many consider it an antipattern. A better solution using D has to be proposed.

Continue reading

Get an exception from a segfault on linux (x86 and x86_64), using some black magic !

Linux (as other UNIXes) allow you to register handlers for signals. Here we are interested in SIGSEGV. This signal is sent to your program when you try to use a memory location you shouldn’t. Typically, when deferencing null.

Language like Java send a NullPointerException, that can be caught and you can recover from it. However, in a system language, you usually get a cryptic « segmentation fault », you cannot recover from it and cannot have any information about it outside a debugger. Let’s see how we can fix this.

As C++ and D are system languages that support exceptions, we will use this mechanism to handle SIGSEGV. I’ll do it in D in this post, but the same is doable in C++. If you understand why it work, it shouldn’t be a problem.

Continue reading

How duplication insidiously invade our code

Duplication is probably the #1 enemy of clean code. Its presence make the code harder to maintain, harder to evolve, more bug prone, harder to test and probably eat babies every morning. If almost any developer will agree on that fact, me can also notice that almost every codebase is crippled with repetitions in the code. How could we explain that ?

Continue reading

Impact of 64bits vs 32bits when using non precise GC.

As ARM release its intention to go 64bits, we can be pretty much sure that almost every device will be 64bits soon, except the one on which it is unrealistic to run a garbage collector.

A garbage collector can be precise like in Java, or not, like D’s GC or Boehm’s GC for C++. It means that theses GC don’t know what it a pointer and what isn’t. Non precise GC cannot move data to compact the heap, and are also prone to false positive. On a theoretical perspective, switching from 32 bits to 64 bits should improve things, but what it is in practice ?

Continue reading

A review of D2 – constness and immutablility

The D programming language is a very promising language. I propose here to do a quick review of some problems it is facing (or at least problems I’m facing when using it) and propose some solutions.

Immutability and constness in D2

I wanted to to a single, but writing it, it kept getting longer and longer. The point wasn’t to rant randomly, but also to make some proposal to improve things. So I did split it into smaller articles, and here the first one. We will discuss constness and immutability in D2.

Continue reading

The hashtable closure pattern

I noticed that I was using a pattern of my own more and more. It is actually very usefull, for several reasons. It may have been used by other before me, but never saw a name for it.

This pattern is useful when you have to apply an operation dependent on parameters several times. for example when you want to apply a calculation on all elements of an array, the calculation depending on some parameters. This article will explain you that pattern and demonstrate how it can be used in Javascript, PHP and D.

This pattern can be used in any language that support first class function and hashtable, that is becoming more and more common (closure support was added in PHP as of version 5.3).

Continue reading