On “Introduction to PHP 7 and MySQL 5.6”

Hi friends!

I finished the second book from my PHP reading list, called “Einstieg in PHP 7 und MySQL 5.6”, Rheinwerk Computing. To make it short: Useless, no recommendation.

The main problem is that the book does not now if it wants to be an introduction for beginners to learn PHP or a reference manual to look up features. It tries to be both.

On one hand, it’s written as if the reader does not know the basics of programming, explaining what a variable is and what and if-statement is, including a really bad introduction to object-oriented programming that I already ranted about on medium.

On the other hand, it is a 600 pages small font book that dedicates only few sentences to each concept – so it is definitly not helping to learn programming from scratch, as the Head First books are. It seems to cover every feature the PHP programming language has one by one, and it’s not teaching the beginner what he needs from the perspective of a use case.

As I explained earlier, I’m not insterested to learn specific parts of syntax; that’s easy and I can google it on the fly. I want to learn about the ecosystem of modern real-world PHP applications, and in this regard the book didn’t help at all.

The only thing new that this book showed me compared to the previous one, was the syntax of classes in PHP 7. It’s basically exactly like Java, so I’m even less worried that I can work in PHP.

I have one last PHP book to read know, “PHP for absolute beginners”. I’m not positive to find there what I am looking for, but at least it’s a thin book. I think afterwards I’ll continue my research online, and the next time in the library I will look for the key words Laravendel and Composer instead of PHP itself.

On “Head first PHP and MySQL”

Hi friends!

As the first step on my endeavour to re-learn PHP I read the book “Head first PHP and MySQL”, O’Reily. I realize that book is quite old (2009), discussing PHP version 5 and is probably missing a lot modern stuff. But it helped my get back into PHP mindset and brought back the memories on what I did with PHP back in the old days.

On the book itself: I still love O’Reily’s “Head first” series! They are always fun to read, very practical and make it easy to grasp concepts. Unlike almost most books on technology or computer science, it’ light, fast reading. What I find awesome for beginners reading this book is that it demonstrates fully working (silly) real-life examples of web applications from chapter 1 on. As a beginner, you can follow through and at every step be exactly sure why you are learning that next concept, because it’s directly solving a problem that the solution from the last chapter showed.

On the content: Web pages in HTML, server-side rendering with PHP script, basic programming concept like variables and loops, writing and reading to/from MySQL database, validating forms, basic auth, sessions, template files, multimedia. It gives you all you need to get started, build your late 2000’er style pet webapp or small business web site with contact forms and so on. Of course nothing about frameworks, unit tests, build scripts, CI; I didn’t expect that from this book anyway. If you are a beginner in web programming, I absolutely recommend this book! You get fun, motivation and all the basic knowledge, but be aware that the real work begins afterwards.

On PHP: Now I remember what a horrible language PHP was! After reading “Clean Code”, getting into the whole mindset of software craftsmanship, and later even switching from Java to Kotlin I’m just so spoiled with elegant programming, that seeing the application code in this book makes me shiver. When I think of that HR-system we hacked together in PHP with xampp in 2008 or so, I realize what enormous development it has been since then.

But to be fair, I should not judge today’s PHP on the base of 10 year old books and experience. It’s reasonable to assume, since PHP is still in use to create new software projects today, it has evolved as well. There also is an ecosystem around PHP, I’ve heard about something called Composer and I’ve seen a job announcement requiring expertise in the Laravendel framework, so I’m curious to learn more about that.

On resume critique

Hi friends!

As I mentioned before, I signed up on hired.com and therecruiternetwork.com in order to provide my profile to recruiters and potentially receive job offers for the US.

From hired.com I received an email saying there is no match for my profile at the moment, I may resubmit my profile again since new jobs are constantly added. What’s annoying about this is that I have to set pretty specific filters to my profile, for example a list of up to ten cities where I would want to work, industries, range of employees (101-500 or rather 501+?) and salary. I dislike that they don’t let me set wildcards there, or show offers that are close exept some of these values I set, because I don’t mean them anyway.
They also say, my profile will not be visible for employers unless there is a larger pool of jobs for my skill set… I’m not exactly sure why this is important for there business model, but fine. Since I just want to be found to check the market, I tweaked my profile and re-submitted.

Feedback for my resume

For therecruiternetwork.com I had to upload a resume as .pdf file, in addition to the profile entries I did anyways. I have decent experience in creating a German style CV, but for the US market I had to learn about the differences. For example, in Germany it’s quite common to put a nice profile picture on the CV, in the US it’s not. The American style CV begins with two or three sentences as summary, advertising who you are – there is no such thing on German CVs.

I hope I got most things right – luckily therecruiternetwork.com offers a free review on your CV, and I was looking forward to learn how experts would rate mine. I was a bit disappointed by what I got. Let me pick three elements of the feedback to make my point:

  • My CV is visually uneven, not polished
  • My resume would compete against 250 others on average when I apply for a job
  • The description of my experience should be achievement-based instead of task base. The expert gives as an example for achievement-based description: “Slashed payroll/benefits administration costs 30% by negotiating pricing and fees

Okay, maybe the US job market is very different from the job market in Germany, so I try to take the critique seriously. But my experience from Berlin is: There is no way an engineer with 10 years of experience is competing with 250 other applications for a job. In contrary, most companies have more openings than applicants; they look at every engineer who applies and find out if he is a fit. When10 engineers apply, the company would be happy to hire all 10, if they make it through the assessment and salary negotiation.
Maybe the situation is not that applicant-sided like it’s here, I’m willing to believe that. But on this level of experience, it’s hard to believe that a hiring manager would only read a CV when it’s designed like art work. (To be clear: My CV is not a black-and-white page of 11pt text paragraphs. I’m using a template with visual structure, colored headlines and short, concise descriptions. But if an engineer puts too much effort into visual styling of anything, you should be suspicious and look out what he is trying to distract you from…)

I’m really trying to look for achievement-oriented wording of my job experience; it sounds credible to me that this is normal for American CVs, I haven’t had a way to check yet. Still, I cannot think of a way to phrase my previous jobs in terms of achievements, because as a software developer I was contributing to large products; there is not that one impact that is clearly my personal achievement. Looking at the example they gave me, I have to wonder: Do their ideas apply to engineers at all?

In total the resume critique is a sales pitch for the service to get the CV rewritten by them, which they offer explicitly. For that reason, the expert has a motivation to not be honest but make you feel bad about your CV. And in addition, I start to doubt that that advice applies to engineers, who can easily fill a page with hard skills they learned on the job and are relevant for the application.

The first match

Besides the resume rewriting advertisement I recieved a mail with job alerts, showing me potential matches the algorithm of therecruiternetwork.com had figured out.

Three of the matches are titled “Lead Android Developer”, “Identity and Access Management Tech Lead”, and “Business Analyst”. I would call that a clear fail in matching, but the scale shows only 50% match (“possible”)… fair enough.

The one match with 75% (“good match”) is called “Lead Full Stack Developer PHP”. Are you kidding me? I do have basic knowledge of PHP, but I didn’t put that on my resume.

Since the CV-expert recommended to put achievements instead of tasks ( = technologies) on my resume, and the algorith doesn’t seem to care about my technology skills as well… I’m courious, is the understanding in the US that technologies don’t matter and any 10 year software engineer can work in any technology?

Not exactly… reading the job offer, they publish an endless list of expected technologies. Now, I wouldn’t mind if I don’t know half of the stuff they mention, that’s how job offers work. But the core point is “Strong understanding of PHP (OO-PHP), Laravel Framework is REQUIRED” in all caps (oh my god, and they are critizing me for visiual design?), and I don’t match that at all.

My sad conclusion is that the matching algorithm is basically worthless. It’s obviously based on keyword recognition, and it’s not able to prioritize, so it will match me up with any job description that uses similar words as my CV, like “software”, “business” and “management”. Looks like I have to figure out a new way to expose me to tech recruiters.

On lists and sets

You probably don’t even need to think about what Collection type to use when: If you need to preserve the order or duplicate entries, you take a List. Otherwise if order does not matter and every element should only be contained once, you’ll use a Set.
Although nearly every programmer is able to explain that when ask, in practice I observe the tendency to use Lists by default, even if the data is logically unordered and unique. I’ve seen that in different teams and code bases now. Did you observe the same? Do you have an explanation for that?

I came up with a couple of possible reasons:

  • In some programming languages it’s common to use arrays for collections. I remember back in school when learning programming in Pascal, there was no Collection framework like in Java that would distingiush between Lists and Sets, there were only plain arrays. And if I’m not mistaken, vanilla JavaScript used to be the same. Is this the reason why many devs are just used to arrays and therefore use lists, which are close in terms of their properties?
  • The widespread Java Persistence API does always returns lists from a query, no matter if you specify an order criteria or not. Which kind of makes sense, because the result of a database query comes always as an observably ordered list of records, even if you don’t specify the order. So if you logically have a collection of results without specified order, you need to convert it to a Set explicitly.
  • The REST API of your Java service provides the data converted to JSON, so any collection is returned as an array, which inherently has an order if element – even if not intended. If the presentation layer is UI instead of rest, still the elements are displayed in some order. Do the devs feel that it’s not worth the effort to convert the JPA-returned List to a Set for the business layer and then have it converted back to a List in the presentation layer again?
  • Often the same code also works with a List, even if you logically deal with a Set. Are the devs just too lazy to think about it and make the distinction, because it’s comfortable to just use lists everywhere? You hardly ever actively want to remove duplicates, and you also don’t care if there is an (unneeded) order, right? If all you do with the collection is persisting it, iterating it, and check if something is contained, the is no difference?

There is actually a reason why this bothers me. I our current project, we write a lot of tests using Mockito; for a unit test e.g. in the presentation layer you then want to verify that the method under test did call the (mocked out) service layer with exactly the expected parameters.
A typical way to to that is this:

// ... some test code that calls the method under test ... 

// afterwards verify the expected behavior:
MyClass expectedParameter = new MyClass("foo", "bar");

It checks that the passed parameter object has exactly the values foo and bar.
Now, what if the method under test also computes a collection of elements, that is passed to the mocked method as parameter? Let’s say, a collection of user ids:

// ... some test code that calls the method under test ... 

// afterwards verify the expected behavior:
List<Integer> expectedUserIds = Arrays.asList(123, 234, 345);
MyClass expectedParameter = new MyClass("foo", "bar");
verify(myService).doMagic(expectedParameter, expectedUserIds);

See how we unintentionally test the order of the user ids?
In case the method under test calls the service with the List [234, 345, 123], the test will fail, since the given List [123, 234, 345] does not match the actual argument.

I picked user ids as an example, because it’s easy to understand that you usally have a Set in mind: You want to pass all the users that are concerned; there should no user id occur twice, and the order doesn’t matter. Therefore, the Set type would be the better pick for the method parameter; the List probably works, but it forces you to specify the order of the expected elements. If the underlying implementation changes, you will see the test fail and have to adjust it. Or worse, if the method under test calculates the user ids in unpredictable order, the tests will sometimes succeed and sometimes fail without any code change.

Because of this, I would strongly recommend to consistently use Sets whereever a Set is logically what the collection represents, and only use Lists when order or duplicates are required.

On the other hand, if you are already working in a codebase where you have lists anywhere, it’s a tough call. We started to introduce Sets over time, doing it “right” for all the new code, but changing the existing code only where required to make it compile. Since once incoming http-request invokes Controller, Services and Repositories of both legacy and new code, we have a lot of inconsistencies now. A service method may be invoked with a List, converting it to a Set for two further method calls but passing the List to two others. It’s tempting to change those two to Set’s as well on the fly, but they again call others methods and are called by different Controllers, and each of the callers and called methods are covered with tests that specify that there are either Sets or Lists… it’s a mess!

My advice for you: Using Sets the right way is great. But being consistent is nearly as great. When you feel like changing List parameters to Sets where it makes sense, discuss with your team first (or whoever is contributing to your code base). If you have different opinions, don’t start changing the previous style on your own! That just creates chaos.
If you are all in to change, consider to refactor the whole code base (or at least one encapsulated component) in one go. Changing only some methods and leaving others as-is results in chaos as well. So be sure it’s worth it!

On moving to the USA

Hi, friends!

To clarify one thing first: I’m more than happy at my current job! The Volkswagen Digital:Lab is an amazing place for passionate software developers, who want to build and own great products. Lean and agile like a start up, but with the resources and relevance of europes numbe one car manufacturer – nothing more to ask for!

That being said, let me reveal to you my intention to find a job in the USA for 2020. This has nothing to do with my current position; my familie’s dream to spend some years overseas is just bigger than that. As part of by blog I want to document the steps I take to either fullfill or abandon that plan.

Volkswagen Group of America

Of course I’m first looking for a job opportunity within Volkswagen. Since I’m happy here and I also want to come back after a while, why would I want to leave.
Therefore I’m currently collecting information about all the branches of the Volkswagen Group of America (VWGoA) that have software engineering there. One source of information will be my colleagues and their network within the company; but I’ll also use the publicly available information on the internet.

Now, keep in mind that Volkswagen is not one company: Beside the core brand Volkswagen, the group owns well-known car brands like Audi, Porsche, Bentley and others. And like most of the car manufacturers, Volkswagen is also in the business of offering loans for buying their cars; so they have themselfes a bank, too. Long story short: Don’t be surprised if I end up at a branch that is not called Volkswagen but something else, let’s see.

My search for publicly available information lead me to the VWGoA career portal. First reaction: Disappointed about the low number of job openings in software.
At least the listings provide a start to research the locations of Volkswagen in the US:

  • Auburn Hills (near Detroit, Michigan) is the headquarters of VWGoA
  • Chattanooga, Tennessee, is the location of Volkswagen’s only plant in the US, where they build actual cars. No software jobs here.
  • Belmont, California: Not interested right now. My family and me should be able to travel to Germany sometimes and also welcome friends and family at our place. West coast ist just too far from Europe, if I can avoid it…
  • Most intersting hit so far: Herndon, Virginia, near Washington D.C.; the VW Credit Inc. has something called innovation lab there, and they seem to be looking for high profile software engineers there. I need to learn more on that!

I’ll keep you updated on the group internal job search… but this is not my only option.

Job portals

In case there is no fit within the Volkswagen Group, I would also consider to join a new company. In Germany us software engineers are spammed with dozends of job offers on LinkedIn each week, so it’s pretty easy to look out for opportunities without putting a lot effort in it. But the recruiters on LinkedIn cannot know that I’m looking for a job in a totally different timezone – so LinkedIn doesn’t help.

In order to receive job offers for the US without much effort, I created my profile on two platforms: hired.com and therecruiternetwork.com. Both are pretty standard, you put your CV in a bunch of form fields to make your skills and experience machine recognizable. therecruiternetwork requires a CV as a .pdf additionally, so you have to do more work there in case you don’t have a regular up-to-date CV prepared. (There are also differences in American-style CV’s to German-style CV’s, take care.)
On the other hand, that second platform offers you a professional review of your CV for free, which might be interesting – more about that later.

I don’t want to rush the search for external jobs, though. That’s why I decided to make me available to be found by recruiters, but I will not actively search until I know more about the opportunities at Volkswagen.

On Kotlin and Java

Hi, friends!

I already mentioned that Kotlin is my favorite programming language. Even more, although most of my professional experience is in Java and I liked working in that language, I can bluntly say that I would never again choose to work in Java instead of Kotlin.
A lot has been said on this topic by different Kotlin fans. Still my blog would always feel incomplete in the future, if I left this out. So let me shortly present you my reasons:

  1. Kotlin was designed to write very concise code. That means, as a programmer you can very well express your intentions in the code without boilerplate noise, making the code readable and understandable.
  2. Kotlin differentiates between nullable and non-nullable types as a language construct. If you use it correctly, you can write much less error-prone code and save yourself from the ‘billion dollar mistake‘.
  3. The is no reason not to use Kotlin over Java. Kotlin is bidirectonally compatible with any Java code, so you can fully utilize all your Java skills and use all the libraries and frameworks you are already used to. You can even start using Kotlin in an ongoing Java project without converting any existing code. Start to write new classes in Kotlin instead of Java, and convert existing classe sone by one over time once you touch them to make changes anyway. This is possible because Kotlin compiles to the same JVM bytecode as Java. After compiling, there is no difference between classes writen in any of the two languages, and because of the great IDE support for Kotlin, even the context assistance will work perfectly between both.

Of course there are more reasons once you go into details (immutability, standard library), but the listed reasons (1) and (2) already give you a boost of productivity from day one, when you are just making your first steps in Kotlin. And reason (3) invalidates every counter argument I can think of.
Let’s have a closer look at those two claims.

Kotlin code is more concise

Take a typical class in Java, representing player characters in a game:

public class Character {

private String name;
private int level;

public Character (String name, int level){
    this.name = name;
    this.level = level;

public String getName() {
    return this.name;
public void setName(String name) {
    this.name = name;
public int getLevel(){
    return this.level;
public void setLevel(int level){
    this.level = level;

public void levelUp() {
    // some logic here ...


What is the intention of the programmer who wrote this class? Not a lot, right?

  • Having a class called Character that can be instanciated to create all the characters in the game
  • A character has the properties name and level
  • A character has a method levelUp with business logic

If you are a Java developer, the implementation seems pretty straight forward. But look closely! Isn’t there a lot of code that had to be written just because of the way Java works, but that has nothing to do with the programmer’s intention?
Do you spot it?
Let’s write the same class in Kotlin:

class Character(
    var name: String?,
    var level: Int?
) {

fun levelUp() {
    // some logic here


Compare with the listed intentions again. It’s all there!
What’s the difference between the Java implementation and the Kotlin implementation?
In Java you had to read a lot of lines of code and then ignore them to find out which lines actually matter.
In Kotlin there is nothing else than the programmers intention!

How is that possible? In fact, Kotlin is exactly as powerful as Java. Any code you can write in Java is possible to write in Kotlin as well. But in Java, there is a lot of code that is there 90% of the time: The modifier “public” for classes and methods, the modifier “private” for properties, getters and setters, and the initializing constructor. We call this boilerplate code, because you don’t think about it, you just type it in everytime you write a new class.

In Kotlin this boilerplate code is invisible. You don’t have to write it and you don’t have to read it, so you can focus on the interesting code. But it’s still there! The Kotlin compiler will generate all these modifiers and getters and setters into the byte code, which means that the above Java class and the Kotlin class have the exact same byte code as output.
Of course, you can also write custom getters and setters and constructors with some logic; then you have to actually write them, in Kotlin same as in Java.
But since most of the time this code is boilerplate, it’s a huge gain to have it generated by the compiler for the default case.
It works like this:

  • Classes and methods are public and final by default, unless declared otherwise
  • Fields are private and have default getters and setters, unless declared otherwise
  • In the top of the class, you write a constructor as part of the class declaration. Every argument of that constructor beginning with “var” or “val” is a declaration of a field at the same time, and the constructor will assign it’s arguments to the field, just like a default initialization constructor.

Up for a bonus? Let’s create a class Fighter that extends the class Character. First Java:

public class Fighter extends Character {

private final int attack;

public Fighter(String name, int level, int attack) {
    super(name, level);
    this.attack = attack;

public int getAttack() {
    return this.attack;


Now Kotlin:

class Fighter(
    name: String?,
    level: Int,
    val attack: Int : Character (name, level)

What is happening here?

  • In Java, the field “attack” is read-only: There is only a getter, no setter. In Kotlin you achieve the same by using “val” instead of “var”
  • The constructor of Fighter takes the arguments for it’s super class and then calls the constructor of the super class with these values. That’s done in Kotlin by not using val or var in the Fighter’s constructor. The “extends” is expressed by the colon “:”, and the call of the super constructor is expressed in the same line
  • There is nothing left to write into the class body of the Kotlin class. Therefore the class body is just left out, no need to write an empty body like { }

Did I convince you that Kotlin is way more readable, because there is much less noise around the signal in the code?

Nullability in the type system

In Java, every object type can hold a null reference. I large code bases this leads to a lot of code like this:

if (playerCharacter.getName() != null) {
    String initial = playerCharacter.getName().substring(0,1);
    // ... do stuff with the initial

What’s the problem with that code?

  • A lot of null checks in the code base add extra noise and distract from the business logic
  • Missing null checks result in NullPointerExceptions, crashing the application
  • Sometimes you think it’s not possible that a property hold the value null (i.e., the player character should always have a name after it is created). How do you deal with that? If you don’t check for null when using the value, you may make a wrong assumption and produce a bug. But checking for null, just to make sure, leaves the problem that there is no meaningful behavior of the application for that case. What should happen in the “else” there?

To help you out of this misery, Kotlin’s type system distingueshes between nullable and non-nullable variables. Look how we declared the properties of “character” to make it equivalent to the Java implementation:

class Character(
    var name: String?,
    var level: Int

The question mark declares the name as nullable. Since we don’t want to allow null as a value for a name, we just remove that question mark:

class Character(
    var name: String,
    var level: Int

Now the Kotlin compiler will prevent anybody from passing null as the value, and in any calling class we can rely that the name is not null.
On the other side, if we do use nullable types, the compiler will prevent the caller from using the value without handling null.

In my opinion, this feature alone makes it worth to use Kotlin over Java, since it prevents tons of potential bugs.

On classes and objects

Hi, friends!

In a job interview as a junior software developer, I once was asked to explain the difference between classes and objects. Of course, if you are a developer that question is no challenge at all, but actually there are people leaving university with a computer science related degree who have never understand object oriented programming, so I guess the question makes sense to filter out candidates on a very basic level.

When asked, I looked around, pointed at a chair and replied: ” ‘Chair’ is a class, and this specific chair over there is an object and an instance of the class ‘Chair’. The class defines what a chair is…” The answer was good enough to proof that I understood the concept of classes and objects and was therefore accepted, but I have to admit that it’s not the best example to explain classes and objects to somebody who doesn’t get it yet.

Yesterday I realized that there is a pretty obvious example that at least every Gamer will understand immediately (and most IT people have played some games in there life, right?):
“In a game there may be classes like ‘sorcerer’ and ‘fighter’ and ‘rogue’. And then there is your player character, who may be an instance of the class ‘fighter’. The class defines the game rules for all the fighters in the game, for example that fighters have hit points and an attack value. Your player character is only one object, holding the individual values in these properties like 500 hit points, while other fighters in the game may have different values.”
I like this example so much, because this example for classes are actually called classes in the games.

I don’t expect to be asked this question ever again, since I don’T apply for junior positions any more. It’s a pitty, I would love the fact that I talk about sorcerers and fighters in a job interview…

On software architects

Hi, friends!

In times where I think about career a lot, when my brain is idling while I’m waiting for the subway, folding laundry or something, it starts to play future job interviews in my head. One voice is coming up with interview questions, the other tries to find good answers. (It’s not required to be schizophrenic to play this game, but it certainly helps…)

Today I had to deal with the question “What do you think about software architects?”.

This was a tough one. Though I do have a strong opinion on software architects, you don’t always want to answer straight away in a job interview. Of course you should answer honestly, but you can still put a spin on it in one way or the other. You want to sound smart and give a well founded own opinion based on your experience, but you do not want to take the risk of insulting the interviewer by discrediting something he may identify with. In this case, how would I know if the interviewer is an evangelist of lean product development or a proud senior architect?

So this is what I answered (After quicksaving and reloading a couple of times. Yes, that’s possible. We are not playing in Iron Man mode here!):

Given that you have the role of a software architect in your organisation, and it’s more prestigous and better paid than the software developers, every developer wants to become an architect, and your best developers are promoted to be architects pretty soon. That means, you architects are probably very good engineers, and they do a great job making all the big decisions, defining interfaces between components and coming to the rescue if a dev team is in trouble.

Nevertheless, I think it’s not a good idea to have the architect’s role at all, because it’s constantly draining the best developers out of the teams, leaving each team in a state of everlasting inexperience.

If those people stay part of the teams instead and keep coding, they contribute a lot individually and teach the less experienced developers by example, making the whole team way more productive. At the same time, when they make that big decisions, they know more how the system currently works (in code, not on paper and diagrams), so the outcome will be better. Even more, they see if the developers understand and embrace the architectural concepts; that way you avoid that the code becomes very different from the ideas over time.

Now, if the team’s product is quite small, there is not enough big-picture-work for a full architect’s position anyway, so he can easily be a senior developer and take care of architectural decisions when necessary. On the other hand, if your system is that large so that you feel you need a team of architects to maintain the big picture, you’re probably better off to split that system into team-sized microservices that can be developed independently and let the teams figure out interfaces for the nnecessary calls from one system to the other.

I admit that I have this view based on a limited experience: I have seen big teams with big systems fail to coordinate, although there were architects in charge; and I have seen small teams succeed with small, communicating services, leaving architectural decisions to experienced developers in the teams. If you show me a software system which is impossible to build as microservices and it works well to have it designed by architects and built by developers, I’m happy to adapt my opinion.

Me, in my head

There is one more thing though that I have to say about architects, but I left out in my answer: A service company (which is renting out their manpower to build a software project) usually can bill a higher rate for someone called “architect” than for someone called “developer”. For their business, it makes sense to staff a project with as many high-ranked employees as the customer is willing to pay. If the customer is convinced that there should be architects, of course the service company gives the title to someone who else would be a senior developer, or even adds an architect who draws diagrams no developer needs, just to increase the bill.

I strongly dislike it, but from a business perspective it makes sense.

On the 10x programmer

Hi, friends!

Have you ever experienced that? You hear a term for the first time that you hadn’t heard in your life before, and shortly after that you hear the same term again in a totally different context? Crazy coincidence or selective perception?

In the SE-Radio Episode with Jonathan Nithingale that I already blogged about, he mentions a “10-ex-developer” (phonetic). I figured he said “10x” like in “ten times” which should mean a really productive developer. But I wan’t sure, he could also have been talking about some kind of rank or whatever.
Today I read the blog article “The cloud skills shortage and the unemployed army of the certified“, and there is the “10x coder” again!

This time I had a PC in front of me (instead of the steering wheel of my car), so I googled the term immediatly. Unsurprisingly, the “10x” means basicly what we thought – a software developer who is ten times as productive as the worst (professional!) developers.

Now, this is funny, because it’s actually a well-known term; and I had once told my managers as my mid-term career goal “I want to be a developer five times as fast as anyone else and be paid accordingly”, without knowing that other people actually talk about something like this.

Also very interesting was to learn that there is a debate whether the 10x programmer exists, argueing whether the literal factor 10 is possible or not. I expected that “10” was an arbitrary number to figuratively say “way more productive”, what I meant when I said “five times”, but here they are discussing if “ten times more productive” is a thing.
The factor 10 is apparently the result of a study from the 1960s that found:

 They studied professional programmers with an average of 7 years’ experience and found that the ratio of initial coding time between the best and worst programmers was about 20 to 1; the ratio of debugging times over 25 to 1; of program size 5 to 1; and of program execution speed about 10 to 1 .

The data was later adapted and confirmed to be around 10x for the overall productivity.

It’s easy to refuse this and think a single programmer can never produce as much output as 10 other programmers in sum. This seems obvious when you have some kind of manual labor in mind, like a construction worker or a barber; I would believe, even the fastest of them cannot do as much work as ten of their colleagues together, because of physical constraints.
But software development is different, the physical activity is not the limiting factor of productivity.

Here is my own reasoning about this:

  • In a typical software project, after some initial weeks the code base has grown enough that a developer is spending only 20% of his time on writing code and 80% on reading already existing code, in order to figure out who the existing stuff works, where to put in new code and what can be copied or reused and so on.
  • A developer who writes clean code can read and understand his existing code much faster.
  • A developer who understands and applies design patterns and good architecture can understand the existing structure and find the place where to add new code much faster.
  • A developer who writes good automated regression tests will hardly break existing code while adding new stuff, which would lead to time consuming bug reports and debugging sessions. (I have seen tasks with 2 days of implementation work followed by 10 days of bug fixing…)
  • A developer who comes up with a working solution for a problem fastly saves lots of time compared to a developer who doesn’t have a good idea in the beginning and stumbles from try to try until he finds a solution.
  • A developer who fully understands the business requirements and has an instinct for questioning given requirements that are potentially incorrect, can save lots of effort of working in the wrong direction.
  • A developer who is teaching and helping his colleagues to be faster and espacially less blocked, can leverage the productivity of his whole team.

If you have a hard time imagining how someone could do the same job ten times faster than someone else, think in the different direction: Imagine a developer who gets all those things right, and then ask yourself if it sounds reasonable that someone else would take ten times longer when he is not able to fullfill all of these properties?

A very nice article on the 10x programmer with different reasons, but a similar conclusion is this blog post by Nathan Epstein.

I like very much that he ranks the aspect of teaching and enabling as the second most important. And I really love the wording of his top reason, “Strong programmers can take ownership of projects”.
In the past I have sometimes thought about how to put in words why I think I am more productive than some of my coworkers (especially before salary negotiations, performance reviews and applications, you need to prepare to argue what you think you are worth!). Now I realized, this is what I unintentionally end up doing in all the projects I join: I take ownership by identifying the stakeholders needs, coming up with some options, get second opinions and align my team members to deliver a great outcome together.